In this module

1.8 Cross-Product Incident Correlation

10-14 hours · Module 1 · Free

Operational Objective

This subsection covers cross-product incident correlation — a core operational skill for security teams working in Microsoft 365 environments. Every concept is demonstrated through practical scenarios from the Northgate Engineering environment.

Deliverable: Working proficiency with the techniques and operational patterns covered in this subsection.

Estimated completion: 25 minutes

Cross-Product Incident Correlation

Introduction

Required role: Security Reader (minimum for portal navigation). Security Administrator for configuration changes.

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.

// Complete cross-product attack timeline for a single user
let targetUser = "j.morrison";
let targetEmail = "j.morrison@northgateeng.com";
let timeWindow = 48h;
union
    // Phase 1: Email delivery
    (EmailEvents
        | where Timestamp > ago(timeWindow)
        | where RecipientEmailAddress =~ targetEmail
        | where ThreatTypes has "Phish" or DeliveryAction == "Delivered"
        | project Timestamp, Phase = "1-Email",
            Detail = strcat("From: ", SenderFromAddress, " | Subject: ", Subject),
            SourceIP = SenderIPv4,
            Entity = RecipientEmailAddress),
    // Phase 2: URL click
    (UrlClickEvents
        | where Timestamp > ago(timeWindow)
        | where AccountUpn =~ targetEmail
        | project Timestamp, Phase = "2-Click",
            Detail = strcat("Clicked: ", Url, " | Verdict: ", ActionType),
            SourceIP = IPAddress,
            Entity = AccountUpn),
    // Phase 3: Authentication
    (IdentityLogonEvents
        | where Timestamp > ago(timeWindow)
        | where AccountUpn has targetUser
        | where ActionType == "LogonSuccess"
        | project Timestamp, Phase = "3-Auth",
            Detail = strcat(LogonType, " from ", IPAddress, " to ", Application),
            SourceIP = IPAddress,
            Entity = AccountUpn),
    // Phase 4: Endpoint activity
    (DeviceProcessEvents
        | where Timestamp > ago(timeWindow)
        | where AccountName has targetUser
        | where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe",
            "mshta.exe", "certutil.exe", "bitsadmin.exe")
        | project Timestamp, Phase = "4-Endpoint",
            Detail = strcat(FileName, " | ", ProcessCommandLine),
            SourceIP = "",
            Entity = DeviceName),
    // Phase 5: Cloud app activity
    (CloudAppEvents
        | where Timestamp > ago(timeWindow)
        | where AccountDisplayName has targetUser
            or AccountId has targetUser
        | where ActionType in ("New-InboxRule", "Set-Mailbox",
            "FileDownloaded", "Consent to application.",
            "Add delegated permission grant.")
        | project Timestamp, Phase = "5-CloudApp",
            Detail = strcat(ActionType, " in ", Application),
            SourceIP = IPAddress,
            Entity = AccountDisplayName)
| order by Timestamp asc

// Pivot on attacker IP: who else was compromised from the same infrastructure?
let attackerIP = "203.0.113.47";
let attackWindow = 7d;
IdentityLogonEvents
| where Timestamp > ago(attackWindow)
| where IPAddress == attackerIP
| where ActionType == "LogonSuccess"
| summarize FirstAccess = min(Timestamp),
    LastAccess = max(Timestamp),
    LogonCount = count(),
    Applications = make_set(Application)
    by AccountUpn
| order by FirstAccess asc

// Pivot on phishing sender domain: how many users received emails from this campaign?
let phishDomain = "contoso-hr.com";
let campaignWindow = 7d;
EmailEvents
| where Timestamp > ago(campaignWindow)
| where SenderFromDomain =~ phishDomain
| summarize EmailCount = count(),
    UniqueRecipients = dcount(RecipientEmailAddress),
    Recipients = make_set(RecipientEmailAddress, 20),
    DeliveredCount = countif(DeliveryAction == "Delivered"),
    BlockedCount = countif(DeliveryAction == "Blocked")
