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