Skip to main content

Microsoft Defender XDR — Cloud Workload Protection

Defender for Endpoint covers the endpoint EDR layer: device onboarding, ASR rules, tamper protection, and EDR in block mode. This chapter covers the three workload-specific Defender products that extend detection across email, cloud apps, and identity, and the unified XDR portal that correlates signals from all of them into a single incident view.

ProductProtectsPrimary Threat
Defender for Office 365 (MDO)Exchange Online, Teams, SharePointPhishing, BEC, malware in email/files
Defender for Cloud Apps (MDA)SaaS apps, OAuth grants, shadow ITData exfiltration, insider threats, cloud misuse
Defender for Identity (MDI)Active Directory, Entra IDCredential theft, lateral movement, recon
Defender XDR PortalAll of the aboveCorrelated incident triage and automated response

Licensing

All four products are available in GCC High. MDO Plan 2, MDA, and MDI are included in Microsoft 365 GCC High E5 and Microsoft 365 GCC High E5 Security. If the tenant is on E3, they are available as add-ons.

ProductMinimum License
MDO Plan 1 (Safe Links, Safe Attachments)M365 E3 + Defender for Office 365 P1 add-on, or E5
MDO Plan 2 (Threat Explorer, AIR, Attack Sim)M365 E5 or E5 Security
Defender for Cloud AppsM365 E5, E5 Security, or MDA standalone
Defender for IdentityM365 E5, E5 Security, or MDI standalone

Portal: https://security.microsoft.us (GCC High XDR portal)


Defender for Office 365

MDO adds threat protection layers on top of Exchange Online Protection (EOP), which handles basic anti-spam and anti-malware. MDO Plan 1 adds pre-delivery detonation; Plan 2 adds post-breach investigation and training.

Safe Links rewrites URLs in email and Office documents and checks the destination at click time against Microsoft's threat intelligence feed. This catches URLs that were benign at delivery but were weaponized after the fact — a common technique in multi-stage phishing.

Key settings:

SettingRecommended Value
Enable Safe Links for email messagesOn
Enable Safe Links for Office appsOn
Do not track when users click Safe LinksOff (tracking required for audit evidence)
Do not allow users to click through to original URLOn for Highly Restricted users
Apply real-time URL scanningOn

Safe Links policies scope to recipients. Create a stricter policy for privileged users (executives, IT admins) that does not permit click-through.

Safe Attachments

Safe Attachments detonates email attachments in an isolated sandbox before delivery. Delivery is delayed by up to 5 minutes while detonation completes. For organizations where email latency is operationally sensitive, configure Dynamic Delivery — this delivers the email body immediately and replaces the attachment with a placeholder until detonation completes.

SettingRecommended Value
Safe Attachments unknown malware responseBlock
Dynamic DeliveryOn (for non-privileged users)
Enable redirectOn — route malicious attachments to security team mailbox
Apply Safe Attachments to SharePoint, OneDrive, TeamsOn (requires separate toggle in Global Settings)
Enable for SharePoint and Teams

Safe Attachments for SharePoint/OneDrive/Teams is controlled by a separate setting in Policies & rules → Threat policies → Global settings, not within the Safe Attachments policy itself. It is off by default.

Anti-Phishing: Impersonation Protection

MDO's anti-phishing policy adds impersonation detection on top of EOP's spoof intelligence. Impersonation protection watches for emails that claim to be from a specific user or domain without being that user or domain.

Users to protect (impersonation): Add executives, finance approvers, and any user who sends wire transfer or payroll instructions. Attackers specifically target these roles for BEC (Business Email Compromise).

Domains to protect (impersonation): Add your own domain(s) and any partner domains from which you regularly receive sensitive instructions.

SettingRecommended Value
Enable users to protectOn — add C-suite + finance + IT admins
Enable domains to protectOn — add owned domains + key partner domains
If message is detected as impersonated userQuarantine
If message is detected as impersonated domainQuarantine
Enable mailbox intelligenceOn
Enable intelligence for impersonation protectionOn

Attack Simulation Training

Attack Simulation Training (AST) sends simulated phishing emails to users and measures click rates, credential submission rates, and reporting rates. It requires MDO Plan 2.

NIST SP 800-171 Rev. 3 3.2.2 requires organizations to provide security awareness training. AST fulfills the practical exercise component of that requirement. Schedule quarterly simulations across the tenant and configure automatic training assignment for users who click.

Retain simulation results as audit evidence: Attack simulation trainingReports → export to CSV. CMMC assessors may request this as evidence of 3.2.2 compliance.

