本ページは広告が含まれています。気になる広告をクリック頂けますと、サーバ運営費になります(^^
※本記事は実際のインシデント対応の一次情報をもとにしていますが、組織・個人が特定されないよう、ホスト名・IPアドレス・ハッシュ値・マルウェア名・日付などはすべて一般化・改変しています。一部の使用ツール（Claude Code / Chrome拡張 など）は、再現性のため実名で記載しています。
おわりに — 「これ、まずいウィルス入ってないか？」から始まった
きっかけは、ごく軽い気持ちだった。Claude の Chrome拡張で、EDR のログ画面を読ませてみたのだ。すると、「これは少しまずいマルウェアが入っている可能性がある」という指摘が返ってきた。
私はセキュリティの専任エンジニアではない。それでも最終的には、
- どうやって侵入されたか（初期感染の経路と手口）
- 何が、どれだけ流出したか（被害の定量評価）
- 他の端末・サーバに広がっていないか（横展開の有無）
- 今後どう守るか（恒久対策）
ここまでを、短時間で・かつ根拠（一次ログ）付きで結論づけることができた。
正直に言う。これは Claude Code とブラウザ拡張がなければ、絶対に到達できなかった。本記事は「すごいツールの宣伝」ではなく、ネットワークに多少の心得がある人間が、AI と二人三脚で本気のフォレンジックをやるとどうなるか、という体験の記録だ。
1. 最初にやったのは「解析」ではなく「封じ込め」だった
EDRのログから「まずい」と分かった瞬間、真っ先にやったのは解析ではない。感染が判明した端末を即座にネットワークから物理的に遮断することだった。
インシデント対応の鉄則は、まずラテラルムーブメント（横展開）を止めること。1台の感染が分かったとき、本当に怖いのは「その1台」ではなく「他にも感染端末がないか、どこまで広がっているか」だ。これを早く知ることが急務だった。
そこで私は、その端末の解析を Claude Code に依頼した。すると Claude Code は、いきなり答えを出すのではなく——「その判断のためには、どのログファイルが必要か」を逆に聞いてきた。
これが転機だった。「AIにこんな進め方ができるのか」と気づいたのだ。
2. Claude Code が「必要なログ」を指示し、私が集める
ここからの進め方は、私が想像していたAIの使い方とまるで違った。
- 私が
CLAUDE.mdのような仕様書を書いて渡す、のではない。 - Claude Code が「次はこのログが要る」と指示 → 私がそれを収集して渡す → さらに次の指示、というキャッチボールだった。
最初は感染端末のイベントログから始まり、「ブラウザ履歴も見たい」「Prefetch を」「$MFT を」「SRUM を」……と、Claude Code の求めに応じて後から後から証拠を足していった。横展開の懸念があったから、対象は1台に留まらず、関連するサーバ類のログも次々に追加していった。
形式はバラバラ（EVTX / SQLite / バイナリ / ESE DB / テキスト）だったが、私はその開き方を知らなくてよかった。Claude Code が、
- イベントログ：
python-evtxで XML 化 → プロセス作成(4688)・サービス登録(7045)・Defender無効化(5001/5004)・ログ消去(1102) を抽出 - ブラウザ履歴：SQLite を読み、WebKitタイムスタンプを変換してダウンロード元URLを時系列化
- Prefetch：不審実行ファイルの初回実行時刻・実行回数を特定
- $MFT：ファイル作成痕跡から「持ち出し用の集約物があるか」を検証
- SRUM：
dissect.esedbでアプリ別の送受信バイト数 → 流出量を推定
を、必要なパーサをその場で導入しながら自動で進めてくれた。「この形式どう開くの？」を私が悩む場面は、ほぼなかった。
鵜呑みにはしない — 人間が反証する
ただし、AIは時に断定しすぎる。だから出てきた結論には、必ず 「その根拠の一次ログはどれ？」「別の解釈は？」 と問い返した。実際これが効いた例があり、あるIPを当初「2台目のC2」と疑ったが、突き詰めると DNSフィルタのブロック応答（シンクホール） だと判明し、結論を訂正できた。AIに分析させ、人間が反証する——この往復が精度を担保した。
3. 「伝達役は私」— Chrome拡張 × 業務用FW × Claude Code の三者対話
横展開の有無を確かめるには、ネットワーク境界の業務用FW（ファイアウォール）を調べる必要があった。だが管理画面（Web UI）はローカルのブラウザの中。Claude Code から直接は触れられない。
そこで、こんな形になった——
- 何を確認すべきか・どう操作すべきかのプロンプトは、Claude Code が考えてくれる
- 私はそれを Claude の Chrome拡張に渡し、業務用FW の管理画面・ログ・設定を読ませる/操作する
- 拡張が取り出した結果を、私が Claude Code に返す
- Claude Code がそれを解釈し、「次はこの宛先で通信ログを絞って」と次の指示を出す
つまり実質、Claude Code と Chrome拡張が「対話」していて、私はその伝達役をしていた。md を書く必要はなく、Claude Code が出してくれる指示を、私がただ実行していっただけだ。
この三者対話で、業務用FW の生ログ（通信ログ）から「どのC2宛てに・何回・いつ・許可か遮断か」を1件ずつ突き止めた。同時に限界も見えた——この通信ログは「何回通信したか」は分かっても「何バイト出たか」は分からない。流出量の算定には端末側の SRUM や NetFlow が要る。AIとの対話を通じて、ツールごとに「何が言えて何が言えないか」を切り分けられたのが大きい。
4. 技術編 — 何が起きて、どう対処したか
ここからは、特定につながらない範囲で技術的な流れをまとめる。
4-1. 初期侵入チェーン
発端は、自己解凍形式の圧縮ファイルの実行だった。展開されると、正規サービスを装った実行ファイルがユーザー権限で書き込める場所（Public 配下の深い階層）に設置されて起動。続けて OS標準の netsh でファイアウォールに受信ポートを開け、外部との通信路を確立していた。
この一連は System / Security のイベントログに 秒単位で一次記録として残っていた。「自己解凍書庫の展開 → 偽装サービスの起動 → netsh による受信許可」が同一時刻帯に連続しており、「怪しい」ではなく「この時刻に、この順序で、これが起きた」と言い切れる。これが時系列突き合わせの強みだ。
4-2. マルウェアの構成
単一ではなく 複数系統のマルウェアが確認された。大別すると、
- 情報窃取型（スティーラー）：認証情報・ブラウザデータの収集
- 遠隔操作／中継型（トロイ）：外部からの操作と、通信の踏み台（プロキシ）化
いずれも更新サービスや同期ツールを思わせる正規っぽい名前に偽装し、ユーザー領域の目立たない場所に常駐。永続化は登録サービス／自動起動の形で行われ、これも 7045 等のログから裏が取れた。
4-3. C2通信と「流出をほぼ防げた本当の理由」
外部C2へは特定の高番ポートで通信が試みられていた。だが決定的だったのは、セキュアDNS（クラウド型のDNSフィルタ）が、感染からわずか十数秒後にC2ドメインの名前解決を遮断していたことだ。これが感染後の数十日間で数千回ブロックされ続けていた。
ここが今回の最重要の学びで——
流出が小規模に留まったのは「境界の業務用FWが守ったから」ではなく、**「DNS段階でC2の名前解決を潰していたから」**だった。
業務用FW の通信ログを精査すると、本物のC2への確立済み接続はほぼ成立しておらず、シンクホールされたC2試行が大量に記録されていた。感染端末から外向きの SYN が FW 側で明示的に拒否された記録はほとんどなく、「FW が止めた」のではなく「名前解決が成立せず宛先に到達できなかった」のが実態。大量の egress block はいずれも感染検知後に手動で封じ込めた以降のものだった。多層防御のうち実際に効いた層を、一次ログで切り分けられたことになる。
4-4. 何が流出したのか（被害の定量評価）
「大量データがまるごと吸い出された」最悪シナリオをまず疑った。だが $MFT とファイル作成痕跡を精査した結果、持ち出し用の集約アーカイブ（zip 等にまとめた痕跡）は存在せず、機微なファイルはクラウド同期フォルダのローカル実体として置かれていただけだった。SRUM から推定した実流出量も 数MB規模 に留まり、想定された最悪値を大きく下回った。
「被害ゼロ」と言いたい気持ちは抑え、「出ていない証拠」を一次ログから積み上げることを徹底した。「集約物がない」「外向き通信量が小さい」「C2接続が成立していない」——この3点が揃って初めて、小規模流出と結論づけた。
4-5. 横展開（他端末への波及）の確認
最初に最も恐れたのが、この横展開だった。感染端末だけで終わらせず、同一ネットワーク上のサーバ群（複数のLinuxサーバ、ドメインコントローラ、各種VPN・ファイル共有サーバ）も一通り精査した。結果、いずれにもC2痕跡や乗っ取りの形跡はなく、被害は当該1台に封じ込められていたと結論づけた。
「2台目が感染か？」と一瞬疑った通信痕跡も、調べると 同じ端末の別DHCPリース（別払い出しIP） だと判明。ここでも一次ログの突き合わせが、誤検知を1つ潰した。
5. 正直な話 — 「誰でもできる」は嘘だ
ここははっきり書いておきたい。
今回の体験を「AIがあれば誰でもフォレンジックができる」とまとめるのは、嘘だと思う。Claude Code が出してくる回答や指示は、ネットワークやOSの基礎知識がないと、そもそも意味が理解できない。DHCPリースとは何か、SYN とは、DNS のシンクホールとは——その土台がなければ、AIの答えを正しく受け取ることも、反証することもできない。
パソコンが苦手な人がこなせる作業ではなかった、というのが正直な実感だ。
ただし——専門のセキュリティエンジニアである必要もなかった。必要だったのは、
- ネットワークやOSについてのある程度の素養
- そして何より、AIを触るのが好きで、興味を持って食らいついていけること
このタイプの人なら、十分に到達できると思う。私自身がそうだった。
6. この一件で得た教訓と、今後の対策
技術者向けに、実務でそのまま効く順に並べる。
- DNSフィルタリングは「地味だが最強クラスに効く」。今回、実際に流出を最小化したのはセキュアDNS の層だった。最優先で維持・強化する。
- 境界ファイアウォールは egress（出ていく通信）を既定で拒否＋ログ化する。今回 egress 側の可視性が弱く、「止めた／止まった」の切り分けに苦労した。
- 通信量を測るなら NetFlow（または端末側 SRUM）が必須。FWの通信ログだけでは「何回」は分かっても「何バイト」は分からない。
- ログの長期保持・集約・NTPによる時刻同期。複数ログを秒単位で突き合わせられたから真相に到達できた。時刻がズレていたら不可能だった。Syslog(TLS) で SIEM に集約し、90日以上保持したい。
- IDS/IPS と DNSクエリログの有効化。今回 DNS の遮断ログが「決め手」になった。可視化を常設しておく価値は大きい。
- インシデント時はまず封じ込め。解析より先に、感染端末をネットワークから切り離す。横展開を止めてから、落ち着いて調べる。
7. まとめ — 「AIに任せ、人間が反証する」
私は専任のセキュリティエンジニアではない。それでも今回、侵入経路・被害範囲・流出量・恒久対策までを、根拠付きで・短時間でまとめ上げることができた。
理由をひと言で言えば——
Chat型AIの「コピペ問答」では断片しか見えない。Claude Code が「次に要るログ」を指示し、ディレクトリごと横断解析してくれたことで、点が線になり、線が物語になった。
そして、AIが直接触れない領域（ブラウザ内の業務用FW 管理画面）も、人間が伝達役になれば、Claude Code と Chrome拡張が対話できる。AIに解析を任せ、人間が「その根拠は？別解は？」と反証し続ける——この二人三脚が、今回の調査の本質だった。
「誰でもできる」とは言わない。でも、ネットワークに興味があって、AIを触るのが好きな人なら、きっと同じ場所に立てる。もしログの山を前に途方に暮れている人がいたら、伝えたい。全部を自分で読もうとしなくていい。読ませて、問い返せばいい。
※本記事の内容は一般化・改変済みです。特定のIPアドレス・ハッシュ値・マルウェア名・組織情報は含めていません。
