Anatomy of a Five-Wave AiTM Phishing Campaign

The first alert

It started with a Sentinel analytics rule: “Sign-in from non-corporate IP immediately following phishing URL click.” One user. One IP. One suspicious sign-in with MFA already satisfied — the attacker had captured the session cookie through a reverse proxy, bypassing MFA entirely.

Standard AiTM. Textbook response: revoke tokens, reset password, check for persistence. Close the incident.

Except it didn’t end there.

What made this different

Over the next 72 hours, the same attacker infrastructure launched four more waves. Each wave adapted to the containment actions taken after the previous one.

Wave 1: Classic AiTM phishing email. Single user compromised. Inbox rule created to forward financial emails. Contained within 90 minutes.

Wave 2: 6 hours later. Different phishing domain. Different lure. Three users targeted. The attacker had learned which users were in Finance and targeted them specifically — suggesting they had accessed the Global Address List during Wave 1.

Wave 3: Next morning. The phishing email originated from one of the Wave 2 compromised accounts that hadn’t been contained yet (the account owner was in a different timezone and hadn’t responded to the password reset notification). Lateral phishing from inside the organisation.

Wave 4: 18 hours later. New infrastructure. The attacker registered a lookalike domain that differed by one character from a legitimate vendor. The phishing email referenced a real purchase order number — information only accessible from the mailbox compromised in Wave 2.

Wave 5: 48 hours after initial detection. The attacker attempted a token replay using a session cookie captured during Wave 3, testing whether the revoked token had been replaced by a new one. It hadn’t — Continuous Access Evaluation (CAE) blocked the replay.

The investigation approach

Each wave required the same investigation methodology, applied faster each time:

Identify the entry point. Which email, which URL, which user clicked. EmailEvents and UrlClickEvents in Defender XDR.

Trace the authentication chain. SigninLogs to find the attacker’s sign-in. Look for: MFA already satisfied (the AiTM proxy captures the MFA token), non-corporate IP, unusual user agent.

Assess the blast radius. What did the attacker access? OfficeActivity for mailbox access. AuditLogs for configuration changes. CloudAppEvents for file access. How many emails were read? Were any rules created? Was any data exfiltrated?

Contain. Revoke all tokens. Reset password. Remove inbox rules. Block the phishing domain in Defender for Office 365. Block the attacker IP in Conditional Access.

Hunt for persistence. Check for MFA method changes (the attacker registering their own authenticator). Check for OAuth application consents. Check for mailbox delegates added. Any of these would give the attacker continued access even after password reset.

What the KQL looks like

The core investigation query chains three tables to trace the full attack path — from phishing email delivery to sign-in to post-compromise activity:

 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

// Step 1: Find the phishing emails
let PhishingEmails = EmailEvents
| where TimeGenerated > ago(7d)
| where ThreatTypes has "Phish"
| where DeliveryAction == "Delivered"
| project EmailTime = TimeGenerated, RecipientEmailAddress,
    SenderFromAddress, Subject, NetworkMessageId;
// Step 2: Find clicks on URLs from those emails
let Clicks = UrlClickEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ClickAllowed"
| project ClickTime = TimeGenerated, AccountUpn, Url, NetworkMessageId;
// Step 3: Find suspicious sign-ins after clicks
PhishingEmails
| join kind=inner Clicks on NetworkMessageId
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType == "0"
    | project SignInTime = TimeGenerated, UserPrincipalName,
        IPAddress, AppDisplayName, AuthenticationRequirement
) on $left.AccountUpn == $right.UserPrincipalName
| where SignInTime between (ClickTime .. (ClickTime + 1h))
| project EmailTime, ClickTime, SignInTime, AccountUpn,
    IPAddress, Subject, AuthenticationRequirement

This query produces a timeline: email delivered → user clicked → attacker signed in. The AuthenticationRequirement field reveals whether the sign-in required MFA (legitimate) or used a captured token (AiTM).

The outcome

Five waves. Seven targeted users. Three compromised accounts. Zero successful credential replays after containment (CAE held). Zero data exfiltration confirmed. Eight new detection rules deployed. One formal IR report delivered to the CISO.

Total investigation time: 14 hours across 72 hours of attacker activity.

Learn the full methodology

Module 12 (Investigating AiTM Credential Phishing) walks through this entire investigation methodology — from initial alert through containment, eradication, and reporting. The module is based on this real incident, sanitised for training use. It includes:

• 8 deployable KQL detection rules for AiTM patterns
• A complete investigation playbook
• An email protection hardening checklist mapped to NIST CSF 2.0
• The IR report template used for the CISO briefing

Start with the free modules → or view the full course syllabus →