Threat Explorer and Real-Time Detections

Threat Explorer (MDO Plan 2) and Real-Time Detections (MDO Plan 1) provide an interactive query interface over email metadata and delivery events. Use them to:

  • Identify all emails from a sender during an incident
  • Find all recipients of a phishing campaign across the tenant
  • Determine the delivery action taken (delivered, junked, blocked, quarantined)
  • Trigger soft deletes of delivered phishing emails across all mailboxes

Soft deleting a delivered phishing campaign:

  1. Threat Explorer → filter by sender domain or subject
  2. Select matching messages → Take actionsMove to deleted items or Soft delete
  3. Review action status in the Action center

Automated Investigation and Response (AIR)

AIR (Plan 2) automatically investigates alerts, correlates related mailbox events, and recommends or executes remediation actions without analyst intervention. It is integrated with the XDR incidents view — AIR investigations appear as sub-investigations within an incident.

Enable AIR and configure the action approval setting:

SettingValue
Automated investigation triggerOn
Remediation approvalAuto-approve for High confidence verdicts; Require approval for Medium

Defender for Cloud Apps

Defender for Cloud Apps is Microsoft's CASB (Cloud Access Security Broker). It sits between users and cloud apps, providing visibility into SaaS usage, behavioral analytics, and inline session controls.

Shadow IT Discovery

MDA discovers cloud apps in use across the tenant by analyzing traffic logs from Defender for Endpoint (agent-based) or by ingesting firewall/proxy logs. The output is an app catalog showing:

  • App name and risk score (Microsoft-assigned, 0–10)
  • Number of users and transactions
  • Data uploaded/downloaded volumes
  • Whether the app is sanctioned or unsanctioned

Enable cloud app discovery via MDE integration:

MDA settings → Cloud discoveryAutomatic log uploadConnected apps → enable the Microsoft Defender for Endpoint integration. This routes endpoint DNS and network telemetry to MDA automatically — no firewall log collection needed.

Review the discovered app catalog monthly and Unsanction apps that pose risk (file sharing via personal storage, unapproved generative AI tools, shadow ERP integrations).

App Governance

App Governance monitors OAuth app consent grants — third-party and internal apps that have been granted permissions to the tenant. Compromised OAuth apps are a common persistence mechanism: the attacker grants a malicious app Mail.Read or Files.ReadWrite.All permissions and retains access even after the user's password is reset.

Key alert policies:

AlertTrigger
App with high privilegeApp granted Mail.ReadWrite or Directory.ReadWrite.All
Unused app with sensitive permissionOAuth app with broad permissions but < 5 users active in 90 days
App with anomalous data accessApp accessing significantly more data than its baseline
Newly registered app accessing sensitive dataNew app (< 30 days old) accessing labeled or sensitive content

Review the App governance dashboard monthly. Revoke consent for any app that cannot be attributed to a known IT-approved integration.

Conditional Access App Control

MDA integrates with Entra Conditional Access to proxy sessions through MDA for session-level controls. This enables policy enforcement on content within a session — not just access control at the authentication layer.

Common use cases:

ScenarioSession Policy
Unmanaged device accessing SharePointBlock download of Restricted-labeled files
External contractor accessing TeamsBlock copy/paste of sensitive content
High-risk user (Adaptive Protection)Monitor all activity and block upload
Any user accessing sensitive SharePoint siteApply watermark on viewed documents

Configure in Entra CA: create a Conditional Access policy with Session control → Use Conditional Access App ControlUse custom policy. Then configure the matching session policy in MDA.

NIST SP 800-171 Rev. 3 3.1.19 requires protecting CUI on mobile and non-organizational devices. MDA session policies are the technical control that satisfies this requirement for browser-based access to SharePoint/Teams from unmanaged devices — blocking download of CUI without blocking access entirely.

CMMC Control Mapping

NIST ControlMDA Capability
3.1.19 — Unmanaged device access to CUISession policy blocks CUI download on unmanaged devices
3.13.1 — Monitor communicationsCloud app discovery monitors data flows to SaaS apps
3.14.6 — Monitor for unauthorized useAnomalous data access alerts in App Governance

Defender for Identity

Defender for Identity (MDI) monitors on-premises Active Directory and Entra ID for attack patterns associated with credential theft, lateral movement, and reconnaissance. It reads AD audit events via a lightweight sensor installed on domain controllers.

Sensor Deployment

