Microsoft tracked a single adversary-in-the-middle phishing campaign that compromised more than 35,000 users across 13,000 organisations in 26 countries in three days during April 2026. That is not a targeted operation. That is a commodity kit running at internet scale.

The broader picture from incident response data is consistent. Phishing remained the top initial access vector in Q2 2026, appearing in more than half of Cisco Talos IR engagements. Unit 42 data attributes 65% of initial access to identity-based techniques. Authentication abuse showed up in 65% of engagements, up from 35% the previous quarter.

How AiTM actually works

The critical thing to understand is that AiTM does not break MFA. It lets MFA succeed and then steals the result.

  1. The victim clicks a phishing link and lands on an attacker-controlled reverse proxy.
  2. The proxy fetches the real login page from the genuine identity provider and renders it to the victim. It is not a copy — it is the actual page, relayed.
  3. The victim enters their username and password. The proxy forwards them upstream.
  4. The identity provider issues a genuine MFA challenge. The victim approves it — push notification, TOTP code, SMS, whatever is configured.
  5. The identity provider, satisfied, issues a session cookie. The proxy captures it in transit.
  6. The attacker imports that cookie into their own browser and is authenticated as the victim, with MFA already satisfied.

Attackers have moved down the stack from the password to the session. The login was legitimate. The MFA was legitimate. Only the browser holding the resulting token is not.

Everything the victim sees is correct. The URL is often the only tell, and modern kits use lookalike domains, valid TLS certificates and open redirects on trusted domains to make even that difficult.

Why the numbers are so bad

Reporting from 2026 puts it starkly: MFA failed to prevent attacks in 84% of incident responses, and 99% of SaaS compromises originate at the identity provider. That second figure is the more useful one for architecture decisions — it says the identity provider is the perimeter now, and everything downstream inherits whatever happens there.

The techniques stack. Beyond AiTM proxies, attackers use session token theft from infostealer logs, MFA fatigue (repeated push prompts until someone approves to make it stop), and self-enrolled device registration — where an attacker with a valid session quietly adds their own MFA method, converting temporary access into permanent access.

What stops it

Phishing-resistant MFA is the only structural fix

FIDO2 security keys and passkeys defeat AiTM by design, not by detection. The authentication ceremony is cryptographically bound to the origin. When the victim is on login-microsoft.attacker-domain.com instead of the real domain, the authenticator simply will not produce a valid assertion. There is nothing for the proxy to relay.

This is the single highest-impact change available. Prioritise the rollout:

  1. Administrators and privileged roles first — no exceptions, including break-glass accounts (which should use a separate hardware key held in a safe).
  2. Finance, HR, legal and anyone with access to payment systems or bulk personal data.
  3. Developers and anyone with production or source control access.
  4. General population, phased.

Then remove the fallbacks

Deploying passkeys while leaving SMS and TOTP enabled as alternatives achieves very little — the attacker just steers the victim toward the weaker method. Once phishing-resistant methods are rolled out to a group, disable the weaker ones for that group. This is where most programmes stall, and it is the step that determines whether the project actually reduces risk.

Add token protection and device binding

Where your identity provider supports binding a session token to the device that requested it, enable it. A stolen cookie replayed from an attacker's machine then fails validation. Coverage varies by application, but it converts a silent compromise into a failed sign-in event you can alert on.

Alert on the post-compromise behaviour

Even with strong preventive controls, build detections for what follows a successful session theft:

  • Impossible travel and sign-ins from hosting provider or VPN exit IP ranges.
  • New MFA method registered shortly after a sign-in from an unusual location — one of the highest-fidelity signals available.
  • Mailbox rules created that forward, delete or move messages matching finance-related keywords.
  • OAuth application consent grants to applications nobody has heard of.
  • Unusual volumes of file access or download in SharePoint, Drive or your document store.

Practical sequencing

If you can do one thing this quarter, roll out phishing-resistant MFA to privileged accounts and disable weaker methods for them. If you can do two, add automated session revocation to your identity compromise playbook. If your programme cannot move that fast, at minimum turn on the "new MFA method registered" alert today — it costs nothing and catches the step where a temporary compromise becomes a persistent one.