情報処理安全確保支援士 2019年 秋期 午後1 問02

解答の論理構成

1. 図3‐B‐(う)より
   「マルウェアPは…HTTPによる通信を試みたが、①当該通信はZ社のネットワーク環境によって遮断されていたことがプロキシサーバのログに記録されていた。」
   ──遮断した主体はプロキシサーバであると読み取れます。
2. 表2‐(c) プロキシサーバの詳細に
   「PCからインターネットにアクセスするためには利用者IDとパスワードによるBASIC認証…を必須としている。」
   とあり、認証なしの通信はプロキシが拒否します。
3. 同じく表2‐(a) PCのWebブラウザ設定に
   「インターネットへの通信は全てプロキシサーバを経由するように設定され…」
   とあり、マルウェアのHTTP通信も例外なくプロキシ経由になります。
4. 攻撃グループXのマルウェアは人間の入力を伴わない自動通信であり、利用者IDとパスワードを送出していないと推定できます。
5. したがって、プロキシサーバで「BASIC認証に失敗」→HTTP要求を拒否→通信遮断、という流れになります。
6. 以上より、下線①が示す遮断理由は
   「プロキシ認証に失敗したから」
   となります。

誤りやすいポイント

• FWのフィルタリングルールで拒否されたと誤解する
  （HTTPは表1‐項番5で「許可」されているためFWではなくプロキシが拒否）
• プロキシサーバがダウンしていたと考える
  （図では「ログに記録されていた」とあるので稼働中）
• マルウェアがDNS通信に切り替えた可能性を理由に挙げる
  （DNS通信はそもそも発生していないと図3‐Dが否定）

FAQ

解答の論理構成

1. 図3の記述
   • 「パブリックDNSサービスLに対してDNSプロトコルによる通信が発生すれば、aのログに記録される。」
     ⇒ a は “DNS通信を外部に流す経路上で必ずログを取得する機器” であると分かります。
2. EDRでは記録できない
   • 同じ文中に「Z社が導入しているEDRでは、DNSプロトコルによる通信を記録しない設定」と明記されています。
     ⇒ クライアント側（(a) PC）ではDNS通信のログが得られないため、ネットワーク側の機器が対象になります。
3. 該当する機器の候補を表2で確認
   • (b) FW：「ステートフルパケットインスペクション型のFWである。」取得ログは「動作ログ」。
   • (c) プロキシサーバ：HTTP/HTTPSを中継し、取得ログは「アクセスログ」「認証結果」。DNSは対象外。
   • (d) 外部DNSサーバ：取得ログ「なし」。
   • (g) 内部DNSサーバ：取得ログ「なし」。
     ⇒ DNSクエリを通過させ、かつログを残すのは (b) FWだけです。
4. FWルールとの整合
   • 表1ルール「3：送信元 全て → 宛先 インターネット／サービスDNS／動作 許可」
     ⇒ PCからパブリックDNSサービスLへのDNS通信はFWを経由し、許可・記録される仕組みです。
5. 以上より a にはFWが入る。
   • 解答：表2中の (b)

誤りやすいポイント

• プロキシサーバはHTTP/HTTPSのみを中継するためDNSログは残らない点を見落としやすい。
• 「外部DNSサーバ (d)」を選びたくなるが、表2に「取得ログ：なし」とある。ログ要件を満たさない。
• 内部DNSサーバ (g) は社内向け権威DNSであり、パブリックDNSサービスLへの問い合わせ経路に含まれない。

FAQ

解答の論理構成

1. 攻撃グループの情報
   【問題文】図2 E(う) に「C&C通信には、HTTP又はDNSプロトコルを使用する。」とあります。したがってマルウェアが情報を外部へ送出する際は、①HTTPでC&Cサーバ（＝「グローバルIPアドレスM」）へ、②DNSで「パブリックDNSサービスL」へ通信が発生します。
2. Z社の実際の調査結果
   図3 B(う)・E(う) では「HTTPによる通信を試みたが…遮断されていた」と記録され、図3 Dでは「パブリックDNSサービスL…該当する通信がなかった」と確認されています。つまり現状は失敗していることが分かります。