| project EmailCount, UniqueRecipients, DeliveredCount, BlockedCount, Recipients

Expand for Deeper Context

Defender XDR automatically correlates alerts into incidents. The correlation engine identifies connections based on shared entities — the same user appearing in an email alert and a sign-in alert, the same device appearing in an endpoint alert and a cloud app alert, the same IP address appearing across multiple alert types. This automated correlation is good, but it has limits. It misses connections when entities are not shared in obvious ways (an attacker using different accounts at different stages), and it cannot construct the narrative that explains how the attack progressed from initial access to objective completion.

This subsection teaches you to manually correlate across products when automated correlation misses connections, when you need to validate and extend what the automation found, and when you need to build a complete attack narrative for an incident report or CISO briefing. The key skill is using KQL unions and joins from Module 6 against the Advanced Hunting tables to construct a single timeline that spans email delivery, identity compromise, endpoint execution, and cloud application abuse.

By the end of this subsection you will be able to identify which Advanced Hunting tables correspond to which Defender products, write cross-product union queries that build a unified attack timeline, use entity-based pivoting to discover connections between seemingly unrelated alerts, and construct a complete attack chain narrative from email delivery through post-compromise activity.

---

The Advanced Hunting schema: which table comes from which product

Every Defender product feeds data into specific tables in the Advanced Hunting schema. Understanding which tables belong to which product is essential for cross-product correlation — you need to know where to look for each stage of an attack.

Defender for Endpoint populates the Device tables. DeviceProcessEvents records every process creation on onboarded devices (parent process, child process, command line, user account, timestamps). DeviceNetworkEvents records every network connection made by a process (destination IP, port, protocol, bytes transferred). DeviceFileEvents records file creation, modification, and deletion (file name, path, hash, size). DeviceRegistryEvents records registry key creation and modification (key path, value name, value data). DeviceLogonEvents records interactive and network logons to the device (logon type, account, source IP). DeviceImageLoadEvents records DLL loads (useful for detecting DLL injection and side-loading). These tables provide the deepest telemetry for any single device.

Defender for Office 365 populates the Email tables. EmailEvents records every email message processed by the email protection stack (sender, recipient, subject, delivery action, threat type, detection technology). EmailUrlInfo and EmailAttachmentInfo provide details about URLs and attachments in those emails (URL domain, click status, attachment file name, hash, malware family). UrlClickEvents records when a user clicks a URL in an email and the result of Safe Links evaluation (blocked, allowed, pending).

Defender for Identity and Entra ID Protection populate the Identity tables. IdentityLogonEvents records authentication events from both Active Directory (via the Defender for Identity sensor) and Entra ID (logon success, failure, source IP, device, logon type, application). IdentityQueryEvents records LDAP and other directory queries (query type, query target, source account). IdentityDirectoryEvents records changes to directory objects (group membership changes, account creation, password resets).

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

Alert and incident data lives in AlertInfo (alert metadata: title, severity, category, detection source), AlertEvidence (entities associated with each alert: devices, users, files, IPs, mailboxes), and DeviceEvents (a catch-all table for device events that do not fit into the more specific Device tables, including tamper protection events, ASR audit events, and Defender for Endpoint response actions).

Figure 1.8: The Advanced Hunting cross-product table map. Each Defender product populates specific tables. The user entity connects all products. Cross-product queries use union to combine events from different tables into a single timeline.

---

The entity pivot: connecting products through shared entities

The fundamental technique for cross-product correlation is the entity pivot. An entity is a discrete object that appears across multiple products: a user account, a device, an IP address, a file hash, or a domain name. When the same entity appears in alerts or events from different products, those events are related — even if the automated correlation engine did not connect them.

The user entity is the strongest connector. In a phishing attack, the same user appears as the email recipient (EmailEvents.RecipientEmailAddress), the authentication subject (IdentityLogonEvents.AccountUpn), the device owner (DeviceProcessEvents.AccountName), and the cloud app actor (CloudAppEvents.AccountDisplayName). By querying all four tables for the same user within the same time window, you reconstruct the complete attack chain.

