Introduction to Microsoft Defender XDR Threat Protection

What Defender XDR is — and what it replaced

Microsoft Defender XDR is the unified security platform at security.microsoft.com. It coordinates detection, investigation, and response across four specialized products: Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. The platform is not a dashboard that displays alerts from separate tools. It is a correlation engine that connects signals from those tools into unified incidents with shared timelines, shared entities, and cross-product response actions.

Before Defender XDR existed, each product ran independently. An email alert lived in the Exchange Online Protection console. An endpoint alert lived in the Defender for Endpoint portal. An identity alert lived in Azure ATP (the predecessor to Defender for Identity). An analyst investigating a phishing attack that led to credential theft, lateral movement, and data exfiltration had to work across four portals, manually connecting evidence by matching timestamps and user principal names. The correlation happened in the analyst's head, or it didn't happen at all.

Defender XDR automates that correlation. When a phishing email, an anomalous sign-in, a malware execution, and an inbox forwarding rule all involve the same user within a short time window, the platform groups those four alerts into a single incident. You investigate one incident with one timeline, not four alerts in four queues. The platform also extends to Microsoft Sentinel: since GA in early 2025, Sentinel alerts land directly in the Defender incident queue alongside XDR signals when the workspace is connected, giving you SIEM and XDR in a single console.

Figure 1.1: The Defender XDR architecture. Four products feed telemetry into the correlation engine, which groups related alerts into incidents and surfaces them through a unified portal at security.microsoft.com.

The four products: what each one protects and where it goes blind

Every Defender product covers a specific domain. Understanding each domain's boundaries is how you know where to look during an investigation, and how you recognize when evidence is missing because the product responsible for that domain isn't deployed or isn't configured.

Defender for Endpoint

Defender for Endpoint protects devices: Windows, macOS, Linux workstations and servers, plus iOS and Android with mobile threat defense. The product combines next-generation antivirus (real-time protection against known malware), endpoint detection and response (behavioral monitoring that catches malware AV misses), and attack surface reduction rules (proactive policy enforcement that blocks risky behaviors before they execute). When something suspicious happens on a device, when a process spawns an unusual child, a script calls a suspicious URL, a credential tool reads LSASS memory, Defender for Endpoint generates an alert.

The key Advanced Hunting tables are DeviceProcessEvents (every process creation, the most important endpoint table), DeviceNetworkEvents (every network connection made by a process), DeviceFileEvents (file creation, modification, deletion), DeviceLogonEvents (local and remote logon events), and DeviceRegistryEvents (registry changes that indicate persistence). You'll query these tables heavily in Section 1.4 and again in the cross-product investigation in Section 1.8.

The response actions available from the device page include full network isolation (the device can communicate only with the Defender service), an investigation package that collects running processes, network connections, autoruns, event logs, and more, a live response session for remote command execution, and app execution restriction that blocks unsigned binaries. These actions appear in every incident where a device is compromised. Section 1.4 covers when to use each one.

Where Defender for Endpoint goes blind: it has no visibility into email content, identity infrastructure, or cloud application activity. If an attacker operates exclusively through stolen OAuth tokens and never touches a managed device, Defender for Endpoint generates zero alerts. That gap is precisely what Defender for Cloud Apps and Entra ID Protection cover.

Defender for Office 365

Defender for Office 365 protects the email and collaboration layer: Exchange Online mailboxes, Teams messages, SharePoint and OneDrive files. The product runs a multi-layer filtering stack. Exchange Online Protection (EOP) handles connection filtering, anti-malware, and anti-spam as the first gate. Defender for Office 365 adds Safe Attachments (sandbox detonation of attachments), Safe Links (time-of-click URL scanning that re-evaluates links at the moment a user clicks, not just at delivery), and anti-phishing policies that detect impersonation, spoofing, and BEC patterns.

The key tables are EmailEvents (every email received with delivery action and threat classification), EmailAttachmentInfo (attachment metadata and threat verdicts), EmailUrlInfo (URLs in email bodies with scanning results), EmailPostDeliveryEvents (zero-hour auto purge actions taken after delivery), and UrlClickEvents (Safe Links user click tracking). Threat Explorer, the primary email investigation tool, provides a visual interface over the same data and is available only with Plan 2 (E5).

The response actions include soft delete (move to Deleted Items), hard delete (purge from all mailbox folders including Recoverable Items), block sender, and submission for deep analysis. Defender for Office 365 also runs Automated Investigation and Response (AIR) playbooks that can trigger when a user reports phishing, when ZAP removes a message post-delivery, or when Threat Explorer identifies a campaign. AIR examines the full campaign scope, identifying all recipients and recommending bulk remediation. Section 1.3 covers these flows in detail.

