情報処理安全確保支援士 2024年 秋期 午後 問01

解答の論理構成

1. まず、マルウェアが他ホストへ感染を広げる手口を把握します。図4 の q.ps1 の動作には
   　「h pingコマンドを使ってホストを探索し、RDP接続を試みる。RDP接続に失敗した場合、何もしない。」
   　「i RDP接続に成功すると、接続先で i.ps1 の実行を試みる。」
   　と記載されています。したがって RDP 接続に“成功”したホストだけが感染拡大候補になります。
2. PC-A の time.csv（表3）で RDP 関連ログを確認します。
   　•「12/04 23:32:51　PC-Aから PC-Cに、.¥administratorで、RDP 接続が許可された。」
   　この行は唯一 “許可された”＝成功した RDP 接続です。
3. 同じ時間帯の他ホストへの RDP は軒並み失敗しています。例えば
   　「12/04 23:32:05　PC-Aから PC-Bに、ad01¥user019で、RDP 接続が失敗した。」
   　「12/04 23:35:17　PC-Aから PC-Dに、.¥administratorで、RDP 接続が失敗した。」
   　などであり、成功していません。
4. よって、マルウェアが“感染拡大のために RDP 接続に成功した唯一のホスト”は「PC-C」です。
5. 図3 の追加調査 1 の文章は
   　「表3から、PC-Aからaにマルウェア感染が拡大している可能性があると考えられるので、aについて PC-A と同様の調査を行う。」
   　とあり、a には上記で判明したホスト名を入れる必要があります。

誤りやすいポイント

• 「成功した RDP が 1 回だけなので見落としやすい」
  失敗ログの量が多く、成功ログが 1 行だけなので読み飛ばしがちです。
• 「ドメインアカウントとローカル administrator を混同する」
  ad01¥user019 で失敗し、.¥administrator で成功している点からマルウェアが窃取したローカル資格情報を用いたと分かります。
• 「通信量の大小で感染先を推定してしまう」
  net2.csv やプロキシログの通信量ではなく、RDP 成功可否が決定的根拠です。

FAQ

解答の論理構成

1. 追加調査の目的
   問題文では「PC-A及びa上のファイルのほか、b上のファイルのうち、アカウントcでアクセス可能なファイルがインターネットに送信されているおそれがある」と記載されています。つまり、bには「インターネット送信の対象になり得る共有ファイルを保管している社内ホスト名」が入るはずです。
2. ファイルを保管しているホストの特定
   表1の記述を引用すると、
   • 「ファイルサーバ … ホスト名は filesv である。」
     また、PC-A の time.csv（表3）にも
   • 「12/04 22:42:06 ¥¥filesvのファイルが参照された。」
     と明記されています。
     これらの情報から、社内の共有ファイルを保持しているのはファイルサーバ「filesv」であることが分かります。
3. インシデントとの関連
   図4の解析結果では q.ps1 が「特定のディスク領域とネットワークドライブのファイルをRAR形式でアーカイブファイルにまとめ、https://△△△.com/v/upl を使ってアップロードする。」とあります。ネットワークドライブとはファイルサーバへの共有フォルダを指すため、外部送信のリスクがあるのは「filesv」のファイルです。
4. 結論
   上記より、bに入るホスト名は「filesv」となります。

誤りやすいポイント

• 「PC-A が参照した D ドライブ」を b と誤解する
  → time.csv にはローカル D ドライブ参照もありますが、問題文では「インターネットに送信されているおそれがある共有ファイル」を問うているため不適切です。
• 「ドメインサーバ ad01」と混同する
  → ドメインサーバは認証情報を持ちますが、設計書や顧客情報などの社外秘ファイルを保管しているのはファイルサーバです。
• 「PC-C」や他の仮想 PC と取り違える
  → PC-C は感染拡大先候補 (a) であり、共有ファイルの保管先ではありません。

FAQ

解答の論理構成

• 【問題文】では、暫定対策として「ドメインサーバでアカウントcのdを行う。」と記載されています。
• どのアカウントを停止すべきかは、マルウェアが通信や横展開に用いているアカウントを特定することで判断できます。
• 表5「プロキシサービスの通信ログ」の全行において利用者IDが“ad01¥user019”と記録されています。
  • 例：12/04 22:12:28 ad01¥user019 https://○○search.com/ 443 許可 1.0
  • 例：12/06 01:34:04 ad01¥user019 https://○○○.com/ 443 許可 0.1
