The first hour of an incident shapes everything after it: contain too late and the attacker spreads; contain the wrong thing and you disrupt the business for nothing. This post is a routine for working a Microsoft Defender XDR incident in time boxes: claim it, understand the story, scope it with assets, evidence and advanced hunting, contain each asset with the right action, and leave a record the next person can pick up.
Status (October 2026): Microsoft Learn describes incident cases (preview, under Cases › Incident) as the recommended experience, with pages such as Overview › Attack graph and Artifacts › Alerts, Assets, Evidence and Activities. The legacy pages under Investigation & response › Incidents & alerts › Incidents remain available during the preview. I name both where they differ; re-check Learn as the preview evolves.
Before you start#
- Permissions: the unified RBAC permission Security Data Read lets you investigate and Security Data Manage lets you manage incidents. Response actions have their own permissions per workload, so test that analysts can isolate a device and disable a user before you need to.
- Decisions made in advance: who approves isolating a server, who contacts users, and the out-of-hours escalation path.
- Data window: advanced hunting keeps 30 days of data, so query older activity before it ages out.
Minutes 0–10: triage from the queue#
Filter the queue to active incidents, sort by severity, and read each row before opening it:
- Tags: Attack Disruption means Defender has already contained something (see automatic attack disruption).
- Service sources: alerts from several products, such as endpoint, identity and email, often mean a multi-stage attack.
- Impacted assets: one device and one user is a different job from fifteen devices and three admins.
- Last activity: if it's minutes old, assume the attacker is still active.
Open the incident and read the summary (in incident cases it includes a priority assessment and, when available, a summary by Copilot). Then claim it: assign it to yourself, which assigns all its alerts too, set the status to in progress, and add a comment that triage has started. Two analysts silently working the same incident waste the hour.
Minutes 10–25: read the attack story#
Open Attack story (legacy) or Overview › Attack graph (incident cases). Work through the alerts in time order and use the incident graph to see how users, devices, mailboxes, IPs and files connect. Group similar nodes or filter by entity type when it gets busy, and check blast radius analysis, where available, for paths to critical assets.
For each alert, note the MITRE ATT&CK techniques, the evidence and, in incident cases, the correlation reason. If an alert clearly belongs elsewhere, move it to another incident so it doesn't distort your scope. Then write a three-line hypothesis as a comment:
- How did the attacker get in?
- What did they do next (credential theft, lateral movement, mailbox rules, data access)?
- What is at risk if you don't act in the next 30 minutes?
Minutes 25–40: scope with assets, evidence and hunting#
On Assets, check each device, user, mailbox, app and cloud resource: is it a server, a privileged account, a shared mailbox? On Evidence, review verdicts and remediation status; on Investigations, see whether automated investigation is waiting for approval. From any entity, Go hunt opens advanced hunting with ready-made queries such as All Activity and Related Alerts.
Then ask what the incident can't tell you. Who else received the phish, and who clicked?
let sender = "billing@invoice-portal.example";
EmailEvents
| where Timestamp > ago(7d) and SenderFromAddress =~ sender
| join kind=leftouter (UrlClickEvents | where Timestamp > ago(7d)
| project NetworkMessageId, AccountUpn, ClickAction = ActionType, IsClickedThrough) on NetworkMessageId
| project Timestamp, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, AccountUpn, ClickAction, IsClickedThroughWhere else has the malicious file landed?
let badHash = "<SHA256 from the Evidence page>";
DeviceFileEvents
| where Timestamp > ago(30d) and SHA256 == badHash
| summarize FirstSeen = min(Timestamp), Devices = dcount(DeviceId), Names = make_set(FileName) by FolderPathUse DeviceNetworkEvents the same way for an attacker IP. For a compromised account, review its Entra sign-in logs, and for mailbox abuse follow investigating a compromised mailbox.
Minutes 40–55: contain#
First check what's already done: the attack disruption banner, Actions & submissions › Action center, and pending approvals. Then choose the lightest action that stops the spread:
| Asset | Action | Watch out for |
|---|---|---|
| Onboarded device | Isolate device | It keeps its Defender connection, so you can still collect an investigation package or use live response. Agree before isolating a server. |
| Unmanaged device found by device discovery | Contain device | Only onboarded devices enforce the block. |
| User account | Disable sign-in, revoke sessions, reset the password, mark as compromised | For synced accounts, disable in Active Directory; the next sync overwrites a cloud-only change. |
| Phishing email | Remove it with Threat Explorer or Take action in advanced hunting; block sender and URL in the Tenant Allow/Block List | Base the recipient list on your query, not the alert alone. |
| File, URL or IP | Stop and quarantine file or Add indicator | Indicators take time to reach devices. |
For a cloud-only account, Microsoft Graph PowerShell does the first two user steps:
Connect-MgGraph -Scopes "User.ReadWrite.All"
$upn = "adele.vance@contoso.com"
Update-MgUser -UserId $upn -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $upnMinutes 55–60: document and hand off#
Write the hand-off as a comment (in incident cases, Comments & Attachments, where you can also attach exported query results):
- Timeline in UTC: first malicious activity, detection, each containment action.
- Scope: confirmed and suspected users, devices and mailboxes, and how you know.
- Actions taken, by whom, and anything awaiting approval.
- Open questions and the next owner.
Use tags for things you'll report on, and tasks (incident cases) for remaining work. Leave classification (True positive, Informational, expected activity or False positive) until you resolve; the activity history records every assignment and status change.
Verify containment held#
- The device page shows the device isolated or contained, and Action center history shows the actions completed.
- Rerunning your hunting queries returns no new activity from contained assets.
- The disabled account shows no new successful sign-ins, and no new alerts join the incident from the same assets.
Tips & gotchas#
- Phone the user before isolating their laptop; email and Teams may not reach them afterwards.
- Save good pivots as shared queries so the next analyst starts faster.
- Don't release contained assets to make a complaint go away; finish eradication first.
- Practise the routine: the SC-200 study plan covers the skills behind it.