The IP address entity connects external attacker infrastructure across products. If a phishing email was sent from IP 203.0.113.47 (EmailEvents.SenderIPv4), and the stolen credentials were used to sign in from the same IP (IdentityLogonEvents.IPAddress), and the attacker's cloud app activity originated from the same IP (CloudAppEvents.IPAddress), the IP entity proves that the same attacker performed all three actions.

The device entity connects endpoint activity to identity and cloud activity. If malware executed on DESKTOP-NGE042 (DeviceProcessEvents.DeviceName), and the compromised user last authenticated from DESKTOP-NGE042 (IdentityLogonEvents.DeviceName), the device entity confirms that the endpoint compromise and the identity compromise are part of the same incident.

The file hash entity connects email delivery to endpoint execution. If a malicious attachment was delivered via email (EmailAttachmentInfo.SHA256), and the same hash appears in a process creation event on a device (DeviceFileEvents.SHA256), you have confirmed that the user opened the malicious attachment and it executed.

---

Building a cross-product attack timeline

The most powerful cross-product query pattern is the unified timeline: a single KQL query that combines events from all relevant tables into one chronological view, filtered to a specific user and time window. This is the query you build during an investigation to see the complete attack story.

Expected Output — Unified Cross-Product Attack Timeline

Timestamp	Phase	Detail	SourceIP
Mar 17 09:14	1-Email	From: hr-updates@contoso-hr.com \| Subject: Q1 Bonus Notification	198.51.100.22
Mar 17 09:18	2-Click	Clicked: https://contoso-hr.com/bonus-review \| Verdict: Allowed	10.0.1.42
Mar 17 09:19	3-Auth	Interactive from 203.0.113.47 to Microsoft 365	203.0.113.47
Mar 17 09:22	5-CloudApp	New-InboxRule in Microsoft Exchange Online	203.0.113.47
Mar 17 09:25	5-CloudApp	FileDownloaded in Microsoft SharePoint Online	203.0.113.47
Mar 17 09:26	5-CloudApp	FileDownloaded in Microsoft SharePoint Online	203.0.113.47
Mar 17 09:30	5-CloudApp	Set-Mailbox in Microsoft Exchange Online	203.0.113.47