• 表3「PC-A の time.csv」にも、RDP接続を試みた際の失敗・成功ログが“ad01¥user019”で多数残っています。
  • 例：12/04 23:32:05 PC-Aから PC-Bに、ad01¥user019で、RDP 接続が失敗した。
  • 例：12/04 23:35:36 PC-Aから PC-Eに、ad01¥user019で、RDP 接続が失敗した。
• よって、攻撃者が主に用いたアカウントは“ad01¥user019”であると断定できます。
• これをドメインサーバ側で無効化（d）することで、
  1. 追加のコネクトバック通信
  2. 他ホストへのRDP横展開
  3. ファイルの不正送信
     を直ちに封じ込める効果が期待できます。
• 以上により、cには“ad01¥user019”を入れるのが妥当です。

誤りやすいポイント

• “.¥administrator”やローカル管理者を選んでしまう
  • 表3には“PC-Aから PC-Bに、.¥administratorで、RDP 接続が失敗した。”という行が複数ありますが、成功したのはたった1回であり、主要な活動は“ad01¥user019”です。
• ログの「利用者ID」欄を見落とす
  • Proxyログはマルウェアの通信主体を特定する重要な証拠です。表5全行に同じIDが記録されている点を必ず確認する必要があります。
• “user019”のみを記載してしまう
  • ドメイン名“ad01”を含めた“ad01¥user019”が完全な識別子です。ドメイン部分を省略すると別アカウントと誤認されるおそれがあります。

FAQ

解答の論理構成

1. まず【問題文】では、 「暫定対策 1　マルウェア感染拡大とこれ以上のファイルの送信を防ぐために、ドメインサーバでアカウントcのdを行う。」
   と明示され、アカウントに対して何らかの操作を実施する必要があると示しています。
2. 同じ段落で、攻撃者がすでに「PC-A及びa上のファイルのほか、b上のファイルのうち、アカウントcでアクセス可能なファイル」を送信したおそれがあると説明されており、cアカウントの侵害が濃厚であることがわかります。
3. 侵害済みアカウントを使ったさらなる通信・横展開を直ちに止める最も確実な方法は、そのアカウント自体を無効化（Disabled）することです。削除・パスワード変更では認証情報が残留または再窃取されるリスクが残りますが、無効化ならログオン自体ができなくなり、インシデントの被害拡大を防ぎやすくなります。
4. 以上より、dには「無効化」が入るのが妥当であり、模範解答も
   d：無効化
   と示されています。

誤りやすいポイント

• 「パスワード変更」と答えてしまう
  侵害元がパスワードハッシュを窃取している可能性が【図4】「g パスワード又はパスワードハッシュをPCのメモリ上から窃取する。」で示唆されています。変更しても再窃取される懸念が残ります。
• 「削除」と答えてしまう
  アカウントを削除すると復旧作業で必要な権限の追跡が困難になります。まずは利用不能にする「無効化」が一般的です。
• 「ロックアウト」と混同
  ログオン試行回数によるロックアウトは自動解除の設定がある場合があり、一時的措置に留まります。意図的かつ恒久的な停止を示す「無効化」とは異なります。

FAQ

解答の論理構成

• 【問題文】の「暫定対策 2　ファイルの送信を防ぐために、①プロキシサービスで対策を行う。」が設問対象です。
• プロキシサービスの機能として、【表1】に「“管理者拒否リスト：管理者が設定できる。アクセスが拒否される URL のリストである。”」と明記されています。よって“通信を遮断する”方法はリスト登録です。
• マルウェアが利用した URL は次の三つであることが各種ログと解析結果から分かります。
  • 【表5】「12/04 22:20:34 … https://△△△.com/i.ps1」
  • 【図4】【q.ps1 の動作】「(e) 1時間おきに https://〇〇〇.com/ にコネクトバック通信」
  • 【図4】【q.ps1 の動作】「(f) … https://□□□.com/ にコネクトバック通信」
• 以上より、すべてのドメインユーザがこれら三つの URL へアクセスできないよう「管理者拒否リスト」に登録することが、ファイル送信を防止する最も直接的かつ即効性のある対策になります。

誤りやすいポイント

