2026年2月、SolarWinds Web Help Desk(WHD)を狙った多段階侵害が、複数のセキュリティベンダにより「実運用での悪用」として報告された。起点はCVE-2025-40551に代表される信頼されないデータのデシリアライゼーションであり、インターネット公開されたWHDから認証なしRCEを取り、以降は「正規ツールの悪用」と「低ノイズな持続化」を組み合わせて、最終的にドメイン侵害(DCSyncなど)へ到達する。

本稿は、SolarWindsの公式アドバイザリ、Microsoft Defender Security Research Teamの調査、Huntressの現場観測を突き合わせ、攻撃チェーンを技術的に分解する。目的はPoCや武器化の再現ではなく、検知点封じ込めの優先順位を明確にすることである。

1. 何が起きたのか: 2026年1月から2月のタイムライン

まず「いつ、何が確度高く言えるか」を時系列で固定する。

  • 2026-01-16: Huntressが観測した持続化(後述のTPMProfiler/QEMU系)の最古タイムスタンプ(UTC)。この時点で攻撃が開始していた可能性がある。
  • 2026-01-28: SolarWindsがCVE-2025-40551(WHDのデシリアライゼーション起因RCE)を初回公開。影響は「12.8.8 HF1以前」、修正は「WHD 2026.1」。
  • 2026-02-03: CISAのKnown Exploited Vulnerabilities(KEV)にCVE-2025-40551が追加(実害前提のカタログ入り)。連邦機関向けの是正期限は2026-02-06
  • 2026-02-06: Microsoftが、WHDのインターネット公開インスタンスを起点とする多段階侵害(RCE→正規RMM導入→横展開→DCSyncまで)を報告。ただし、初期侵入に使われたCVEは確定できない、と明記。
  • 2026-02-08: Huntressが、3組織での悪用観測と、Zoho系RMM、Cloudflareトンネル、Velociraptor等を用いた事後活動の詳細を公開。

重要なのは、「脆弱性の深刻さ(CVSS)」より、KEV入りと、実運用での攻撃チェーン(RCE→管理ツール→AD侵害)が同時に揃った点である。WHDはヘルプデスク/ITSMの性質上、資産情報や認証情報に近く、侵害後の影響半径が大きい。

2. 起点: CVE-2025-40551(信頼されないデータのデシリアライゼーション)

CVE-2025-40551は、SolarWindsの説明では「WHDが信頼されないデータのデシリアライゼーションに脆弱で、認証なしにコマンド実行へ至り得る」タイプである。影響範囲はWHD 12.8.8 HF1 およびそれ以前、修正はWHD 2026.1とされ、CISA KEVにも追加された。

攻撃者視点での要点は次の3点に尽きる。

  • インターネット公開: 公開面があるとスキャンと到達が容易で、侵入の「母集団」を増やせる。
  • 認証なしRCE: パスワード総当たりやフィッシングを経由せず、即座に実行コンテキストを得られる。
  • アプリ文脈での実行: 侵入後は、アプリが持つネットワーク到達性、設定ファイル、保存済み認証情報、OS権限へ連鎖できる。

また、Microsoftは同系列としてCVE-2025-40536(セキュリティ制御バイパス)や、過去に公表されていたCVE-2025-26399(AjaxProxyのデシリアライゼーションRCE)にも言及しており、複数CVEが同時に残存する環境では「どのCVEで落ちたか」を事後に一意に特定できないケースがある。この不確実性は、インシデント対応において「起点CVSS」ではなく「観測された挙動」で封じ込めるべきことを示している。

3. 多段階RCEの実際: “マルウェアを置かない”侵入の設計

2026年2月の観測で特徴的なのは、侵入後のオペレーションが正規ツール中心である点である。これは、署名済みバイナリや一般的な管理ツールを使うことで、従来の「マルウェア指標」依存の検知をすり抜ける意図がある。

Huntressは、WHDサービスラッパー(wrapper.exe)→Java/Tomcat(java.exe)→cmd.exemsiexec.exeというプロセス連鎖を示し、静かなMSIインストールでRMMを導入する流れを記述している。

  • 初期実行: WHDのプロセス配下からPowerShellやcmdが起動され、BITS等でペイロードを取得。
  • 対話的支配: Zoho ManageEngine/Zoho Assistなど、RMMを導入し“Hands-on-keyboard”へ移行。
  • C2/持続化: Cloudflareトンネル(cloudflared)のようなアウトバウンド・トンネルで、境界FWの内側に長期足場を作る。加えて、VelociraptorのようなDFIRツールを、逆用してC2化する。
  • 環境偵察: ドメインコンピュータ列挙など、ADの“価値ある対象”を洗い出す。

