2025年12月22日にHuntressが公開した分析が、ちょっと痛快です。世の中のレポートは「攻撃者は高度化し、洗練され、一直線に目的へ」と描きがち。でも実際のEDR（エンドポイント検知・対応）やWindows Event Log（Windowsイベントログ）をのぞくと、現場はもっと泥くさい。コマンドを打ち間違えたり、入れたいツールが入らなかったり、Defender（Microsoft Defender）に弾かれて戻ってきたり……つまり“試行錯誤”が山ほどある、という話です。(Huntress)
- 「巧妙さ」の正体は、失敗ログの積み重ねだった
- 3つの侵害に共通した入り口：IIS(w3wp.exe)からのコマンド実行
- Incident 1：Defenderに弾かれたら、名前を変えてまた来る（2025年11月6日報告）
- Incident 2：学習してDefender除外を入れるが、永続化がコケる（2025年11月17日）
- Incident 3：ほぼコピペ手順、それでも同じ落とし穴（2025年11月25日）
- ここが“エラーコード”の核心：イベントID7000/7009/7040は何を語る？
- 実務の対処：ログから“試行錯誤”を検知して先回りする手順
- IOCをテキストで置いておく（コピペ用）
- 他ユーザーの“現場の声”：除外設定って、思ったより一筋縄じゃない
- みんなの掲示板：あなたの環境だと、どこで止められそう？
「巧妙さ」の正体は、失敗ログの積み重ねだった
攻撃は“完成された手順書”ではなく、失敗と修正の連続として観測されることが多いです。(Huntress)
冒頭の例が分かりやすい。Velociraptor（DFIR＝デジタル・フォレンジック/インシデント対応）を悪用した一件では、Cloudflare tunnel（トンネル）を何度も入れようとしてDefenderに隔離され、OpenSSH（SSHサーバー）を「入ってないのに起動しようとする」みたいなミスまで残っていました。Windows側の反応として「cat（表示コマンド）が認識されない」も出てくる。ほら、人間くさい。(Huntress)
ここがポイントで、守る側は「相手が完璧」と思い込むほど、ログの“変な揺れ”を見逃します。逆に言うと、揺れはチャンスです。
3つの侵害に共通した入り口：IIS(w3wp.exe)からのコマンド実行
IIS（Microsoft Internet Information Server）のw3wp.exe配下でcmd.exeやPowerShellが動く時点で、かなり赤信号です。(Huntress)
Huntressが示した3件は、いずれもWebアプリの脆弱性を突いて「Webサーバープロセス経由で端末上のコマンドを叩く」流れが見えます。Webシェル（web shell＝Web経由の遠隔操作口）を置いた、と断定できないケースもあり、ページごとにアクセス先がバラバラだった点も示唆的でした。(Huntress)
そして共通して出てくるのが、Golang（Go言語）製のトロイの木馬っぽいagent.exe。ここから先で、攻撃者の「行き当たりばったり感」がログに染み出します。
Incident 1：Defenderに弾かれたら、名前を変えてまた来る（2025年11月6日報告）
Defenderに止められても撤退せず、別ファイル投入→数日後に再訪、という粘着パターンが確認されています。(Huntress)
時系列で見ると生々しいです。まず whoami.exe、netstat -an、ipconfig /all などで列挙（enumeration＝調査）を実施。その後、certutil.exe（LOLBin＝正規ツール悪用）で「110.172.104[.]95:8000」から C:\Users\Public\agent.exe を落として実行しようとして、ここはDefenderにブロックされます。(Huntress)
そこで攻撃者は「Defenderを無効化して突破」ではなく、なぜか別の 815.exe を実行。しかも一発で動かせず、何度か起動を試してやっと成功っぽい挙動。洗練というより、can’t（できない）からの手探りです。
さらに厄介なのが再訪です。12月1日に「C:/Users/Public/agent.exe C:/Users/Public/ca.bin」を実行。最初はPUA（潜在的に望ましくないアプリ）扱いで放置され、12月3日のDefender更新後に「ShellcodeRunner」として隔離されます。すると12月8日にまた来て、今度はGotoHTTP（RMM＝遠隔監視・管理）を改名して落とす。セキュリテイって、最後は粘り勝ちを許すとしんどい。(Huntress)
Incident 2：学習してDefender除外を入れるが、永続化がコケる（2025年11月17日）
攻撃者は前回の失敗を踏まえてDefender除外を追加したのに、サービス起動エラーでつまずきました。(Huntress)
Incident 2では、開始30秒ほどで PowerShell（自動化シェル）を使い、Add-MpPreference（Defender設定変更）で除外を追加します。たとえば C:\users\public や inetsrv 配下、拡張子 .exe .bin .dll をまとめて除外。Get-MpPreference（設定参照）で確認までしていて、「前回は弾かれた、だから先に土台を崩す」という発想が丸見えです。(Huntress)
その後、agent.exe相当を dllhost.exe にコピーして隠し属性（attrib +s +h）を付与し、sc.exe（Service Control Manager操作）で WindowsUpdate というサービス名で永続化（persistence＝居座り）を狙います。ところが Systemログに Service Control Manager のイベントID 7000 / 7009 / 7040 が並び、サービスが起動できず失敗。攻撃側も「え、動かん…」となる瞬間です。(Huntress)
Incident 3：ほぼコピペ手順、それでも同じ落とし穴（2025年11月25日）
手口が似ているほど“検知ルールでまとめて刈れる”可能性が上がります。(Huntress)
Incident 3は、Defender除外の入れ方も、test.exe→dllhost.exe→WindowsUpdateサービスも、ほぼIncident 2の再演。POSTの痕跡は別ページですが、やりたいことは同じ。つまり攻撃者側のオペレーションも「改善したつもりが、まだ粗い」状態です。ここ、守る側が一番おいしいゾーンなんですよね。(Huntress)
ここが“エラーコード”の核心：イベントID7000/7009/7040は何を語る？
イベントID7000/7009は「サービスが起動できなかった」事実で、攻撃の“失敗点”をピン留めできます。(Huntress)
7000はサービス開始失敗、7009はタイムアウト系、7040は開始種類の変更など、いずれも「永続化が成立しなかった」痕跡として効きます。加えてIncident 1ではSysmon（System Monitor）イベントID 5（プロセス終了）とDefender隔離が近接していて、「止めた瞬間」を時系列で追いやすい。攻撃者が完璧ならログは滑らかですが、実際はギザギザ。そのギザギザを、あなたの監視が拾えるかが勝負です。(Huntress)
実務の対処：ログから“試行錯誤”を検知して先回りする手順
「w3wp.exe→cmd/PowerShell」「Defender除外操作」「サービス作成失敗」を3点セットで追うと、再訪型の侵害に強くなります。(Huntress)
(1) IISログでPOSTが集中したページと時刻を抜き出し、直後に同端末でw3wp.exe配下の子プロセス生成がないか確認します。(Huntress)
(2) w3wp.exe→cmd.exe / powershell.exe の連鎖を、EDRやSysmonで“通常運用としてあり得るか”棚卸しします。(Huntress)
(3) certutil.exe -urlcache -split -f の実行、C:\Users\Public 配下への不審EXE作成、直後のstart実行をまとめてアラート化します。(Huntress)
(4) PowerShellで Add-MpPreference / Set-MpPreference が走ったら、端末の管理ポリシー（IntuneやGPO）と突合し、「誰が何を除外したか」を即時エスカレーションします。(Microsoft Learn)
(5) Systemログで Service Control Manager イベントID 7045（サービス作成）と7000/7009（起動失敗）が連続したら、失敗していても“侵害が進行中”として隔離判断を早めます。(Huntress)
(6) GotoHTTPなどRMM（正規の遠隔管理）が入った形跡は「正規利用の証跡があるか」で切り分けます。RMMは攻撃でも便利に使われます。(Elastic)
(7) 最後に、同一IP帯や類似User-Agent、同名ファイル（agent.exe、dllhost.exe、test.exe）の再出現を“再訪予兆”として監視し、パッチ・WAF（Webアプリ防御）・コードレビューに優先度を付けます。(Huntress)
IOCをテキストで置いておく（コピペ用）
IOCは「再訪」を止めるための最低限の地図です。(Huntress)
Incident 1で出たファイルは C:\users\public\815.exe、SHA256は 909460d974261be6cc86bbdfa27bd72ccaa66d5fa9cbae7e60d725df13d7e210。ダウンロード元として 110.172.104[.]95、Webログや通信で 188.253.126.205 / 188.253.126.202 / 103.36.25.171。(Huntress)
Incident 2と3は agent.exe / dllhost.exe が中心で、SHA256は 66a28bd3502b41480f36bd227ff5c2b75e0d41900457e5b46b00602ca2ea88cf。test.exe のSHA256は 272de450450606d3c71a2d97c0fcccf862dfa6c76bca3e68fe2930d9decb33d2。WebログのIPは 103.36.25.169 や 188.253.121.101 が出ています。(Huntress)
他ユーザーの“現場の声”：除外設定って、思ったより一筋縄じゃない
Defender除外は攻撃者だけでなく運用者も触るので、「効かない」「反映されない」報告が混ざりやすいです。(Reddit)
たとえばReddit（掲示板）では、Add-MpPreferenceが成功したように見えるのに反映されない、という相談が昔から出ています。管理下端末だとポリシーで上書きされる、という典型パターンですね。こういう“運用の揺れ”を知っていると、攻撃由来の除外追加を見たときに「誰の作業か」を素早く切り分けできます。(Reddit)
みんなの掲示板：あなたの環境だと、どこで止められそう？
「攻撃者がつまずく場所」を共有できると、次の一手が速くなります。
コメント欄に、あなたの現場の条件を書いてみてください。たとえば「IISは使ってる？」「Sysmon入ってる？」「Defender除外は誰が触れる？」みたいなやつ。
「w3wp.exe配下の子プロセス、うちは実は定期バッチで出る」みたいな例外も大歓迎。そこが一番、話が盛り上がるので。
