Microsoft Defender / Exposure Management を使うSOCチームやID防御担当者にとって、今後さらに重要になる考え方が露出ベースの封じ込めです。これは、攻撃者が実際に悪用したアカウントや端末だけを後追いで止めるのではなく、「この端末上で認証情報が露出した可能性が高い」「このIDは次に使われる危険が高い」と判断した段階で、先回りして横展開を止める防御アプローチです。
2026年4月17日にMicrosoftが公開した事例では、Active Directoryドメイン侵害後の攻撃で、Microsoft Defender の Predictive shielding が高権限IDの悪用を事前に封じ、ラテラルムーブメントを抑え込んだ流れが紹介されました。ポイントは「侵害後に何を検知したか」だけでなく、「侵害によって何が露出し、次にどこへ攻撃が広がるか」を防御判断に組み込んでいる点です。(Microsoft)
Microsoft Defender / Exposure Management の最新動向として注目すべき理由
Microsoft Defender の防御は、従来の「アラートを確認してから対応する」運用だけではなく、XDRの相関分析、Exposure Management の攻撃パス把握、Predictive shielding による先回りの封じ込めへと広がっています。
特にSOCリーダーやID防御担当者が注目すべき理由は、ドメイン侵害や認証情報窃取のような攻撃では、攻撃者の横展開速度が人間の調査速度を上回ることが珍しくないためです。
Microsoftの事例では、攻撃者はインターネット公開IISサーバーへの侵入、Webシェル設置、権限昇格、Mimikatzによる認証情報窃取、ドメインコントローラーへのリモートタスク作成、NTDS関連活動、Exchange権限の悪用へと進みました。さらに、後続フェーズではパスワードスプレーにより少なくとも14台のサーバーへアクセスを広げたと説明されています。(Microsoft)
このようなケースでは、「悪用されたアカウントを止める」だけでは足りません。攻撃者は別の認証情報、別のサーバー、別の管理経路へ移ります。だからこそ、防御側は攻撃者が次に使いそうな露出済みIDや経路まで含めて封じ込める必要があります。
露出ベースの封じ込めとは何か
露出ベースの封じ込めとは、侵害後の環境で「すでに悪用されたもの」だけでなく、「悪用される前だが、攻撃者の手に渡った可能性が高いもの」を防御対象にする考え方です。
たとえば、次のような状況が該当します。
| 状況 | 従来型の対応 | 露出ベースの封じ込め |
|---|---|---|
| 端末上でMimikatzやLSASSダンプの兆候を検知 | 実際に悪用されたアカウントを無効化・調査 | その端末にログオンしていた高権限IDもリスク対象として制限 |
| ドメインコントローラーへの不審なリモート操作 | 実行元端末や実行アカウントを調査 | ドメイン管理者、サービスアカウント、同期アカウントの露出可能性を評価 |
| パスワードスプレーで複数サーバーへ拡大 | 成功したログオンを追跡 | 再利用されそうな資格情報と横展開経路を先に狭める |
| ExchangeやEntra Connectへの到達を確認 | 対象サーバーの証跡調査 | メールボックス権限、同期資格情報、特権委任の悪用可能性を封じる |
重要なのは、露出ベースの封じ込めは「すべてを止める」運用ではないことです。ドメインコントローラー、ID基盤、業務アプリ、サービスアカウントを無差別に停止すれば、業務影響が大きくなります。
目指すべきは、攻撃パスと露出情報を使って、止めるべき対象を絞り込むことです。
Predictive shielding が示した「事前封じ込め」の実効性
Microsoft Learnでは、Predictive shielding は Microsoft Defender の自動攻撃妨害を拡張する機能として説明されています。攻撃の進行を予測し、必要な箇所に限定して保護を適用することで、攻撃者が重要資産へ到達する前に経路を狭める考え方です。(Microsoft Learn)
2026年4月17日の事例で特に重要なのは、Predictive shielding が実際に悪用されたアカウントだけでなく、同じ侵害面に紐づくコンテキスト上のIDにも封じ込めを適用した点です。Microsoftは、認証情報ダンプや侵害ホストからの再利用といった露出シグナルが現れた際、新しいサインインやインタラクティブなピボットをブロックしたと説明しています。(Microsoft)
さらに、高位のEnterprise AdminやSchema Adminに相当する資格情報が露出した場面では、悪用前に封じ込めが行われ、通常なら深刻な権限拡大につながり得る展開を防いだとされています。(Microsoft)
ここから読み取れる実務上の示唆は明確です。
侵害後防御では、悪用の証拠を待つだけでは遅い場面があるということです。特にActive Directory、Microsoft Entra Connect、Exchange、バックアップ基盤、管理用ジャンプサーバーのような領域では、認証情報が露出した時点で攻撃者の選択肢が急増します。
なぜドメイン侵害後の防御で露出情報が重要になるのか
ドメイン侵害が難しいのは、単に高権限アカウントが危険だからではありません。問題は、攻撃者が一度ドメインレベルの認証情報や権限に到達すると、複数の経路を使って環境全体へ影響を広げられることです。
Microsoftのブログでは、ドメイン管理権限を得た攻撃者が、グループメンバーシップやACLの変更、Kerberosチケットの作成、ディレクトリシークレットの複製、GPO経由のポリシー展開などを行える可能性があると説明されています。(Microsoft)
この段階で防御側が抱える制約は大きくなります。
- ドメインコントローラーを簡単に停止できない
- サービスアカウントを一斉に無効化すると業務停止につながる
- krbtgtローテーション、GPO確認、ACL検証などの復旧作業に時間がかかる
- 攻撃者は調査完了を待たずに別の認証情報へ切り替える
つまり、ドメイン侵害後の勝負は「完全な調査が終わってから対応する」ではなく、不確実性が残る中で、どこを止めるべきかを判断する運用になります。
そこで役立つのが Exposure Management の考え方です。
Exposure Management は「どこを止めるべきか」を判断する土台になる
Microsoft Security Exposure Management は、エンドポイント、クラウドリソース、外部攻撃面などにまたがるセキュリティ態勢を統合的に把握し、攻撃面や露出リスクを管理するためのソリューションです。公式ドキュメントでは、デバイス、ID、クラウド資産、外部攻撃面を含む統合的な露出グラフを提供すると説明されています。(Microsoft Learn)
露出ベースの封じ込めにおいて特に重要なのは、次の3つです。
攻撃パス
攻撃パスは、攻撃者が入口から重要資産へ到達するまでに利用し得る資産や技術のつながりを示します。Microsoft Security Exposure Management では、収集された資産・ワークロード情報をもとに攻撃パスを生成し、攻撃者が悪用し得る弱点を可視化します。(Microsoft Learn)
SOCの現場では、アラート単体よりも攻撃パスを見た方が優先順位を決めやすくなります。
たとえば、同じ「脆弱なサーバー」でも、次のように判断が変わります。
| サーバーの状態 | 優先度の考え方 |
|---|---|
| 重要資産へ到達する経路にない検証用サーバー | パッチ適用や分離は必要だが、即時封じ込めの優先度は相対的に低い |
| ドメイン管理者が頻繁にログオンする管理サーバー | 認証情報露出時の影響が大きいため、封じ込め・調査を優先 |
| Entra Connectやバックアップ基盤へ到達可能な中継サーバー | 攻撃者の次のピボット先になりやすく、横展開経路として重点監視 |
| 複数の攻撃パスが交差するチョークポイント | 1カ所の対策で複数経路を減らせるため、改善効果が高い |
重要資産
露出管理では、何を重要資産として扱うかが防御判断を左右します。
ID防御の観点では、重要資産はサーバーだけではありません。次のようなID・システムも含めて考える必要があります。
- Domain Admins、Enterprise Admins、Schema Adminsに関係するアカウント
- Microsoft Entra Connect サーバーと同期用資格情報
- Exchange管理権限を持つアカウント
- バックアップ管理者、EDR管理者、クラウド管理者
- GPOを編集できるアカウント
- 管理用ジャンプサーバー
- 特権IDがログオンする運用端末
攻撃者にとって価値が高いのは、「管理者」と名の付くアカウントだけではありません。バックアップ、メール、同期、監視、ソフトウェア配布、証明書、CI/CDなど、環境全体へ影響できる権限を持つものは重要資産として扱うべきです。
チョークポイント
チョークポイントは、複数の攻撃パスが集中する資産や経路です。Microsoftのドキュメントでも、Attack Path dashboard は攻撃パス、チョークポイント、重要資産を把握し、防御の優先順位付けに使えると説明されています。(Microsoft Learn)
実務では、すべての脆弱性や設定不備を一度に直すことは困難です。だからこそ、チョークポイントを押さえることが重要です。
たとえば、次のような対策は費用対効果が高くなりやすいです。
- 管理者が一般端末へログオンしない運用に変える
- 特権IDのログオン先を専用端末・専用サーバーに限定する
- Entra Connect、バックアップ、ドメインコントローラーへの管理経路を分離する
- GPO編集権限を棚卸しし、不要な委任を削除する
- サービスアカウントの対話型ログオンを禁止する
- 重要サーバーへのSMB、WinRM、RDPの到達範囲を絞る
侵害後防御で見るべきシグナル
露出ベースの封じ込めを運用に組み込むには、SOCが見るべきシグナルを事前に整理しておく必要があります。特にID中心の攻撃では、以下のようなイベントを単体で終わらせず、攻撃パスや露出情報と組み合わせて判断します。
| シグナル | 何を疑うべきか | 初動で確認すること |
|---|---|---|
| LSASSダンプ、Mimikatz、comsvcs.dll MiniDump | 端末上の認証情報露出 | その端末にログオンしていた特権ID、サービスアカウント、管理者の一覧 |
| NTDS関連操作、ntdsutil、IFM、Volume Shadow Copy | ドメイン資格情報の大量窃取 | ドメインコントローラー上の実行元、実行アカウント、作成ファイル |
| Impacket、PsExec、WmiExec、atexec.py | リモート実行・横展開 | 接続元、接続先、使用アカウント、同時刻の認証失敗 |
| パスワードスプレー | 使い回しパスワードの探索 | 成功ログオン先、対象アカウント、ログオン元IP |
| Exchange権限変更、ApplicationImpersonation、Add-MailboxPermission | メールボックス横断アクセス | 付与された権限、対象メールボックス範囲、委任元アカウント |
| Entra Connectサーバーへのアクセス | クラウド同期資格情報の窃取 | 同期アカウント、接続元、PowerShellやリモート管理の痕跡 |
| GPO変更、ACL変更、グループメンバー変更 | 永続化・権限拡大 | 変更者、変更対象、直前の認証イベント |
ここで大切なのは、アラート名だけで判断しないことです。
たとえば「LSASSダンプを検知した端末」が一般ユーザー端末なら、影響範囲は限定的かもしれません。しかし、その端末にドメイン管理者がログオンしていた場合、封じ込め対象は端末だけでは不十分です。
SOCリーダーが決めるべき運用ルール
露出ベースの封じ込めは、ツールを有効化するだけでは機能しません。SOCリーダーは、事前に「どの条件でどこまで自動化を許容するか」を決める必要があります。
封じ込め判断を3段階に分ける
実務では、すべての対応を同じ強度で実施すると業務影響が大きくなります。以下のように段階化すると運用しやすくなります。
| レベル | 条件例 | 対応例 |
|---|---|---|
| 観測・強化 | 不審な認証、軽微な探索、単発の失敗 | 監視強化、追加ログ取得、該当資産の優先調査 |
| 限定封じ込め | 認証情報窃取の高信頼シグナル、侵害端末上の特権ID露出 | ユーザー封じ込め、端末隔離、対象経路の一時ブロック |
| 強制封じ込め | ドメインコントローラー操作、NTDS窃取、特権IDの悪用前露出 | 高権限IDの制限、管理経路遮断、復旧手順の即時起動 |
このルールを事前に決めておくと、インシデント中に「止めるべきか、待つべきか」で迷う時間を減らせます。
業務影響を前提にした例外管理を用意する
自動封じ込めに対する現場の最大の不安は、業務停止です。特にグローバル企業では、地域・時差・業務時間が異なるため、日本時間の夜間に海外拠点の業務が止まる可能性もあります。
そのため、次のような例外管理を用意しておくべきです。
- 24時間稼働が必要な基幹システムの一覧
- 封じ込め時に連絡すべき業務責任者
- 一時解除の承認者
- 解除後に必ず実施する再評価項目
- 封じ込め対象から除外するのではなく、代替コントロールを設定するルール
注意したいのは、重要システムを安易に「自動対応の対象外」にすることです。攻撃者は重要システムほど狙います。完全除外ではなく、ネットワーク分離、管理経路制限、特権IDの分離、追加監視などで代替防御を設計する必要があります。
ID防御担当者がすぐ確認すべきポイント
ID防御担当者は、Predictive shielding や Exposure Management の導入有無にかかわらず、まず「露出したときに危険なID」を整理することから始めるべきです。
特権IDのログオン先を棚卸しする
最初に確認すべきなのは、特権IDがどの端末・サーバーにログオンしているかです。
特権IDが一般端末、公開サーバー、開発サーバー、ファイルサーバーに日常的にログオンしている場合、1台の侵害がドメイン全体のリスクに直結します。
確認する観点は次の通りです。
- Domain Adminsなどの高権限グループのメンバー
- 過去30〜90日で特権IDがログオンした端末
- 管理者がRDP、WinRM、SMB経由で接続した先
- サービスアカウントの対話型ログオン有無
- 退職者・異動者・旧運用アカウントの残存
- 緊急用アカウントの利用履歴と保管方法
管理経路を分離する
露出ベースの封じ込めを有効にするには、普段から攻撃パスを短くしないことが重要です。特権IDがどこからでも使える状態では、封じ込め対象が広がりすぎます。
推奨される方向性は次の通りです。
- ドメイン管理は専用の管理端末からのみ実施する
- 管理端末からインターネット閲覧やメール利用をしない
- サーバー管理者、ID管理者、クラウド管理者の権限を分ける
- Entra Connectやバックアップ基盤への接続元を限定する
- 管理用プロトコルを必要な範囲だけ許可する
- 特権IDの常時付与を避け、必要時だけ昇格する
サービスアカウントを「見えない特権」として扱う
サービスアカウントは、人間の管理者より見落とされがちです。しかし、攻撃者にとっては非常に価値があります。パスワードが長期間変更されていない、複数サーバーで使い回されている、過剰な権限を持っている、といった状態は横展開の燃料になります。
最低限、次を確認してください。
- どのサーバーで使われているか
- 対話型ログオンが許可されていないか
- ドメイン管理権限を持っていないか
- パスワードローテーション方針があるか
- gMSAなど、より安全な運用へ移行できるか
- アプリ停止時の影響範囲が文書化されているか
Microsoft Defender で確認したい設定と運用ポイント
Microsoft Defender XDR の自動攻撃妨害は、複数のMicrosoft Defender製品の信号を相関し、攻撃中の侵害資産を自動的に封じ込める仕組みです。Microsoft Learnでは、エンドポイント、ID、メール、コラボレーションツール、SaaSアプリなどの信号を相関し、攻撃者が利用している資産を特定して対応すると説明されています。(Microsoft Learn)
Predictive shielding を含む運用を検討する場合は、以下を確認します。
Microsoft Defender for Endpoint P2 のカバレッジ
Microsoftのブログでは、Predictive shielding は前提条件を満たす Microsoft Defender for Endpoint P2 顧客向けの強化機能として利用可能と説明されています。(Microsoft)
実務では、ライセンスだけでなく、対象端末・サーバーがDefender for Endpointにオンボードされているかが重要です。未オンボードの重要サーバーが多いと、露出情報や封じ込めの精度が下がります。
Defender for Identity センサーの展開
Predictive shielding の管理ドキュメントでは、Microsoft Defender for Identity センサーを使用することで、ユーザー名、Active Directory詳細、グループメンバーシップなどのメタデータが追加され、セキュリティインサイトとカバレッジの向上に役立つとされています。(Microsoft Learn)
ID中心の攻撃を扱うなら、ドメインコントローラーへのセンサー展開は優先度が高い項目です。
インシデント画面とAction centerでの確認
Predictive shielding が適用されたインシデントは、Defenderポータル上でタグやインシデントグラフ、Activitiesタブ、Action centerから確認できます。ドキュメントでは、Predictive Shieldingタグによるフィルター、適用されたアクション、ポリシーステータス、トリガーとなったアラートを確認できると説明されています。(Microsoft Learn)
SOC運用では、単に「自動で止まった」と記録するだけでは不十分です。次の情報をインシデントレビューに残しましょう。
- どのシグナルが封じ込めのトリガーになったか
- どのID・端末・ポリシーが対象になったか
- ブロックされたサインインや横展開の内容
- 業務影響の有無
- 解除判断の根拠
- 恒久対策として削減すべき攻撃パス
失敗しやすいポイント
露出ベースの封じ込めは強力ですが、運用を誤ると効果が薄くなります。特に以下の失敗は避けるべきです。
アラート対応だけで満足する
攻撃者が使ったアカウントを無効化しても、同じ端末上で別の特権IDが露出していれば再侵入されます。
対応チケットには、「対象アラート」だけでなく「露出した可能性があるID」「到達可能だった重要資産」「次に使われそうな経路」を必ず書くべきです。
重要資産の定義が曖昧なまま運用する
Exposure Management の価値は、重要資産が正しく定義されているほど高まります。ドメインコントローラーだけを重要資産にしていると、Entra Connect、Exchange、バックアップ、証明書基盤、管理端末などのリスクを見落とします。
特にハイブリッド環境では、オンプレミスADとクラウドIDの境界にある資産を重点的に扱う必要があります。
自動封じ込めを「オンかオフか」で考える
自動化の議論は、しばしば「業務影響が怖いから無効」「攻撃が怖いから全面有効」の二択になりがちです。しかし現実的には、対象、条件、解除手順、例外管理を設計して段階的に適用する方が安全です。
まずは高リスク領域から始めるとよいでしょう。
- ドメイン管理者がログオンする端末
- 外部公開サーバー
- Entra Connectサーバー
- Exchange管理系
- バックアップサーバー
- EDRや管理ツールの管理サーバー
復旧手順が整っていない
封じ込めはゴールではありません。攻撃者を止めた後に、認証情報のリセット、セッション失効、GPO確認、ACL検証、サービスアカウント更新、不要権限削除まで進めなければ、再侵害の余地が残ります。
特にドメイン侵害では、復旧手順を平時から文書化し、演習しておくことが重要です。
導入・見直しの実践ステップ
これから Microsoft Defender / Exposure Management を使って露出ベースの封じ込めを強化するなら、次の順序で進めると現実的です。
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 1 | 重要資産を定義する | DC、Entra Connect、Exchange、バックアップ、管理端末、特権ID一覧 |
| 2 | 特権IDのログオン実態を確認する | 特権IDがログオンした端末・サーバーのリスト |
| 3 | Defender for Endpoint / Identity のカバレッジを確認する | 未オンボード端末、センサー未展開DCの一覧 |
| 4 | Attack path とチョークポイントを確認する | 優先的に潰す攻撃経路のリスト |
| 5 | 自動封じ込めの適用範囲を決める | 対象資産、例外、承認者、解除手順 |
| 6 | インシデントレビュー項目を更新する | 露出ID、ブロック経路、業務影響、恒久対策の記録項目 |
| 7 | 演習する | 認証情報窃取、DC侵害、Entra Connect到達を想定した机上演習 |
最初から全社一斉に完璧な運用を目指す必要はありません。まずは「高権限IDが露出したら、どこまで自動または準自動で止めるか」を決めるだけでも、侵害後の対応速度は大きく変わります。
これからの侵害後防御は「検知後対応」から「露出後封じ込め」へ
2026年4月17日のMicrosoftの事例が示したのは、Predictive shielding の個別機能だけではありません。より大きな流れとして、侵害後防御の中心が「何が悪用されたか」から「何が露出し、次に何が悪用されるか」へ移っていることです。
SOCリーダーは、アラート処理の効率化だけでなく、攻撃パス、重要資産、チョークポイント、特権IDの露出を使った封じ込め判断を運用設計に組み込む必要があります。ID防御担当者は、特権IDのログオン先、サービスアカウント、管理経路を棚卸しし、攻撃者が横展開しにくい構造へ変えていくべきです。
次に取るべき行動はシンプルです。自社環境で「侵害されたら最も困るIDと資産」を10個挙げ、それぞれについて「どの端末に露出し得るか」「どの攻撃パスで到達されるか」「露出時にどこまで封じ込めるか」を確認してください。露出ベースの封じ込めは、ツールの機能ではなく、侵害後も被害を広げないための防御戦略そのものです。
コメント