Defender XDR Incident Correlation

Incident correlation is the process by which Microsoft 365 Defender (M365D) automatically groups related alerts from different security domains—endpoint (Microsoft Defender for Endpoint), identity (Microsoft Defender for Identity), email and collaboration (Microsoft Defender for Office 365), and cloud applications (Microsoft Defender for Cloud Apps)—into a single incident. This provides security operations teams with a unified view of an attack chain, reducing alert fatigue and enabling faster, more effective response.

The SC-200 exam expects you to understand the correlation mechanism, how incidents are created, enriched, and resolved, and how to manually adjust correlation or create custom detections.

M365D uses a sophisticated correlation engine that runs within the Microsoft 365 Defender portal (security.microsoft.com). The engine continuously evaluates incoming alerts against a set of correlation rules. These rules consider:

When the engine finds a match, it creates a new incident or adds alerts to an existing incident. The incident is assigned a unique ID (e.g., inc-12345) and a severity level based on the highest severity alert within it.

1. Alerts: Raw signals from each defender workload. Each alert has a severity (Informational, Low, Medium, High), category (e.g., Malware, Suspicious Activity), and a detection source. 2. Incident: A container for related alerts. Properties include: - Incident ID - Title (automatically generated based on attack type) - Severity (Informational, Low, Medium, High, Critical) - Status (New, In Progress, Resolved) - Tags (custom labels) - Assigned to (analyst) - Classification (True positive, False positive, Benign) - Determination (e.g., Malware, Phishing, Unwanted software) 3. Correlation Engine: Runs on a backend service that processes alerts in near real-time. It uses machine learning to identify patterns and reduce false positives. 4. Incident Queue: The main view in M365D portal where incidents are listed. Default sorting by last updated time.

- Critical alert → Critical incident - High alert → High incident - Medium alert → Medium incident - Low alert → Low incident - Informational → Informational (rarely used)

To view incidents: Navigate to https://security.microsoft.com/incidents. Use filters for status, severity, assigned to, etc.

To manually correlate alerts: You can manually add alerts to an existing incident from the alert details page by selecting "Link to incident" and providing the incident ID.

To create custom correlation rules: Use Advanced Hunting with Kusto Query Language (KQL). For example, to find alerts from the same user within 1 hour:

AlertEvidence
| where Timestamp > ago(1h)
| summarize TotalAlerts = count() by AccountUpn, AlertId
| where TotalAlerts > 1

To create an automation rule that triggers on incident creation:

1. Alert Generation: Each workload generates alerts based on detections. For example, Defender for Endpoint creates an alert when a suspicious PowerShell command is executed. 2. Ingestion: Alerts are sent to the M365D backend via the unified audit log and API. 3. Correlation: The engine runs correlation algorithms, grouping alerts that share entities (user, device, IP) within the time window. 4. Incident Creation: A new incident is created with a title like "Multi-stage incident involving a user and endpoint." The severity is set to the highest alert severity. 5. Enrichment: The incident is automatically enriched with: - Threat intelligence: Known indicators (IPs, hashes) from Microsoft Threat Intelligence. - User context: User risk level from Azure AD Identity Protection. - Device context: Device risk score from Defender for Endpoint. - Alert evidence: List of all related alerts with their details. 6. Notification: Assigned analysts receive alerts via email or Microsoft Teams (if configured). 7. Automation rules: If conditions match, automation rules run (e.g., add tag, assign to tier 2). 8. Triage and Response: Analyst reviews the incident, performs actions, and resolves.

Scenario 1: Phishing Attack on a Financial Institution

A financial institution with 10,000 users deploys M365D across all domains. An attacker sends a phishing email to an employee in finance. Defender for Office 365 detects the malicious link and creates an alert. The user clicks the link and enters credentials. Defender for Identity detects the anomalous logon from a foreign IP and creates another alert. The attacker then uses the compromised account to access SharePoint and download sensitive files. Defender for Cloud Apps triggers an alert for mass download. The M365D correlation engine sees all three alerts share the same user (employee@contoso.com) and occur within 2 hours, grouping them into a single incident titled "Phishing campaign with credential theft and data exfiltration." The SOC analyst sees the full timeline, identifies the compromised user, resets the password, and blocks the malicious IP. Without correlation, these alerts would be triaged separately, delaying response.

Scenario 2: Ransomware Outbreak at a Healthcare Provider

A hospital uses M365D. A user opens a malicious attachment, triggering a Defender for Endpoint alert for suspicious file execution. The ransomware begins encrypting files, causing multiple alerts for file modifications and process injections. Defender for Identity detects the compromised account moving laterally to other servers. The correlation engine groups all alerts into one incident, identifying the attack as ransomware. An automation rule automatically isolates the affected device and disables the user account. The incident severity is set to Critical. The SOC team investigates using the incident graph and confirms the containment. They then perform remediation steps like restoring from backups.

