For years, organizations have treated multi-factor authentication as the finish line of identity security. Deploy MFA, check the box, and assume phishing is solved.
It isn’t.
Over the past year, a class of attack that was once niche has gone fully mainstream: Adversary-in-the-Middle (AiTM). It’s fast, scalable, and brutally effective—and it breaks one of the most deeply held assumptions in modern security programs:
“If a user completes MFA, the session can be trusted.”
It can’t.
AiTM doesn’t defeat MFA. It steps around it by stealing the authenticated session after MFA succeeds. Once an attacker has the session token, they are the user. No password. No second factor. No additional friction.
This is why AiTM matters, how it actually works, and what organizations can do about it.
Why AiTM Exists: Attackers Adapted
Attackers didn’t suddenly get smarter. They adjusted their business model.
As MFA became widespread, password theft stopped being enough. To keep compromising accounts at scale, attackers needed a way to impersonate users after authentication.
The answer was reverse-proxy phishing.
What began as a technique used by sophisticated actors is now sold as turnkey SaaS. These kits come with dashboards, analytics, and automation that would look familiar to anyone in marketing ops.
AiTM isn’t an advanced trick anymore. It’s a commodity.
How Adversary-in-the-Middle Works
When a user clicks an AiTM phishing link, here’s what happens:
The link routes through a reverse proxy
The attacker places themselves between the victim and the real login service.The real login page is displayed
This isn’t a fake page—it’s the legitimate one, transparently proxied.Credentials are captured in real time
Everything the user types passes through the attacker.MFA succeeds
The user completes their second factor normally.The session token is intercepted
This is the critical moment. The authenticated session cookie is copied.The attacker replays the session
They now have a fully authenticated, high-trust session—no MFA required.Persistence and abuse begin
Common follow-on actions include:Registering a new MFA method
Granting OAuth access
Creating mailbox rules for BEC
Exfiltrating data from SaaS platforms
Spinning up cloud resources
From the platform’s perspective, this all looks like legitimate user activity. Many detections fail precisely because nothing “breaks.”
Why This Keeps Working: Identity Is the Perimeter
AiTM thrives because modern environments are built this way:
SSO is everywhere
Sessions last hours—or weeks
Conditional access trusts authenticated sessions by default
OTPs, push prompts, and SMS aren’t cryptographically bound
Browser sessions aren’t tied to a specific device
Attackers don’t need malware.
They don’t need a zero-day.
They just need a user to log in—through them.
Phishing-Resistant MFA Is the Real Fix
The only authentication methods that reliably stop AiTM are those that are cryptographically bound and origin-verified:
FIDO2 security keys
Passkeys
WebAuthn device-bound credentials
These methods don’t transmit secrets that can be intercepted. Authentication is bound to:
the device
the browser
the legitimate domain
A proxy can’t fake that.
If your organization relies on MFA but hasn’t standardized on phishing-resistant MFA, AiTM isn’t hypothetical. It’s an active risk.
Detecting AiTM in Practice
AiTM leaves fingerprints if you’re looking in the right places:
MFA completion from one device followed by session use from another location minutes later
Browser or JA4 fingerprint mismatches between authentication and session activity
Unexpected OAuth consent grants
New MFA methods added by the “user”
Silent mailbox forwarding rules
Near-instant impossible travel events
Token refreshes from unusual IP ranges (residential proxies, cloud VMs)
When identity telemetry is collected and correlated properly, AiTM stands out clearly. The challenge isn’t visibility—it’s knowing what matters.
More on that later. This part gets long.