3. “成功”の痕跡がどこに残るか
   ・HTTP経路が成功すれば「グローバルIPアドレスMへのHTTP通信成功のログ」がプロキシサーバに残るはずです。
   ・DNS経路が成功すれば「パブリックDNSサービスLへのDNS通信成功のログ」がFWまたはDNS関連ログに残るはずです。
4. したがって、質問②に対する「情報持ち出しが成功した可能性が高い痕跡」は上記2点となります。

誤りやすいポイント

• 「遮断されたログ」を痕跡と誤解する
  成功／失敗を示すフラグを読み違えると減点になります。
• 内部DNSサーバへの問い合わせを選んでしまう
  図2 E(う) に「攻撃対象となる組織が管理するDNSサーバを経由して…事例は報告されていない」と明示されています。
• HTTP成功ログの宛先を “汎用検索サービスA” と書くミス
  C&Cサーバは「グローバルIPアドレスM」であることを押さえましょう。

FAQ

解答の論理構成

1. 共有情報の目的
   ISACには「他社がEDRなどセキュリティ対策ソフトウェア又はセキュリティ機器を用いて感染端末を検出する際に有効」な手掛かりを渡すことが求められています。したがって、 ・ネットワーク監視で一致を確認できる情報
   ・エンドポイント検索で痕跡を素早く絞り込める情報
   が最適です。
2. ネットワーク監視に有効な手掛かり
   本文中に
   「マルウェアPは、汎用検索サービスA及びグローバルIPアドレスMへのHTTPによる通信を試みた」
   「マルウェアRは、汎用検索サービスA及びグローバルIPアドレスMへのHTTPによる通信を試みた」
   とあります。
   C&C通信先となる「グローバルIPアドレスM」はFWやプロキシ、IDS/IPSのブラックリスト登録・相関分析に直接利用できるため、解答群「イ：マルウェアPとマルウェアRがHTTPによる通信を試みたグローバルIPアドレスM」が該当します。
3. エンドポイント検索に有効な手掛かり
   本文中に
   「マルウェアPは … PC-VのローカルストレージのフォルダNに配置されていた」
   「PC-TのローカルストレージのフォルダNにbV6fZq3hi.exeというファイルが配置され」
   とあります。
   フォルダ位置はエンドポイント横断検索（EDRのパス検索、ファイル監査）で“感染の可能性が高い保管場所”を簡単にフィルタリングできるため、解答群「ウ：マルウェアPとマルウェアRが配置されていたフォルダNのパス名」が該当します。
4. 採用しなかった選択肢
   ・ファイル名（オ・キ）は本文に「同じマルウェアを攻撃対象ごとにファイル名だけ変更して送付することもある」とあり、検出信頼度が低い。
   ・感染日時や端末のプライベートIPアドレス（ア・エ・カ）は他社の環境では一致せず検知に生かせない。

誤りやすいポイント

• ファイル名だけで検知できると誤解する
  → 問題文E)(あ) のとおり攻撃対象ごとに「ファイル名を変更」する手口が明示されています。
• 社内端末のプライベートIPアドレスを外部に共有してしまう
  → 他社では無関係で検知ロジックに組み込めないため無意味です。
• 感染日時をIOCと勘違い
  → 日時は環境固有で再利用不能、共有価値はありません。

FAQ

解答の論理構成

• 図4には
  「ディジタル署名が付与されていない実行ファイルからの通信をEDRで遮断する。」
  「Z社の業務で利用しているソフトウェアの実行ファイル（以下、正規実行ファイルという）には、ソフトウェア開発会社がディジタル署名を付与するか、自社で付与することができる。」
  「④デジタル署名を検証すれば、正規実行ファイルか否かを判定できる。」
  と記載されています。ここで検証対象は「実行ファイル」です。
