Dissecting the Multi-Stage AiTM Campaign: A Security Operations Playbook

Microsoft's busy celebrating their 2026 security awards. Meanwhile, threat actors keep getting better at what they do. The recent Microsoft Security Blog post on the resurgent multi-stage Adversary-in-the-Middle (AiTM) phishing campaign abusing SharePoint? That's a wake-up call.

I've spent the last few years building and scaling MDR services at Crayon. I've seen these phishing campaigns firsthand. They're smart, they bypass traditional defenses, and they work. This is a practical incident response playbook based on Microsoft's latest threat intel and my own operational experience.

What is the multi-stage AiTM attack chain?

A multi-stage AiTM attack is a phishing chain that splits the work across several legitimate-looking surfaces — typically a SharePoint document, a credential-harvesting reverse proxy, and a post-login mailbox automation step — so that no single hop looks malicious on its own. The chain is built to defeat URL filtering (because SharePoint is trusted), to defeat MFA (by stealing the session cookie after MFA succeeds), and to defeat human review (because the attacker uses the stolen mailbox to send the next wave from inside the org).

Here's how the typical attack flows:

1. Initial Compromise: Spear-phishing emails with SharePoint links
2. Trust Exploitation: Legitimate SharePoint URLs bypass URL filtering
3. Credential Harvesting: AiTM proxy captures credentials and session tokens
4. Session Hijacking: Immediate use of stolen sessions for Business Email Compromise (BEC)
5. Persistence: Additional account compromise for sustained access

The SharePoint abuse is what makes this nasty. SharePoint-based threats fly under the radar constantly. Why? The initial touchpoint looks completely legitimate. Your users trust SharePoint. Your filters trust SharePoint. The attackers know this.

Why SharePoint is the perfect lure

SharePoint links are a particularly attractive abuse target for three structural reasons. First, the sharepoint.com namespace is on every well-maintained URL allow-list and is signed off by Microsoft directly, so reputation-based blocking can't fire. Second, OneDrive and SharePoint share the same tenant-scoped URL pattern, which trains users to expect "weird looking" URLs from internal collaboration. Third, the document hosted on SharePoint can itself be a clean PDF — the malicious step is the next click, often a "Click here to access the full document" button that opens the AiTM proxy in a new tab. By the time the proxy fires, the user has already trusted the experience.

Where MITRE ATT&CK maps this

The chain crosses several ATT&CK tactics: Initial Access (T1566.002 — Phishing: Spearphishing Link), Credential Access (T1539 — Steal Web Session Cookie), Defense Evasion (T1550.004 — Web Session Cookie), Persistence (T1098.002 — Additional Email Delegate Permissions and inbox-rule abuse), and Collection (T1114.003 — Email Forwarding Rule). Mapping detections to this matrix is the cleanest way to audit your hunt coverage — gaps in your KQL hunts line up directly with empty ATT&CK cells.

How do you detect AiTM with Defender XDR Advanced Hunting?

The honest answer is that single-table detection underperforms. Email security sees the inbound phish but not the session theft. Identity Protection sees the risky sign-in but not the click that preceded it. Cloud App Security sees the inbox-rule creation but not the original IP. The detection that actually works joins all three signals into a single correlated hunt, so the SOC analyst opens an incident with the full chain already assembled instead of three siloed alerts that nobody connects.

Hunting for SharePoint Phishing URLs in Emails

// Find emails containing SharePoint links followed by suspicious clicks
EmailUrlInfo
| where Timestamp > ago(24h)
| where UrlDomain endswith "sharepoint.com" or UrlDomain endswith "sharepoint-df.com"
| join kind=inner (
    EmailEvents
    | where Timestamp > ago(24h)
    | where EmailDirection == "Inbound"
) on NetworkMessageId
| join kind=leftouter (
    UrlClickEvents
    | where Timestamp > ago(24h)
    | where IsClickedThrough == true
) on Url
| project Timestamp, RecipientEmailAddress, SenderFromAddress, Subject, Url, UrlDomain, IsClickedThrough
| where isnotempty(IsClickedThrough)

This is a triage query, not an alerting query — it surfaces every inbound SharePoint link that someone clicked through Safe Links. Filter the noise by joining on sender reputation (EmailEvents.ThreatTypes and DetectionMethods) and by whitelisting your own tenant's known SharePoint domains.

Detecting AiTM Session Token Theft

