3.9 Cross-Product Investigation: Purview + Defender XDR + Sentinel

Cross-Product Investigation: Purview + Defender XDR + Sentinel

Introduction

Every previous subsection in this module taught a specific Purview investigation skill in isolation — DLP alert investigation, insider risk case management, audit log search, eDiscovery content search. In practice, these skills combine. A real security investigation does not live in a single product or a single log. It traces the attack across email delivery (Defender for Office 365), credential compromise (Entra ID sign-in logs), post-compromise activity (Purview audit log), data exposure (DLP alerts), and evidence collection (eDiscovery).

This subsection demonstrates the complete cross-product investigation through a worked BEC scenario. You will build the investigation timeline that connects signals from five different data sources into a single narrative. This is the capstone skill of Module 3 — and the investigation methodology you will use in Modules 11-15.

The scenario: Business Email Compromise via AiTM

The SOC receives three correlated alerts in the Defender XDR incident queue:

Alert 1 (Defender for Office 365): “Phishing email delivered” — an email from hr-portal@contoso-updates.com to j.morrison@northgateeng.com containing a link to a credential harvesting page.

Alert 2 (Entra ID Protection): “Anomalous sign-in” — j.morrison signed in from IP 203.0.113.47 (Russia) 8 minutes after the phishing email was delivered. MFA was completed (the AiTM proxy relayed the MFA token).

Alert 3 (DLP): “Credit card numbers detected in outbound email” — j.morrison sent an email with 15 credit card numbers to an external Gmail address 45 minutes after the anomalous sign-in.

These three alerts are correlated into a single incident. Your investigation must determine: what happened, how much data was exposed, and what response actions are needed.

Phase 1: Email delivery analysis (Defender for Office 365)

Start with the phishing email. This is the initial access vector — everything else follows from it.

1
2
3
4
5
6
7
8

// Find the phishing email and its delivery details
EmailEvents
| where Timestamp > ago(48h)
| where RecipientEmailAddress =~ "j.morrison@northgateeng.com"
| where SenderFromAddress has "contoso-updates.com"
| project Timestamp, SenderFromAddress, Subject, DeliveryAction,
    DeliveryLocation, ThreatTypes, AuthenticationDetails
| order by Timestamp desc

The result shows the email was delivered to the inbox (DeliveryAction = “Delivered”). Check why it was not blocked: examine the authentication details (did SPF/DKIM/DMARC pass for the attacker’s domain?), check the ThreatTypes (was it classified as phishing at delivery time?), and check whether the user clicked the link.

1
2
3
4
5
6

// Did the user click the link?
UrlClickEvents
| where Timestamp > ago(48h)
| where AccountUpn =~ "j.morrison@northgateeng.com"
| where Url has "contoso-updates"
| project Timestamp, Url, ActionType, IsClickedThrough, IPAddress

If IsClickedThrough is true, the user clicked the link and visited the credential harvesting page. The timestamp of the click establishes the start of the credential theft.

Phase 2: Credential compromise analysis (Entra ID)

The phishing email delivered a credential harvesting page. Now trace the authentication.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Sign-in analysis for the compromised account
SigninLogs
| where TimeGenerated > ago(48h)
| where UserPrincipalName =~ "j.morrison@northgateeng.com"
| where ResultType == "0"
| extend Country = tostring(LocationDetails.countryOrRegion)
| extend City = tostring(LocationDetails.city)
| project TimeGenerated, IPAddress, Country, City, AppDisplayName,
    AuthenticationRequirement, ConditionalAccessStatus,
    RiskLevelDuringSignIn = tostring(RiskLevelDuringSignIn)
| order by TimeGenerated asc

The sign-in from 203.0.113.47 at 09:22 — 8 minutes after the phishing email click — confirms the AiTM proxy captured credentials and the MFA token, then replayed them immediately.

Phase 3: Post-compromise audit analysis (Purview)

Now trace what the attacker did with the compromised access. This is where Purview audit data becomes essential.

 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
34
35
36
37
38
39
40
41
42
43
44
45
46