• 実行ファイルに付与するディジタル署名は、ソフトウェアに対して発行される証明書でなければなりません。
• 解答群を機能別に整理すると
  ・「ア：S/MIME証明書」＝メール署名／暗号化用
  ・「イ：TLSクライアント証明書」＝クライアント認証用
  ・「ウ：TLSサーバ証明書」＝サーバ認証用
  ・「エ：コードサイニング証明書」＝プログラム（コード）署名用
  となり、実行ファイルの真正性を保証できるのは「エ：コードサイニング証明書」です。
• したがって、④に用いる証明書の正解は
  「エ：コードサイニング証明書」 となります。

誤りやすいポイント

• 「TLSサーバ証明書は“https通信を扱う＝安全”だからディジタル署名にも使える」と早合点する。TLSサーバ証明書は通信路の暗号化とサーバ認証が目的であり、実行ファイルの署名には流用できません。
• 「S/MIME証明書もディジタル署名と付くので万能」と思い込む。S/MIMEはメール本文・添付ファイルの署名／暗号化専用であり、OSが実行ファイルを検証する仕組み（Authenticodeなど）とは連携しません。
• 「クライアント証明書は端末を識別するからプログラムにも使えるのでは」と混同する。クライアント証明書は端末やユーザを認証するためのもので、コード署名用ではありません。

FAQ

解答の論理構成

1. 【問題文】表3項番1には
   「マルウェアが⑤プロキシ認証情報を窃取して、プロキシ認証を突破し、C&C通信を行う。」
   とあり、設問は「プロキシ認証情報の窃取に使用できない攻撃手法」を問うています。
2. プロキシ認証情報とは、プロキシサーバで行う「BASIC認証」に用いる「利用者IDとパスワード」のペア（表2 (c) の説明）です。したがって“窃取手法”としては
   • 利用者が入力するID/パスワードを覗き見る
   • 端末内に保存されたID/パスワードを盗み出す
   • 通信路を盗聴してID/パスワードを取得する
   ‥‥などが典型です。
3. 解答群を検討します。
   • ア「Webブラウザのオートコンプリート情報の窃取」：端末に保存された資格情報を盗む攻撃であり可能。
   • イ「キーロガーによる攻撃」：入力中のID/パスワードを記録でき、可能。
   • エ「総当たり攻撃」：ID/パスワードを推測して繰り返し試行する手法であり、窃取を目的として成立。
   • オ「偽のBASIC認証入力フォームの表示とそのフォームへの利用者の誘導」：フィッシングにより直接資格情報を入力させ、可能。
   • カ「ネットワーク盗聴」：平文のBASIC認証は通信路で容易に取得でき、可能。
   • ウ「ゴールデンチケットの窃取」：Kerberos認証プロトコルにおける特権チケット（TGT）の偽造・窃取で、Active Directoryの支配や横展開に使われる攻撃です。KerberosとBASIC認証は別物であり、プロキシ認証情報（利用者ID・パスワード）を直接得る手法ではありません。
4. 以上より、設問条件「使用できない攻撃手法」に該当するのは
   「ウ：ゴールデンチケットの窃取」 です。

誤りやすいポイント

• 「総当たり攻撃」は“窃取”ではなく“推測”だから不可と誤解する例。窃取手段の一つとして成立します。
• 「ネットワーク盗聴」はHTTPSなら不可と早合点する例。本件はBASIC認証であり平文転送が前提です。
• 「ゴールデンチケット」が高権限を得る攻撃なので万能だと考え、“資格情報が取れそう”と誤答するケース。

FAQ

解答の導き方

• 項番1は「送信元：オフィスセグメント、宛先：DMZ … 許可」だが、今回のパケットの宛先はインターネットなので項番1は一致しない。
• 項番2も宛先が内部サーバセグメントであり一致しない。
• そこで項番3に到達し、現状の「送信元：全て、宛先：インターネット、サービス：DNS、動作：許可」が一致すると通信が許可されてしまう。

誤りやすいポイント