Where it goes blind: Defender for Office 365 has no endpoint visibility and no identity telemetry. Once a user clicks a malicious link, downloads a payload, and runs it, the email story ends and the endpoint story begins. If the phishing email passes all filters and the user's credentials are stolen through a convincing AiTM page hosted on a legitimate cloud service, the identity compromise is visible only to Entra ID Protection and Defender for Identity.

Defender for Identity

Defender for Identity monitors on-premises Active Directory. It runs as a sensor installed on domain controllers (or as a standalone sensor that captures mirrored traffic) and analyzes authentication protocols, LDAP queries, DNS requests, and SMB traffic to detect attacks against the identity infrastructure.

The detection categories are reconnaissance (LDAP enumeration, DNS record queries, SMB session enumeration, the attacker mapping targets), credential theft (Kerberoasting service ticket requests, AS-REP roasting against accounts without pre-authentication, NTLM relay, DCSync replication requests), lateral movement (pass-the-hash, pass-the-ticket, overpass-the-hash, remote code execution via WMI or DCOM), and domain dominance (golden ticket, skeleton key, SID-history injection). Each detection maps directly to the MITRE ATT&CK matrix for Active Directory attacks.

The key tables are IdentityLogonEvents (authentication events from domain controllers, including type, protocol, and result), IdentityQueryEvents (LDAP and DNS queries that indicate reconnaissance), and IdentityDirectoryEvents (directory changes including group membership modifications and password resets).

One of the most valuable features is the Lateral Movement Paths visualization, which maps how compromised credentials can chain across machines. If a service account logged into three workstations and two of those workstations have a domain admin cached credential, Defender for Identity shows the two-hop path from the service account to domain admin. That visual map changes how you assess the blast radius of a compromised account.

Where it goes blind: Defender for Identity requires sensors on domain controllers, so it covers only on-premises AD. Cloud-only environments running Entra ID without on-premises AD have no Defender for Identity coverage. Critically, attacks that bypass on-premises AD entirely, such as AiTM token replay against Entra ID, are invisible to Defender for Identity. This is why the AiTM investigation in Section 1.8 relies on sign-in logs and CloudAppEvents, not IdentityLogonEvents.

Defender for Cloud Apps

Defender for Cloud Apps is the cloud access security broker (CASB). It provides visibility into cloud application usage across the organization, including sanctioned M365 services and unsanctioned third-party SaaS. The product operates through API connectors for sanctioned apps (deep visibility into activity, file sharing, permissions) and through Cloud Discovery for unsanctioned apps (network traffic analysis identifying shadow IT).

The primary security use cases are OAuth governance (detecting malicious or overprivileged application consent grants, which are a growing attack vector for persistent access without credentials), anomalous behavior detection (impossible travel, mass file downloads, unusual admin activity), and session controls (integrating with Conditional Access to enforce real-time restrictions like blocking downloads from unmanaged devices during authenticated sessions).

The key table is CloudAppEvents, which captures activity across all connected cloud applications. This is the table that shows you post-compromise actions like inbox rule creation, mail forwarding configuration, bulk file access, and application consent grants: the activities that indicate an attacker establishing persistence and exfiltrating data after initial access.

Where it goes blind: detection depth depends on the API connector for each SaaS application. Microsoft 365 services have deep integration. Third-party apps like Salesforce or Google Workspace have varying levels of visibility depending on the connector capabilities. On-premises applications with no cloud connectivity are completely invisible.

How the correlation engine works

The correlation engine is the component that makes XDR more than four products with a shared portal. It processes individual alerts from all four products and groups them into incidents based on three types of signal matching.

Entity matching is the primary mechanism. When alerts from different products share common entities, the same user principal name, the same device, the same IP address, the same mailbox, the engine links them. A phishing email alert (Office 365) involving j.morrison@northgateeng.com and an anomalous sign-in alert (Entra ID) involving the same UPN are linked because the entity matches.

Temporal proximity strengthens the correlation. Alerts involving the same entities that occur within a compressed time window receive higher correlation confidence than alerts separated by days. A credential phishing alert followed by an anomalous sign-in twelve minutes later and a suspicious inbox rule twenty minutes after that presents strong temporal evidence of a single attack chain.

ATT&CK chain logic adds tactical context. The engine recognizes that Initial Access (phishing) followed by Credential Access (token theft) followed by Collection (inbox rule) followed by Persistence (OAuth app consent) represents a coherent attack progression. Alerts that fit a recognized pattern receive higher correlation confidence than alerts with matching entities but no tactical relationship.

The output is an incident with a severity calculated from the highest-severity alert, an attack story narrative, a list of all impacted entities, and the complete set of correlated alerts with their product sources and timestamps. This incident is the unit of work in Defender XDR. You investigate incidents, not individual alerts.