// Complete post-compromise activity from attacker IP
let attackerIP = "203.0.113.47";
let startTime = datetime(2026-03-18 09:20);
let endTime = datetime(2026-03-18 11:30);
union
    // Mailbox access
    (CloudAppEvents
        | where Timestamp between (startTime .. endTime)
        | where AccountId =~ "j.morrison@northgateeng.com"
        | where IPAddress == attackerIP
        | where ActionType in ("MailItemsAccessed", "New-InboxRule",
            "Set-InboxRule", "Send", "SearchQueryInitiatedExchange")
        | extend Detail = case(
            ActionType == "MailItemsAccessed",
                strcat("Read emails: ", tostring(RawEventData.AffectedItems)),
            ActionType has "InboxRule",
                strcat("Rule: ", tostring(RawEventData.Parameters)),
            ActionType == "Send",
                strcat("Sent to: ", tostring(RawEventData.To)),
            ActionType has "SearchQuery",
                strcat("Searched: ", tostring(RawEventData.SearchQuery)),
            ActionType)
        | project TimeGenerated = Timestamp, Phase = "Mailbox",
            Action = ActionType, Detail, SourceIP = IPAddress),
    // File access
    (OfficeActivity
        | where TimeGenerated between (startTime .. endTime)
        | where UserId =~ "j.morrison@northgateeng.com"
        | where ClientIP == attackerIP
        | where Operation in ("FileDownloaded", "FileAccessed", "FileCopied")
        | project TimeGenerated, Phase = "Files",
            Action = Operation,
            Detail = strcat(OfficeObjectId, " from ", Site_Url),
            SourceIP = ClientIP),
    // DLP alerts
    (CloudAppEvents
        | where Timestamp between (startTime .. endTime)
        | where AccountId =~ "j.morrison@northgateeng.com"
        | where ActionType has "DlpRule"
        | project TimeGenerated = Timestamp, Phase = "DLP",
            Action = "DLP Alert",
            Detail = strcat(tostring(RawEventData.PolicyName), " | ",
                tostring(RawEventData.SensitiveInfoTypeName), " x",
                tostring(RawEventData.SensitiveInfoTypeCount)),
            SourceIP = IPAddress)
| order by TimeGenerated asc

Phase 4: Data exposure assessment (DLP + eDiscovery)

The timeline reveals three data exposure vectors that require assessment:

Vector 1: Email forwarding rule. The attacker created a forwarding rule at 09:35 that sent all of j.morrison’s incoming email to attacker@proton.me. Every email received by j.morrison between 09:35 and when the rule was removed was forwarded to the attacker. Use the audit log to determine when the rule was removed, then scope the exposure: how many emails were forwarded during that window?

Vector 2: File downloads. The attacker downloaded Q4-Financial-Forecast.xlsx and Customer-Database-Export.csv. Use eDiscovery to examine these files: does the financial forecast contain material non-public information? Does the customer database contain PII? The answers determine the regulatory notification requirements.

Vector 3: DLP alert — credit card data. The DLP alert shows 15 credit card numbers sent to an external Gmail address with audit-only action (delivered, not blocked). This is confirmed personal data exposure requiring GDPR/UK GDPR breach notification assessment. The clock starts now — 72 hours to notify the supervisory authority.

1
2
3
4
5
6
7

// Scope the forwarding rule exposure
CloudAppEvents
| where Timestamp between (datetime(2026-03-18 09:35) .. datetime(2026-03-18 11:30))
| where AccountId =~ "j.morrison@northgateeng.com"
| where ActionType == "MailItemsAccessed"
| where tostring(RawEventData.OperationProperties[0].Value) == "Sync"
| summarize ForwardedEmails = count()

Phase 5: Remediation and documentation

Based on the cross-product investigation, the remediation actions are:

Immediate containment (already done at 11:30): password reset, all sessions revoked, account contained.

Inbox rule removal: delete the forwarding rule to attacker@proton.me. Verify no other rules were created.

DLP policy upgrade: the credit card DLP policy was audit-only. Recommend upgrading to block mode for external email to prevent future data exposure.

Finance team notification: the attacker sent a fraudulent invoice redirect email to finance@northgateeng.com at 10:15. Notify the finance team immediately to verify all pending wire transfers and hold any new payment requests that reference the fraudulent email.

Data breach notification assessment: 15 credit card numbers were sent to an external address. Customer-Database-Export.csv likely contains personal data. Begin GDPR Article 33 notification process with the DPO.

