Microsoft Defenderの自動攻撃中断（automatic attack disruption）は、ランサムウェアやBECなどの進行中の攻撃を高い確度で検知したとき、侵害されたデバイスやユーザーを自動的に封じ込めるMicrosoft Defender XDRの機能です。今回確認すべきポイントは、「有効化するかどうか」だけではありません。ライセンス、Defender各製品の展開範囲、デバイスグループの自動化レベル、IdentityやOffice 365側の監査設定までそろっていないと、期待した範囲で自動封じ込めが動かない可能性があります。(Microsoft Learn)
特に管理者は、Microsoft Defender for Endpoint Plan 2相当の要件、デバイス探索の標準探索、Sense Agentのバージョン、Defender for Identityの権限、Exchange Onlineメールボックスの監査、Action centerでの確認体制を優先して点検してください。開発者や運用自動化の担当者は、アカウント無効化やデバイス封じ込めを別の自動化が上書きしないよう、既存のID管理・ヘルプデスク・SOAR連携を見直す必要があります。
Microsoft Defender XDRの自動攻撃中断とは
Microsoft Defender XDRの自動攻撃中断は、単一のマルウェア検知や単純なIOCブロックではなく、エンドポイント、ID、メール、SaaSアプリなど複数のシグナルを相関し、攻撃全体をインシデント単位で判断して封じ込める仕組みです。Microsoftの公式説明では、攻撃中に攻撃者が利用している侵害済み資産を自動的に封じ込め、横展開や被害拡大を早期に抑えることが目的とされています。(Microsoft Learn)
実務上の価値は、SOC担当者が調査を始める前に「攻撃者が次に使いそうな足場」を止められる点です。たとえば、侵害されたユーザーアカウントでメールボックス操作や端末アクセスが続いている場合、Defender XDRが高い確度で攻撃を判断すると、ユーザーの無効化やデバイス封じ込めといった応答が自動で実行されます。
ただし、これは「何でも自動で復旧してくれる機能」ではありません。自動攻撃中断は被害拡大を止めるための初動対応であり、調査、根本原因の除去、資産の復旧判断は引き続きセキュリティ運用チームが行います。
今回の公式情報で管理者が見るべき変更点・確認ポイント
2026年6月時点のMicrosoft Learnの内容では、Microsoft Defender XDRで自動攻撃中断を構成する前提条件が細かく整理されています。ポイントは、Defender XDR単体のスイッチではなく、関連するDefender製品の展開状況と自動応答レベルが保護範囲を左右することです。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント | 不備がある場合の影響 |
|---|---|---|
| ライセンス | Microsoft 365 E5/A5、Microsoft Defender Suite add-on、Defender for Endpoint Plan 2など対象ライセンスを確認する | 自動攻撃中断や関連するXDR機能を利用できない、または一部機能に制限が出る |
| Defender製品の展開範囲 | Endpoint、Office 365、Identity、Cloud Appsなど、攻撃シナリオに必要な製品が展開済みか確認する | 検知に使えるシグナルや実行できる応答アクションが限定される |
| Device Discovery | Microsoft Defender for Endpointのデバイス探索を標準探索にする | Contain Deviceの自動開始に必要な前提を満たせない |
| デバイスグループ | Remediation levelを確認し、原則として自動修復が可能なレベルにする | 自動調査や修復が承認待ちになり、攻撃中断の効果が弱まる |
| Identity連携 | Defender for Identityの監査、アクションアカウント、センサー配置を確認する | オンプレミスADアカウントの無効化などが期待通り動かない |
| Office 365連携 | Exchange Online、メールボックス監査、Safe Linksポリシーを確認する | BECやメール起点の攻撃で必要な検知・対応が不足する |
| 通知・監査 | Action centerとメール通知ルールを整備する | 自動封じ込め後の確認、承認、復旧判断が遅れる |
重要なのは、「自動攻撃中断を入れる」ではなく「どの攻撃シナリオで、どの資産に対して、どの自動応答が実行できる状態か」を棚卸しすることです。
影響範囲はエンドポイントだけではない
Microsoft Defenderという名前から端末保護だけを想像しがちですが、自動攻撃中断の影響範囲はエンドポイント、ID、メール、SaaSアプリにまたがります。Defender XDRは複数のMicrosoftセキュリティ製品のシグナルを相関し、必要に応じて関連製品の応答アクションを使います。(Microsoft Learn)
エンドポイントへの影響
Defender for Endpointでは、疑わしいデバイスの通信を制限する「デバイス封じ込め」や、プレビュー機能としてのデバイス分離が自動応答の例として示されています。公式情報では、デバイス封じ込めはMicrosoft Defender for Endpointの機能を基にしており、疑わしいデバイスとの送受信通信をブロックするものと説明されています。(Microsoft Learn)
管理者が注意すべき点は、業務端末が突然ネットワークから切り離されたように見えるケースです。ヘルプデスクが「ネットワーク障害」と誤認すると、調査前に端末を戻してしまう恐れがあります。端末が封じ込められた場合は、まずMicrosoft Defenderポータルのインシデント画面とAction centerを確認する運用にしておきましょう。
ID・アカウントへの影響
自動攻撃中断では、侵害されたユーザーの無効化や、ユーザーの一時的な封じ込めが行われる場合があります。Defender for Identityは、Active Directory、Microsoft Entra ID、統合されたIDプロバイダーのユーザーに対する修復アクションを支援します。ユーザーがActive Directoryに存在する場合、Defender for Identityセンサーが動作するドメインコントローラー経由でアクションが実行される点も押さえておく必要があります。(Microsoft Learn)
ここで失敗しやすいのが、人事システムやID管理ツールによる「有効な社員アカウントは常に有効化する」という自動化です。公式情報でも、攻撃中断によって無効化されたアカウントを別の自動化が意図せず再有効化しないか確認する必要があるとされています。(Microsoft Learn)
メール・コラボレーションへの影響
Defender for Office 365側では、メールボックスがExchange Onlineにホストされていること、メールボックス監査ログが有効であること、最低限必要な監査イベントが取得されていることなどが前提になります。公式情報では、MailItemsAccessed、UpdateInboxRules、MoveToDeletedItems、SoftDelete、HardDeleteなどの監査イベントが挙げられています。(Microsoft Learn)
BEC対策では、攻撃者が受信トレイルールを作成したり、メールを削除したりする操作の可視化が重要です。メールボックス監査が不十分だと、攻撃のつながりをDefender XDRが十分に判断できず、自動中断の精度や範囲に影響する可能性があります。
Cloud Apps・SaaSへの影響
Microsoft Defender for Cloud Appsを攻撃中断のシグナルとして活用するには、Microsoft Office 365コネクタとの接続やApp Governanceの有効化が前提として示されています。SaaSアプリ側のシグナルを使う攻撃シナリオでは、Cloud Appsの展開が検知範囲に直結します。(Microsoft Learn)
「Endpointは導入済みだから大丈夫」と判断せず、クラウドアプリの利用実態に合わせてCloud Apps側の連携も確認してください。
設定前に確認すべき前提条件
自動攻撃中断は、事前準備が不十分なまま有効化すると「動くはずの場面で動かない」「動いた後に現場が混乱する」という問題が起きやすい機能です。設定前に、次の順番で確認すると抜け漏れを減らせます。
ライセンス要件を確認する
Microsoft Defender XDRの利用には、Microsoft 365 E5/A5、Microsoft 365 E3とDefender Suite add-on、Defender for Endpoint、Defender for Identity、Defender for Cloud Apps、Defender for Office 365 Plan 2、Microsoft Defender for Businessなど、複数の対象ライセンスが示されています。また、Microsoft Defender XDRの前提条件ページでは、自動攻撃中断にMicrosoft Defender for Endpoint Plan 2が必要と明記されています。(Microsoft Learn)
まずMicrosoft 365管理センターで、対象ユーザーやデバイスに必要なライセンスが割り当てられているか確認してください。ライセンスがテナントに存在していても、対象ユーザーに割り当てられていなければ実運用で期待通りにならない場合があります。
Defender製品の展開範囲を確認する
自動攻撃中断の保護範囲は、Defender製品の展開範囲に左右されます。公式情報でも、展開範囲が広いほど保護カバレッジが広がり、特定の検知にDefender for Cloud Appsのシグナルが必要な場合は該当製品が必要になる、またデバイスを自動封じ込めするにはDefender for Endpointが必要になると説明されています。(Microsoft Learn)
確認すべき観点は次のとおりです。
- 重要端末がDefender for Endpointにオンボードされているか
- ドメインコントローラーにDefender for Identityセンサーが展開されているか
- Exchange Onlineメールボックスの監査が有効か
- Defender for Cloud AppsがMicrosoft 365と接続されているか
- App Governanceが必要なテナントで有効化されているか
特に買収・統合後の環境や、部門ごとに端末管理が分かれている環境では、未オンボード端末や対象外グループが残りやすいので注意が必要です。
Microsoft Defender for Endpointのデバイスグループを確認する
Microsoft Defenderポータルで、System > Settings > Endpoints > Device groupsを開き、各デバイスグループのRemediation levelを確認します。公式情報では、Full - remediate threats automaticallyの利用が推奨されています。また、Semiの自動化レベルでも手動承認なしで自動攻撃中断をトリガーできる一方、No automated responseは自動封じ込めから除外する設定として扱われ、限定的なデバイスにのみ使うべきとされています。(Microsoft Learn)
| 自動化レベル | 実務上の使いどころ | 注意点 |
|---|---|---|
| Full – remediate threats automatically | 一般的な業務端末、標準管理端末 | 自動修復が動く前提で、ヘルプデスクとSOCの連携手順を整える |
| Semi | サーバーや一部の重要端末で、慎重な修復判断が必要な場合 | 設定によって承認待ちが増えるため、運用担当者の確認遅れに注意する |
| No automated response | 例外的な検証端末、特殊な業務要件の端末 | 攻撃中断の効果を下げるため、広範囲に適用しない |
また、自動攻撃中断はMicrosoft Defender Antivirusの動作状態がActive、Passive、EDR Block Modeのいずれであってもデバイスに作用できると説明されています。ウイルス対策の状態だけを見て「対象外」と判断しないようにしましょう。(Microsoft Learn)
Sense Agentのバージョンを確認する
Contain Userアクションには、MDEクライアントのSense Agentバージョンv10.8470以上が必要とされています。端末側で確認する場合は、PowerShellでMicrosoft Defender for Endpointの状態を確認します。(Microsoft Learn)
Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' -Name "MsSenseDllVersion"古いOSイメージや長期間更新されていないVDI、検証用端末では、エージェント更新が遅れていることがあります。自動攻撃中断の展開前に、重要端末だけでなく代表的な端末グループを抽出してバージョンを確認してください。
Defender for Identityの監査とアクションアカウントを確認する
Defender for Identityでは、ドメインコントローラーの監査ポリシーが正しく構成されていること、アクションアカウントが必要な権限を持っていること、対象のActive Directoryアカウントを無効化するドメインコントローラーにセンサーが展開されていることが重要です。(Microsoft Learn)
オンプレミスADとMicrosoft Entra IDを同期している環境では、アカウントの無効化が複数のID基盤に波及します。開発者やID管理担当者は、次のような自動化を洗い出してください。
- 入退社管理システムがアカウント状態を定期的に上書きしていないか
- PowerShellやGraph APIの定期ジョブが無効化ユーザーを再有効化しないか
- サービスアカウントや同期アカウントが一般ユーザーと同じルールで扱われていないか
- 緊急用アカウントを除外する場合、代替の監視・認証制御があるか
自動攻撃中断で無効化されたアカウントを別システムがすぐ戻してしまうと、攻撃者に再び操作機会を与える可能性があります。
除外設定は「広く無効化」ではなく「最小限の例外」にする
自動攻撃中断では、特定のユーザーアカウント、デバイス、IPアドレスを自動封じ込めから除外できます。ただしMicrosoftは、除外が高度で影響の大きい攻撃に対する保護効果を下げる可能性があるため、推奨しないと注意しています。(Microsoft Learn)
例外設定が必要になる代表例は、業務停止リスクが極端に高い制御端末、緊急用アカウント、ネットワーク機器や特殊な監視対象IPなどです。ただし、例外にする場合は「なぜ除外するのか」「代わりにどの監視を置くのか」「いつ見直すのか」を記録してください。
| 除外対象 | 検討すべきケース | 代替策 |
|---|---|---|
| ユーザーアカウント | 緊急用アカウント、特定の管理アカウント | 強力なMFA、条件付きアクセス、利用時通知、定期レビュー |
| デバイスグループ | 特殊な制御端末、停止できない検証端末 | 専用ネットワーク分離、監視強化、手動封じ込め手順 |
| IPアドレス/IP範囲 | ネットワーク機器、特殊な業務システム | セグメント単位の監視、通信制御、ログ相関 |
全体をオプトアウトする場合は、Microsoft Defenderポータルでサポートケースを開き、件名にAttack disruption opt-outを指定する必要があると案内されています。ただし、公式情報でも特定エンティティの除外を検討するよう示されており、全体停止は最後の手段と考えるべきです。(Microsoft Learn)
Action centerとインシデント画面で運用を回す
自動攻撃中断が発生した場合、Microsoft Defender XDRのインシデント画面にはAttack Disruptionタグ、通知バナー、封じ込められたデバイスや停止されたユーザーの状態が表示されます。インシデントグラフから攻撃ストーリーを確認し、どの資産にどのアクションが実行されたかを追跡できます。(Microsoft Learn)
Action centerでは、保留中の修復アクションの承認、完了済みアクションの監査ログ確認、履歴の確認ができます。統合Action centerは、デバイス、メール・コラボレーション、IDに関する修復アクションを1か所で管理する役割を持ちます。(Microsoft Learn)
運用設計では、次のルールを決めておくと混乱を減らせます。
Attack Disruptionタグ付きインシデントはSOCが優先確認する- 端末の封じ込め解除やユーザー再有効化は、調査完了後に実施する
- ヘルプデスクは、ユーザーから「急にログインできない」「端末が通信できない」と申告された場合、Defenderのインシデント有無を確認する
- Action centerの履歴を週次または月次でレビューし、誤検知や例外設定の必要性を評価する
- メール通知ルールを作成し、手動・自動の応答アクションを関係者に通知する
特に、封じ込め解除を急ぎすぎるのは危険です。公式情報でも、アクションを元に戻す前にリスクを評価して調査を完了する必要があり、早すぎる解除は攻撃者の活動再開につながる可能性があると注意されています。(Microsoft Learn)
メール通知を設定して見落としを防ぐ
自動攻撃中断は強力ですが、実行後に誰も気づかなければ復旧判断や関係者連絡が遅れます。Microsoft Defenderポータルでは、手動または自動の応答アクションについてメール通知ルールを作成できます。通知では、アクションの種類、ステータス、アクションソース、デバイスグループのスコープ、受信者などを指定できます。(Microsoft Learn)
おすすめは、最初から通知先を広げすぎないことです。SOC、ID管理、エンドポイント運用、ヘルプデスクの代表窓口に絞り、通知量を見ながら調整しましょう。重要な本番環境では、メールだけでなくチケット管理システムやオンコール通知との連携も検討してください。
開発者・自動化担当者が確認すべきポイント
Microsoft Defender XDRの自動攻撃中断は、セキュリティ管理者だけの話ではありません。ID管理、端末管理、監視基盤、社内ポータル、チケットシステムを開発・運用している担当者にも影響します。
アカウント状態を上書きする処理を見直す
人事マスターやID同期処理が「在籍中ならアカウントを有効化する」という単純なロジックになっている場合、Defenderによる無効化を戻してしまう恐れがあります。自動攻撃中断による無効化を検知した場合は、例外フラグやセキュリティインシデント状態を優先する設計に変更してください。
悪い例は、次のような処理です。
在籍中ユーザー = true の場合、毎時アカウントを有効化する改善するなら、次のようにセキュリティ状態を条件に含めます。
在籍中ユーザー = true
かつ セキュリティ封じ込め中ではない
かつ インシデント対応中ではない
場合のみアカウントを有効化するAPI連携やSOARでAttack Disruptionを識別する
公式情報では、自動攻撃中断の可能性が高いインシデントのタイトル末尾に(attack disruption)という文字列が追加される例が示されています。また、インシデント画面ではAttack Disruptionタグやアクティビティタブのポリシーステータスなども確認できます。(Microsoft Learn)
既存のSOAR、チケット起票、Slack/Teams通知などがDefender XDRのインシデント情報を取り込んでいる場合は、Attack Disruptionタグやアクションソースを条件にして、通常アラートより優先度を上げる運用が有効です。
サービスアカウントを安易に除外しない
サービスアカウントやアプリケーション用アカウントは、業務影響が大きいため除外したくなります。しかし、攻撃者に悪用された場合の被害も大きくなりがちです。除外する前に、次の対策を検討してください。
- 対話型サインインを禁止できるか
- 条件付きアクセスで利用場所や端末を制限できるか
- 最小権限になっているか
- パスワードレス、証明書、マネージドIDなどに置き換えられるか
- アカウント利用ログを即時監視できるか
「止められないから除外」ではなく、「止めなくてもよい設計に寄せる」ことが長期的なリスク低減につながります。
展開時に失敗しやすいポイント
自動攻撃中断の展開でよくある失敗は、技術設定よりも運用設計の不足です。以下の点を事前に確認してください。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 一部端末がDefender for Endpoint未オンボード | 攻撃経路の可視化や封じ込めが不十分になる | 重要端末、サーバー、VDI、リモート端末を棚卸しする |
| Device groupを広くNo automated responseにしている | 自動中断の保護効果が落ちる | 例外は最小限にし、理由と期限を管理する |
| ID自動化が無効化を戻す | 攻撃者が再びアカウントを使える | HR/ID管理ジョブにセキュリティ状態の判定を追加する |
| Action centerを見る担当が決まっていない | 承認待ちや履歴確認が放置される | SOC、ヘルプデスク、ID管理の責任分界を決める |
| 通知先が未設定 | 封じ込め後の復旧判断が遅れる | 自動応答アクションのメール通知ルールを作成する |
| 除外設定が増えすぎる | 重要資産ほど守られない状態になる | 四半期ごとに除外リストをレビューする |
展開初期は、まず可視化と運用手順を固めることが重要です。いきなり広範囲に例外を作るより、通知、Action center確認、インシデント対応フローを整えたうえで、実際の発生状況を見ながら調整しましょう。
管理者向けの実践チェックリスト
最後に、管理者が今日確認すべき項目を整理します。
| 優先度 | 確認すること | 確認場所・観点 |
|---|---|---|
| 高 | 対象ライセンスがあるか | Microsoft 365管理センターのライセンス割り当て |
| 高 | Defender for Endpoint Plan 2相当の要件を満たすか | Defender XDRの前提条件 |
| 高 | 重要端末がDefender for Endpointにオンボード済みか | Microsoft Defenderポータルのデバイス一覧 |
| 高 | Device Discoveryが標準探索か | Endpoint設定 |
| 高 | デバイスグループのRemediation levelが適切か | System > Settings > Endpoints > Device groups |
| 高 | Defender for Identityの監査とアクション権限が正しいか | ドメインコントローラー、アクションアカウント |
| 中 | Exchange Onlineメールボックス監査が有効か | Exchange管理、監査ログ設定 |
| 中 | Defender for Cloud AppsとOffice 365コネクタが有効か | Defender for Cloud Apps設定 |
| 中 | 除外ユーザー、除外デバイス、除外IPが妥当か | Settings > Microsoft Defender XDRのAutomated response |
| 中 | Action centerの確認担当が決まっているか | SOC/ヘルプデスク運用 |
| 中 | 自動応答アクションのメール通知があるか | Settings > Microsoft Defender XDR > Email notifications |
| 低 | SOARやチケット連携がAttack Disruptionを識別できるか | インシデントタグ、タイトル、アクションソース |
Microsoft Defender XDRの自動攻撃中断は、設定できるかどうかよりも「攻撃時に確実に動き、動いた後に安全に復旧できるか」が重要です。まずはライセンスとDefender製品の展開範囲を確認し、次にデバイスグループの自動化レベル、IdentityとOffice 365の前提条件、Action centerと通知の運用を整備してください。
開発者や自動化担当者は、ID管理やSOAR連携がDefenderの封じ込めを打ち消さないよう、既存ジョブの条件分岐を見直しましょう。除外設定は便利ですが、保護範囲を狭める設定でもあります。最小限の例外に絞り、理由、代替策、見直し期限を残すことが、安全な展開の第一歩です。
コメント