AD6.8 Automatic Attack Disruption

What automatic attack disruption covers

Automatic attack disruption activates for high-confidence attack patterns that Microsoft's AI models recognize. The primary scenarios include:

BEC financial fraud. When the correlation engine detects a compromised account creating inbox rules that forward financial emails, automatic disruption may disable the account — stopping the BEC progression before the fraud email is sent. The incident title includes "(attack disruption)" to indicate automated action was taken.

Human-operated ransomware. When endpoint signals show lateral movement patterns consistent with ransomware operators (credential dumping, service creation, scheduled task deployment across multiple devices), automatic disruption may contain the affected devices and disable the compromised user account.

AiTM with post-compromise activity. When the correlation engine sees a phishing email → AiTM sign-in → inbox rule creation in rapid succession, automatic disruption may disable the account during the post-compromise phase — potentially before the attacker completes their setup.

Recognising when automatic disruption fires

Look for these indicators in your Defender portal:

Incident title. Incidents where automatic disruption acted include "(attack disruption)" in the title. Example: "BEC financial fraud attack launched from a compromised account (attack disruption)."

Attack Disruption tag. The incident has an "Attack Disruption" tag that you can filter on in the incident queue.

Action center entries. Navigate to security.microsoft.com → Action center. Automatic disruption actions appear here: "User account disabled," "Device contained," or "IP blocked" with the source listed as "Automatic attack disruption."

User reports "I can't sign in." If automatic disruption disabled a user account, the user can't sign in and will contact the helpdesk. Check the Defender incident queue — if an attack disruption incident exists for that user, the account was disabled by Microsoft, not by you.

What to do when disruption fires

Automatic disruption handles steps 1 and 2 of AD6.2 (account disabled = sessions terminated + sign-in blocked). You still need to complete steps 3-5:

1. ✅ Sessions/access — handled by disruption (account disabled)
2. ✅ Sign-in blocked — handled by disruption (account disabled)
3. ⬜ Review MFA methods — check for attacker-registered MFA devices
4. ⬜ Remove persistence — check inbox rules, OAuth consents, delegates
5. ⬜ Report and document — incident report to management

After completing steps 3-5, re-enable the user account. Navigate to the Action center → find the "Disable user" action → click "Undo" to re-enable. Or in Entra ID: entra.microsoft.com → Users → select user → "Enable account."

Important: Don't re-enable the account until you've completed steps 3-5. If you re-enable before removing the attacker's MFA methods and inbox rules, the attacker may regain access through the persistence mechanisms that automatic disruption didn't address.

When automatic disruption makes a mistake

Automatic disruption is designed for high confidence — false positive rate is low. But it can disable a legitimate account if the activity pattern matches a known attack pattern. Common false positive scenarios: a user traveling internationally who triggers impossible travel + unusual inbox rule creation (they set up a vacation auto-reply), or an IT admin performing bulk operations that look like lateral movement.

If the disruption was a false positive: re-enable the account in the Action center, classify the incident as FP in the Defender portal, and submit feedback to Microsoft. The false positive feedback improves the AI model — your feedback reduces similar false positives for your tenant and for all M365 customers.

Verifying attack disruption actions in the Action center

Navigate to security.microsoft.com → Action center → History tab. Filter by "Action type" → select "Disable user" or "Contain device." Each entry shows: the action taken, the entity affected (user UPN or device name), the incident that triggered it, and the timestamp.

Click on an action to see the full details: the alert that triggered the disruption, the confidence score, and the specific containment action taken. If the confidence score is "High" and the alert description matches a known attack pattern (BEC, ransomware, AiTM), the disruption is almost certainly correct. If the confidence is "Medium" or the alert description is vague, investigate before deciding whether the account should stay disabled or be re-enabled.

The Action center also shows "Pending actions" — these are disruption actions that require your approval before execution (if your tenant is configured for semi-automated response). Review pending actions promptly: a pending "disable user" action that waits 4 hours for approval gives the attacker 4 hours of continued access. If you have automatic disruption enabled, consider setting it to fully automated for high-confidence scenarios to eliminate this approval delay.

Re-enabling a disrupted account

After completing AD6.2 steps 3-5 and confirming the account is clean:

Via Action center: security.microsoft.com → Action center → History → find the "Disable user" action → click "Undo." The account is re-enabled immediately.