The incident above is what you see in the portal. Four alerts from four different products, correlated by the shared user entity and compressed time window, presented as a single investigation. Section 1.2 teaches you how to triage and investigate incidents like this one.

Automatic attack disruption

Automatic attack disruption is the XDR capability that acts before you do. When the correlation engine identifies a high-confidence attack in progress, specifically human-operated ransomware, AiTM phishing, or business email compromise, it takes containment actions automatically: disabling the compromised user account through Defender for Identity, isolating the affected device through Defender for Endpoint, or both. The goal is to stop lateral movement while the analyst catches up.

The system operates in three stages. First, it correlates signals across products into a high-confidence incident, using the same entity matching and ATT&CK chain logic described above but with a higher confidence threshold. Second, it identifies the assets the attacker controls: the compromised account, the infected device. Third, it takes containment actions against those assets: disabling the user in Active Directory (via the Defender for Identity sensor on the domain controller), containing the device on the network (via the Defender for Endpoint agent), or both.

Attack disruption is enabled by default when the prerequisite products are deployed and configured. The yellow "Attack Disruption" tag on an incident in the queue tells you that automated containment has already occurred. You investigate the incident knowing the attacker's access has been interrupted, which changes your triage priority: containment is done, so you focus on scoping the blast radius and eradicating persistence rather than racing to contain.

The analyst retains full control. Every automated action appears in the incident timeline with the tag "Attack Disruption" and can be reversed. If the classification changes — the incident turns out to be a false positive — you re-enable the user account and release the device from isolation. The platform does not permanently remediate; it contains. The analyst decides what happens next.

Advanced Hunting: the unified query workspace

Advanced Hunting at security.microsoft.com provides a single KQL workspace that queries tables from all four Defender products. The same KQL syntax you use in Sentinel works here, with one critical difference: the available tables are not the same.

SigninLogs is a Sentinel table. It does not exist in Advanced Hunting. If you write a query that references SigninLogs in the Advanced Hunting editor, it fails. The equivalent data in Advanced Hunting lives in IdentityLogonEvents (for Defender for Identity telemetry) and AADSignInEventsBeta (for Entra ID sign-in data). This table name mismatch trips up every analyst who moves between Sentinel and Advanced Hunting. When the course provides a KQL query, it specifies which interface the query runs in. Most queries work in both environments, but the table names differ.

// Advanced Hunting — cloud app activity for a specific user
CloudAppEvents
| where Timestamp > ago(24h)
| where AccountDisplayName == "Jordan Morrison"
| summarize EventCount = count() by ActionType, Application
| sort by EventCount desc

This query runs in Advanced Hunting against the CloudAppEvents table: data from Defender for Cloud Apps. The same query structure works against any table in the unified schema. In Section 1.8, you'll build cross-product queries that join EmailEvents (Office 365), IdentityLogonEvents (Identity), DeviceProcessEvents (Endpoint), and CloudAppEvents (Cloud Apps) to trace a multi-stage attack from initial phishing email through to data exfiltration.

Licensing: what each tier gives you

Licensing determines which products are active in your portal, which directly determines your detection coverage. Understanding the licensing boundaries is a practical skill because you'll encounter environments at every tier, and the investigation workflow changes when products are missing.

M365 E3 includes Defender for Endpoint Plan 1 (next-gen AV and basic EDR, but no Advanced Hunting tables, no live response, no automated investigation) and basic XDR incident correlation. It does not include Defender for Office 365, Defender for Identity, or Defender for Cloud Apps. An E3 organization investigating a phishing attack has no email telemetry, no identity attack detection, and no cloud app visibility in the Defender portal. The analyst works with endpoint data only.

M365 E5 includes all four products at full capability: Defender for Endpoint Plan 2 (full EDR with Advanced Hunting, live response, and automated investigation), Defender for Office 365 Plan 2 (Threat Explorer, AIR, campaign views), Defender for Identity, and Defender for Cloud Apps. E5 is where the full XDR correlation engine operates — all four signal sources are active. Advanced Hunting has the complete table schema.

M365 Business Premium includes Defender for Endpoint Plan 1 and Defender for Office 365 Plan 1 (Safe Attachments and Safe Links without Threat Explorer or AIR). No Defender for Identity, no Defender for Cloud Apps. Business Premium organizations have email and endpoint protection but no identity or cloud app visibility, and limited Advanced Hunting.

This course assumes M365 E5 licensing. The developer tenant from Module 0 provides E5 capability for lab exercises. If your production environment runs E3 or Business Premium, the investigation methodology applies, but the tools available to you are a subset of what the course demonstrates.