M04 · Microsoft Defender XDR

Course: Microsoft Defender — Security Operations Fundamentals Module duration: 3.5 hours (including lab) Format: Instructor-led, hands-on

Currency note (as of June 2026): Portal paths, schema table names, and feature labels in the unified Defender portal change frequently. Verify navigation and Advanced Hunting schema against current Microsoft Learn / in-portal schema reference before relying on specifics.

Learning objectives

By the end of this module you will be able to:

  1. Explain the unified portal’s data sources and how signals from multiple workloads are correlated.
  2. Navigate incidents, alerts, and the investigation graph.
  3. Describe how automated attack disruption works and when it triggers.
  4. Perform basic threat hunting using the Advanced Hunting interface and pre-built queries.

1. What “XDR” means here

Extended Detection and Response (XDR) unifies detections from multiple security workloads into a single, correlated investigation experience. Microsoft Defender XDR is the unified portal (https://security.microsoft.com) that brings together the workload Defenders so you investigate one incident instead of chasing separate alerts in separate consoles.

The workloads that feed it:

  • Microsoft Defender for Endpoint (MDE) — device/endpoint detections.
  • Microsoft Defender for Office 365 (MDO) — email and collaboration threats.
  • Microsoft Defender for Identity (MDI) — on-premises identity / Active Directory threats.
  • Microsoft Defender for Cloud Apps (MDCA) — SaaS/cloud-app activity.

Identity risk from Microsoft Entra and other signals also contribute. The portal’s value is correlation: it stitches these into one timeline.

2. Signal correlation — alerts into incidents

The core concept: alerts are individual detections; an incident is the automatically correlated collection of related alerts, assets, and evidence that together describe one attack.

flowchart TD A1["MDE alert<br/>(suspicious process on a device)"] --> INC["Incident<br/>(correlated story)"] A2["MDO alert<br/>(malicious email delivered)"] --> INC A3["MDI alert<br/>(lateral movement attempt)"] --> INC A4["MDCA alert<br/>(anomalous cloud-app activity)"] --> INC INC --> E["Entities: devices, users, mailboxes, files, IPs"]

Diagram alt text: Four separate alerts — one each from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps — all feed upward into a single Incident node that represents the correlated story. The incident then connects to its entities: devices, users, mailboxes, files, and IP addresses.

Defender XDR correlates by shared entities (the same user, device, file hash, or IP appearing across alerts) and known attack patterns. The payoff: a phishing email (MDO), the endpoint that opened it (MDE), and the identity used to move laterally (MDI) become one incident with one attack story, instead of three analysts working three tickets.

Incident management workflow

Each incident carries metadata the SOC uses to triage:

  • Severity (Informational → Low → Medium → High) — relative urgency.
  • Status (New / In progress / Resolved) — where it is in the workflow.
  • Assignment — which analyst owns it.
  • Classification (true positive / false positive / etc.) — recorded on resolution to improve tuning and reporting.

3. The investigation graph

The incident graph (investigation graph) is a visual map of the incident’s entities and how they relate — which device ran which process, which user signed in where, which file was involved. It lets you trace the attack chain spatially rather than reading a flat alert list. You will use it in the lab to follow an attack from its entry point through its later stages.

4. Automated attack disruption

Automated attack disruption is a capability that automatically contains an in-progress attack — without waiting for analyst approval — when Defender XDR has high-confidence signal that a known high-impact attack (e.g., ransomware, business email compromise, adversary-in-the-middle) is unfolding.

  • What it does: takes targeted containment actions such as disabling a compromised user account or isolating a device, to break the attack chain early and limit blast radius.
  • When it triggers: only at high confidence, based on correlated multi-workload signals and Microsoft threat intelligence — it is deliberately conservative to avoid disrupting legitimate work.
  • Analyst role: you review the actions it took in the incident, understand why, and can undo them if needed. Disruption buys time; it does not replace investigation.

Key distinction: ordinary automated investigation and response (AIR) remediates after investigation, often with approval; attack disruption acts during an attack, automatically, to stop spread. As of June 2026, verify trigger scenarios and supported actions in-portal.

5. Advanced Hunting

Advanced Hunting is a query-based threat-hunting interface that runs KQL (Kusto Query Language) over a rich schema of raw event tables — letting you proactively search for threats and suspicious behavior beyond what alerts surface.

Schema overview

Data is organized into tables. Commonly used ones include (verify exact names in-portal, as of June 2026):

  • DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents — endpoint telemetry (MDE).
  • EmailEvents, EmailAttachmentInfo, UrlClickEvents — email telemetry (MDO).
  • IdentityLogonEvents, IdentityDirectoryEvents — identity telemetry (MDI).
  • CloudAppEvents — cloud-app activity (MDCA).
  • AlertEvidence, AlertInfo — alert metadata across workloads.

Basic KQL patterns

Three operators carry most beginner queries:

  • where — filter rows by condition.
  • project — select/rename columns to keep output readable.
  • summarize — aggregate (count, group by).
// Top processes launched via PowerShell in the last 24 hours
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName == "powershell.exe"
| summarize Count = count() by FileName, DeviceName
| order by Count desc

Expected output: a ranked list of processes that PowerShell launched, with counts per device — useful for spotting suspicious child processes of PowerShell. If the result is empty, either no such activity occurred in the window or the relevant devices are not onboarded/reporting.

Defender ships pre-built / shared queries you can run and adapt — a fast way to start hunting without writing KQL from scratch. The lab uses two of these and asks you to interpret the results.

ATT&CK tie-in

Hunting connects directly to M01: many Advanced Hunting queries and detections are mapped to MITRE ATT&CK techniques, and Defender XDR alerts are tagged with the tactics/techniques they represent — so a hunt for, say, LSASS credential access (T1003.001) is expressed in the same ATT&CK vocabulary you learned to map attacks with.

6. Cross-domain investigation (worked idea)

The signature Defender XDR move is linking an endpoint alert to an email campaign: a High incident shows a device alert (MDE) for a malicious process; the graph reveals the file arrived as an attachment in an email (MDO); pivoting to the email entity shows other recipients who got the same message. One incident now answers “who else is affected?” — the question that used to require three tools. This is exactly the kind of chain the lab walks you through.

7. Module summary

  • Defender XDR unifies detections from MDE, MDO, MDI, and MDCA (plus identity signals) into correlated incidents in one portal.
  • Alerts are individual detections; incidents are correlated stories built from shared entities; incidents carry severity, status, assignment, and classification.
  • The investigation graph visualizes the attack chain across entities.
  • Automated attack disruption auto-contains high-confidence, high-impact attacks in progress (e.g., disabling an account, isolating a device); analysts review and can undo.
  • Advanced Hunting runs KQL over endpoint/email/identity/cloud tables; where, project, and summarize cover most starter queries; pre-built queries accelerate hunting; detections map to MITRE ATT&CK.

Glossary (first-use acronyms in this module)

  • AIR — Automated Investigation and Response.
  • KQL — Kusto Query Language.
  • MDCA — Microsoft Defender for Cloud Apps.
  • MDE — Microsoft Defender for Endpoint.
  • MDI — Microsoft Defender for Identity.
  • MDO — Microsoft Defender for Office 365.
  • XDR — Extended Detection and Response.

Sources

Citations recorded per CLAUDE.md. Living documents; “as of June 2026” stamps indicate currency.

  1. Microsoft Learn — “What is Microsoft Defender XDR?” https://learn.microsoft.com/defender-xdr/microsoft-365-defender
  2. Microsoft Learn — “Incidents and alerts in Microsoft Defender XDR.” https://learn.microsoft.com/defender-xdr/incidents-overview
  3. Microsoft Learn — “Automatic attack disruption in Microsoft Defender XDR.” https://learn.microsoft.com/defender-xdr/automatic-attack-disruption
  4. Microsoft Learn — “Overview of advanced hunting in Microsoft Defender XDR.” https://learn.microsoft.com/defender-xdr/advanced-hunting-overview
  5. Microsoft Learn — “Advanced hunting schema reference.” https://learn.microsoft.com/defender-xdr/advanced-hunting-schema-tables
  6. Microsoft Learn — “Kusto Query Language (KQL) overview.” https://learn.microsoft.com/azure/data-explorer/kusto/query/
  7. MITRE ATT&CK — Enterprise tactics and techniques (for alert/hunt mapping). https://attack.mitre.org/matrices/enterprise/

M04 of 10 · Microsoft Defender — Security Operations Fundamentals · maps to curriculum.md → M04 learning objectives 1–4. Student handout — distribute freely to learners. No answer keys contained.