Via Entra ID: entra.microsoft.com → Users → search for the user → the account shows "Sign-in blocked: Yes." Click "Edit properties" → "Account enabled: Yes" → Save. Or via PowerShell:

Update-MgUser -UserId "r.williams@northgateeng.com" -AccountEnabled:$true
Write-Host "Account re-enabled"

Verification: After re-enabling, have the user sign in from a known device. Confirm they can access M365 normally. Monitor the sign-in log for 24 hours — if any suspicious activity appears from the same user, the cleanup was incomplete and the account may need to be disabled again for further investigation.

Communication to the user: "Your account was automatically disabled by Microsoft's security system due to suspicious activity. Our security team has investigated, cleaned up the issue, and re-enabled your account. You'll need to sign in again and may need to re-register your authenticator app. If you notice anything unusual in your mailbox (missing emails, unfamiliar sent messages, new rules), please let me know immediately."

Attack disruption and your response timeline

Understanding when attack disruption fires relative to your detection changes your response approach:

Disruption fires BEFORE your Monday review: The attacker was contained automatically. You discover the incident during your Monday review with containment already in place. Your response is: verify the disruption (check the Action center), complete steps 3-5 of AD6.2 (MFA, persistence, report), and re-enable the account. This is the best-case scenario — automated containment is faster than any human response.

Disruption fires DURING your investigation: You're investigating a suspicious sign-in when automatic disruption disables the account. The attacker is contained, but you're mid-investigation. Continue your investigation (the evidence is preserved by the disable action), complete the remaining steps, then re-enable. The disruption accelerated your containment — you don't need to execute steps 1-2 yourself.

Disruption does NOT fire: The incident confidence didn't meet the automatic disruption threshold. This is the scenario where your manual response procedures (AD6.2-AD6.4) are essential. Not every incident triggers automatic disruption — the system is designed for high-confidence attacks, not borderline cases. Your procedures handle everything that automation doesn't catch.

Checking your automatic disruption configuration

Navigate to security.microsoft.com → Settings → Microsoft Defender XDR → Automatic attack disruption. Verify:

Service status: Automatic attack disruption should show as "Enabled." If disabled, enable it — the high-confidence threshold means the false positive rate is very low, and the automated containment is significantly faster than any human response.

Response actions: Check which automatic actions are configured. Available actions depend on your licensing: user disable (requires Defender for Identity — available with E5 or standalone license), device contain (requires Defender for Endpoint — E5), and IP block (requires Defender for Endpoint — E5).

E3 limitation: On E3 without Defender for Identity or Defender for Endpoint, automatic attack disruption has limited capability. The correlation engine still detects attack patterns, but the automated response actions (user disable, device contain) require the corresponding Defender products. The incident is created and flagged as "(attack disruption)" but the automated containment may not execute. In this case, you're the containment mechanism — the alert tells you what the system detected, and you execute the response manually via AD6.2.

Regardless of licensing, automatic disruption provides value through its correlation — grouping related alerts into a single high-confidence incident that clearly identifies the attack pattern. Even if the automated response didn't fire, the incident with the "(attack disruption)" tag tells you this is a confirmed attack, not a low-confidence detection.

The user recovery workflow

After completing AD6.2 steps 3-5 and confirming the account is clean, re-enable the user:

1. Action center release: security.microsoft.com → Action center → find the "Disable user" action → "Undo." This re-enables the Entra ID account.

1. Communicate with the user: "Your account has been re-enabled. You'll need to sign in with a new temporary password [provide via phone/SMS, not email]. On first sign-in, you'll be prompted to create a new password and re-register MFA. Please use your legitimate phone number for MFA — do not accept any MFA prompts you didn't initiate."

1. Monitor for 48 hours: Check the sign-in log daily for 2 days after re-enablement. Any sign-in from an unfamiliar IP means the attacker found a persistence mechanism you didn't catch — re-execute the containment procedure.

1. User awareness conversation: Brief the user on what happened: "Your account was compromised via a phishing email. Our security controls detected the attack and automatically disabled your account. We've cleaned up the attacker's access. Going forward, please: report suspicious emails using the Report Message button, never enter your password on a page you reached via an email link, and contact IT immediately if you receive unexpected MFA prompts."

This conversation isn't blame — it's education. The user is more likely to report the next phishing attempt if they understand that their report leads to rapid containment rather than punishment.