3.4.3. Incidents Contained by Attack Disruption
💡 First Principle: When automatic attack disruption acts, it has bought time, not finished the job. The attacker's assets are contained, but the root cause, the full scope, and the cleanup are still the analyst's work. Responding to a disrupted incident means verifying what was contained, completing the investigation and remediation, then deliberately releasing containment.
Recognizing a disrupted incident is straightforward: the incident queue shows an Attack Disruption tag, the incident page shows a yellow banner, and the incident graph marks assets as contained or disabled. The Action center lists each disruption action (contain device, contain user, disable user, revoke session) with its time and target.
Working the incident follows the normal investigation with a head start. Review the attack story to understand what triggered disruption; scope the attack beyond the contained assets (other devices the user touched, other accounts sharing the credential); collect evidence such as investigation packages from contained devices; and remediate root causes (purge the phishing email, reset credentials, remove persistence, patch the exploited vulnerability).
Releasing containment is a deliberate step taken when remediation is complete:
- Contained devices are released from the device page or the Action center (release from containment), restoring their communication with other onboarded devices.
- Contained users are released from the user page or Action center, restoring their ability to authenticate and access resources.
- Disabled accounts (disabled by Defender for Identity in AD or Entra ID) are re-enabled, ideally after a password reset and MFA review.
Releasing too early returns the attacker's foothold; never releasing leaves users and services broken. Record the decision in the incident comments. If disruption acted on an asset that shouldn't be automatically contained (a critical server, an executive's device), add an exclusion (2.4.3) after the incident so business-critical assets get human review next time.
⚠️ Exam Trap: "After attack disruption contained a user, the analyst reset the password, but the user still can't sign in" means containment is still in effect; the analyst must release the user from containment (or re-enable the disabled account). Password resets don't lift disruption actions.
Reflection Question: What should be true before you release a device contained by attack disruption, and what would you check to confirm it?
