Microsoft Defender XDRの Automatic attack disruption（自動攻撃の中断） は、進行中の攻撃を検知した後に管理者が手作業で止めるための機能ではなく、攻撃者に使われているデバイス・ユーザー・IPなどの資産をMicrosoft Defenderが自動で封じ込める機能です。管理者が最初に確認すべきポイントは、自動隔離やユーザー無効化が業務に影響する可能性がある一方で、横移動やランサムウェア拡散を早期に止めるための防御機能であるという点です。2026年5月の公式更新では、信頼度の高いインシデント分析に基づいて侵害デバイスをネットワークから分離するプレビュー機能が追加されており、Defender for Endpointの展開状況、デバイスグループの自動化レベル、除外設定、インシデント後の解除手順を早めに棚卸しする必要があります。(Microsoft Learn)
Microsoft DefenderのAutomatic attack disruptionとは
Automatic attack disruptionは、Microsoft Defender XDRがエンドポイント、ID、メール、コラボレーションツール、SaaSアプリなどのシグナルを相関し、ランサムウェアや高度な攻撃を高い信頼度で検出した場合に、攻撃に使われている資産を自動的に封じ込める機能です。単一の不審ファイルやIPアドレスだけを見てブロックするのではなく、インシデント全体の文脈を見て、攻撃者が操作している可能性が高い資産に対して応答します。(Microsoft Learn)
動作の流れは大きく分けて3段階です。
| 段階 | Defenderが行うこと | 管理者が理解すべき意味 |
|---|---|---|
| シグナルの相関 | エンドポイント、ID、メール、SaaSアプリなどの情報を1つの高信頼インシデントとして関連付ける | Defender製品の展開範囲が狭いと、検出や対応の範囲も狭くなる |
| 攻撃者が制御する資産の特定 | 横移動や攻撃拡散に使われているデバイス、ユーザー、IPを判断する | 「感染端末」だけでなく、侵害アカウントや未オンボード端末に関連するIPも影響範囲に入る |
| 自動応答 | デバイスの封じ込め、デバイス分離、ユーザー無効化、ユーザー封じ込めなどを実行する | SOCは自動アクションの結果を確認し、調査完了後に解除や復旧を判断する |
重要なのは、Automatic attack disruptionが「完全な復旧」まで自動で完結する機能ではないことです。攻撃の進行を止める時間を稼ぎ、被害拡大を抑えるための機能であり、調査、根本原因の除去、再発防止、資産の復旧は引き続きセキュリティ運用チームの責任です。
2026年5月更新で注目すべき変更点
2026年5月のMicrosoft Defender XDRの更新で特に重要なのは、Automatic attack disruptionが侵害されたデバイスをネットワークから自動的に分離できるようになった点です。この機能はプレビューとして案内されており、Defenderが高い信頼度で「そのデバイスが攻撃者の足場として使われている」と判断した場合に動作します。分離中も調査や修復に必要なセキュリティサービスとの接続は維持され、アクションは時間制限付きで、対象もインシデントに関係するデバイスに限定されます。(Microsoft Learn)
既存の「Device contain」と新しい「Isolate device」は似ていますが、運用上の意味は異なります。
| 自動応答アクション | 状態 | 主な対象 | 実務上の意味 |
|---|---|---|---|
| Device contain | 既存機能 | 疑わしいデバイス | 対象デバイスとの送受信通信をブロックし、攻撃拡散を抑える |
| Contain IP | プレビュー | 未検出・未オンボード端末に関連する悪意あるIPなど | Defender for Endpointにオンボード済み、または検出済みのデバイスへの横移動や暗号化活動を抑える |
| Isolate device | プレビュー | 攻撃の足場と判断された侵害デバイス | 多くのネットワーク通信を遮断しつつ、調査・修復に必要なセキュリティサービスとの接続を維持する |
| Disable user | 既存機能 | 侵害されたユーザーアカウント | ADまたはMicrosoft Entra ID上のアカウントを無効化し、横移動やメール悪用を抑える |
| Contain user | 既存機能 | 疑わしいID | IDプロバイダー側のアカウントは無効化せず、エンドポイント層で一時的に攻撃利用を制限する |
管理者が特に注意すべきなのは、デバイス分離は業務影響が大きいが、解除可能な応答アクションであるという点です。たとえば、ファイルサーバー、踏み台サーバー、管理端末、重要業務端末が自動分離された場合、業務停止に見えることがあります。しかし、攻撃者の通信や横移動を止めることが目的であるため、安易に即時解除するのではなく、インシデントグラフ、Action center、Activitiesタブで根拠を確認してから判断する必要があります。(Microsoft Learn)
影響範囲はDefender for Endpointだけではない
Automatic attack disruptionという名前だけを見ると、エンドポイント保護の機能に見えます。しかし実際には、Microsoft Defender XDRの相関分析を使うため、影響範囲はエンドポイント、ID、メール、SaaSアプリ、Microsoft Entra ID、オンプレミスActive Directoryに広がります。
特に確認すべき対象は次のとおりです。
| 領域 | 確認すべきサービス・設定 | 確認しない場合のリスク |
|---|---|---|
| エンドポイント | Microsoft Defender for Endpoint、デバイス検出、デバイスグループ、自動化レベル | デバイス封じ込めや分離が期待どおりに動作しない |
| ID | Microsoft Defender for Identity、AD監査、アクションアカウント、Microsoft Entra ID | 侵害ユーザーの無効化や封じ込めが不完全になる |
| メール | Defender for Office 365、Exchange Online、メールボックス監査、Safe Linksポリシー | BECやメール起点の攻撃で相関・調査範囲が不足する |
| SaaSアプリ | Microsoft Defender for Cloud Apps、Microsoft 365コネクタ、App Governance | クラウドアプリ側の攻撃シグナルを十分に使えない |
| 運用基盤 | Action center、通知ルール、Advanced hunting、既存SOAR | 自動応答の把握や復旧判断が遅れる |
Microsoftの構成ガイドでは、Defender製品を広く展開するほど保護範囲が広がり、特定の応答アクションを実行するには関連する製品の展開が必要だと説明されています。たとえば、デバイスを自動的に封じ込めるにはDefender for Endpointが必要です。(Microsoft Learn)
管理者が最初に確認すべき前提条件
Automatic attack disruptionを安全に運用するには、「機能が有効か」だけでなく、ライセンス、権限、エージェント、監査、除外設定まで確認する必要があります。
| 確認項目 | 推奨される確認内容 |
|---|---|
| ライセンス | Microsoft Defender XDRの利用条件に加え、Automatic attack disruptionではMicrosoft Defender for Endpoint Plan 2が必要になる点を確認する |
| Defender製品の展開範囲 | Defender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Appsの導入状況を棚卸しする |
| Defender for Endpointのデバイス検出 | デバイス検出がStandard discoveryに設定されているか確認する |
| Sense Agentのバージョン | Contain userを使う場合、MDEクライアントの最小要件としてSense Agent v10.8470以上が求められる |
| デバイスグループの自動化レベル | Full – remediate threats automaticallyが推奨される。SemiでもAutomatic attack disruptionは手動承認なしにトリガー可能だが、No automated responseは限定的な例外として扱う |
| Defender for Identity | ドメインコントローラーの監査、アクションアカウント、センサー展開先を確認する |
| Defender for Cloud Apps | Microsoft Office 365コネクタとApp Governanceが有効か確認する |
| Defender for Office 365 | メールボックスがExchange Onlineにあり、必要なメールボックス監査イベントとSafe Linksポリシーが整っているか確認する |
ライセンス面では、Microsoft Defender XDRにアクセスできるライセンスは複数ありますが、Automatic attack disruptionにはDefender for Endpoint Plan 2が必要です。既存契約だけで判断せず、Microsoft 365管理センターで実際に割り当てられているライセンスを確認してください。(Microsoft Learn)
ID環境で注意すべきポイント
ユーザー無効化の動作は、アカウントがどこでホストされているかによって変わります。
| ユーザーの種類 | Disable userの動作 |
|---|---|
| Active Directory上のユーザー | Defender for Identityセンサーが稼働するドメインコントローラーで無効化アクションが実行される |
| ADでホストされMicrosoft Entra IDに同期されているユーザー | オンボード済みドメインコントローラー経由でAD側の無効化を実行し、Microsoft Entra ID側のアカウントも無効化する |
| Microsoft Entra IDのみのクラウドネイティブユーザー | Microsoft管理のエンタープライズアプリケーションを使い、RBACで権限を検証したうえでMicrosoft Entra ID上のアカウントを無効化する |
クラウドネイティブユーザーの無効化では、Microsoft Defender for Identityというエンタープライズアプリケーションが使われます。古いテナントではRadius Aad Syncerとして表示される場合があるため、見慣れない名称だからといって安易に削除・ブロックしないようにしてください。(Microsoft Learn)
また、既存のID運用スクリプトにも注意が必要です。たとえば、人事マスターやID管理ツールが「在籍中の社員アカウントは必ず有効に戻す」という処理を定期実行している場合、Defenderが攻撃中に無効化したアカウントを自動的に再有効化してしまう可能性があります。Microsoftの構成ガイドでも、自動化が攻撃中断の動作に干渉しないか確認するよう注意されています。(Microsoft Learn)
自動アクションを確認する場所
Automatic attack disruptionが動作したかどうかは、Microsoft Defenderポータルの複数の場所で確認できます。
| 確認場所 | 見るべきポイント |
|---|---|
| インシデントキュー | Attack Disruptionタグが付いたインシデントを確認する |
| インシデントページ | 黄色のバナー、インシデントグラフ、資産の状態を確認する |
| Activitiesタブ | Provider: Attack disruptionやPolicy statusで、アクションがActive、Inactive、No statusのどれか確認する |
| Action center | 実行済み・保留中の修復アクション、解除可能なアクションを確認する |
| API | 高信頼で中断対象となったインシデント名に(attack disruption)が付く場合がある |
特に大規模環境では、Action centerだけでは「現在もポリシーが有効か」が分かりにくい場合があります。ActivitiesタブのPolicy status列は、過去に実行されたアクションが現在も有効なのか、すでに解除されたのかを確認するために役立ちます。(Microsoft Learn)
通知ルールを作成して見落としを防ぐ
Automatic attack disruptionは攻撃中に動作するため、メール通知やSOCの運用ルールと組み合わせることが重要です。Microsoft Defenderポータルでは、手動または自動の応答アクションに対するメール通知ルールを作成できます。設定場所は、Microsoft DefenderポータルのSettings > Microsoft Defender XDR > Email notifications > Actionsです。(Microsoft Learn)
通知ルールでは、次の条件を設計しておくと実務で使いやすくなります。
| 条件 | 設定例 |
|---|---|
| Action source | Automated response actionsを含める |
| Action | Isolate device、Contain device、Disable user、Contain userなど重要アクションを選ぶ |
| Device groups scope | 重要サーバー、一般端末、検証端末などの管理範囲に合わせる |
| Action status | CompletedとFailedの両方を通知対象にする |
| Recipients | SOC、インフラ管理者、ID管理者、ヘルプデスクの代表アドレスを登録する |
注意点として、通知設定にはManage security settings権限が必要です。また、レスポンスアクションのメール通知は、応答アクションを含むカスタム検出には現時点で対応していないとされています。(Microsoft Learn)
Advanced huntingで確認する場合の注意点
開発者やSOCエンジニアがログ分析や自動化に組み込む場合は、Advanced huntingのテーブル仕様を理解しておく必要があります。DisruptionAndResponseEventsテーブルは、Automatic attack disruptionやPredictive shieldingに関連するイベントを扱いますが、プレビュー扱いであり、主にDefender for Endpointベースの制御結果を表します。Contain userやDisable userの「実行そのもの」をすべて記録するテーブルではなく、ブロック結果やポリシー適用結果を確認する用途として考えるべきです。(Microsoft Learn)
運用確認用のクエリ例は次のとおりです。
DisruptionAndResponseEvents
| where Timestamp > ago(7d)
| summarize Events=count() by ActionType, ReportType, IsPolicyOn
| order by Events descユーザー封じ込めによるブロック傾向を確認したい場合は、DeviceEvents側も併用します。
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType contains "ContainedUser"
| summarize Events=count() by ActionType, DeviceName
| order by Events descデバイスやユーザーの自動封じ込めをSOARやチケットシステムに連携する場合は、1つのテーブルだけで完結させないでください。Action center、インシデントページ、Activitiesタブ、Advanced huntingを組み合わせ、現在の状態と過去の実行履歴を分けて扱う設計にすることが重要です。
除外設定は「最後の手段」として扱う
Automatic attack disruptionでは、特定のユーザー、デバイスグループ、IPアドレスを自動応答から除外できます。ただし、Microsoftは自動応答からの除外を推奨しておらず、除外によって高度な攻撃から環境を保護する効果が下がる可能性があるとしています。(Microsoft Learn)
除外を検討してよいのは、次のようなケースに限定するのが現実的です。
| 除外を検討するケース | 判断基準 |
|---|---|
| 医療、製造、制御系など停止影響が極めて大きい端末 | 代替監視、ネットワーク分離、手動対応手順が整っている |
| 検証中の重要サーバーグループ | 一時的な検証目的であり、期限と責任者が決まっている |
| 誤検知調査中の特定IP | 恒久除外ではなく、調査完了後に解除する運用がある |
| 既存自動化と競合するID | 自動再有効化スクリプトなどを修正するまでの暫定措置である |
一方で、「重要なサーバーだから除外する」「役員アカウントだから除外する」という判断は危険です。攻撃者は重要資産や高権限アカウントを優先的に狙います。除外は業務継続のための例外であり、保護対象から外すための便利な設定ではありません。
また、デバイスグループを自動応答から除外すると、Automated investigation and responseにも影響します。攻撃中断だけを止めたつもりで、他の自動修復まで弱めてしまう可能性があるため、変更前に影響範囲を確認してください。(Microsoft Learn)
展開・移行時に失敗しやすいポイント
Automatic attack disruptionの展開でよくある失敗は、機能を有効化すること自体ではなく、周辺運用の準備不足です。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| Defender製品の展開範囲が偏っている | エンドポイントは見えるが、IDやSaaSアプリの文脈が不足する | Defender for Identity、Defender for Office 365、Defender for Cloud Appsの展開状況を確認する |
| デバイスグループの自動化レベルを理解していない | 期待した自動封じ込めが動作しない、または意図せず抑止される | Full、Semi、No automated responseの意味を整理する |
| 重要端末を安易に除外する | 攻撃者の足場になった場合に自動防御が効かない | 除外は期限付き・理由付き・レビュー付きで管理する |
| ID管理スクリプトが無効化アカウントを戻す | 攻撃中に封じ込めたアカウントが再び使える状態になる | HR連携、IDaaS、PowerShell運用を点検する |
| 通知先がSOCだけ | 端末停止やアカウント無効化の問い合わせにヘルプデスクが対応できない | SOC、ID管理者、端末管理者、ヘルプデスクに通知を分ける |
| プレビュー機能を前提に固定的な自動化を作る | UIやスキーマ変更で連携が壊れる | プレビュー列やテーブルに依存しすぎず、Action centerなど複数ソースで確認する |
移行時は、いきなり全社展開の是非だけを議論するより、まず「どの自動アクションが発生したら誰が何を見るか」を決める方が実務的です。たとえば、Disable userはID管理者、Isolate deviceは端末管理者、Contain IPはネットワーク担当も巻き込む、といった役割分担を決めておくと、インシデント時の混乱を抑えられます。
インシデント発生時の実務フロー
Automatic attack disruptionが動作した場合は、次の順序で確認すると判断を誤りにくくなります。
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 1 | インシデントキューでAttack Disruptionタグを確認 | 自動応答が発生したインシデントかを切り分ける |
| 2 | インシデントページで攻撃ストーリーとグラフを確認 | どの資産が攻撃者に使われたと判断されたかを見る |
| 3 | ActivitiesタブでPolicy statusを確認 | 自動応答が現在も有効か、すでに解除済みかを確認する |
| 4 | Action centerで実行済みアクションを確認 | 解除可能なアクション、失敗したアクション、保留中のアクションを確認する |
| 5 | 根本原因を調査 | 端末、認証情報、メール、SaaSアプリ、永続化手段を確認する |
| 6 | リスク軽減後に解除 | デバイスの封じ込め解除、ユーザー有効化などを必要に応じて実行する |
| 7 | 再発防止 | 認証情報のリセット、脆弱性対応、条件付きアクセス、除外設定の見直しを行う |
Microsoftのドキュメントでは、封じ込められた資産は、リスクを軽減しインシデント調査を完了した後にAction centerなどから解除できると説明されています。つまり、解除ボタンは「業務影響が出たからすぐ押す」ものではなく、「攻撃者のアクセスを取り除いた後に押す」ものです。(Microsoft Learn)
管理者・開発者向けチェックリスト
最後に、Automatic attack disruptionを運用に組み込む前に確認すべき項目を整理します。
| 対象 | チェック内容 |
|---|---|
| ライセンス | Defender for Endpoint Plan 2を含む必要ライセンスが割り当てられているか |
| エンドポイント | Defender for Endpointのオンボード率、デバイス検出、Sense Agentバージョンを確認したか |
| ID | AD監査、Defender for Identityセンサー、アクションアカウント、Microsoft Entra ID連携を確認したか |
| メール | Exchange Online、メールボックス監査、Safe Linksポリシーを確認したか |
| SaaS | Defender for Cloud AppsのMicrosoft 365コネクタとApp Governanceを確認したか |
| 自動化 | ID再有効化スクリプト、SOAR、チケット連携が自動応答と競合しないか |
| 通知 | 自動応答アクションのメール通知ルールを設定したか |
| 除外 | 除外対象に期限、理由、責任者、レビュー日を付けているか |
| 調査 | Action center、Activitiesタブ、Advanced huntingの確認手順をSOC手順書に入れたか |
| 復旧 | 誰がデバイス解除、ユーザー再有効化、業務部門連絡を行うか決めたか |
Automatic attack disruptionは、単に「Microsoft Defenderの便利な自動化機能」として扱うべきものではありません。攻撃者の横移動を止めるために、業務影響を伴うアクションを高信頼で実行する防御機能です。管理者は、ライセンスと前提条件を確認し、デバイス分離やユーザー無効化が発生した場合の通知・調査・解除フローを整備してください。開発者やSOCエンジニアは、Advanced huntingやAction centerを使った可視化を準備しつつ、既存のID管理・SOAR・チケット運用がDefenderの自動応答を打ち消さないように点検することが次のアクションです。
コメント