Cross-Product Incident Correlation

The Advanced Hunting schema: which table comes from which product

Every Defender product feeds data into specific tables in the Advanced Hunting schema. Cross-product correlation starts with knowing where to look for each stage of an attack.

Figure 1.12: Each Defender product populates specific Advanced Hunting tables. The user entity connects all products. Cross-product queries use union to combine events from different tables into a single chronological view.

Defender for Endpoint populates the Device tables. DeviceProcessEvents records every process creation on onboarded devices (parent process, child process, command line, user account). DeviceNetworkEvents records network connections (destination IP, port, bytes transferred). DeviceFileEvents records file creation, modification, and deletion. DeviceLogonEvents records interactive and network logons. These tables provide the deepest per-device telemetry in the schema.

Defender for Office 365 populates the Email tables. EmailEvents records every email processed by the protection stack (sender, recipient, delivery action, threat type). EmailUrlInfo and EmailAttachmentInfo provide URL and attachment details. UrlClickEvents records Safe Links evaluations when users click URLs. These tables are where phishing campaigns begin.

Defender for Identity and Entra ID populate the Identity tables. IdentityLogonEvents records authentication events from both Active Directory (via the MDI sensor) and Entra ID. IdentityQueryEvents records LDAP queries (reconnaissance activity). IdentityDirectoryEvents records directory changes (group membership, password resets). AADSignInEventsBeta provides rich sign-in data including conditional access evaluation results.

Defender for Cloud Apps populates CloudAppEvents, which records user actions within connected cloud applications: inbox rule creation, file downloads, OAuth consent grants, admin configuration changes. This table captures post-compromise activity in Exchange Online, SharePoint, and connected third-party apps.

Alert and incident data lives in AlertInfo (alert metadata), AlertEvidence (entities associated with alerts), and DeviceEvents (catch-all for events that do not fit the specific Device tables, including ASR audit events and response actions).

The entity pivot: connecting products through shared entities

The fundamental technique for cross-product correlation is the entity pivot. When the same entity appears in events from different products, those events are related. The entity types, in order of reliability as connectors:

User. The strongest connector. In the scenario incident, j.morrison appears as the email recipient (EmailEvents.RecipientEmailAddress), the authentication subject (IdentityLogonEvents.AccountUpn), and the cloud app actor (CloudAppEvents.AccountDisplayName). By querying all three tables for the same user within the attack window, you reconstruct the chain from delivery to compromise to post-compromise activity.

IP address. The attacker attribution pivot. The attacker's IP (203.0.113.47) appears in IdentityLogonEvents and CloudAppEvents but not in EmailEvents (which records the sender infrastructure, not the clicker's IP). When you find the same IP accessing multiple user accounts, you have identified either a single attacker with multiple stolen credentials or a shared VPN exit node. Check the IP's geolocation and hosting provider to distinguish.

Device. Connects endpoint activity to identity events. If Mimikatz executes on DESKTOP-NGE042 (DeviceProcessEvents), and admin.t.clark's cached credentials were on that device (DeviceLogonEvents), the credential theft and the subsequent admin.t.clark sign-in from an unusual IP are part of the same chain.

File hash. Connects email delivery to endpoint execution. The attachment hash in EmailAttachmentInfo should match the file hash in DeviceFileEvents when a user opens a malicious attachment. If the hashes match, you have confirmed the delivery-to-execution link.

// Cross-product timeline for a single user across all Defender products
let targetUser = "j.morrison@northgateeng.com";
let attackWindow = 7d;
union
    (EmailEvents
     | where Timestamp > ago(attackWindow)
     | where RecipientEmailAddress =~ targetUser
     | project Timestamp, Source = "Email",
       Detail = strcat(SenderFromAddress, " → ", Subject),
       Action = DeliveryAction),
    (IdentityLogonEvents
     | where Timestamp > ago(attackWindow)
     | where AccountUpn =~ targetUser
     | project Timestamp, Source = "Identity",
       Detail = strcat(Application, " from ", IPAddress),
       Action = ActionType),
    (CloudAppEvents
     | where Timestamp > ago(attackWindow)
     | where AccountDisplayName =~ "Jordan Morrison"
     | project Timestamp, Source = "CloudApp",
       Detail = strcat(Application, ": ", ActionType),
       Action = ActionType)
| order by Timestamp asc

This query produces a unified chronological timeline from three different Defender products. Each union leg projects its product-specific fields into consistent columns (Timestamp, Source, Detail, Action), so the results read as a single narrative. In the scenario incident, the timeline would show the phishing email delivery (Monday 09:15), the attacker sign-in from 203.0.113.47 (Monday 09:19), the inbox rule creation (Monday 09:21), and the SharePoint downloads (Wednesday 14:30-15:45). The 48-hour gap between Monday and Wednesday is visible in the timeline, confirming that the two incidents in the queue are a single multi-day attack.

Notice the field name differences: EmailEvents uses RecipientEmailAddress, IdentityLogonEvents uses AccountUpn, and CloudAppEvents uses AccountDisplayName. The project operator in each union leg normalizes these into consistent output columns. This normalization is not optional. Without it, the union produces columns from all three tables with nulls everywhere, and the timeline is unreadable.

Correlation patterns for common attack types

Different attack types leave signatures across different product combinations. Knowing which tables to query for each pattern saves investigation time.