Common Misconfigurations:

What SC-200 Tests on Incident Correlation:

Common Wrong Answers:

Specific Values and Terms:

Edge Cases:

How to Eliminate Wrong Answers:

1. Myth: Incidents are only created when multiple alerts exist. Reality: A single alert can create an incident if no other alerts correlate.

2. Myth: The correlation engine uses only machine learning. Reality: It uses rule-based and ML models.

3. Myth: You can disable correlation entirely. Reality: There is no UI toggle; correlation is always on.

4. Myth: Incident severity is calculated by averaging alert severities. Reality: It uses the highest severity among alerts.

5. Myth: Automation rules can only run on alerts. Reality: They can run on incidents as well.

1. Incident vs. Alert - Incident: A collection of related alerts; has a lifecycle (New, In Progress, Resolved); can be assigned to an analyst. - Alert: A single detection signal; has a severity and category; can exist independently.

2. Manual vs. Automatic Correlation - Manual: Analyst links alerts to an existing incident via portal or API. - Automatic: Engine groups alerts based on rules and ML.

3. Incident in M365D vs. Incident in Sentinel - M365D: Native to Defender; limited to Defender workloads; automatic correlation. - Sentinel: SIEM; can ingest from multiple sources; correlation via analytics rules.

1. Q: How do I manually correlate alerts into an incident? A: Open the alert details page, click "Link to incident", enter the incident ID, and click confirm. The alert will be added to that incident.

2. Q: Can I change the default correlation time window? A: There is no direct UI setting. You can use Advanced Hunting to create custom queries that group alerts within a different window, but the default engine uses 24 hours.

3. Q: What happens if I resolve an incident but new related alerts come in? A: The incident will be reopened automatically, and its status will change back to "In Progress" or "New" depending on configuration.

4. Q: How do I create an automation rule for incidents? A: Go to Settings > Microsoft 365 Defender > Automation rules > Add rule. Define conditions (e.g., severity = High) and actions (e.g., assign to analyst).

5. Q: Can I integrate M365D incidents with a third-party SIEM? A: Yes, via the Microsoft 365 Defender API or by streaming incidents to Microsoft Sentinel and then to other SIEMs.

6. Q: What is the difference between an alert and an incident? A: An alert is a single detection signal. An incident is a collection of related alerts that together represent an attack story.

7. Q: How do I view the incident timeline? A: Open the incident, go to the "Timeline" tab. It shows alerts in chronological order.

1. Q: What is the default time window for automatic alert correlation in Microsoft 365 Defender? A: 24 hours. The correlation engine groups alerts that occur within 24 hours of each other and share common entities.

2. Q: When an incident is created, how is its severity determined? A: It is set to the highest severity among all alerts in the incident. For example, if one alert is Critical and others are Medium, the incident severity is Critical.

3. Q: Which of the following is NOT a valid incident status? A: "In Review" is not a valid status. Valid statuses are New, In Progress, and Resolved.

4. Q: True or False: You can manually create an incident in Microsoft 365 Defender. A: True. You can manually create an incident from the incidents page or via API.

5. Q: What is the purpose of incident enrichment? A: To provide additional context such as threat intelligence, user risk level, and device risk score, helping analysts make faster decisions.

Scenario 1: Phishing Attack on a Financial Institution

A financial institution with 10,000 users deploys M365D across all domains. An attacker sends a phishing email to an employee in finance. Defender for Office 365 detects the malicious link and creates an alert. The user clicks the link and enters credentials. Defender for Identity detects the anomalous logon from a foreign IP and creates another alert. The attacker then uses the compromised account to access SharePoint and download sensitive files. Defender for Cloud Apps triggers an alert for mass download. The M365D correlation engine sees all three alerts share the same user (employee@contoso.com) and occur within 2 hours, grouping them into a single incident titled 'Phishing campaign with credential theft and data exfiltration.' The SOC analyst sees the full timeline, identifies the compromised user, resets the password, and blocks the malicious IP. Without correlation, these alerts would be triaged separately, delaying response.

Scenario 2: Ransomware Outbreak at a Healthcare Provider

A hospital uses M365D. A user opens a malicious attachment, triggering a Defender for Endpoint alert for suspicious file execution. The ransomware begins encrypting files, causing multiple alerts for file modifications and process injections. Defender for Identity detects the compromised account moving laterally to other servers. The correlation engine groups all alerts into one incident, identifying the attack as ransomware. An automation rule automatically isolates the affected device and disables the user account. The incident severity is set to Critical. The SOC team investigates using the incident graph and confirms the containment. They then perform remediation steps like restoring from backups.

Common Misconfigurations:

Performance Considerations: At scale (e.g., 50,000+ endpoints), the correlation engine handles high throughput, but analysts may experience alert fatigue if false positives are not tuned. Automation rules help reduce noise by auto-resolving low-severity incidents or adding tags for filtering.