DefenderHow-to

Your first hour with a Defender XDR incident: triage, scoping and containment

A time-boxed first hour for a Defender XDR incident: claim it, read the attack story, scope users, devices and mailboxes with hunting, contain safely and document the hand-off.

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.

How this guide is organised: Before you start → Minutes 0–10 → Minutes 10–25 → Minutes 25–40 → Minutes 40–55 → Minutes 55–60 → Verify containment held → Tips & gotchasFlow diagram of the article's sections in reading order: 1. Before you start. 2. Minutes 0–10. 3. Minutes 10–25. 4. Minutes 25–40. 5. Minutes 40–55. 6. Minutes 55–60. 7. Verify containment held. 8. Tips & gotchas. Toolbox: Cases › Incident, Overview › Attack graph, DeviceNetworkEvents, Artifacts › Alerts.1Before you start2Minutes 0–103Minutes 10–254Minutes 25–405Minutes 40–556Minutes 55–607Verify containmentheld8Tips & gotchasTOOLBOXCases › IncidentOverview › Attack graphDeviceNetworkEventsArtifacts › AlertsHow this guide is organised: Before you start → Minutes 0–10 → Minutes 10–25 → Minutes 25–40 → Minutes 40–55 → Minutes 55–60 → Verify containment held → Tips & gotchasFlow diagram of the article's sections in reading order: 1. Before you start. 2. Minutes 0–10. 3. Minutes 10–25. 4. Minutes 25–40. 5. Minutes 40–55. 6. Minutes 55–60. 7. Verify containment held. 8. Tips & gotchas. Toolbox: Cases › Incident, Overview › Attack graph, DeviceNetworkEvents, Artifacts › Alerts.1Before you start2Minutes 0–103Minutes 10–254Minutes 25–405Minutes 40–556Minutes 55–607Verify containment held8Tips & gotchasTOOLBOXCases › IncidentOverview › Attack graphDeviceNetworkEventsArtifacts › Alerts
At a glance: how this guide is organised · 8 sections · 4 key settings and tools

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?

KQL
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, IsClickedThrough

Where else has the malicious file landed?

KQL
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 FolderPath

Use 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:

AssetActionWatch out for
Onboarded deviceIsolate deviceIt 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 discoveryContain deviceOnly onboarded devices enforce the block.
User accountDisable sign-in, revoke sessions, reset the password, mark as compromisedFor synced accounts, disable in Active Directory; the next sync overwrites a cloud-only change.
Phishing emailRemove it with Threat Explorer or Take action in advanced hunting; block sender and URL in the Tenant Allow/Block ListBase the recipient list on your query, not the alert alone.
File, URL or IPStop and quarantine file or Add indicatorIndicators take time to reach devices.

For a cloud-only account, Microsoft Graph PowerShell does the first two user steps:

PowerShell
Connect-MgGraph -Scopes "User.ReadWrite.All"
$upn = "adele.vance@contoso.com"
Update-MgUser -UserId $upn -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $upn

Minutes 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.

References#

Written and checked against current Microsoft Learn documentation. Test changes with a pilot group before rolling them out to everyone, and if an admin center path has moved since, search for the setting name instead.

Spotted a mistake, or did this fix work differently for you? Email me or message me on LinkedIn — corrections are credited in the article.

Written by

Omer Eltayeb

Intune Subject Matter Expert in Cairo, Egypt, former Microsoft Cloud Solutions Architect, Microsoft Certified Trainer and Microsoft Innovative Educator Expert (2024–26) and Microsoft Elevate Educator Expert (2026–27). I share practical, step-by-step guides, study plans, scripts and toolkits for Microsoft Intune, Configuration Manager, Microsoft Entra ID, Microsoft Defender, Exchange and Microsoft 365 with the community.

Microsoft Certified Trainer (MCT) 2026Microsoft Innovative Educator Expert 2025–2026Microsoft Elevate Educator Expert 2026–2027ISC2 Certified Information Systems Security Professional (CISSP)Microsoft 365 Certified: Enterprise Administrator Expert (MS-102)