• 「表1の項番1にある 'DNS' を見て項番1を変更すればよい」と考える誤り：項番1は宛先がDMZの通信に対するルールであり、端末が宛先をインターネット（パブリックDNSのIP）にした場合は一致しない。宛先の違いを見落とすと遮断できない。
• ルール適用の順序（先に一致したルールが適用される）を無視する誤り：上から順に評価されるため、どの項番が実際にパケットに適用されるかを順に検証する必要がある。
• 「項番3を単に '拒否' にする」誤り：DMZ内の公開Webサーバやプロキシ、外部DNSサーバが正当にインターネットの名前解決を行う必要があるため、全体を拒否すると業務影響が出る。
• DNS以外のチャネル（DoH/DoTやHTTPプロキシ経由のC&C）を考慮しない誤り：今回の変更はDNSプロトコル（ポート53）ベースの手法に対するものであり、他の手法は別途対策が必要。

FAQ

解答の論理構成

1. 攻撃者が用意するサーバの役割
   • 【問題文 表3】には
     「攻撃者は、あらかじめ攻撃用ドメインを取得し、bをC&Cサーバとして、インターネット上に用意しておく。」
     とあります。
   • 攻撃用ドメインの権限を持ち、DNSの応答を自由に操作できるサーバは「権威DNSサーバ」です。したがって
     → b：権威DNSサーバ
2. マルウェアが最初に問い合わせる社内のDNS
   • 同じく【問題文 表3】
     「マルウェアが、cに攻撃用ドメインについてのdを送信すると…」
   • 図1のネットワーク構成では、PCから外部への名前解決はDMZ内の「外部DNSサーバ」がフルサービスリゾルバとして担当します。
     また、【図1注¹】では「外部DNSサーバは…フルサービスリゾルバとして機能する。」と説明されています。
   • よってマルウェアがまず問い合わせるのは社内DMZの「外部DNSサーバ」です。
     → c：外部DNSサーバ
3. 問い合わせの種類とその対比
   • 【問題文 表3】には
     「…cがC&Cサーバに非dを送信する。」
     とあります。前段でマルウェアは d を送信し、後段で c が「非d」を送るという対比が示されています。
   • 再帰的クエリ⇔非再帰的クエリというセットがDNSでは対応語です。
   • PC（マルウェア）がフルリゾルバに送るのは「再帰的クエリ」であり、フルリゾルバが権威サーバに送るのは「非再帰的クエリ」です。
     → d：再帰的クエリ

誤りやすいポイント

• 図1の「内部DNSサーバ」を選んでしまう
  PCから外部名を引くときは「外部DNSサーバ」が使用される点を見落としやすいです。
• 「再帰的問い合わせ」と「再帰的クエリ」の表記ゆれ
  用語は【問題文 表3】の文言と一致させる必要があります。
• 「権威DNSサーバ」と「フルサービスリゾルバ」の混同
  前者はドメインを管理するサーバ、後者は再帰検索を行うサーバで役割が異なります。

FAQ

解答の論理構成

1. 【問題文】の表3で、DNSを使うC&C手法について
   「大量の情報を持ち出す場合、次の特徴が現れる。
   ・長いホスト名をもつDNSクエリの発生
   ・e」
   と記載されています。
2. その直前には、攻撃者が事前に取得した「攻撃用ドメイン」を介し、マルウェアがDNSクエリを送信すると説明されています。つまり、情報を細切れにエンコードしたクエリを“同じ攻撃用ドメイン”へ繰り返し送ることでデータを外部へ流出させる方式です。
3. したがって、大量に持ち出すとクエリ数が増加し、しかも宛先ドメインは固定されます。
4. 以上から e には「特定のドメインに対する多数のDNSクエリの発生」が入ると論理的に導けます。

誤りやすいポイント

• 「DNS応答が大きくなる」と考えてしまう。実際には分割済みデータをクエリ側に埋め込むため、応答サイズより“クエリ数”が顕著です。
• 複数のドメインが使われると誤解する。攻撃用に取得したドメインは通常1つで、そこに集中する点が特徴になります。
• UDP 53トラフィック総量だけを見ること。多数の小さいクエリは総量が目立たず、件数分析が必要です。

FAQ