Microsoftも同様に、RCE後に正規RMM(ManageEngine)を導入し、逆SSH/RDP、スケジュールタスクを用いた持続化(QEMUでSYSTEM起動しSSHをポート転送する例)を報告している。いずれも、侵害後の行動が「よくある管理作業」に見えやすい。

4. 侵害の終着点: AD侵害(DCSync)とNTDS.dit窃取の現実味

侵入の最終目標は、単なるサーバ乗っ取りではなくドメイン支配であることが多い。Microsoftは、WHD起点の多段階侵害において、DLLサイドローディング(wab.exeが不正なsspicli.dllをロード)でLSASSへ到達し、認証情報窃取へ進む例を提示した上で、少なくとも1件でDCSyncまでエスカレートしたと述べている。

また、同レポートでは「print.exe /D:\\...\\ntds.dit」のようなコマンドラインを手掛かりに、NTDS.dit窃取の可能性を追うハンティングクエリを提示している。これらは“やられた後”の議論ではなく、やられている最中に止めるための観測点である。

ここで防御側が誤解しやすいのは、「WHDはヘルプデスクだから、ADとは遠い」という直感である。実際には、WHDサーバは以下の理由で横展開に適してしまう。

  • サーバはしばしば“社内の深い場所”にあり、AD到達性が高い。
  • 運用上、サービスアカウントや管理者が触れる頻度が高く、認証情報が集まりやすい。
  • インベントリ/チケットのために、端末やユーザの情報がまとまっている。

5. 防御の優先順位: パッチ適用だけで終わらせない

対策は「パッチ適用」で終わらない。今回のような“正規ツール悪用”は、侵入後の封じ込め設計が問われる。

5.1 最優先: WHDの更新と露出削減

  • アップデート: SolarWindsが修正として示すWHD 2026.1へ更新する(CVE-2025-40551等)。
  • インターネット公開の廃止: 管理系パスを含め、WHDの管理UIを直接公開しない。VPNやIP制限、リバースプロキシで防御面を狭める。
  • ログの増強: SolarWindsはアプリログ/アクセスログに残る兆候(特定URL/キーワード等)を示している。ログ保存期間を延ばし、SIEMへ転送する。

5.2 侵害前提の検知: プロセス連鎖と“正規ツール”の異常利用

  • プロセス系: wrapper.exejava.execmd.exe/powershell.exebitsadmin.exe/msiexec.exeのような連鎖を高優先で監視する。
  • RMM導入: Zoho/ManageEngine系の新規導入、ToolsIQ.exe等の生成、サービス登録を監査する。
  • トンネル: cloudflared、VS Codeトンネル等、アウトバウンドで成立する永続トンネルを検出し遮断する(許可制にする)。

5.3 資格情報の防衛: “その後”を断つ

  • 資格情報のローテーション: WHDから到達可能なサービス/管理者アカウントから順に、強制的に変更する(Microsoft/Huntressとも推奨)。
  • AD防御: DCSyncの検知(Defender for Identity等)を有効化し、ドメインレプリケーション権限の棚卸しを実施する。
  • サーバ分離: WHDホストをTier分離の観点で見直し、ドメインコントローラや管理ネットワークへの到達性を最小化する。

FAQ

Q1. CVE-2025-40551だけ直せば十分か?

十分とは言い切れない。MicrosoftとHuntressはいずれも、CVE-2025-40551に加えてCVE-2025-40536、CVE-2025-26399など複数の脆弱性が同時に影響し得る状況に言及している。まずはSolarWindsが示す修正バージョン(WHD 2026.1等)へ更新し、加えてインターネット露出の削減と、侵害後行動(RMM/トンネル/DCSync)の検知を整備すべきである。

Q2. Cloudflareトンネルは“悪”なのか?

ツール自体は正規である。問題は「誰が、どの端末で、何の目的で」使っているかだ。Huntressは、侵害後の持続化としてCloudflareトンネルが悪用され得ることを具体例として示している。運用上は、許可された端末・アカウントに限定し、実行ファイルの出所や設定の監査を行うべきである。

Q3. DCSyncやNTDS.dit窃取まで到達していた場合、どこから復旧すべきか?

少なくとも「ドメイン管理権限が侵害された」前提で動く必要がある。ドメインコントローラ側の監査、KRBTGTを含む資格情報の再発行計画、特権アカウントの全面ローテーション、侵害経路(WHD)封鎖と端末隔離を並行する。個別環境の優先順位は、ADの依存度と業務影響で決まるため、IRチーム主導で段階的に進めるべきである。

Q4. “マルウェアが見つからない”なら被害は軽微か?

逆である。正規ツール悪用は、検知を難しくするための設計であり、侵害の深刻度を下げる要因にはならない。Microsoftは、RCEから正規RMM導入、資格情報窃取、DCSyncまで到達する多段階侵害を報告している。痕跡が薄いほど、封じ込めの初動が遅れやすい。

参考文献