// Identify suspicious sign-in patterns indicating session hijacking
AADSignInEventsBeta
| where Timestamp > ago(6h)
| where Application contains "SharePoint"
| where RiskLevelDuringSignIn in ("medium", "high") or RiskState == "atRisk"
| project Timestamp, AccountUpn, IPAddress, SessionId, Application, RiskLevelDuringSignIn, City, Country
| join kind=inner (
    AADSignInEventsBeta
    | where Timestamp > ago(6h)
    | where Application !contains "SharePoint"
    | project Timestamp, AccountUpn, IPAddress, Application, City
) on AccountUpn
| where IPAddress != IPAddress1
| where datetime_diff('minute', Timestamp1, Timestamp) between (0 .. 30)
| summarize
    InitialAccess = min(Timestamp),
    SessionHijackTime = min(Timestamp1),
    TargetApps = make_set(Application1),
    SuspiciousIPs = make_set(IPAddress1)
    by AccountUpn, IPAddress

The detection logic here is same user, same window, two different IPs — which is the cookie-replay signature. Entra ID Protection separately raises "anomalous token" risk events for this pattern; if you have an Entra P2 license, ingest those via the Identity Protection Sentinel connector and treat them as high-fidelity instead of medium.

Hunting for BEC Activity Post-Compromise

// Detect inbox rule creation after suspicious SharePoint access
CloudAppEvents
| where Timestamp > ago(24h)
| where ActionType == "New-InboxRule"
| extend RuleConfig = tostring(RawEventData.Parameters)
| where RuleConfig contains "ForwardTo" or RuleConfig contains "RedirectTo" or RuleConfig contains "DeleteMessage"
| join kind=inner (
    AADSignInEventsBeta
    | where Timestamp > ago(24h)
    | where Application contains "SharePoint"
    | where RiskLevelDuringSignIn != "none"
    | project AccountUpn, SharePointAccess = Timestamp, RiskLevel = RiskLevelDuringSignIn
) on $left.AccountObjectId == $right.AccountUpn
| where datetime_diff('hour', Timestamp, SharePointAccess) between (0 .. 6)
| project Timestamp, AccountUpn, ActionType, RuleConfig, SharePointAccess, RiskLevel

The three RuleConfig patterns are the classic BEC trinity: ForwardTo exfiltrates incoming mail to the attacker's address, RedirectTo does the same while hiding from the user, and DeleteMessage removes replies (typically to security teams or banks) before the user sees them. Any one of those rule actions on an account that had a risky SharePoint sign-in inside the last six hours is a confirmed compromise until proven otherwise.

Cross-Domain Attack Correlation

// Unified view: Email → SharePoint click → Session compromise → BEC
let timeWindow = 24h;
let suspiciousClicks =
    UrlClickEvents
    | where Timestamp > ago(timeWindow)
    | where UrlDomain contains "sharepoint"
    | where IsClickedThrough == true
    | project ClickTime = Timestamp, AccountUpn, Url;
let riskySignIns =
    AADSignInEventsBeta
    | where Timestamp > ago(timeWindow)
    | where RiskLevelDuringSignIn in ("medium", "high")
    | project SignInTime = Timestamp, AccountUpn, IPAddress, Application;
let inboxChanges =
    CloudAppEvents
    | where Timestamp > ago(timeWindow)
    | where ActionType in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox")
    | project RuleTime = Timestamp, AccountObjectId, ActionType;
suspiciousClicks
| join kind=inner riskySignIns on AccountUpn
| where datetime_diff('hour', SignInTime, ClickTime) between (0 .. 2)
| join kind=leftouter inboxChanges on $left.AccountUpn == $right.AccountObjectId
| project AccountUpn, ClickTime, SignInTime, RuleTime, IPAddress, Application, ActionType
| order by ClickTime desc

This is the hunt I'd put behind a scheduled Sentinel analytics rule with a 1-hour cadence. The output of one row is, by definition, a chain that crossed three trust boundaries (email → identity → mailbox) on the same account in the same window — the false-positive rate is low enough that you can wire it straight into automation.

Reference table: signal → table → response