Evidence preservation: create an eDiscovery case, place j.morrison’s mailbox on legal hold, export the phishing email, the forwarded emails, the DLP alert evidence, and the attacker’s outbound emails as evidence artifacts.

Incident report: the investigation timeline (the table above) is the core of the report. It tells the complete story from initial phishing to containment with evidence from five data sources.

Detecting secondary compromise: did the attacker phish others?

Cross-product investigation does not end with the primary victim. The attacker used j.morrison’s compromised account to send a fraudulent invoice email to finance@northgateeng.com at 10:15. Did they also send phishing emails to other users from the compromised account? If so, those users may also be compromised — creating a secondary wave that extends the incident scope.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Check for secondary phishing from the compromised account
EmailEvents
| where Timestamp between (datetime(2026-03-18 09:22) .. datetime(2026-03-18 11:30))
| where SenderFromAddress =~ "j.morrison@northgateeng.com"
| where DeliveryAction == "Delivered"
| extend IsExternal = (RecipientEmailAddress !has "northgateeng.com")
| extend HasUrl = (UrlCount > 0)
| extend HasAttachment = (AttachmentCount > 0)
| project Timestamp, RecipientEmailAddress, Subject, IsExternal,
    HasUrl, HasAttachment, ThreatTypes
| order by Timestamp asc

This secondary compromise detection is the step that distinguishes a thorough investigation from an incomplete one. Many analysts investigate and remediate the primary victim without checking whether the attacker used the compromised account to attack others. In Module 11 (AiTM Investigation), you will see this pattern in a real multi-wave campaign where each compromised account was used to phish additional victims.

Structuring the incident report from cross-product evidence

The cross-product investigation timeline directly maps to the incident report structure from Module 14. Each phase of the investigation becomes a section of the report.

Executive summary (2-3 sentences): “On 18 March 2026, a targeted AiTM phishing attack compromised the account of j.morrison. The attacker accessed 52 emails, downloaded sensitive financial documents, exfiltrated 15 credit card numbers to an external address, and attempted financial fraud via a fake invoice redirect. The account was contained within 2 hours 8 minutes of initial compromise.”

Attack timeline (the complete table from this subsection): every event, in order, with evidence source and IP address. This is the technical core of the report.

Data exposure assessment (from Phase 4): 15 credit card numbers confirmed exposed (DLP evidence). Customer database downloaded (content assessment via eDiscovery pending). 23 emails forwarded to external address (audit log evidence). Financial forecast document downloaded (sensitivity label: Highly Confidential).

Response actions taken (from Phase 5): account contained (password reset + session revocation + user containment), forwarding rule removed, DLP policy upgraded to block, finance team notified, eDiscovery legal hold placed.

Recommendations (from investigation findings): upgrade DLP policy for credit card data from audit-only to block. Implement conditional access policy requiring compliant device for Exchange Online access. Review and restrict j.morrison’s SharePoint permissions to least-privilege. Investigate the three secondary phishing recipients.

From investigation to detection: creating Sentinel analytics rules

The cross-product investigation revealed specific attack patterns that can be codified as Sentinel analytics rules. The investigation is reactive (you found the attack after it happened). The analytics rule is proactive (it detects the next attack as it happens).

The specific patterns from this investigation that should become detection rules:

Pattern: Inbox rule creation followed by bulk MailItemsAccessed from a different IP within 30 minutes. Detection: scheduled KQL rule that joins New-InboxRule events with MailItemsAccessed events by user, where the IPs differ and the time gap is under 30 minutes.

Pattern: Email delivery from a known phishing domain followed by a sign-in from a new IP within 15 minutes. Detection: scheduled KQL rule that joins EmailEvents + UrlClickEvents with SigninLogs by user, where the sign-in IP is not in the user’s 30-day baseline.

Pattern: DLP alert for external email immediately preceded by an anomalous sign-in for the same user. Detection: scheduled KQL rule that joins DLP events with risky sign-in events by user within a 2-hour window.

Module 15 (Detection Engineering) teaches you to formalize these patterns into production analytics rules with appropriate severity, entity mapping, and automated response actions. The investigation findings from this module are the raw material for that detection engineering work.

Knowledge check