• 「管理者許可リスト」に“拒否”したい URL を登録してしまう
• PC-A のみ、あるいは該当ユーザのみを対象に設定し、他ユーザを見落とす
• ドメイン名の前後に誤ってワイルドカードやパスを付け、別のホスト名を許可してしまう
• FW や L3SW の ACL で遮断しようとして、HTTPS 復号ができず実質的に防げないパターン

FAQ

解答の論理構成

1. 図3の下線②には
   「プロキシサービスのログで、PC-A、aのほかに②マルウェアに感染している社内ホストがないか調査を行う」
   と書かれています。したがって“調査の内容”＝「どのような通信を指標にしてマルウェア感染ホストを洗い出すか」を具体化する必要があります。
2. マルウェアが行う代表的な通信は、C社解析結果（図4）の
   「e 1時間おきに https://〇〇〇.com/ にコネクトバック通信をする。」
   「f …失敗した場合は、https://□□□.com/ にコネクトバック通信をし、以降は、1時間おきに https://□□□.com/ にコネクトバック通信をする。」
   で判明します。
3. さらに、PC-A の感染経路としてプロキシログ（表5）に
   「12/04 22:20:34 … https://△△△.com/i.ps1」
   「12/04 22:33:25 … https://△△△.com/v/q.ps1」
   などのダウンロード通信が残っています。よって
   ・初期侵入／追加モジュールの入手：https://△△△.com/
   ・C&C（コネクトバック）：https://〇〇〇.com/、https://□□□.com/
   が IOC（Indicator of Compromise）として明確です。
4. ②の調査は「PC-A と a 以外の L 社内ホストで、上記 3 つのドメインに対する通信が無いか」をプロキシサービスの通信ログから横串検索することになります。
5. 以上をまとめると模範解答どおり
   「https://○○○.com/、https://△△△.com/又はhttps://□□□.com/に通信したL社内ホストがないか調査する。」
   が論理的に導かれます。

誤りやすいポイント

• 解析結果にない https://△△△.com/ を見落とし、C&C ドメインだけを調べてしまう。
• プロキシログではなく DNS ログなど別ソースを想定し、設問の「プロキシサービスのログ」を外してしまう。
• 「PC-A、a を除く」という条件を忘れ、既に感染が判明しているホストまで含めて列挙してしまう。

FAQ

解答の論理構成

1. 追加調査の目的
   【問題文】には「Yさんは③追加調査の3として、L社内ホストの全てに対して新たな調査を行う必要がある」とあり、すでに実施済みの追加調査1・2では“見逃したおそれ”が残っていると示されています。
2. “見逃したおそれ”の根拠
   図4の解析結果より、i.ps1 は「a タスクを登録する。…・タスク名：install」と明記され、さらに「i RDP接続に成功すると、接続先でi.ps1の実行を試みる。」とあります。つまり、RDPで横展開が成功した端末にも同じ “タスク名：install” が自動生成される仕組みです。
3. 時系列ログでの実例
   PC-A の time.csv には「12/04 22:33:21 “タスク名：install” が登録された。」という実記録が存在します。したがって他の端末でも同一タスクが登録されていれば、感染・横展開が成立した可能性が高いと推測できます。
4. 調査対象の具体化
   ②までの調査はPC-AとRDP先候補の限定チェックでしたが、横展開成功時にタスクが残る特徴を利用すれば、全L社内ホストで“install”タスクの有無を検索することで感染端末を網羅的に洗い出せます。
5. 結論
   以上より、③で実施すべき具体的な調査内容は「タスク名がinstallであるタスクが登録されているL社内ホストがないかを調べる」こととなります。

誤りやすいポイント

• “install” という文字列だけをファイル名と思い込み、スクリプトファイルや実行ファイルを検索対象にしてしまう。タスクスケジューラのエントリを確認する必要があります。
• PC-A 以外の端末で q.ps1 の通信ログや powershell.exe の通信量だけを手掛かりにしようとすると、リトライ失敗などで通信が発生しないケースを見落とします。永続化の痕跡（タスク登録）を探すことが本質です。
• ドメインサーバやサーバ系ホストを除外してしまうミス。i.ps1 は “RDP接続に成功すると、接続先でi.ps1の実行を試みる。” ため、全ホストが調査対象に入ります。

FAQ

解答の論理構成

