以下の内容はhttps://error-daizenn.hatenablog.com/entry/2025/12/31/101730より取得しました。


Windowsイベントログが示したIIS侵入の原因と攻撃者の試行錯誤を整理


本記事が扱う事象は、Windowsイベントログ(Windows Event Logs)とEDR(エンドポイント検知・対応)の記録から、同一系統とみられる攻撃者が複数組織に対して「試しては直す」動きを重ねていた点です。米SC Mediaは2025年12月30日、住宅開発会社・製造業・企業向け共通サービス(shared services)組織の3件で、攻撃者が試行錯誤しつつ侵入を進めた状況を短報として整理しました。 (SC Media)
このテーマは「攻撃は常に一直線」という前提では説明しきれない部分があり、そのためログの読み方と、阻害点(Defenderなど)に対する反応を因果で捉える必要があります。 (SC Media)

3件の侵害で共通した「試行錯誤」が確認された背景

3件はいずれもMicrosoft IIS(Internet Information Server)経由で端末上のコマンド実行が試みられ、失敗と再試行がログに残りました。 (SC Media)

Huntressは2025年12月22日付の分析で、WindowsイベントログやEDRテレメトリを丁寧に追うと、攻撃者が障害に当たって作業を修正する場面が繰り返し観測されると述べています。具体例として、別件の11月事案ではCloudflareトンネルの導入を複数回試し、コマンドの打ち間違いが生じ、OpenSSHサーバーが未導入の状態で起動を試みた点が挙げられました。 (Huntress)

この観点を3件の侵害に当てはめると、入口はIISで共通しつつも、攻撃者はDefenderに遮断される、サービスが起動しないといった阻害に応じて次の手を変えていました。なお、SC Mediaの短報では「高度」と表現されつつも、実際の手順は連続した成功ではなく、失敗を含む履歴として観測されています。 (SC Media)

つまり、侵害の全体像は「完成済みの手順」だけでなく、「阻害への反応」も含めて整理する必要があります。そのため次章では、3件の時系列と共通点を、ログ上の根拠と対応づけてまとめます。 (Huntress)

3インシデントの時系列と共通点を表で整理

共通点は「w3wp.exe配下でのコマンド実行→マルウェア投入→永続化の試行」で、差分はDefender対策の有無と再侵入の頻度でした。 (Huntress)

3件はそれぞれ報告日が2025年11月6日、11月17日、11月25日とされ、いずれもIISのワーカープロセス(w3wp.exe)を起点に端末側の実行へ接続しています。最初の事案ではcertutil.exeを用いたダウンロードがDefenderで遮断され、その後に別実行ファイルの複数回起動、12月に入ってからの再侵入がログに残りました。 (Huntress)
一方で2件目・3件目では、初動の早い段階でDefender除外をPowerShellで追加しており、1件目の遮断を踏まえた変更と読み取れると説明されています。 (Huntress)

そのため、最低限の整理として、対象・入口・主要動作を以下にまとめます。

事案(報告日) 対象組織 入口(ログ上の起点) 要点(コピペ実例を含む)
Incident 1(11/6) 住宅開発会社 IIS w3wp.exe からコマンド実行 Process=certutil.exe のダウンロードがDefender遮断→別ファイルを複数回起動、12月に再侵入 (Huntress)
Incident 2(11/17) 製造業 IIS w3wp.exe から実行連鎖 CommandLine contains Add-MpPreference -ExclusionPath で除外追加→sc.exeでサービス作成も起動失敗 (Huntress)
Incident 3(11/25) 共有サービス組織 IIS w3wp.exe から実行連鎖 web shell(Webシェル)アクセスの記載、手順はIncident 2とほぼ同型、サービス起動失敗も同様 (Huntress)

さらに、検知側が「攻撃の試行錯誤」を拾うには、実行コマンドそのものより、設定変更・永続化・遮断イベントの組み合わせが判断材料になります。そこで、WindowsログやEDRで使いやすい形に落とした例を整理します(環境によりフィールド名は差が生じます)。

観測ポイント コピペ実例 意味 関連根拠
Defender除外の追加 CommandLine contains "Add-MpPreference" and ("-ExclusionPath" or "-ExclusionExtension") 防御回避の前段 Huntressの除外追加手順、Add-MpPreferenceの仕様 (Huntress)
certutilによる取得 CommandLine contains "certutil.exe" and " -urlcache " 端末側への取得操作 Incident 1の遮断されたコマンド (Huntress)
隠し属性付与 Process=attrib.exe and CommandLine contains "+s +h" ファイル痕跡の隠蔽 Incident 2のattrib実行 (Huntress)
サービス作成・起動 Process=sc.exe and ("create" or "start") 永続化の試行 Incident 2/3のサービス作成 (Huntress)
サービス起動失敗 EventID in (7000,7009,7040) and ServiceName="WindowsUpdate" 永続化の失敗点 Huntressが示したSCM(Service Control Manager)ログ (Huntress)

要点を整理すると、「入口(IIS)」「防御回避(除外)」「永続化(サービス)」「失敗(起動不可)」が連続して現れる構図が共通します。そうすることによって、単発のアラートでは見落としやすい再試行の連なりを、時系列で束ねて確認できます。 (Huntress)
次章では、入口として共通したIIS侵入が、どのように「端末上の実行」へ接続されたのかを整理します。

IIS経由のコマンド実行が成立した構造とログ上の手掛かり

