13.4 Wave 1: Email Analysis

2–3 hours · Module 13

Wave 1: Email Analysis

At 09:40 GMT, Defender XDR fires the alert. Your investigation starts here — with the phishing email itself.

Step 1: Identify the campaign scope

1
2
3
4
5
6
EmailEvents
| where TimeGenerated between (datetime(2026-02-27T08:00:00Z) .. datetime(2026-02-27T12:00:00Z))
| where ThreatTypes has "Phish" or SenderMailFromDomain has "northgate-voicemail"
| project TimeGenerated, SenderFromAddress, RecipientEmailAddress, Subject,
    DeliveryAction, DeliveryLocation, ThreatTypes, DetectionMethods
| sort by TimeGenerated asc

Result: 23 emails from noreply@northgate-voicemail[.]com with subject line “New voicemail message from [name] — [duration].” The attacker personalised each email with a realistic sender name and voicemail duration.

Metric	Value
Total emails sent	23
Unique recipients	23 (all finance department)
Delivery: Inbox	19
Delivery: ZAP removed	4
Delivery: Blocked	0
Detection technology	URL detonation (post-delivery)

Zero emails blocked at delivery

All 23 emails were initially delivered to the inbox. The phishing kit's Cloudflare turnstile CAPTCHA prevented Safe Links' automated URL detonation from reaching the proxy page at scan time. ZAP caught 4 when the URL verdict was updated 23 minutes later — but 19 were already accessible.

Step 2: Analyse the phishing URL

1
2
3
4
5
EmailUrlInfo
| where TimeGenerated between (datetime(2026-02-27T08:00:00Z) .. datetime(2026-02-27T12:00:00Z))
| where Url has "northgate-voicemail"
| project TimeGenerated, Url, UrlDomain, NetworkMessageId
| distinct Url, UrlDomain

Result: All 23 emails contained the same base URL with a unique per-recipient hash: https://northgate-voicemail[.]com/auth/[32-character-hex]/login

The /auth/[hash]/login path structure is the phishing kit’s signature. The hash is unique per recipient — it identifies which target accessed the proxy, allowing the attacker to match stolen tokens to specific mailboxes.

URL pattern = kit fingerprint

The domain will change in future waves. The path structure will not — it is baked into the phishing kit. Detecting /auth/[a-f0-9]{32}/login across all inbound URLs catches future waves regardless of which domain the attacker registers. This is your most valuable IOC.

Step 3: Analyse email headers

The email headers reveal the sending infrastructure. Key headers to examine:

1
2
3
4
5
6
EmailEvents
| where TimeGenerated between (datetime(2026-02-27T08:00:00Z) .. datetime(2026-02-27T12:00:00Z))
| where SenderMailFromDomain has "northgate-voicemail"
| project SenderFromAddress, SenderMailFromAddress, SenderIPv4,
    AuthenticationDetails, Subject
| take 1

What to check:

SenderFromAddress vs SenderMailFromAddress: If these differ, the display name is spoofed. In this case, both use the phishing domain — the attacker registered a real domain rather than spoofing.
SenderIPv4: The sending mail server IP. Cross-reference with threat intelligence feeds. In this case, the IP resolves to a cloud VPS provider — consistent with disposable phishing infrastructure.
AuthenticationDetails: SPF, DKIM, DMARC results. The attacker configured SPF and DKIM for their phishing domain (it takes 5 minutes). DMARC does not help here because the sender domain is the attacker’s, not a spoofed legitimate domain.

SPF/DKIM pass does not mean the email is safe

These protocols verify that the email was sent from an authorised server for the sender domain. The attacker owns the sender domain — so SPF and DKIM pass legitimately. Email authentication verifies "this email was sent from the domain it claims to be from." It does not verify "this domain is legitimate." Do not dismiss phishing because authentication passed.

Step 4: Check who clicked

1
2
3
4
5
6
UrlClickEvents
| where TimeGenerated between (datetime(2026-02-27T08:00:00Z) .. datetime(2026-02-27T12:00:00Z))
| where Url has "northgate-voicemail"
| project TimeGenerated, AccountUpn, Url, ActionType, IsClickedThrough,
    NetworkMessageId, ThreatTypes
| sort by TimeGenerated asc

Result:

User	Click time	Safe Links warned?	Clicked through?
a.chen@	09:17	Yes	Yes
m.patel@	09:18	Yes	Yes
j.morrison@	09:19	Yes	Yes
s.williams@	09:21	Yes	Yes
r.thompson@	09:23	Yes	Yes
d.kumar@	09:24	Yes	No (heeded warning)
l.garcia@	09:31	Yes	No (heeded warning)

5 users clicked through the Safe Links warning. 2 users saw the warning and stopped. 16 users did not click at all.

5 users on the AiTM proxy page ≠ 5 compromised accounts

Clicking through to the proxy page means the user saw the fake login page. It does not mean they entered credentials. Some users may have closed the page immediately. Some may have entered credentials but the proxy failed to capture a complete token. The sign-in log investigation (next subsection) determines who was actually compromised.

Analysis decision: Safe Links warned all 7 clickers but 5 clicked through

Safe Links correctly identified the URL as suspicious and showed a warning page. 5 of 7 users clicked through the warning anyway. What does this tell you?

What action should this observation drive?

Check your understanding

1. The phishing domain has valid SPF and DKIM. Does this mean the email is legitimate?

Yes — authenticated emails are trustworthy

Only if DMARC also passes

No — SPF/DKIM verify the email came from the claimed domain's authorised servers. The attacker owns the domain and configured its authentication correctly. Authentication proves origin, not legitimacy.

Email authentication answers "did this email come from the domain it says?" not "is this domain trustworthy?" Attackers routinely set up SPF and DKIM for their phishing domains — it takes minutes and makes the email appear more legitimate to both filters and recipients.

2. Why is the URL path pattern /auth/[hash]/login more valuable as an IOC than the phishing domain?

Domains are disposable (the attacker registers new ones for each wave). The URL path structure is generated by the phishing kit and remains consistent across all domains — detecting the path catches all waves.

The domain is harder to detect

URL paths cannot be changed

Phishing domains are the most perishable IOC — attackers register and discard them daily. The kit's internal URL structure is much harder to change because it is embedded in the kit's code. A detection matching the path pattern catches the kit regardless of which domain it is deployed on.

← 13.5 Wave 1: Sign-In Log Investigation 13.3 Setting Up Your Investigation →