Complete attack narrative: Phishing email delivered at 09:14. User clicked the URL at 09:18 (4 minutes — fast response, consistent with a convincing lure). Attacker authenticated from a different IP (203.0.113.47 — not the user's normal IP) at 09:19 — this is the AiTM session cookie replay. Within 11 minutes, the attacker created an inbox forwarding rule, downloaded files from SharePoint, and modified mailbox settings. The IP pivot confirms that all post-compromise activity came from the same attacker infrastructure. This is the exact pattern detailed in Module 12 (AiTM Investigation).

---

Entity-based pivoting: expanding the investigation

Once you have established the attack chain for one user, the next question is: did the attacker target other users? Entity-based pivoting uses the attacker's infrastructure identifiers (IP address, sending domain, phishing URL domain, file hash) to search for additional victims across the entire tenant.

Expected Output — All Accounts Accessed from Attacker IP

AccountUpn	FirstAccess	LastAccess	LogonCount	Applications
j.morrison@northgateeng.com	Mar 17 09:19	Mar 17 11:42	14	["Microsoft 365","Microsoft Teams"]
a.chen@northgateeng.com	Mar 17 10:05	Mar 17 10:38	6	["Microsoft 365"]
r.williams@northgateeng.com	Mar 17 11:15	Mar 17 12:02	9	["Microsoft 365","SharePoint Online"]

Multi-victim campaign: The attacker IP accessed three accounts over three hours. The first account (j.morrison) was the initial victim from the phishing email. The second and third accounts were likely compromised through internal phishing — the attacker used j.morrison's mailbox to send phishing emails to colleagues. Each account now needs full investigation: check for inbox rules, file access, OAuth consent grants, and further internal phishing from each compromised account.

Expected Output — Campaign Scope from Sender Domain Pivot

EmailCount	UniqueRecipients	DeliveredCount	BlockedCount	Recipients (sample)
47	31	8	39	["j.morrison@...","a.chen@...","r.williams@...",...]

Campaign analysis: 47 emails sent to 31 unique recipients. Defender for Office 365 blocked 39 but delivered 8. Those 8 delivered emails are your blast radius — each recipient needs checking: did they click the URL (UrlClickEvents)? Did their account show a successful authentication from the attacker IP (IdentityLogonEvents)? You already know 3 accounts were compromised. The remaining 5 may also be compromised but have not yet been detected.

---

Correlation patterns for common attack types

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

Phishing → credential theft → BEC. This is the most common cross-product attack pattern. The chain runs: EmailEvents (delivery) → UrlClickEvents (click) → IdentityLogonEvents (attacker sign-in from new IP) → 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 → malware delivery → endpoint compromise. The chain runs: EmailEvents (delivery) → EmailAttachmentInfo (malicious attachment hash) → DeviceFileEvents (file written to disk with same hash) → DeviceProcessEvents (file executed) → DeviceNetworkEvents (C2 connection). The connecting entity is the file hash (email attachment hash matches the executed file hash) and the user (email recipient matches the device owner).

Credential theft → lateral movement → data exfiltration. The chain runs: DeviceProcessEvents (credential theft tool execution — Mimikatz, Rubeus) → IdentityLogonEvents (compromised credentials used on additional devices) → DeviceLogonEvents (attacker logging on to new devices) → CloudAppEvents (data download from SharePoint/OneDrive). The connecting entity is the user account and the attacker IP (which appears across identity and cloud app events).

Insider threat → data exfiltration. This pattern involves a single user and does not typically include email delivery or endpoint malware. The chain runs: CloudAppEvents (anomalous file download volume from SharePoint/OneDrive) → possibly DeviceFileEvents (files copied to USB or personal cloud storage) → 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 indicators.

---

When automated correlation fails

Automated correlation in Defender XDR works by matching entities across alerts. It fails in specific scenarios that you should watch for:

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 automated correlation may create two separate incidents instead of linking them. You connect them manually by finding the device or IP that appears in both incident timelines.

Time gaps between stages. Automated correlation has a time window for connecting alerts. If the attacker pauses for several days between initial access and post-compromise activity (a common pattern in sophisticated attacks), alerts from the two stages may land in separate incidents. Run periodic searches for dormant compromises: accounts that showed suspicious sign-in patterns days or weeks ago but only recently showed post-compromise activity.

Third-party data sources. Alerts from third-party security products integrated via Sentinel do not participate in Defender XDR's native correlation engine. If your firewall alerts, EDR alerts from non-Microsoft endpoints, or CASB alerts from a third-party product contain related entities, you must correlate them manually using Sentinel's cross-workspace queries or by exporting and comparing entity lists.

Multi-tenant attacks. If your organization manages multiple M365 tenants (common for MSPs and large enterprises with subsidiary tenants), an attack that moves between tenants will not be automatically correlated because each tenant has its own incident queue. Cross-tenant correlation requires manual comparison or a centralized Sentinel workspace that ingests data from all tenants.

---

Building the investigation narrative

The purpose of cross-product correlation is not just to generate a timeline — it is to construct a narrative that explains the attack from the attacker's perspective: what they did, why they did it, 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 or incident commander.

A well-constructed narrative follows this structure:

Initial access. How did the attacker get in? Which product detected the entry point? What technique did they use (phishing, credential stuffing, exploiting a vulnerability)?

Execution and persistence. What did the attacker do immediately after gaining access? Did they execute malware on an endpoint? Did they establish persistence (inbox rules, OAuth apps, scheduled tasks, registry modifications)?

Discovery and lateral movement. Did the attacker move beyond the initial compromise? How many accounts and devices were affected? What technique did they use to move (pass-the-hash, internal phishing, token replay)?

Objective. What was the attacker's goal? Data exfiltration (file downloads, email forwarding)? Financial fraud (BEC, payment redirection)? Ransomware deployment? Espionage?

Containment and gaps. What containment actions were taken and when? Were there gaps in your detection that allowed the attacker to operate undetected for a period? What would you detect differently next time?

Try it yourself

In Advanced Hunting on your developer tenant, run the data pipeline health check query from subsection 1.7 to see which tables have data. Then try a simplified cross-product union query: combine EmailEvents and IdentityLogonEvents for a specific user (use a sample user from your developer tenant) and sort by timestamp. Even with limited data in a developer tenant, this exercise builds familiarity with the union syntax and the different field names across tables. If EmailEvents is empty, check whether Defender for Office 365 is configured in your developer tenant.

What you should observe

The cross-product union query returns events from different tables in a single chronological view. You will notice that field names differ between tables — EmailEvents uses RecipientEmailAddress while IdentityLogonEvents uses AccountUpn. The project operator in each union leg normalizes these different field names into consistent columns, which is essential for readability. In a real investigation, this query pattern is the foundation for every cross-product analysis you will perform.

Knowledge check

Compliance mapping

NIST CSF: DE.AE-1 (Baseline of operations established), PR.DS-1 (Data-at-rest is protected). ISO 27001: A.8.15 (Logging), A.8.16 (Monitoring activities). SOC 2: CC7.2 (Monitor system components). Every configuration in this subsection contributes to the logging and monitoring controls that auditors verify.

Compliance Myth: "Default security settings are sufficient"

The myth: Default security settings are sufficient

The reality: Microsoft's security defaults provide a baseline — MFA for admins, blocking legacy authentication. But defaults do not configure: conditional access policies tailored to your risk profile, Defender for Office 365 anti-phishing policies for your specific impersonation targets, custom detection rules for your environment, or data loss prevention policies for your sensitive data. Defaults prevent the easiest attacks. Custom configuration prevents the attacks targeting YOUR organization.

Check your understanding

1. You are investigating a phishing incident. EmailEvents shows the phishing email was delivered to j.morrison@northgateeng.com. IdentityLogonEvents shows a successful sign-in for j.morrison from IP 203.0.113.47 four minutes after the email delivery. CloudAppEvents shows a New-InboxRule action from the same IP two minutes after the sign-in. What entity connects these three events across three different products?

Two entities connect them: the user (j.morrison appears as the email recipient, the sign-in subject, and the inbox rule creator) and the IP address (203.0.113.47 appears in both the sign-in event and the cloud app event, confirming the same attacker performed both actions). The user entity connects the email to the sign-in. The IP entity confirms the sign-in and the cloud app activity are from the same source.

Only the IP address connects them — the user name is different in each table.

The incident ID connects them automatically — no manual correlation is needed.

Cross-product correlation relies on entity pivoting. The user entity is the primary connector (the email recipient is the same person whose credentials were stolen and whose mailbox was manipulated). The IP entity provides the attacker attribution — it confirms that the post-compromise activity was performed by an external actor, not by the legitimate user. Both entities are needed: the user connects the products, and the IP proves the malicious intent.

2. You discover that the attacker IP (203.0.113.47) was used to access three different user accounts over three hours. The first account received a phishing email, but the other two did not. How were the second and third accounts likely compromised?

The attacker likely used the first compromised account to send internal phishing emails to the second and third users. Check EmailEvents for emails sent FROM the first compromised user's address TO the other two users during the attack window. Internal phishing is harder to detect because it comes from a trusted sender within the organization.

The attacker guessed their passwords through brute force — check for failed login attempts.

All three users clicked the same external phishing link — the emails were just not detected.

Internal phishing (using a compromised mailbox to send phishing to internal colleagues) is a hallmark of AiTM and BEC campaigns. The attacker compromises one account, then uses that trusted internal identity to phish additional victims. Defender for Office 365 is less likely to block internal phishing because the sender is a legitimate internal user. This is why post-compromise containment — revoking the first victim's sessions and disabling their account — is time-critical: every minute the attacker has access to the first mailbox is a minute they can use to expand the campaign.

3. You have two separate incidents in the queue. Incident A contains an endpoint alert (Mimikatz execution on DESKTOP-NGE042). Incident B, created three days later, contains a cloud app alert (anomalous file downloads from SharePoint by admin.t.clark). The incidents are not automatically correlated. How do you determine whether they are related?

Check whether admin.t.clark has any association with DESKTOP-NGE042. Query IdentityLogonEvents and DeviceLogonEvents for admin.t.clark logons to DESKTOP-NGE042 in the time window between the two incidents. If admin.t.clark logged on to DESKTOP-NGE042 (or if Mimikatz on that device extracted admin.t.clark's credentials from cached logon data), the Mimikatz execution is the credential theft stage and the SharePoint download is the data exfiltration stage of a single multi-day attack.

They are clearly unrelated — three days apart and different products, so treat them separately.

Merge the incidents in the portal and let the AI re-analyze them together.

Time gaps between attack stages are one of the main reasons automated correlation fails. Sophisticated attackers deliberately pause between credential theft and data exfiltration to avoid triggering time-based correlation logic. The entity pivot — checking whether the admin account was associated with the compromised device — is how you connect incidents that the automation missed. If Mimikatz extracted cached credentials from DESKTOP-NGE042, and admin.t.clark had previously logged on to that device, the two incidents are almost certainly part of the same attack chain.

4. Which Advanced Hunting table would you query to find inbox rules created by an attacker after compromising a user account?

CloudAppEvents — inbox rule creation is a cloud application action that occurs within Exchange Online. Filter by ActionType == "New-InboxRule" and check for rules that forward, redirect, or delete messages.

EmailEvents — because inbox rules affect email delivery.

DeviceProcessEvents — because the rule was created through a browser on the user's device.

CloudAppEvents records actions performed within connected cloud applications. Inbox rule creation is an Exchange Online administrative action, not an email delivery event (EmailEvents) or a device process event (DeviceProcessEvents). Even though the user may have accessed Exchange Online through a browser on their device, the rule creation is a server-side action captured by the Defender for Cloud Apps connector, not by the endpoint sensor.

Interactive lab: triage cross-product Defender XDR alerts

Six alerts from across the Defender product suite — Endpoint, Office 365, Identity, and Cloud Apps. Each alert comes from a different product with different telemetry. Classify each and identify which alerts are part of the same attack chain.

Decision point

You manage NE's M365 security stack. Microsoft releases a new Defender feature in preview. The feature promises to reduce AiTM risk by 80%. Do you enable it immediately?

Not in production. Enable in a test tenant or for a pilot group first. Preview features may: change behavior before GA, have undocumented interactions with existing CA policies, or produce unexpected results in specific tenant configurations. The deployment sequence: (1) enable in a test tenant and validate against NE's CA policy set, (2) enable for a pilot group of 10 users for 2 weeks, (3) monitor for FPs and operational impact, (4) roll out to all users after successful pilot. Microsoft's '80% reduction' claim is based on their telemetry across all tenants — NE's specific configuration may produce different results.

You've set up your M365 tenant and learned the Defender XDR unified portal.

Module 0 got your M365 developer tenant configured with sample data. Module 1 took you through the Defender XDR unified incident queue across endpoint, email, identity, and cloud apps. Now you investigate every major M365 attack type and deploy the detections that catch them next time.

15 investigation and configuration modules — Defender for Endpoint, Purview, Defender for Cloud, Security Copilot, Sentinel workspace design, log ingestion, analytics rules, and threat hunting
5 named attack investigations — AiTM credential phishing, BEC and financial fraud, consent phishing and OAuth grant abuse, token replay and session hijacking, insider threat
KQL from fundamentals through advanced hunting — dedicated modules on query language, cross-table joins, statistical analysis, and threat hunting queries
SC-200 exam objectives fully covered — every module maps to the January 2026 SC-200 update. The certification is the side effect of operational competence, not the goal
Production artefacts per module — detection rules, investigation playbooks, and hardening checklists you deploy to your own tenant

Unlock the full course with Premium See Full Syllabus

← Previous Next →