2.4.3. Automatic Attack Disruption
💡 First Principle: Some attacks, such as human-operated ransomware and business email compromise, move faster than any human approval loop. When Defender XDR correlates signals across endpoints, identities, email, and cloud apps into a high-confidence picture of an attack in progress, it can contain the attacker's footholds immediately, before anyone reads the incident. Attack disruption buys the SOC time; it doesn't replace the investigation.
Attack disruption works at the incident level rather than on a single indicator. Microsoft states that its containment actions are held to a confidence of 99% or higher, and new detectors are validated in audit mode before broad release. Disruption is documented for scenarios such as human-operated ransomware, business email compromise (including financial fraud from a compromised mailbox), and adversary-in-the-middle phishing. When it triggers, it takes containment actions in whichever product owns the asset:
| Action | Executed by | Effect |
|---|---|---|
| Contain device | Defender for Endpoint | Other onboarded devices block communication with the compromised device |
| Contain IP | Defender for Endpoint | Blocks an IP tied to undiscovered, non-onboarded devices |
| Contain user | Defender for Endpoint | Restricts the compromised account's authentication, file, and network paths across devices |
| Disable user | Defender for Identity | Disables the account in Active Directory and, for synced or cloud accounts, in Entra ID |
| Revoke session / suspend user | Microsoft Entra ID | Interrupts active sessions and blocks further access |
| OAuth app action | Defender for Cloud Apps | Contains a compromised OAuth app |
Disruption depends on prerequisites in each product, and missing ones explain most "why didn't it act?" questions. Defender for Endpoint: device discovery set to Standard, a sufficiently recent sensor version for Contain user, and devices whose group automation level isn't No automated response (Full is recommended; Semi still allows disruption). Defender for Identity: sensors on the domain controllers where accounts will be disabled, with the required auditing and a valid action account. Defender for Cloud Apps: the Microsoft 365 app connector fully configured. Defender for Office 365: Exchange Online mailboxes with mailbox auditing of key events such as MailItemsAccessed and UpdateInboxRules.
Control stays with the SOC. You can exclude critical users, devices, and IP addresses from automated containment (and setting a device group to No automated response also excludes it). Disrupted incidents carry an Attack Disruption tag and a banner in the incident, the incident graph shows each asset's containment status, and every action appears in the Action center, where it can be reviewed and undone once the threat is remediated (3.4.3 covers the response side).
⚠️ Exam Trap: "Ensure the CEO's laptop is never automatically contained, while keeping disruption active for everyone else" calls for an attack disruption exclusion for that device, not disabling attack disruption tenant-wide and not switching the whole device group to No automated response.
Reflection Question: Attack disruption contained a user account during a ransomware attack, but the same account's on-premises AD object stayed enabled. Which product's prerequisite was most likely missing, and why does that product own that action?