Phishing to credential theft to BEC. The most common cross-product pattern. EmailEvents (delivery) to UrlClickEvents (click) to IdentityLogonEvents (attacker sign-in from new IP within minutes of click) to CloudAppEvents (inbox rules, file access, internal phishing). The connecting entity is the user. The distinguishing indicator is a sign-in from an IP that does not match the user's historical pattern, occurring within minutes of a URL click.

Phishing to malware delivery to endpoint compromise. EmailEvents (delivery) to EmailAttachmentInfo (malicious attachment hash) to DeviceFileEvents (file written to disk with matching hash) to DeviceProcessEvents (file executed) to DeviceNetworkEvents (C2 connection). The connecting entities are the file hash (attachment hash matches executed file hash) and the user (email recipient matches device owner).

Credential theft to lateral movement to exfiltration. DeviceProcessEvents (credential theft tool execution) to IdentityLogonEvents (stolen credentials used on additional devices) to DeviceLogonEvents (attacker logging on to new devices) to CloudAppEvents (data download from SharePoint or OneDrive). The connecting entities are the user account and the attacker IP, which appears across identity and cloud app events.

Insider threat to data exfiltration. A single-user pattern without external attacker indicators. CloudAppEvents (anomalous file download volume) to DeviceFileEvents (files copied to USB or personal cloud storage) to IdentityLogonEvents (access from unusual times or locations). The connecting entity is the user. The distinguishing indicator is behavior deviation from the user's historical baseline rather than external attacker infrastructure.

The cross-product query from the scenario produces a timeline. Here is what the reconstructed attack sequence looks like when you assemble the results into a structured document for the incident report.

The environment labels (Email, Identity, Cloud) in the timeline correspond directly to the Defender products and Advanced Hunting tables that recorded each event. This mapping is what makes cross-product correlation actionable: you know which table to query for evidence at each stage. The 48-hour gap between Monday and Wednesday is visible as a distinct period of inactivity that the correlation engine could not bridge.

When automated correlation fails

Defender XDR's correlation engine connects alerts based on shared entities within a time window. It fails in specific, predictable scenarios.

Different accounts at different stages. If the attacker uses one account for initial access and a different account obtained through credential theft for lateral movement, the engine may create two separate incidents. You connect them by finding the device or IP that appears in both timelines. In the scenario, querying IdentityLogonEvents for the attacker IP (203.0.113.47) across all accounts reveals three compromised users that the engine may have split across multiple incidents.

Time gaps between stages. The correlation engine has a time window for connecting alerts. Sophisticated attackers deliberately pause between initial access and post-compromise activity. The scenario shows exactly this pattern: credential theft on Monday, data exfiltration on Wednesday. Run periodic hunting queries for dormant compromises: accounts that showed suspicious sign-in patterns days ago but only recently exhibited post-compromise activity.

Third-party data sources. Alerts from third-party products integrated via Microsoft Sentinel do not participate in Defender XDR's native correlation. Firewall alerts, non-Microsoft EDR alerts, and third-party CASB alerts sit in Sentinel's incident queue but are not correlated with XDR incidents. If the Northgate firewall logged outbound connections from 203.0.113.47 to an internal IP, that evidence exists in Sentinel but does not appear in the XDR incident. You correlate manually using Sentinel's cross-workspace queries.

Multi-tenant environments. Organizations managing multiple M365 tenants (MSPs, enterprises with subsidiary tenants) will not see cross-tenant correlation. An attack that moves between tenants produces separate incidents in each tenant's queue. Cross-tenant correlation requires a centralized Sentinel workspace ingesting data from all tenants or manual entity comparison.

Building the investigation narrative

The purpose of cross-product correlation is to construct a narrative that explains the attack from the attacker's perspective: what they did, how they moved between products, what they achieved, and what they failed to achieve. This narrative is what goes into your incident report and what you present to the CISO.

A complete narrative covers five stages. Initial access: how the attacker got in and which product detected the entry point. Execution and persistence: what the attacker did immediately after gaining access (malware execution, inbox rules, OAuth consent grants). Discovery and lateral movement: whether the attacker moved beyond the initial compromise, how many accounts and devices were affected, and what technique they used. Objective: what the attacker was trying to achieve (data exfiltration, financial fraud, ransomware deployment). Containment and gaps: what containment actions were taken, when, and whether detection gaps allowed the attacker to operate undetected for a period.

For the scenario incident, the narrative reads: attacker sent credential phishing emails to 19 Northgate Finance users on Monday (EmailEvents). Three users clicked (UrlClickEvents). The attacker signed into j.morrison's account from IP 203.0.113.47 four minutes after the click (IdentityLogonEvents). Within two minutes, the attacker created an inbox rule forwarding emails containing "invoice" and "payment" to an external address (CloudAppEvents). The attacker returned Wednesday and downloaded 47 files from the Q3 Financials SharePoint library (CloudAppEvents). Two other accounts (a.chen, r.williams) also showed sign-ins from the same IP during the Monday window, suggesting the attacker used j.morrison's compromised mailbox to send internal phishing.

That narrative connects two portal incidents, four Defender products, and five days of attacker activity into a single story. Without cross-product correlation, the Monday phishing incident and the Wednesday exfiltration incident would be investigated separately, and the connection between them would depend on an analyst recognizing the shared IP address across two different incident pages.