Stage	Defender XDR table	Strongest field	Containment action
Phishing email arrives	EmailEvents, EmailUrlInfo	UrlDomain, ThreatTypes	Safe Links retro-block, ZAP malicious mail
User clicks SharePoint URL	UrlClickEvents	IsClickedThrough, ActionType	Tenant Allow/Block, user education
Reverse proxy captures cookie	AADSignInEventsBeta	RiskLevelDuringSignIn, SessionId	Revoke-MgUserSignInSession
Cookie replayed from new IP	AADSignInEventsBeta	IPAddress, RiskEventTypes	Conditional Access block, MFA re-registration
Inbox rule planted for BEC	CloudAppEvents	ActionType=New-InboxRule	Delete rule, audit Sent Items, notify recipients

What is the right immediate-response playbook?

The right playbook for AiTM containment is short and runs on a 30-minute clock. Revoke active sessions for the affected account, disable the account in Entra ID, block the attacker IP at the Conditional Access layer, then move into investigation. Doing investigation before containment is the single most common SOC mistake here — by the time you've finished mapping the SharePoint click chain, the inbox rules are already in place.

Phase 1: Containment (0-15 minutes)

1. Revoke user sessions: Use Microsoft Graph PowerShell to invalidate all active sessions
2. Disable affected accounts: Temporary disable to prevent further access
3. Block suspicious IPs: Add to conditional access policies if patterns emerge

The PowerShell call that matters is Revoke-MgUserSignInSession -UserId <upn>, which invalidates the refresh token. Without that step, password resets alone do nothing — the attacker's stolen cookie keeps working until it expires naturally (up to 90 days, depending on tenant policy).

Phase 2: Investigation (15-60 minutes)

1. Analyze SharePoint access logs: Look for document downloads, sharing modifications
2. Review email activity: Check for rule creation, message forwarding, sent items
3. Assess lateral movement: Monitor sign-ins to other applications post-compromise

Pay particular attention to Set-Mailbox -ForwardingSmtpAddress events — that's a tenant-level forwarding setting that survives password resets and rule deletion. It's the single hardest persistence artefact to spot if you only look at inbox rules.

Phase 3: Eradication (1-4 hours)

1. Reset credentials: Force password reset and MFA re-registration
2. Remove malicious rules: Delete any forwarding or redirect rules
3. Review SharePoint permissions: Audit and remove suspicious sharing permissions

MFA re-registration is non-negotiable. AiTM kits routinely add the attacker's own authenticator to the victim's account during the proxy session — leaving the original MFA method in place is enough for the attacker to come back in two weeks once the SOC has stopped watching.

How do you build resilient defenses against AiTM?

Resilience against AiTM is structural, not detective. The detective controls above shrink the dwell time of a successful AiTM attack from days to minutes, but they don't prevent the initial token theft. Phishing-resistant authentication (FIDO2, Windows Hello, certificate-based) and Conditional Access policies that bind sessions to compliant devices are the only controls that genuinely break the AiTM playbook at step one. Everything else is harm reduction.

Conditional Access Enhancements: Implement location-based restrictions for SharePoint access. This is especially important for external sharing activities. Pair this with the "require compliant device" grant control — a stolen cookie replayed from an attacker laptop fails device compliance, even if the credential check would pass.

Zero Trust Email Security: Deploy Microsoft Defender for Office 365 with Safe Links configured for SharePoint documents. Enable Safe Attachments dynamic delivery so users can read the body while attachments are detonated in the sandbox.

User Education: Regular training on SharePoint phishing. Focus on URL verification techniques. People need to know what to look for. Anchor the training in real screenshots of the campaign — generic "look for typos" advice does not survive a campaign that lives on a real sharepoint.com URL.

Session Management: Implement shorter session lifetimes for SharePoint external access. The Conditional Access "Sign-in frequency" control is the right knob here; an hourly forced re-auth on sensitive scopes drastically shortens the useful life of any stolen cookie.

Phishing-resistant MFA for high-value roles: Global Admins, Privileged Role Administrators, and anyone with payment authority should be on FIDO2 hardware keys or Windows Hello for Business. The authenticator is bound to the legitimate origin, so an AiTM proxy literally cannot complete the cryptographic challenge.

Where to start

Implement the detection queries above in your Defender XDR environment. Adapt them to your tenant. Review your SharePoint security posture, particularly external sharing policies and conditional access rules.

Then run a tabletop exercise simulating a SharePoint-based compromise. Find the gaps in your playbook before a real incident does. If you want a parallel detection-engineering walkthrough on a different attack family, the Sliver C2 hunting guide applies the same correlate-across-tables approach to post-exploitation rather than initial access — and the same composite-scoring pattern carries over to the Tsundere Bot initial-access-broker hunt.

---

Connect on LinkedIn or see my CV.