1.2 Mitigate Incidents Using Microsoft Defender XDR

Mitigate Incidents Using Microsoft Defender XDR

Introduction

An incident is a collection of correlated alerts that together describe an attack. Managing incidents — from initial triage through investigation to closure — is the core daily workflow of a SOC analyst. This subsection teaches you the complete incident lifecycle in Defender XDR: how incidents are created, how to triage them efficiently, how to investigate the underlying evidence, and how to remediate and close them.

This is not theoretical. Every shift as a SOC analyst starts with the incident queue. You will learn the practical decision framework for: which incident do I look at first? Is this a true positive or a false positive? How far has the attack progressed? What action do I take? When do I escalate?

Here is what this subsection covers:

• How incidents are created — alert grouping, entity correlation, and automatic attack disruption
• The incident queue — how to read it, sort it, and prioritize
• Incident triage — the 5-minute assessment that determines your response
• Investigation workflow — following evidence from the incident through alerts, entities, and raw data
• Remediation actions — containing and eliminating the threat
• Incident classification and closure — documenting the outcome for metrics and learning

How incidents are created

Defender XDR creates an incident when one or more alerts share a common entity. The correlation logic evaluates:

• Shared user — multiple alerts involving the same UserPrincipalName
• Shared device — multiple alerts involving the same DeviceId
• Shared IP address — alerts referencing the same source IP
• Shared email — alerts tied to the same message or campaign
• Temporal proximity — alerts occurring within a time window that suggests a connected attack

A single alert can also become an incident if it is high-severity or triggers automated investigation.

Automatic attack disruption

Defender XDR can automatically disrupt attacks in progress without waiting for analyst intervention. When the correlation engine identifies a high-confidence, multi-stage attack (such as ransomware pre-encryption activity or BEC with active mail forwarding), it takes immediate containment actions:

• Disabling a compromised user account
• Isolating a compromised device
• Blocking a malicious OAuth application

These actions appear in the incident timeline with the label “Automatic attack disruption.” They are reversible — you can re-enable the account or release the device if the action was a false positive.

The incident queue — your shift start

Navigate to security.microsoft.com → Incidents & alerts → Incidents. This is the queue you will check at the beginning of every shift.

Key columns in the incident queue:

Effective queue sorting:

1. Filter Status = “New” (only unworked incidents)
2. Sort by Severity descending (High first)
3. Within the same severity, prioritize incidents with recent “Last activity” (potentially still active) over older ones
4. Check the “Automated investigation” column — if AIR has already remediated a high-severity incident, it may need only verification, not full investigation

Incident triage — the 5-minute assessment

When you open an incident, your first task is not a deep investigation. It is a rapid assessment to determine: is this real? Is it still active? How bad is it? What do I do next?

The 5-minute triage framework:

Minute 1: Read the incident summary. The incident page shows a narrative summary, the alerts, the affected entities, and a timeline. Read the summary and the alert names — they tell you what Defender XDR thinks happened.

Minute 2: Check the entities. How many users are affected? Which devices? Are any of them high-value (executives, IT admins, domain controllers)? A single-user incident is different from one affecting 50 users.

Minute 3: Check the timeline. When did it start? Is there recent activity? An incident with its last alert 3 hours ago may be dormant. An incident with alerts from 5 minutes ago is potentially active.

Minute 4: Check automated actions. Has automatic attack disruption acted? Has AIR completed? If the user is already disabled and the device isolated, the immediate threat is contained — your focus shifts to verification and eradication.

Minute 5: Classify and decide.

Investigation workflow

After triage, the investigation follows the evidence from the incident down through the alerts to the raw data.

Level 1: The incident. Shows the big picture — how many alerts, which entities, what attack categories. This is your map.

Level 2: The alerts. Each alert within the incident tells a specific part of the story. “Suspicious sign-in activity” is one chapter. “Inbox rule with suspicious keywords” is another. Click each alert to see its details, evidence, and recommended actions.

Level 3: The entities. Click on a user to see their complete activity profile: recent sign-ins, devices, email activity, alerts. Click on a device to see its timeline, alerts, and security recommendations. Entities connect the dots between alerts.

Level 4: Advanced Hunting. When the portal investigation reaches its limit — you need to answer a question the alert details do not cover — pivot to Advanced Hunting and write a KQL query. This is where Module 6 pays off.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// Example: investigate a user flagged in an incident
let targetUser = "j.morrison@northgateeng.com";
let incidentStart = datetime(2026-03-20T08:00:00Z);
let incidentEnd = datetime(2026-03-20T12:00:00Z);
union
    (IdentityLogonEvents | where Timestamp between (incidentStart .. incidentEnd)
        | where AccountUpn == targetUser
        | project Timestamp, ActionType, Application, IPAddress, Type),
    (EmailEvents | where Timestamp between (incidentStart .. incidentEnd)
        | where RecipientEmailAddress == targetUser
        | project Timestamp, ActionType = "EmailReceived", Application = SenderFromDomain,
            IPAddress = SenderIPv4, Type),
    (CloudAppEvents | where Timestamp between (incidentStart .. incidentEnd)
        | where AccountDisplayName has "morrison"
        | project Timestamp, ActionType, Application, IPAddress, Type)
| order by Timestamp asc

Remediation actions

Once the investigation confirms the threat, take action. Defender XDR provides remediation actions directly from the incident and alert views.

Incident classification and closure

After investigation and remediation, classify and close the incident. This documentation drives SOC metrics and learning.

Add a comment explaining what happened, what actions were taken, and any follow-up needed. This comment becomes the incident record — when your CISO asks “what happened with that high-severity incident last week,” the comment is the answer.