1. マルウェアが行う代表的な二つの挙動を把握
   図4「q.ps1 の動作」に、 ・「c マルウェア対策ソフトを停止する。」
   ・「h pingコマンドを使ってホストを探索し、RDP接続を試みる。」
   と明記されています。したがって、マルウェアの活動を自動検出するには、 (A) マルウェア対策ソフトが停止された端末の発見
   (B) 異常に多い RDP 接続試行を行う端末の発見
   の二系統の監視が必要です。
2. (A) を実現する社内リソースの確認
   表1「マルウェア対策サービス」には
   「管理用の Web ページから、…マルウェア対策ソフトの稼働状況の確認…ができる。」
   とあり、さらに「マルウェアが検知されたときは、情シス部にアラートメールが送付される。」とも記載されています。
   稼働状況を常時収集しているこのサービスのログを用いれば、「VSCAN_SVC [ 1 ] が停止された。」（表3）と同種のイベントを即時に検出できます。
3. (B) を実現する社内リソースの確認
   表1「ドメインサーバ」では「…ログオンする際の利用者認証に利用される。」と説明されており、図4 h に対応する多数の RDP 失敗ログ（表3 23:31:15 〜 23:37:54）が auth.csv に残っています。ドメインサーバ上の認証ログは中央集約されているため、ここを監査すれば RDP 接続を繰り返す端末を網羅的に検出できます。
4. 以上より、下線④で求められる「自動検出の仕組み」は以下の二つとなります。
   ①「マルウェア対策サービス」のログを用いて、マルウェア対策ソフトが停止した L 社内ホストを検出する。
   ②「ドメインサーバ」のログを用いて、RDP 接続をくり返している L 社内ホストを検出する。

誤りやすいポイント

• 「サービス停止」は Windows イベントログだけでなく SaaS 側の「マルウェア対策サービス」ログを使う点を見落とす。
• RDP の失敗監視を各 PC で個別に行うと考え、集中管理できる「ドメインサーバ」ログを使う発想に至らない。
• 図4 e～f のコネクトバック通信ばかりに注目し、内部横展開（h）や防御無効化（c）の重要性を軽視する。

FAQ

解答の論理構成

1. マルウェアの横展開手法の把握
   • 図4の q.ps1 の動作に「h pingコマンドを使ってホストを探索し、RDP接続を試みる。」および「i RDP接続に成功すると、接続先でi.ps1の実行を試みる。」とある。
   • 表3にも「PC-Aから PC-Bに、.¥administratorで、RDP 接続が失敗した。」など RDP 試行の痕跡が多数記録されている。
   • したがって攻撃者は RDP を用いた横展開を試みていると判断できる。
2. 横展開を阻止する技術的対策（e）
   • 一般的に RDP での横展開を防ぐには「不要な RDP を無効化」「二要素認証」「接続元制限」などが有効。
   • 本社では情シス部が保守目的で RDP を使用するため完全停止は難しいが、アクセス元を保守用 PC などに限定することは可能。
   • よって「仮想PCへのRDP接続に対して、IPアドレスによる接続元制限を行う」が妥当。
3. 機密ファイルの持ち出し手口の把握
   • 図4の q.ps1 の動作に「d 特定のディスク領域とネットワークドライブのファイルをRAR形式でアーカイブファイルにまとめ、https://△△△.com/v/upl を使ってアップロードする。」と明示されている。
   • 表5でも「12/04 23:00:05 … https://△△△.com/v/upl … 送受信量 511.0Mバイト」と大量通信が確認できる。
4. データ持ち出しを阻止する技術的対策（f）
   • ファイルの不正アップロードを検知・遮断する代表的手法は DLP（Data Loss Prevention）。
   • DLP を導入し、機密情報や大容量アーカイブの外部送信を検出・ブロックする設定を行えば同様の事象を防止できる。
   • よって「L社内にDLPを導入し、ファイルの持ち出しを制限する」が適切。

誤りやすいポイント

• 「RDPそのものを禁止」と書いてしまう
  → 保守用途で必要なため完全禁止は非現実的。接続元制限まで踏み込むのがポイントです。
• 「ファイアウォールのポート遮断」だけを答える
  → 具体的に RDP (TCP 3389) を対象にし、かつ IP 制限であることを示さないと部分点止まりになりやすいです。
• 「暗号化通信監視」や「HTTPSプロキシ強化」でデータ流出対策とする
  → 今回はファイル自体の持ち出しを制御する DLP が適切。プロキシ強化だけでは ZIP/RAR の判定が難しい場合があります。

FAQ