Microsoft 365 AiTM Defense

AiTM phishing steals the session cookie after MFA succeeds, then replays it for full account takeover. Here's how to catch it in your tenant and the controls that make the cookies useless when it happens.

6 artifacts Updated Apr 30, 2026

What this bundle covers

If you run Microsoft 365 and you've kept your eye on phishing trends, you've heard the noise about AiTM. The framing in vendor blogs is usually "this defeats MFA," which is true but loses the nuance. The attack doesn't bypass MFA. It lets MFA happen normally, then walks off with the receipt — the session cookie that Microsoft hands back to prove the user authenticated.

Once the attacker has that cookie, they can paste it into their own browser and skip the entire login flow. No MFA prompt. No password. Just a fully authenticated Outlook session, looking exactly like the user.

This bundle is what we wish we'd had the first time we triaged one of these. Three layers, in this order:

The threat model. Read this first. The detections and mitigations only make sense once you understand what step they're breaking.
Detections. KQL queries for Sentinel and 365 Defender. Three queries that catch the attack at different stages.
Mitigations. Conditional Access policies that make the cookies useless even when they're stolen. Plus the rollout order that doesn't lock your tenant out.
Playbook. What to do at 2am when the detection fires.

Who this is for

Anyone running M365 / Azure AD who wants to harden against AiTM. The detections assume Sentinel or Defender XDR. The mitigations assume Conditional Access (P1 or P2). If you're on the free tier, the threat model still applies but your prevention options narrow — focus on phishing-resistant MFA and don't sleep on user awareness.

Status

Live and being added to. Threat model + 3 detections + CA policy guide + IR runbook are published. More coming as we hit them in engagements.

Threat model & overview

AiTM phishing — what actually happens, and what breaks each step

High

The attack in plain English, mapped to ATT&CK, and which defensive control kills which step. Read this before deploying anything else.

T1566.002, T1539, T1078.004, T1098.002, T1098.003 8 min read

Detections

Sentinel detection — same session, two sources

Medium

When an attacker replays a stolen cookie, the same session ID shows up from two different IPs within minutes. This KQL catches it. Plus the false positives we keep hitting.

Microsoft Sentinel (KQL) T1539, T1078.004 5 min read

Sentinel detection — sign-in from a hosting ASN

High

Real users sign in from residential ISPs and corporate networks. Attackers replaying cookies sign in from rented VPS. Hosting ASNs are an extremely strong signal.

Microsoft Sentinel (KQL) T1078.004, T1090.003 6 min read

Sentinel detection — suspicious sign-in plus persistence action

Critical

The highest-fidelity detection in this bundle. Catches the chain: dodgy sign-in, then within 2 hours a forwarding rule, OAuth consent, MFA registration, or device registration. Almost never a false positive.

Microsoft Sentinel (KQL) T1098.002, T1098.003, T1098.005, T1556.006 6 min read

Mitigations

Conditional Access policies that actually break AiTM

High

Five Conditional Access policies, deployed in this order, make AiTM economically unviable against your tenant. Plus the rollout sequence and break-glass setup so you don't lock yourself out.

T1539, T1078.004 10 min read

Playbooks

AiTM incident response — what to do when the alert fires at 2am

High

Step-by-step runbook for when an AiTM detection lights up. Revoke, reset, audit, clean persistence, pivot-hunt. Exact PowerShell included.

T1539, T1078.004, T1098.002, T1098.003 8 min read

Need help deploying any of this?

Tuning these detections to your tenant, rolling out the Conditional Access policies, designing the IR runbook for your team — we do that work.

Talk to us about an engagement