Defenderを無力化する巧妙なマイニング攻撃：AI時代のインシデント対応録

エンジニアにとって、PCの動作が重くなることは日常茶飯事だ。特に開発機であれば、バックグラウンドで走るDockerコンテナや、肥大化したIDE、あるいは最近導入したばかりのAIコーディング支援ツールがCPUを食いつぶしているのではないかと疑うのは、極めて自然な思考プロセスである。今回、Qiitaで報告されたインシデントは、まさにその「エンジニアの先入観」を逆手に取った巧妙な攻撃であった。被害者は、自作Botの不調を「自分が最近実装したAIコードのバグ」だと誤認し、5日間もの間、自身の開発機が暗号通貨マイナーの踏み台にされていることに気づかなかった。

このインシデントの恐ろしい点は、攻撃者がWindowsの正規タスク名やプロセス名を完璧に模倣していたことにある。例えば、タスクスケジューラに登録された『MicrosoftWindowsShellFamilySafetyRefreshingTask』といった名称は、一見するとOSの正常な管理タスクに見える。しかし、その実行パスは『C:Users<ユーザー名>AppDataLocalMicrosoftEdgeSystemupdate.exe』を指しており、明らかに正規のシステムフォルダではない。我々エンジニアは、タスク名やプロセス名という「ラベル」を信頼しがちだが、攻撃者はそのラベルの裏側にある「実行パス」という本質的な情報を隠蔽することで、管理者の目を欺いたのである。これは、スパゲッティコードをデバッグする際に、関数の名前だけで処理内容を推測し、中身のロジックを見落とすのと同種の、極めて初歩的かつ致命的な誤認である。

特筆すべきは、この調査と駆除のプロセスを、被害者自身ではなく『Claude Code』というAIエージェントが主導したという点だ。AIは「AIがコードを壊した」という人間の主観的なバイアスに囚われず、プロセスごとのCPU消費量や通信先、実行パスといった「冷徹な数値データ」のみを解析した。その結果、5秒間で75秒分ものCPU時間を消費する『updater.exe』という名のプロセスを特定し、それがXMRig 6.21.3であることを突き止めた。人間が「最近の変更」という時間軸で犯人を決めつける一方で、AIは「CPUの増分」という物理的な事実から犯人を特定した。この対比は、今後のインシデントレスポンスにおいて、人間がAIをどう活用すべきかという問いを突きつけている。

「Windows Defenderが有効だから大丈夫」という安心感は、現代のWindows開発環境において最も危険な幻想かもしれない。本件において、Defenderは決して無能ではなかった。実際、マイニングソフトが使用するカーネルドライバ『WinRing0x64.sys』が除外リスト外の『C:WindowsSystemTemp』に展開された瞬間、Defenderは即座に脅威として検知・隔離している。しかし、攻撃者は管理者権限を奪取した直後に、自身のマルウェアが配置されたフォルダをDefenderの『除外リスト』に登録するという、極めて狡猾な手法をとっていた。これにより、マイニングの本体であるXMRigは、Defenderの監視網をすり抜け、5日間もの間、20コア中15コアを占有し続けたのである。

この事実は、我々エンジニアに「セキュリティ製品は設定次第で無力化される」という教訓を突きつける。特に、開発機においてはビルド速度向上のためにコンパイラやライブラリのパスを除外リストに入れることが一般的だが、その設定が攻撃者にとっての「聖域」として悪用されるリスクを考慮しなければならない。今回のインシデントで明らかになった、マルウェアの潜伏手法とDefenderの挙動を以下の表にまとめる。

駆除プロセスにおいて、AIが示した「順番の重要性」は、まさに熟練のインシデントレスポンスエンジニアの思考そのものである。まず偽装タスクを削除して再起動を阻止し、次にプロセスを停止させ、その後にDefenderの除外設定を解除し、最後にファイルを削除する。この順序を誤れば、Defenderが監視を再開する前にマルウェアが再生成されるリスクがあった。特に『RuntimeBroker.exe』のような、正規プロセスと偽装プロセスが混在する環境下で、パスを特定してピンポイントで停止させる手法は、AIの論理的な正確さが遺憾なく発揮された場面と言える。我々が明日から取るべき対策は、単にDefenderを信じることではなく、定期的に『Get-MpPreference』コマンドを叩き、除外リストに身に覚えのないパスが含まれていないかを監視する、という泥臭い運用に他ならない。

今回のインシデント報告を読んで、私は強い危機感を抱かざるを得ない。それは、攻撃手法の巧妙さ以上に、我々エンジニアが「自分のPCで何が起きているか」を把握する能力を、AIや自動化ツールに依存しすぎているのではないかという懸念だ。被害者は、PCがやたらと熱いことや、キーボード入力が引っかかるという物理的な違和感を「夏だから」「ソフトが増えたから」と合理化してしまった。これは、システム障害の予兆を「一時的な負荷」として無視し、大規模なダウンタイムを招く現場のエンジニアと全く同じ心理状態である。技術的な知識があるからこそ、事象を都合よく解釈してしまう『専門家のバイアス』が、セキュリティの穴を広げている。

AIは確かに強力な調査ツールだ。今回のように、465個のプロセスから偽装を見抜き、WMIイベント購読やスタートアップ項目を網羅的にチェックする作業は、人間が手動で行えば数時間はかかる。しかし、AIがどれほど優秀であっても、最終的に「そのPCを信頼するか否か」を判断するのは人間である。もしAIが攻撃者にハックされていたら？もしAIが提示した駆除コマンドが、システムを破壊するような罠だったら？我々は、AIの回答を鵜呑みにするのではなく、その根拠となるコマンドやログを自ら検証する『疑う力』を失ってはならない。AIはあくまで、我々の認知能力を拡張する補助輪であり、ハンドルを握っているのは常に自分自身であるべきだ。

最後に、読者諸君に問いたい。あなたの開発機で、今この瞬間に動いている『updater.exe』や『RuntimeBroker.exe』が、本当にOSの正規プロセスであると断言できるだろうか？タスクマネージャのリストを眺めるだけで満足していないだろうか？もし心当たりがないのであれば、今すぐ管理者権限でPowerShellを開き、実行パスを確認する習慣を身につけるべきだ。セキュリティとは、高価なツールを導入することではなく、自分の環境に対する『徹底的な不信感』を維持し続けることにある。AI時代において、真に価値のあるエンジニアとは、AIを使いこなす者ではなく、AIが提示した結果の裏側にある『真実』を、自らの手で検証し続ける者であると私は確信している。