12.4 Email Analysis: Tracing the Phishing Campaign

Email Analysis: Tracing the Phishing Campaign

The scoping queries (11.3) told you how many users received the phishing email and how many clicked. This subsection analyses the email itself: sender infrastructure, URL characteristics, delivery verdict, and campaign scope. The output is a complete picture of the phishing delivery mechanism.

Required role: Microsoft Sentinel Reader for KQL. Defender for Office 365 Security Reader for Threat Explorer access.

Analyse the phishing email

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// Full details of the phishing emails
EmailEvents
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where SenderFromDomain == "sharepoint-secure-verify.com"
| project
    TimeGenerated,
    SenderFromAddress,          // The From: header the user sees
    SenderMailFromAddress,      // The envelope sender (may differ)
    RecipientEmailAddress,
    Subject,
    DeliveryAction,             // Delivered, Blocked, Junked
    DeliveryLocation,           // Inbox, JunkFolder, Quarantine
    AuthenticationDetails,      // SPF, DKIM, DMARC results
    ThreatTypes,                // Phish, Malware, or empty
    DetectionMethods,           // What flagged it (if anything)
    NetworkMessageId            // Unique ID for cross-referencing
| order by TimeGenerated asc

What to examine in the results:

SenderFromAddress vs SenderMailFromAddress. If these differ, the email uses sender spoofing — the display name shows one address while the envelope sender is different. AiTM campaigns frequently use this technique: the From header might show documents@sharepoint-online.com while the envelope sender is noreply@sharepoint-secure-verify.com.

DeliveryAction and DeliveryLocation. If DeliveryAction = “Delivered” and DeliveryLocation = “Inbox”: the email bypassed all protections and reached the user’s inbox. This is the worst-case scenario — the user saw it immediately with no warning. If DeliveryLocation = “JunkFolder”: Safe Links or anti-phishing flagged it but did not quarantine it — the user may still have opened it from junk.

AuthenticationDetails. Parse the SPF, DKIM, and DMARC results. An AiTM phishing domain is attacker-controlled — it typically passes SPF (the attacker configured DNS correctly) and may even have DKIM signing. DMARC may show “none” if the attacker did not configure a DMARC policy on their domain — but absence of DMARC does not flag the email as malicious; it just means DMARC alignment was not checked.

ThreatTypes and DetectionMethods. If ThreatTypes is empty and DetectionMethods is empty: the email was not flagged at delivery time. This is common for AiTM campaigns using new infrastructure — the phishing URL has no reputation, the domain is freshly registered, and the email content does not match known phishing signatures.

Analyse the phishing URL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Extract and analyse URLs from the phishing emails
EmailUrlInfo
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where NetworkMessageId in (
    EmailEvents
    | where SenderFromDomain == "sharepoint-secure-verify.com"
    | project NetworkMessageId
)
| project TimeGenerated, NetworkMessageId, Url, UrlDomain, UrlLocation
| distinct Url, UrlDomain

What to examine:

URL structure. AiTM proxy URLs typically mimic the legitimate Microsoft sign-in URL. Example: https://login-microsoftonline.secure-portal-verify.com/auth/v2. The subdomain (login-microsoftonline) and the path (/auth/v2) are designed to look legitimate on quick inspection. The domain (secure-portal-verify.com) is the attacker’s.

Multiple URLs. A campaign may use multiple URLs pointing to the same AiTM infrastructure (different subdomains, different paths). Or it may use a URL shortener or redirect chain. Extract all unique domains — each is an IOC for threat intelligence sharing and blocking.

Determine who clicked

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Who clicked the phishing URL, when, and from which device
UrlClickEvents
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where Url has "secure-portal-verify.com"
| project
    TimeGenerated,
    AccountUpn,
    Url,
    ActionType,        // ClickAllowed, ClickBlocked
    IsClickedThrough,  // Did user click through the Safe Links warning?
    NetworkMessageId,
    IPAddress,
    Workload           // Email, Teams, etc.
| order by TimeGenerated asc

Critical fields:

ActionType. “ClickAllowed” means Safe Links allowed the click — either the URL was not flagged or the user clicked through a warning. “ClickBlocked” means Safe Links blocked the navigation — the user saw a warning page and was prevented from reaching the phishing site. Blocked clicks are not compromises, but they indicate targeted users.

IsClickedThrough. If true: the user saw a Safe Links warning and chose to proceed anyway. This is the highest-risk scenario — the user actively overrode the safety control. Security awareness training should be updated to address this behaviour.

Investigation decision point: For every user where ActionType = “ClickAllowed”: that user may have entered credentials on the AiTM proxy. Proceed to subsection 12.5 (Sign-In Log Investigation) for each clicker to determine if token replay occurred.

For every user where ActionType = “ClickBlocked”: no credential compromise expected, but document as a targeted user. They may receive future phishing attempts.

Check for post-delivery remediation (ZAP)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Did Zero-hour Auto Purge remove the phishing emails after delivery?
EmailPostDeliveryEvents
| where TimeGenerated > datetime(2026-02-26T09:00:00Z)
| where NetworkMessageId in (
    EmailEvents
    | where SenderFromDomain == "sharepoint-secure-verify.com"
    | project NetworkMessageId
)
| project TimeGenerated, RecipientEmailAddress, Action,
    ActionType, ActionTrigger, ActionResult

What to examine: If ZAP ran and moved emails to quarantine or deleted them: check the timing. If ZAP ran at 09:15 but the user clicked at 08:52, ZAP was too late — the user already interacted with the email. If ZAP ran before any clicks: the protection worked, but only for users who had not yet opened the email.

Operational takeaway: ZAP is a reactive control — it catches phishing emails after delivery when new intelligence identifies the URL or sender as malicious. It does not prevent the initial delivery or the initial click. For AiTM campaigns using new infrastructure, ZAP may not trigger for hours or days.

Build the phishing campaign profile

Compile the email analysis into a campaign profile:

Save this as a bookmark tagged INC-2026-0227-001, email-analysis. This profile is a key artifact in the investigation record and the IR report (11.11).

Subsection artifact: The four email analysis queries above (email details, URL extraction, click tracking, ZAP check) plus the campaign profile template. These form the email analysis section of your AiTM investigation playbook.

Knowledge check