1.8 Cross-Product Incident Correlation

Cross-Product Incident Correlation

Introduction

This subsection is not in Microsoft Learn. It teaches the skill that defines an advanced SOC analyst: tracing an attack across multiple Defender products using KQL and the unified Advanced Hunting schema.

Defender XDR automatically correlates alerts into incidents. But automated correlation has limits — it identifies connections based on shared entities, not on your understanding of the attack. This subsection teaches you to manually correlate across products when the automated correlation misses connections, or when you need to validate and extend what the automation found.

The key skill: using KQL joins and unions from Module 6 against the Advanced Hunting tables to build a complete attack narrative across email, identity, endpoint, and cloud apps.

The cross-product investigation pattern

A phishing attack touches every Defender product in sequence:

1. Email (EmailEvents) — phishing email delivered
2. Identity (IdentityLogonEvents) — attacker signs in with stolen credentials
3. Cloud Apps (CloudAppEvents) — attacker creates inbox rule, accesses mailbox
4. Endpoint (DeviceProcessEvents) — if the attacker drops malware

Each step lives in a different table. The entity that connects them is the user: the email recipient is the sign-in user is the inbox rule creator is the device owner.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// Complete cross-product attack timeline for a single user
let targetUser = "j.morrison";
let timeWindow = 24h;
union
    (EmailEvents
        | where Timestamp > ago(timeWindow)
        | where RecipientEmailAddress has targetUser
        | where ThreatTypes has "Phish"
        | project Timestamp, Phase = "1-Email", 
            Detail = strcat("Phishing from ", SenderFromDomain, ": ", Subject),
            SourceIP = SenderIPv4),
    (IdentityLogonEvents
        | where Timestamp > ago(timeWindow)
        | where AccountUpn has targetUser
        | where ActionType == "LogonSuccess"
        | project Timestamp, Phase = "2-Identity",
            Detail = strcat("Sign-in to ", Application),
            SourceIP = IPAddress),
    (CloudAppEvents
        | where Timestamp > ago(timeWindow)
        | where AccountDisplayName has targetUser
        | where ActionType in ("New-InboxRule", "MailItemsAccessed", "Set-Mailbox")
        | project Timestamp, Phase = "3-CloudApp",
            Detail = strcat(ActionType, " in ", Application),
            SourceIP = IPAddress),
    (DeviceProcessEvents
        | where Timestamp > ago(timeWindow)
        | where AccountName has targetUser
        | where InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
        | project Timestamp, Phase = "4-Endpoint",
            Detail = strcat(InitiatingProcessFileName, " → ", FileName),
            SourceIP = "device-local")
| order by Timestamp asc

When automated correlation is incomplete

XDR correlation groups alerts by shared entities. But it can miss:

• Time-delayed connections — the phishing email arrives Monday, the credential is cracked and used Thursday. XDR may not correlate events 4 days apart.
• Different entity representations — EmailEvents uses RecipientEmailAddress, IdentityLogonEvents uses AccountUpn. If the formats differ slightly, automatic correlation may miss the link.
• Cross-tenant activity — if the attacker uses the stolen credential to access a partner organization, that activity is in a different tenant.

In these cases, your manual KQL correlation fills the gap. The cross-product query above is your template — adapt the time window, the user, and the tables to the specific investigation.