3件はいずれもWebサーバープロセスを経由して端末上の実行に接続しており、Web層と端末層のログ突合が重要な前提となります。 (Huntress)

Huntressは、3件とも「Webアプリの脆弱性によりWebサーバー経由で端末上のコマンドが実行された」可能性を述べています。各事案でアクセスされたページが異なり、ファイル書き込み型のアップロード脆弱性でWebシェルを設置した、と一律に断定しにくい点も記載されています。 (Huntress)
つまり、Web層では「POST要求の直後に端末側で whoami.exe や列挙コマンドが実行される」といった相関が、初動の判断材料になります。 (Huntress)

Incident 1では、IISログのPOST記録が初期のコマンド実行点として示され、その後に whoami.exe、netstat、ipconfig、ローカル管理者グループの確認などが続きました。ここから、攻撃者が侵入直後に環境調査(enumeration)を行い、次にダウンロード・実行へ進めた流れが読み取れます。 (Huntress)
他方、Incident 2・3では、同種のIISログ(/Login.aspx へのPOSTなど)が前段として見つかり、端末側では除外追加や永続化へ進んでいます。 (Huntress)

なお、この種の分析は「EVTX(.evtx)として保存されるイベントログ」を前提に、端末内の時系列を復元します。EVTXの形式や取り扱いはMicrosoftのドキュメントにも整理があり、ログの保持・収集設計が検証の前提条件となります。 (Microsoft Learn)
次章では、攻撃者がDefenderを避けるために何を変え、どこで止まったのかを、試行錯誤の連鎖として整理します。

Defender回避と永続化の失敗が示す「学習」の痕跡

1件目の遮断を受けて2件目以降はDefender除外を先に追加し、ただし永続化(Windowsサービス)が起動しない点で連続して止まっています。 (Huntress)

Incident 1では、certutil.exeで agent.exe を取得して起動する試みがDefenderにより遮断されました。その後、別ファイル(815.exe)の複数回起動、さらに12月1日・12月8日に再侵入し、別ツールの投下まで進む流れが記載されています。ここではDefender設定の変更は明確に示されず、投入物を替える方向で迂回が試みられています。 (Huntress)

一方でIncident 2では、プロセス開始から約30秒後にPowerShellで Add-MpPreference を用いた除外追加が連続して実行されました。Add-MpPreferenceは、拡張子・パスなどの除外を追加するコマンドレットであり、除外がスキャン動作に影響することはMicrosoftの説明でも示されています。 (Huntress)
この後、attrib.exeで dllhost.exe に隠し属性を付け、sc.exeで WindowsUpdate というサービス名で永続化を作成したものの、Service Control Managerのイベント(7000/7009/7040)として起動失敗が残ったとされています。ここが阻害点となり、攻撃連鎖がそこで停止しています。 (Huntress)

Incident 3は、web shell へのアクセスがあったとされつつも、Defender除外や実行ファイル、永続化の試行がIncident 2と同型で、同じくサービスが起動しない点で停止しています。つまり、学習によって「遮断されやすい箇所(除外未設定)」は先回りしたが、「成立しない箇所(サービス起動)」は再現してしまう構造です。 (Huntress)

以上を踏まえると、検知側は「侵入→除外→永続化→失敗」の連続を、単発アラートではなく一つのストーリーとして扱う必要があります。なお、Sysmon(System Monitor)を導入していた端末では、プロセス終了などがイベントIDで補強され、時系列の精度が上がる点も言及されています。ログが保管されまますかどうかが、分析可能性の条件差になり得ます。 (Huntress)

監視・調査で整理すべき確認点と判断材料

実務上は「Webログと端末ログを同一時刻軸で結ぶこと」「Defender除外の変更を高優先で扱うこと」が確認点となります。 (Huntress)

本記事の対象となる事象では、IISログのPOST記録が端末側実行の前段として現れ、端末側では whoami.exe などの列挙、取得操作、除外追加、永続化が続きました。したがって、Webサーバー側ログと、端末側のプロセス作成・PowerShell実行・サービス制御のログを突合できるかが、調査の出発点になります。 (Huntress)
そのため、ログ収集は「どのチャネルのEVTXを残すか」「転送時に欠落が生じないか」が判断材料として重要です。MicrosoftはEVTXをEvent Viewerで開けることや収集手順を示しており、取得経路の設計は事前条件になります。 (Microsoft Learn)

次に、Defender除外は攻撃の前進に直結しやすい操作として位置づけられます。Add-MpPreferenceは除外追加のための公式コマンドであり、除外の種類(拡張子・パスなど)が整理されています。したがって、PowerShellのコマンドラインに除外パラメータが含まれる事象は、前後のプロセスツリーと結びつけて扱うのが自然です。 (Microsoft Learn)
他方、永続化は「成功した事実」だけでなく「失敗した履歴」も重要です。今回の2件ではサービス名WindowsUpdateでの起動失敗がログに残っており、これは再侵入時の再現性を測る材料にもなります。 (Huntress)

最後に、攻撃者の試行錯誤は「同じ入口に戻る」「投入物の名前や手順を変える」「防御設定を先に変える」といった差分として観測されます。つまり、観測側の整理軸は「侵入経路」「回避操作」「永続化」「阻害点」の4点に収束します。そうすることによって、3件のように組織が異なっても、共通の連鎖として評価できる枠組みが得られます。 (SC Media)




以上の内容はhttps://error-daizenn.hatenablog.com/entry/2025/12/31/101730より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14