本記事が扱う事象は、Windows Event Logs（Windowsイベントログ）とSysmon（シスモン）のtelemetyを用いた分析から、攻撃が常に整然と進むわけではない点を整理するものです。Huntressは2025年11月の複数事案を基に、IIS（Microsoft Internet Information Services）経由の侵入後に、攻撃者が失敗と再試行を繰り返しながら手順を調整していく様子を示しました。(Huntress)
- 公開されがちな攻撃像と、端末ログが示す実態の差
- IISを起点にした侵入から、端末実行に至る共通フロー
- 3件の事案が示した「失敗→修正→再試行」の繰り返し
- Defender除外とWindowsサービス永続化が示す摩擦点
- ログ運用で再侵入を止めるための整理軸
公開されがちな攻撃像と、端末ログが示す実態の差
一般に「高度な攻撃」は、段取りが固定された手順で淡々と進むものとして語られます。ただし、端末側のイベントログを時系列で追うと、実行コマンドの誤り、導入ツールの不整合、導線のやり直しが混在し、直線的な手順にならない場合があります。Huntressが示した3件の分析では、攻撃者がCloudflare Tunnel（クラウドフレア・トンネル）の導入に失敗したり、未導入のOpenSSH（オープンエスエイチエス）を実行しようとしたりするなど、環境理解が途中であることを示す痕跡が残りました。(Cyber Security News)
この点から、攻撃の評価は「巧妙さ」よりも「ログに残る反復」と「失敗後の分岐」を軸に整理する必要があります。 つまり、攻撃者が想定通りに動けない局面は、防御側にとって検知や封じ込めの判断材料として重要です。そのため、イベントログとSysmonの相関（同一プロセスの親子関係、コマンドライン、ハッシュ、生成元）を押さえ、失敗が発生した直後に何が試されたかを追える状態が実務上の確認点となります。(Microsoft Learn)
IISを起点にした侵入から、端末実行に至る共通フロー
Huntressの整理では、侵入口としてMicrosoft IISサーバーが繰り返し使われています。手口は、Webアプリケーションの脆弱性悪用を起点にリモートコマンドを発行し、端末へGolang（Go言語）製トロイの木馬とされるagent.exeをダウンロードして実行させる流れです。(Huntress) ここで重要なのは、IISプロセス（例：w3wp.exe）を経由したコマンド実行が、Windows側のプロセスツリーやコマンドラインとして観測できる点です。SysmonのEvent ID 1（Process creation：プロセス作成）は、新規プロセスのコマンドラインやハッシュを含むため、Webサーバー起点の不自然な子プロセス生成を追跡しやすくなります。(Microsoft Learn)
言い換えると、侵入経路がWeb側でも、痕跡の中心は「端末上のプロセス生成」と「防御機能との相互作用」に移ります。 そのため、IISログだけで完結させず、Windowsイベントログ、Sysmon、Microsoft Defenderの検知・隔離ログを同一タイムラインで接続することが重要です。ただし、収集量が増えるため、運用では必要イベントの選別や設定調整が追加確認が必要となる領域です。(Elastic)
3件の事案が示した「失敗→修正→再試行」の繰り返し
3件はいずれも同一の攻撃者像を示す重なりがある一方で、成功よりも失敗と再挑戦が目立つ構図でした。Incident 1ではcertutil.exeを用いたダウンロードが試され、Defender側で阻止されるとファイル名変更や実行名の差し替えが繰り返されました。Incident 2では、先行失敗を踏まえたようにDefenderの除外設定変更が先行し、その後に別系統のペイロードが投入されています。Incident 3は他組織でもほぼ同様の再現となり、同一TTP（戦術・技術・手順）の再利用が確認されました。(Huntress)
なお、整理のために主要点を表にまとめます。
| 区分 | 侵入口 | 主な試行 | 阻止・失敗点 |
|---|---|---|---|
| Incident 1（2025-11月上旬） | IIS | certutil.exeで取得、実行名変更（例：815.exe）、再訪して別ツール投入 |
Defenderが隔離し実行継続が困難 |
| Incident 2（2025-11-17） | IIS | PowerShellで除外追加後にSparkRAT（dllhost.exe）投入、サービス名WindowsUpdateで永続化 |
サービス起動失敗で実行が止まる |
| Incident 3（2025-11-25） | IIS | Incident 2と近い手順を別組織で反復 | 除外・サービス永続化が再度失敗 |
| 共通点 | 複数組織 | agent.exe、test.exe、dllhost.exeなどの利用 |
失敗後に同系統の再試行が続く |
要点を整理すると、同一侵入口でも「ブロックされた後に何を変えたか」が事案間で連続しており、そこが追跡の核になります。 さらにHuntressは、IPアドレス188.253.126.202、103.36.25.171、188.253.121.101の重なりや、ツール名の一致を示しており、インフラと実行痕跡の両面で関連付けが可能です。(Cyber Security News) この結果、単発の侵害として閉じず、再侵入を前提に監視条件を更新する運用が論点になります。
Defender除外とWindowsサービス永続化が示す摩擦点
Incident 2以降で目立つのが、Microsoft Defenderの除外設定を先に変更し、検知・隔離の再発を避けようとする動きです。PowerShellではAdd-MpPreferenceなどで除外パスを追加でき、実行前に保護を弱める導線が成立します。(Microsoft Learn) 一方で、除外設定の変更自体もログや監査の対象となり得るため、端末側で「設定変更→直後に未知実行ファイルが生成」という並びが観測されれば、検知ルール設計の材料になります。
ただし、攻撃者が除外を追加しても、永続化がサービス起動失敗で止まるように、環境差がそのまま防御側の阻止点になります。 Windowsサービスによる永続化はMITRE ATT&CKでも代表的な手法として整理されており、sc.exe等による作成・変更、サービス実行ファイルのパス、レジストリ変更が監視対象になります。(attack.mitre.org) そのため、防御側では「サービス名が正規風（例：WindowsUpdate）」「実行ファイルが不自然」「作成元プロセスがWebサーバー系」など、複数条件の重なりで精度を上げる設計が現実的です。なお、certutil.exeのようなLOLBIN（Living-off-the-Land Binary：OS標準ツール悪用）は一般論として整理されており、ダウンロードやデコードに使われる点が周知されています。(techzone.bitdefender.com)
ログ運用で再侵入を止めるための整理軸
以上を踏まえると、守る側の焦点は「高度な手口の列挙」ではなく、「失敗の発生箇所」と「再試行の癖」を継続的に拾う体制に移ります。具体的には、(1) IIS起点の不自然な子プロセス、(2) certutil.exeやPowerShellによる取得・設定変更、(3) Defenderの検知・隔離とその回避試行、(4) サービス作成・変更の一連、を同一タイムラインで追うことが基本になります。Sysmonのプロセス作成イベントは相関の土台になり、Defenderの設定変更はAdd-MpPreference等の実行痕跡として追跡可能です。(Microsoft Learn)
そうすることによって、攻撃者が「二度目・三度目」に同じ環境へ戻った際、同じ反復が早期に露見し、封じ込め判断を前倒しできます。 他方、ログは集めるだけでは運用負荷が増えるため、誤検知の扱い、保管期間、相関ルールの優先度といった設計が必要です。さらに、Huntressが示したように、同一IP群や実行ファイル名の再利用が見られる場合は、ネットワーク側のブロックと端末側の実行制御を連携させると、再侵入の成立条件を減らせます。(Huntress) つまり、本記事の対象となる事象は「攻撃が整然と進まない」事実を示すだけでなく、防御側がログを基点に反復パターンを管理する必要性を示しています。