Install the MDI sensor on every domain controller (primary and read-only). The sensor reads the AD event log and network traffic in real time and forwards signals to the MDI cloud service.

# Download sensor installer from MDI portal
# Settings → Sensors → Add sensor → Download installer

# Install on each DC (run as Domain Admin)
.\Azure ATP sensor Setup.exe /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<workspace-access-key>"

For GCC High, the MDI workspace endpoint is <workspace-name>.atp.azure.us — verify the installer is configured to point to the correct sovereign cloud endpoint before deploying.

After installation, verify sensor health in the MDI portal (Security.microsoft.us → Settings → Identities → Sensors) — all DCs should show Running within 5 minutes.

Key Detection Categories

CategoryExample Detections
ReconnaissanceLDAP enumeration, SMB session enumeration, user/group discovery
Credential accessPass-the-hash, pass-the-ticket, Kerberoasting, AS-REP roasting, NTLM relay
Lateral movementOverpass-the-hash, suspected DCSync, remote code execution via WMI/PSExec
Domain dominanceSkeleton key attack, Golden Ticket, DCSync from non-DC
ExfiltrationUnusual large LDAP query, suspected NTDS.dit export

MDI triggers alerts that appear as incidents in the unified XDR portal, correlated with any related MDE, MDO, or Entra signals.

Honeytoken Accounts

MDI supports configuring honeytoken accounts — AD accounts that should never be used in normal operations. Any authentication or query against a honeytoken account generates an immediate High severity alert.

Create 2–3 honeytoken accounts with names that appear valuable to an attacker (e.g., svc-backup, admin-legacy) but are disabled or have no real permissions. Register them in MDI: Settings → Honeytoken accounts.

Integration with Entra ID Protection

MDI feeds its user risk signals into Entra ID Protection. A user flagged by MDI for pass-the-hash activity will have their Entra user risk score elevated, which can trigger a Conditional Access policy requiring MFA re-authentication or blocking access until the risk is remediated — without manual security team intervention.

Ensure the Entra ID Protection integration is enabled in MDI settings: Settings → Microsoft Entra ID → Enable Entra ID Protection integration.


The Unified XDR Incidents View

The Microsoft Defender XDR portal correlates alerts from MDE, MDO, MDA, and MDI into unified incidents — a single case that links all related alerts, affected users, devices, and emails. This is the primary triage interface for the security operations team.

Incidents Triage Workflow

  1. Incidents queue (security.microsoft.us/incidents) — sorted by severity. High/Critical incidents should be triaged within 1 hour.
  2. Open an incident → review the Attack story graph — this shows the kill chain: initial access, execution, lateral movement, and data access in a visual timeline.
  3. Review Evidence and response — affected mailboxes, devices, users, and cloud apps, with recommended actions for each.
  4. Execute remediation actions directly from the incident: isolate device, soft delete emails, revoke user sessions, disable user account.
  5. Close the incident with a classification: True positive (with threat type) or False positive.

Advanced Hunting

Advanced Hunting provides a KQL query interface over the full 30-day event history across all Defender workloads. Use it for proactive threat hunting and deep incident investigation.

Useful starting queries:

// Emails delivered containing known phishing URLs
EmailEvents
| where ThreatTypes has "Phish"
| where DeliveryAction == "Delivered"
| summarize count() by SenderFromAddress, RecipientEmailAddress, Subject
| sort by count_ desc

// Devices with high-severity MDI alerts in past 7 days
AlertInfo
| where ServiceSource == "Microsoft Defender for Identity"
| where Severity == "High"
| where Timestamp > ago(7d)
| join AlertEvidence on AlertId
| summarize Alerts=count() by DeviceName, AccountUpn
| sort by Alerts desc

// OAuth apps with Mail.ReadWrite permission granted recently
CloudAppEvents
| where ActionType == "Consent to application"
| where RawEventData has "Mail.ReadWrite"
| where Timestamp > ago(30d)
| project Timestamp, AccountDisplayName, Application=tostring(RawEventData.AppDisplayName)

Secure Score

Microsoft Secure Score aggregates configuration health across the entire Defender XDR suite into a single score. Each recommended action has an associated point value and maps to a control framework (NIST, ISO 27001, SOC 2).

Review Secure Score monthly and prioritize recommendations by:

  1. Impact (points)
  2. Implementation effort (Low/Medium/High)
  3. Regulatory relevance (filter by NIST 800-171 to see compliance-relevant actions)

Secure Score is not a compliance score — a high score does not mean you are compliant. Use it as an operational hygiene metric alongside your compliance control matrix.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.