Windows環境で今回押さえるべき結論は、「新しい脆弱性対応」ではなく、信頼済みの管理経路・外部委託先・正規ツールを前提にした監視体制の見直しです。Microsoft Incident Responseが公開した「Undermining the trust boundary」は、攻撃者が目立つマルウェアや未知の脆弱性ではなく、第三者のITサービス事業者、HPE Operations Agent、Windowsの認証拡張機構、RDP、WMI、ngrokなどを組み合わせ、通常の管理作業に紛れて長期潜伏した事例を解説しています。(Microsoft)
Windows管理者がすぐ確認すべきポイントは、ドメインコントローラー上のLSA通知パッケージ、ネットワークプロバイダー、EDR未導入サーバー、外部委託先が利用する管理ツール、サーバーの外向き通信制御です。開発者や運用ベンダー側も、認証イベントに関わるDLLやレガシーAPI、管理自動化スクリプトを「便利だから残す」のではなく、署名・権限・監査ログ・展開手順まで含めて再点検する必要があります。
今回の公式情報は「Windowsの更新」ではなく、信頼境界の見直しを促すインシデント分析
今回の情報は、Windows Updateで配布されるパッチや新機能の案内ではありません。Microsoft Security Blogで公開された、実際の侵入調査に基づくセキュリティ分析です。重要なのは、攻撃者が「怪しい実行ファイルをばらまく」のではなく、組織がすでに信頼している管理経路を使って侵入・認証情報窃取・横展開・永続化を行った点です。(Microsoft)
Microsoftの説明では、この攻撃でHPE Operations Agent自体の脆弱性や欠陥が悪用されたわけではありません。問題は、第三者のITサービス事業者に管理が委任されていた運用基盤が侵害され、その正規の管理機能を通じてスクリプトやバイナリが実行されたことです。(Microsoft)
つまり、管理者が見るべき論点は「どのCVEに対応するか」だけではありません。以下のような問いに答えられるかが、今回の実務上の焦点です。
| 確認すべき問い | 実務上の意味 |
|---|---|
| 外部委託先はどのサーバーへ管理権限を持っているか | 信頼境界が自社ネットワーク内だけで完結していない可能性がある |
| 正規の管理ツールから何が実行されているか | 攻撃と通常運用の見分けがつきにくい |
| ドメインコントローラーで認証関連DLLが変更されていないか | 認証情報窃取が長期間続く可能性がある |
| WebサーバーにEDRと詳細ログがあるか | 初期侵入やWebシェルの痕跡を見落とす可能性がある |
| サーバーから外部への通信を制御しているか | ngrokなどのトンネルで内側から抜け道を作られる可能性がある |
何が変わるのか：管理者の前提が「信頼」から「継続的な検証」に変わる
今回の情報で変わるのは、Windowsの画面や機能というより、Windows環境を守る前提です。従来は「正規ツールで実行された処理」「委託先アカウントの操作」「署名済みの管理エージェント経由の処理」は、比較的信頼されやすい扱いでした。
しかし今回の事例では、その信頼が攻撃者に利用されました。Microsoftは、第三者サービス事業者や統合された管理ツールが、可視性や検証が不足している場合に“執行上の隙間”になり得ると説明しています。(Microsoft)
実務では、次のように考え方を変える必要があります。
| 従来の見方 | 今後必要な見方 |
|---|---|
| 正規ツールの実行だから安全 | 正規ツールでも、実行内容・実行元・対象範囲を検証する |
| 委託先アカウントだから許可 | 委託先アカウントも最小権限・MFA・操作ログ監査の対象にする |
| ドメインコントローラーは管理者だけが触る | 認証関連レジストリやDLL変更を継続監視する |
| 外部公開していないRDPは安全 | 内部から張られたトンネル経由のRDPも想定する |
| EDRは重要端末だけでよい | Webサーバー、管理サーバー、DC、SQLサーバーまで対象にする |
この変化は、特にActive Directoryを中心にWindows Serverを運用している組織に大きく関係します。攻撃者が狙ったのは、Windowsの「正規の拡張機構」や「管理のための仕組み」そのものだったからです。
影響範囲：Active Directory、ドメインコントローラー、外部委託運用がある組織は要注意
今回の事例は、特定のWindowsバージョンだけに限定して考えるべきものではありません。特に注意すべきなのは、次のような環境です。
Active Directoryを利用している企業
ドメインコントローラーは、ユーザー認証、パスワード変更、管理者権限の制御に関わる中核です。今回の事例では、攻撃者がドメインコントローラー上で悪意あるネットワークプロバイダーDLLやパスワードフィルターDLLを登録し、サインインやパスワード変更のタイミングで認証情報を取得していました。(Microsoft)
Active Directory環境では、ドメインコントローラーに入った時点で被害が一気に広がります。通常の端末侵害よりも優先度を上げて、DC上のレジストリ、DLL、イベントログ、EDR検知を確認すべきです。
外部ITベンダーやMSPに運用を委託している組織
第三者のITサービス事業者に監視、運用、パッチ適用、障害対応を委託している組織では、委託先の管理経路が自社の攻撃面になります。MITRE ATT&CKのT1199「Trusted Relationship」でも、外部委託先やサービスプロバイダーの既存アクセスが悪用される可能性が整理されています。(MITRE ATT&CK)
「委託先が管理しているから大丈夫」ではなく、「委託先経由の操作を自社でも検証できるか」が重要です。
Webサーバーや業務サーバーにEDRを入れていない組織
Microsoftの調査では、インターネット公開WebサーバーにWebシェルが見つかりましたが、該当サーバーにはEDRのカバレッジがなく、Webシェルの作成経路を確認できなかったと説明されています。(Microsoft)
これは実務上、非常に重要です。EDRが入っていないサーバーでは、侵入後の実行、ファイル作成、PowerShell、WMI、RDPの痕跡を後から追えないことがあります。重要資産だけでなく、攻撃者が足場にしやすいWebサーバーや管理サーバーにも可視性を確保する必要があります。
攻撃の流れ：正規機能を悪用して検知を遅らせる構成
今回の侵入は、派手な破壊活動よりも「通常運用に紛れる」ことを重視した流れでした。Microsoftのタイムラインでは、初期足場の確立、認証情報窃取、Webベースの永続化、横展開、追加の認証情報窃取、永続化の再確立が長期間にわたり行われています。(Microsoft)
| 段階 | 使われた仕組み | 管理者が見るべきポイント |
|---|---|---|
| 初期アクセス | 第三者ITサービス事業者、管理基盤 | 委託先アカウント、管理ツールの操作ログ |
| 実行 | HPE OA、VBScript、PowerShell | 正規ツール経由のスクリプト実行 |
| 認証情報窃取 | ネットワークプロバイダーDLL、パスワードフィルターDLL | LSA、NetworkProvider、DLL署名 |
| 永続化 | Webシェル、認証関連DLL、ngrok | Webファイル改ざん、外向き通信、RDP |
| 横展開 | 取得済み資格情報、RDP、WMI | 高権限アカウントのログオン元と対象 |
| 再侵入 | 既存の足場の再利用 | 一度削除した痕跡の復活、再作成 |
この流れから分かるのは、攻撃者が「脆弱性を突いて終わり」ではなく、管理作業、認証、リモート接続、Webアプリのファイル構成といった複数の層をつないでいたことです。そのため、単一の対策だけでは不十分です。
管理者が最優先で確認すべきWindows設定
LSA通知パッケージに不審なDLLが登録されていないか
パスワードフィルターDLLは、パスワードポリシー適用やパスワード変更通知などに使われるWindowsの正規機構です。Microsoft Learnでは、ドメインアカウントにパスワードフィルターを使う場合、各ドメインコントローラーにDLLを配置し、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa の Notification Packages に登録すると説明されています。(Microsoft Learn)
今回のような攻撃では、この仕組みが悪用されると、パスワード変更イベントを横取りされる可能性があります。まず、ドメインコントローラーで以下を確認してください。
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "Notification Packages"確認時の判断基準は次の通りです。
| 確認項目 | 注意すべき状態 |
|---|---|
| 登録名 | 見覚えのないDLL名、製品名と一致しない名前 |
| 配置場所 | C:\Windows\System32 以外、または不自然な業務フォルダー |
| 署名 | 未署名、署名不正、発行元不明 |
| 変更時刻 | 障害対応や製品更新と一致しない日時 |
| 導入根拠 | 設計書、変更申請、ベンダー資料に記録がない |
正規のパスワードフィルター製品を利用している場合でも、「存在するから正常」と判断しないでください。導入目的、導入日、署名、ハッシュ、対象DC、ベンダーのサポート状況まで照合することが重要です。
ネットワークプロバイダーの登録内容を確認する
今回の事例では、攻撃者がネットワークプロバイダーを登録し、Windowsの認証プロセスを悪用していました。Microsoft Learnでは、ネットワークプロバイダーの ProviderOrder や ProviderPath がレジストリに登録され、MPRがDLLを読み込むことが説明されています。(Microsoft Learn)
確認する主なレジストリは以下です。
reg query "HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order" /v ProviderOrder
reg query "HKLM\SYSTEM\CurrentControlSet\Services" /s /f NetworkProvider特に、既定で見慣れないプロバイダー名が ProviderOrder に追加されている場合は注意が必要です。Microsoftのハンティング例でも、RDPNP や LanmanWorkstation 以外のプロバイダーを抽出し、DLLの署名状態を確認する考え方が示されています。(Microsoft)
LSA保護と認証関連DLLの署名を確認する
LSAは、ローカルおよびリモートサインインの検証やローカルセキュリティポリシーの適用に関わります。Microsoft Learnでは、追加のLSA保護により、保護されていないプロセスによるメモリ読み取りやコード注入を防ぐ助けになると説明されています。また、保護モードでLSAに読み込まれるプラグインはMicrosoft署名が必要とされています。(Microsoft Learn)
ただし、LSA保護を有効にする前には、既存の認証プラグイン、スマートカード関連モジュール、パスワードフィルター、レガシー認証製品が影響を受けないかを検証してください。いきなり全DCへ展開すると、認証障害やパスワード変更処理の失敗につながる可能性があります。
展開時は、次の順で進めるのが現実的です。
| 手順 | 作業内容 | 失敗を防ぐポイント |
|---|---|---|
| 棚卸し | LSA関連DLL、パスワードフィルター、認証製品を一覧化 | DCごとの差分も確認する |
| 署名確認 | DLLの発行元、署名状態、ハッシュを記録 | ベンダー更新版の有無も確認する |
| 検証環境 | 代表的なログオン、RDP、パスワード変更をテスト | サービスアカウントの認証も含める |
| 段階展開 | 一部DCから適用 | 監視強化期間を設ける |
| 本番展開 | 全DCへ展開 | ロールバック手順を用意する |
Windows 11 24H2以降の移行観点：NPLogonNotifyとNPPasswordChangeNotifyにも注意
今回の攻撃で言及された NPLogonNotify と NPPasswordChangeNotify は、Windowsの資格情報管理に関わるAPIです。Microsoft Learnでは、どちらのAPIも非推奨であり、将来のリリースで削除される可能性があると説明されています。(Microsoft Learn)
さらに、Windows 11 バージョン24H2以降では、MPR通知にパスワードペイロードを含める動作が、グループポリシーにより既定で無効化されると案内されています。Microsoftは、この変更の主な理由をセキュリティ強化とし、有効化すると呼び出し元がユーザーのパスワードを取得できるため、パスワード漏えい・収集のリスクがあると説明しています。(Microsoft Learn)
開発者や認証連携製品の担当者は、次の点を確認してください。
| 対象 | 確認内容 |
|---|---|
| 自社開発の資格情報管理DLL | NPLogonNotify、NPPasswordChangeNotify に依存していないか |
| パスワード同期製品 | パスワード変更時の平文パスワード取得に依存していないか |
| レガシーSSO製品 | Windows 11 24H2や将来のWindowsで動作保証があるか |
| グループポリシー | EnableMPRNotifications を有効化していないか、有効化理由が記録されているか |
| 移行計画 | より安全な認証方式、Kerberos、Entra ID連携、製品更新への移行余地があるか |
注意点は、互換性だけを理由に EnableMPRNotifications を安易に有効化しないことです。業務上どうしても必要な場合でも、対象端末、対象ユーザー、利用期間、監査ログ、代替策の期限を決めて運用すべきです。
Microsoft Defenderで確認すべき検知・ハンティング項目
Microsoftは、今回の事例に関連してMicrosoft Defender XDRのAdvanced Huntingクエリ例を示しています。Advanced Huntingは、Microsoft Defender XDRで最大30日分の生データをクエリベースで調査できる脅威ハンティング機能です。(Microsoft Learn)
管理者が特に確認したいのは、次の2系統です。
パスワードフィルターDLLの確認
Microsoftの例では、LSAの Notification Packages に登録されたDLLを確認し、署名が無効または未署名のものを抽出する考え方が示されています。(Microsoft)
確認観点は次の通りです。
| 観点 | 調査の狙い |
|---|---|
Notification Packages の変更 | 不審なパスワードフィルター登録を見つける |
C:\Windows\System32\*.dll の署名状態 | 未署名・署名不正DLLを見つける |
| DC上のDLL作成イベント | 攻撃者による追加タイミングを特定する |
| パスワード変更イベントとの相関 | 認証情報窃取の開始時期を推定する |
ネットワークプロバイダーDLLの確認
ネットワークプロバイダーは正規の仕組みですが、登録内容が不審な場合は認証情報窃取に使われる可能性があります。Microsoftのハンティング例では、ProviderOrder から既定以外のプロバイダーを抽出し、対応するDLLの署名状態を確認しています。(Microsoft)
実務では、Defenderのクエリだけに頼らず、変更管理台帳とも照合してください。たとえば「製品Aの導入時に追加されたDLL」と分かっても、現在も必要なのか、署名は有効か、ベンダーのサポート対象かを確認する必要があります。
EDR、ログ、外向き通信制御の見直しポイント
今回の事例では、Webサーバー、ドメインコントローラー、SQLサーバー、RDP、WMI、SMB、SMTP、ngrokなど、複数の経路が絡んでいました。したがって、対策は「マルウェアを検知する」だけでは足りません。
Microsoftは軽減策として、Microsoft Defender Antivirusのクラウド提供保護、EDRの全エンドポイント展開、既定拒否の外向き通信制御、不要なソフトウェアの削除、Webサーバーの詳細ログと監視、Enterprise Access Modelの実装、SOCとインシデント対応の強化を挙げています。(Microsoft)
EDRは「重要端末」ではなく「攻撃経路」に入れる
Microsoft Defender for EndpointのEDR機能は、攻撃検知、侵害範囲の可視化、対応アクションを支援するものです。Microsoft Learnでは、EDRがプロセス情報、ネットワーク活動、ログオン活動、レジストリやファイルシステム変更などの行動テレメトリを継続的に収集すると説明されています。(Microsoft Learn)
EDR展開の優先順位は、以下のように考えると現実的です。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 最優先 | ドメインコントローラー | 認証情報窃取と権限昇格の中核になる |
| 最優先 | インターネット公開Webサーバー | 初期侵入・Webシェル設置の足場になりやすい |
| 高 | 管理サーバー、監視サーバー | 正規管理ツール経由の実行に悪用される |
| 高 | SQLサーバー、業務サーバー | 高権限アカウントの横展開先になりやすい |
| 中 | 一般端末 | 資格情報窃取や初期感染の起点になり得る |
クラウド保護とサンプル送信を無効化しない
Microsoft Defender Antivirusの「Block at first sight」は、クラウド保護、サンプル送信、Defender Antivirusの更新が有効な場合に、新しいマルウェアを短時間で検出・ブロックするための機能です。Microsoft Learnでは、クラウド保護や自動サンプル送信が前提設定として説明されています。(Microsoft Learn)
一部の企業では、誤検知や情報送信への懸念からクラウド保護を無効化している場合があります。しかし、今回のように攻撃者が独自ツールを目立たせず、正規経路に紛れ込む場合、検知機能を弱める設定はリスクになります。無効化している場合は、理由、対象、代替策、再有効化の条件を文書化してください。
外向き通信は「許可ベース」に近づける
今回の事例では、ngrokによるトンネルがRDPの継続アクセスに使われました。外部からRDPポートを開けていなくても、内部サーバーから外向きにトンネルを張られると、境界型ファイアウォールだけでは検知が難しくなります。(Microsoft)
サーバーの外向き通信は、次のように見直してください。
| 対象 | 推奨される確認 |
|---|---|
| ドメインコントローラー | インターネット直接通信を原則不要として制限 |
| Webサーバー | 必要な更新先、監視先、API先のみ許可 |
| SQLサーバー | 外部通信を最小化し、例外を申請制にする |
| 管理サーバー | 委託先や管理クラウドへの接続先を明文化 |
| 全サーバー | ngrokなどトンネル系サービスへの通信を監視・制御 |
「通信をすべて遮断する」ではなく、「業務上必要な通信を把握し、それ以外を検知または拒否する」方針が現実的です。
外部委託先・管理ツールの棚卸しで確認すべきこと
今回のテーマである「信頼境界の侵食」は、技術設定だけでは解決しません。委託契約、運用設計、アカウント管理、監査ログの責任分界も含めて見直す必要があります。
確認すべき項目は次の通りです。
| 分野 | 確認内容 | 見落としやすい失敗 |
|---|---|---|
| アカウント | 委託先ごとの専用アカウントになっているか | 共有管理者アカウントを複数社で使っている |
| 権限 | 必要なサーバー・作業だけに限定されているか | ドメイン管理者権限を常時付与している |
| MFA | 管理アクセスに多要素認証があるか | VPNだけで安全と判断している |
| 操作ログ | 誰が、どこから、何を実行したか追えるか | 管理ツール内のログしか残していない |
| ツール | 監視・自動化ツールの実行内容を確認できるか | 正規ツールのスクリプト実行を監視していない |
| 契約 | インシデント時のログ提供・初動連携が決まっているか | 侵害後にログ開示範囲で揉める |
特に、委託先が利用する管理ツールは「社外から入る経路」ではなく「自社環境内で高権限を持つ実行基盤」として扱うべきです。管理ツールのサーバー、エージェント、配布スクリプト、認証情報保管場所、操作ログは、ドメインコントローラーに近い重要度で管理してください。
開発者が注意すべき実装・移行ポイント
Windows向けの認証連携、パスワード同期、業務アプリのシングルサインオン、管理エージェントを開発・保守している場合、今回の事例は運用担当だけの問題ではありません。
認証情報を平文で扱う設計を避ける
NPLogonNotify や NPPasswordChangeNotify のような認証イベントに関わる仕組みは、互換性のために残っている場合があります。しかし、Microsoftが非推奨化や既定無効化の方向を示している以上、平文パスワード取得に依存する設計は長期的なリスクになります。(Microsoft Learn)
移行時は、次の順で整理してください。
| 確認項目 | 判断基準 |
|---|---|
| 平文パスワードが必要か | ハッシュ、トークン、フェデレーションで代替できないか |
| 既存APIが非推奨か | Microsoft Learnでサポート状況を確認する |
| DLLの署名要件を満たすか | LSA保護有効化時に読み込めるか |
| 監査ログが残るか | 認証情報に触れる処理の実行者・日時・対象を追えるか |
| 顧客環境で無効化される可能性があるか | Windows 11 24H2以降の既定値やGPOを確認する |
管理自動化スクリプトは「実行できるか」より「説明できるか」を重視する
今回の攻撃では、VBScriptやPowerShellが正規の管理チャネルから実行されました。管理自動化は便利ですが、スクリプトの中身、実行対象、実行者、変更履歴が曖昧だと、攻撃者にとって隠れ場所になります。
開発者やSRE、運用自動化担当者は、以下を整備してください。
| 項目 | 実装・運用のポイント |
|---|---|
| スクリプト署名 | 本番で実行するPowerShellは署名や実行ポリシーを検討する |
| 変更管理 | Gitなどで変更履歴を残し、緊急変更も後追い記録する |
| 実行ログ | 実行者、対象ホスト、引数、結果をログ化する |
| 最小権限 | スクリプト専用アカウントを用意し、不要な管理者権限を避ける |
| 配布経路 | 管理ツール経由の配布先を限定し、例外を監査する |
「いつも動いているスクリプトだから安全」ではありません。攻撃者は、まさにその“いつもの動き”に紛れます。
すぐ実施できる確認チェックリスト
まずは、以下の順で確認すると効果的です。すべてを一度に完璧にするより、認証情報窃取と横展開に直結する箇所から着手してください。
| 優先度 | 確認項目 | 対象 |
|---|---|---|
| 高 | Notification Packages の登録内容を確認 | 全ドメインコントローラー |
| 高 | ProviderOrder とネットワークプロバイダーDLLを確認 | DC、重要サーバー |
| 高 | EDR未導入のWebサーバー・管理サーバーを洗い出す | サーバー全体 |
| 高 | 委託先アカウントの権限、MFA、ログを確認 | AD、VPN、管理ツール |
| 高 | ngrokなどトンネル系通信の痕跡を確認 | プロキシ、FW、EDR |
| 中 | PowerShell、VBScript、WMIの実行ログを確認 | 管理対象サーバー |
| 中 | LSA保護の有効化可否を検証 | DC、認証関連サーバー |
| 中 | Windows 11 24H2以降のMPR通知設定を確認 | クライアント、認証製品 |
| 中 | 外向き通信を許可ベースへ近づける | サーバーネットワーク |
| 中 | 委託契約にログ提供・初動対応条項があるか確認 | 契約・運用設計 |
展開時の注意点：止めてはいけない認証系こそ段階的に進める
今回の対策は、ドメインコントローラー、LSA、認証API、管理ツール、EDR、外向き通信制御に関わります。どれも重要ですが、影響も大きい領域です。特に認証関連DLLの削除、LSA保護の有効化、外向き通信の遮断は、十分な検証なしに実施すると業務停止につながります。
安全に進めるには、以下の順序がおすすめです。
| フェーズ | 実施内容 |
|---|---|
| 調査 | レジストリ、DLL、アカウント、管理ツール、EDR導入状況を棚卸し |
| 照合 | 変更管理台帳、ベンダー資料、契約内容と一致するか確認 |
| 検知強化 | Defender XDR、SIEM、FW、プロキシで監視ルールを追加 |
| 検証 | テスト環境または一部サーバーでLSA保護や通信制御を試す |
| 段階展開 | DC、Webサーバー、管理サーバーの優先度順に展開 |
| 定着 | 月次レビュー、委託先アクセス棚卸し、ハンティング定例化 |
セキュリティ対策でありがちな失敗は、「一度確認して終わり」にすることです。今回の攻撃の本質は長期潜伏です。確認作業も一回限りではなく、定期的な差分確認として運用に組み込む必要があります。
まとめ：Windows管理者は“正規の操作”を検証できる状態にする
今回のMicrosoft公式情報から読み取るべきポイントは、Windowsに新しい脆弱性が見つかったという単純な話ではありません。攻撃者は、第三者サービス事業者、正規の管理ツール、Windowsの認証拡張機構、RDP、WMI、トンネル通信を組み合わせ、通常運用に紛れて侵入を長期化させました。
管理者が次に取るべき行動は明確です。まず、ドメインコントローラーの Notification Packages とネットワークプロバイダー登録を確認してください。次に、EDR未導入のWebサーバーや管理サーバーを洗い出し、委託先アカウントの権限と操作ログを見直します。あわせて、Windows 11 24H2以降の認証関連APIの既定動作や非推奨化を踏まえ、平文パスワード取得に依存する古い実装を移行対象として扱うべきです。
信頼できる委託先や正規ツールを使うこと自体は問題ではありません。問題は、それらの動作を自社で検証できない状態です。Windows環境の防御では、これから「信頼する」だけでなく、「信頼している経路を継続的に検証する」運用が前提になります。
コメント