Windowsイベントログが暴く高度攻撃の失敗連続と再侵入の構造整理

本記事が扱う事象は、Windows Event Logs（Windowsイベントログ）とEDR（Endpoint Detection and Response：エンドポイント検知・対応）の突合によって、いわゆる高度攻撃が「計画通りに進む一枚絵」ではなく、失敗とやり直しを含む運用上の揺れ（運用ノイズ）として観測された点です。2025年11月上旬から下旬にかけて複数組織で確認された一連の侵害では、IIS（Microsoft Internet Information Services：Webサーバー）経由の侵入、Golang（Go言語）製トロイの木馬「agent.exe」の投入、Windows Defender（Microsoft Defender）への例外設定、Windowsサービスを使う永続化の失敗など、同型の手順が反復して記録されました。(GBHackers Security)

• Windowsイベントログが示した「運用ノイズ」という観測
• 11月6日〜12月の侵害で見えた試行錯誤の連鎖
• 11月17日と11月25日の再侵入で固定化した手順
• ログ観測から整理できる攻撃者の摩擦点と防御側の論点
• IOCsと関連痕跡の整理

Windowsイベントログが示した「運用ノイズ」という観測

Windowsイベントログは、攻撃が滑らかに進んだように見える局面でも、誤入力や失敗の反復を時系列で残し得ます。(GBHackers Security)

高度な持続的脅威（APT：Advanced Persistent Threat）を想定した説明では、初期侵入から権限取得、横展開、最終目的までが整然と進む前提が置かれがちです。ただし、イベントログとEDRテレメトリを合わせて見ると、攻撃者が防御側の遮断に対して場当たり的に手順を組み替える場面が残ります。つまり「戦術の刷新」よりも、「失敗の回収と再試行」が観測の中心になる場合があります。(GBHackers Security)

この点から、運用ノイズは偶発的な例外ではなく、侵害活動の通常要素として扱う必要が出ます。たとえば、Cloudflare Tunnel（クラウドフレア・トンネル）の導入に複数回失敗したり、存在しないOpenSSH（オープンエスエイチエス）サーバーを起動しようとしたりする挙動は、攻撃が「事前に完成した手順書」だけで動いていない可能性を示します。なお、表面上はランサムウェア（例：Warlock ransomware）到達へ一直線に見える侵害でも、粒度を上げると試行錯誤の痕跡が増える、という整理になります。(GBHackers Security)

11月6日〜12月の侵害で見えた試行錯誤の連鎖

第1の侵害では、Defenderによる遮断に対して高度な回避ではなく、単純な差し替えと再実行が繰り返されました。(Huntress)

3件の関連侵害のうち、最初の事案ではWebアプリの脆弱性を起点にIIS経由で遠隔実行へ至り、その後のダウンロード工程でcertutil.exe（証明書ユーティリティ）を使う試行がDefenderに阻止されたと整理されています。そこで攻撃者は、回避設定の組み込みより先に、実行ファイル名を変えた「815.exe」を配置し、複数回起動を試みた記録が残りました。要点を整理すると、遮断への反応が「手順の高度化」ではなく「同等手段の反復」に寄っていた、という点が重要です。(Huntress)

この結果、いったんは「agent.exe」の投入まで進みますが、Defenderの更新後に検知・隔離へ至った経緯もログで追えます。そうすることによって、攻撃者側にとっては既存ツールの寿命が短くなり、同一侵入口を維持したまま代替ツールへ切り替える動機が生じます。実際に、隔離の後日（12月上旬）に、正規の遠隔管理ツールGotoHTTPを改名した実体が持ち込まれた、と記録されています。一方で、侵入口そのもの（同じWebアプリ）へ戻ってきている点は、入口対策と事後対策が別問題として残り得ることを示します。(Huntress)

11月17日と11月25日の再侵入で固定化した手順

第2・第3の侵害では、Defender例外の事前投入が共通化した一方で、永続化サービスが起動できない失敗が反復しました。(Huntress)

11月17日（Incident 2）と11月25日（Incident 3）では、IISのw3wp.exeプロセス配下から不審実行（test.exeなど）が始まり、直後にPowerShellでDefender例外（Add-MpPreference）が複数パスへ追加された記録が示されています。言い換えると、先行事案で隔離が起きた経験を踏まえ、検知面の摩擦を先に下げる設計へ寄せた形です。なお、Defender設定の変更は、環境側の運用でも実施され得るため、ログ上は「何が、いつ、どの経路で」行われたかの突合が判断材料として重要である、という論点になります。(Huntress)

他方で、永続化はWindowsサービス（名称「WindowsUpdate」）を作成してdllhost.exe相当を起動する方式でしたが、Service Control Manager（サービス制御マネージャー）のイベントで起動失敗（例：7000/7009系）が繰り返し残っています。つまり、攻撃者は同じ構成を再利用しているのに、同じ箇所で詰まっている構図です。そのため、侵害の連続性を評価する際は「成功した段」だけでなく「失敗した段」の一致が、同一実行者の推定材料になります。しｓかし、成功・失敗の境界は製品更新や設定差で変わるため、単一要因で断定しない整理も必要です。(Huntress)

ログ観測から整理できる攻撃者の摩擦点と防御側の論点

反復する失敗点は、攻撃者の能力評価ではなく、検知・遮断・復旧の設計点を特定するための観測値になります。(GBHackers Security)

3事案の共通点は、侵入口（Webアプリ経由）、配置先（Public配下など）、ツール名の付け替え、Defender例外、サービス永続化という「型」が崩れていないことです。ただし、その型は完成度が高いというより、過去の成功体験を再利用している性格が強いと解釈する余地があります。以上を踏まえると、防御側の論点は「攻撃者が新しいTTP（Tactics, Techniques, and Procedures：戦術・技術・手順）へ変化したか」だけでは足りません。むしろ、隔離・検疫の発生点、同じ侵入口への再接続、サービス起動失敗の再現性など、摩擦点の連鎖を設計レビューの対象に置く必要が出ます。(Huntress)

ただし、運用ノイズは「雑さ」を意味しません。反復する行動は、結果として突破確率を上げ得ます。そのため、ログ分析では「一回の侵害」ではなく「戻ってくる」前提を含めて、どのイベント種別（例：Defender検知、Sysmon、IISログ、サービス制御）が連結して見えるかを整理することが実務上の確認点となります。一般に、IISの強化、LOLBins（Living Off the Land Binaries：既存正規ツール）乱用の監視、Defender例外の監査などが対抗軸として挙がりますが、本件では「どこで詰まったか」を固定的に追う観測設計が中心課題になります。(SOC Prime)

IOCsと関連痕跡の整理

IOCs（Indicators of Compromise：侵害指標）は単体で完結せず、観測時点とログ種別を併記してはじめて比較可能になります。(Huntress)

3事案では、ファイルハッシュ、関連IP、永続化名、Defender例外の追加といった要素が繰り返し出ています。ただし、同じ指標でも「IISログに出たのか」「端末のネットワーク接続に出たのか」で意味が変わります。つまり、IOCsはブラックリストとしての列挙ではなく、時系列復元のための索引として扱うのが整理しやすい構造です。この点から、主要要素を最小限でまとめると次の通りです。(Huntress)

表の通り、同一指標が再登場する一方で、永続化の失敗という「未達」も継続して残ります。要点を整理すると、検知側が得られる材料は「成功痕跡」だけではありません。失敗の反復を束ねることで、侵入口の共通性、運用の癖、次に狙われる工程を推定しやすくなり、結果として見落す範囲を狭める方向へつながります。(Huntress)