1.1 Introduction to Microsoft Defender XDR Threat Protection

Introduction to Microsoft Defender XDR Threat Protection

Introduction

Microsoft Defender XDR (Extended Detection and Response) is the unified security platform that ties together four specialized security products — Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps — under a single correlation engine and investigation interface.

Before Defender XDR existed, each product operated independently. An email alert was in one portal. An endpoint alert was in another. An identity alert was in a third. An analyst investigating a phishing attack that compromised a user’s credentials, led to malware on their device, and resulted in data exfiltration through a cloud app had to pivot between four separate portals, manually connecting the evidence.

Defender XDR solves this by:

1. Correlating alerts into incidents — a phishing email alert, a suspicious sign-in alert, and a malware detection alert become a single incident when XDR determines they are part of the same attack
2. Providing a unified investigation interface — one portal, one incident queue, one advanced hunting schema across all products
3. Enabling cross-product response — from a single incident view, you can remediate email, isolate a device, revoke user sessions, and block an OAuth app

This subsection maps the platform architecture so you understand what each component does, what data it produces, and how the pieces connect. Subsections 1.2-1.6 then go deep on each component.

The four pillars of Defender XDR

Each Defender product protects a specific domain and produces specific data. Understanding what each one does — and what it does NOT do — is essential for knowing where to look during an investigation.

Microsoft Defender for Endpoint

What it protects: Devices — Windows, macOS, Linux, iOS, Android workstations and servers.

What it detects: Malware execution, suspicious process behavior, network connections to known-malicious destinations, credential dumping, lateral movement, privilege escalation, persistence mechanisms.

Key data tables:

• DeviceProcessEvents — every process created on the device (the most important endpoint table)
• DeviceNetworkEvents — every network connection made by processes
• DeviceFileEvents — file creation, modification, deletion
• DeviceLogonEvents — local and remote logon events
• DeviceRegistryEvents — registry key changes (persistence indicators)
• DeviceInfo — device inventory and health status

Key response actions: Isolate device, collect investigation package, run antivirus scan, restrict app execution, live response (remote shell).

Coverage gap: Does not protect email content, identity infrastructure, or cloud applications. If the attacker operates purely through OAuth tokens and never touches a device, Defender for Endpoint generates no alerts.

Microsoft Defender for Office 365

What it protects: Email (Exchange Online), collaboration (Teams, SharePoint, OneDrive) — the communication and file-sharing layer.

What it detects: Phishing emails (including impersonation and spoof), malicious attachments (sandbox detonation), malicious URLs (time-of-click scanning), business email compromise patterns, malicious files in SharePoint/OneDrive/Teams.

Key data tables:

• EmailEvents — every email received, with delivery action and threat classification
• EmailAttachmentInfo — attachment metadata and threat verdict
• EmailUrlInfo — URLs in email bodies with scanning results
• EmailPostDeliveryEvents — ZAP actions taken after delivery
• UrlClickEvents — user click tracking for Safe Links

Key response actions: Soft delete/hard delete emails from mailboxes, block sender, submit for analysis, automated investigation of email campaigns.

Coverage gap: Does not protect endpoints, identity, or non-M365 cloud apps. A zero-day malware attachment that passes sandbox detection and executes on a device is an Endpoint problem, not an Office 365 problem.

Microsoft Defender for Identity

What it protects: On-premises Active Directory and hybrid identity infrastructure — the authentication backbone.

What it detects: Reconnaissance (LDAP enumeration, DNS reconnaissance), credential theft (Kerberoasting, AS-REP roasting, DCSync, pass-the-hash), lateral movement (pass-the-ticket, overpass-the-hash, remote code execution), privilege escalation (SID-history injection, domain controller exploitation).

Key data tables:

• IdentityLogonEvents — authentication events from AD domain controllers
• IdentityQueryEvents — LDAP, DNS, and SMB queries (reconnaissance indicators)
• IdentityDirectoryEvents — directory changes (group membership, password resets)

Key response actions: Disable user account in Active Directory, force password reset, suspend user in Entra ID.

Coverage gap: Requires sensors installed on domain controllers. Does not protect cloud-only (Entra ID only) environments. Does not detect attacks that bypass AD entirely (e.g., AiTM token replay against Entra ID — this is why the Module 11 AiTM investigation does not rely heavily on Defender for Identity).

Microsoft Defender for Cloud Apps

What it protects: Cloud applications — both Microsoft (M365 services) and third-party SaaS (Salesforce, Google Workspace, Dropbox, etc.).

What it detects: Anomalous cloud app usage, OAuth consent phishing (malicious app registrations), impossible travel for cloud apps, mass file download (data exfiltration), shadow IT (unauthorized SaaS usage), suspicious inbox rules.

Key data tables:

• CloudAppEvents — activity across connected cloud applications

Key response actions: Revoke OAuth app permissions, suspend user, require step-up authentication via conditional access app control.

Coverage gap: Requires app connectors for third-party SaaS visibility. Detection depth depends on the API access granted by each SaaS provider. On-premises applications without cloud connectivity are invisible.

The XDR correlation engine — how signals become incidents

The defining capability of Defender XDR is automated incident correlation. Individual alerts from different products are automatically grouped into incidents when XDR identifies shared entities — the same user, the same IP address, the same device, the same email.

Example: an AiTM phishing attack across the stack

1. Defender for Office 365 detects a suspicious email → generates an alert
2. Entra ID Protection detects a sign-in from an unusual location with a suspicious token → generates an alert
3. Defender for Cloud Apps detects an inbox rule creation with suspicious keywords → generates an alert
4. Defender for Endpoint detects a suspicious process on the user’s device → generates an alert

All four alerts reference the same user. XDR correlates them into a single incident: “Multi-stage attack: phishing → credential theft → post-compromise activity → endpoint compromise.” The analyst sees one incident with four correlated alerts, not four separate alerts in four separate queues.

The unified portal — security.microsoft.com

The Defender XDR portal at security.microsoft.com is your primary workspace. Understanding its layout saves time during every investigation.

Key sections:

Advanced Hunting — the KQL interface

Advanced Hunting is where Module 6 (KQL) meets Module 1 (Defender XDR). The same KQL queries you wrote against Sentinel tables work in Advanced Hunting — but the tables are slightly different.

Sentinel vs Advanced Hunting table availability:

Licensing — what you get at each tier

Understanding licensing matters because it determines which features are available in your portal.