Adversary-in-the-Middle

For years, organizations have treated multi-factor authentication (MFA) as the final boss of identity security—an end state. Check the box, roll out MFA, and declare phishing solved.

Except that it isn’t.

Over the past year, a new class of attack has gained mainstream adoption among both advanced threat actors and entry-level cybercriminals: Adversary-in-the-Middle (AiTM). It’s fast, scalable, terrifyingly effective, and it breaks one of the most persistent assumptions in modern security programs:

We cannot.

AiTM doesn’t break MFA. It bypasses it—by stealing the user’s authenticated session after the MFA challenge has been satisfied. Once a threat actor has the session token, they become the user. No password needed. No second factor needed. No friction at all.

This post explains why AiTM matters, how these attacks actually work, and what organizations can do to stop them—from first principles.

Why AiTM Exists: A Shift in the Attacker’s Business Model

Attackers didn’t magically become more sophisticated. They adapted.

As organizations rolled out MFA, threat actors needed a way around it. Password theft alone wasn’t enough anymore. They needed a way to impersonate a user after MFA.

Enter reverse-proxy phishing kits. At first, they lived in the realm of nation-state operators. Today, they're sold as easy-to-use SaaS platforms with dashboards that look like marketing automation tools.

In other words: AiTM is no longer an APT trick—it’s a commodity.

How Adversary-in-the-Middle Actually Works (Step-By-Step)

Here’s what happens behind the scenes when a user clicks an AiTM phishing link:

1. The phishing link directs to a proxy server
   The attacker’s server sits between the victim and the real login page.

2. The user sees the real login screen
   It’s not a clone—it’s the actual login page, just proxied.

3. Credentials are captured in real time
   Every keystroke routes through the attacker.

4. MFA is completed successfully
   The victim uses their real second factor.

5. The attacker steals the session cookie
   This is the key: the authenticated session token is forwarded back to the attacker.

6. The attacker logs in as the victim—no MFA required
   They now hold a fully authenticated, high-trust identity session.

7. Persistence or escalation begins
   Examples include:

   • Registering a new MFA method

   • Creating OAuth grants

   • Inbox rule manipulation for BEC

   • Data exfiltration from SaaS (Drive, SharePoint, Notion, GitHub, Jira)

   • Spinning up cloud resources

Once inside, many detections collapse because the activity is “user-like.”
This is precisely why AiTM is so dangerous.

Why This Is Increasing: Identity is the New Perimeter

Adversary-in-the-Middle attacks thrive in modern environments because:

• Organizations rely heavily on single sign-on for SaaS.

• Sessions last hours to weeks, depending on configuration.

• Most conditional access systems implicitly trust already-authenticated sessions.

• Legacy MFA (OTP codes, push prompts, SMS) offers no cryptographic binding.

• Browser session tokens are not tied to a device.

Attackers don’t need malware.
They don’t need a zero-day.
They just need one user to log in—through them.

Phishing-Resistant MFA: The Only Real Fix

The only class of authentication resistant to AiTM is cryptographically bound, origin-verified authentication, such as:

• FIDO2 keys

• Passkeys

• WebAuthn-based device-bound credentials

These don’t send secrets the attacker can intercept.
They bind the authentication to:

• the specific browser,

• the specific device,

• the specific domain.

A proxy cannot replicate that binding.

If your organization relies heavily on MFA but has not yet standardized on phishing-resistant MFA, you should treat AiTM as an active risk—not a theoretical one.

How to Detect AiTM in the Wild

AiTM patterns show up as:

• MFA completed from a normal device/IP followed by session usage from a totally different location minutes later.

• JA4 fingerprints mismatch. The user authenticates with one browser signature; the session continues with a different one.

• Unusual OAuth consent grants

• New MFA methods registered by the “user”

• Mailbox forwarding rules created silently

• Impossible travel events (often minutes apart)

• Token refresh events from non-standard IP ranges (e.g., residential proxies, cloud VMs)

Identity telemetry—done correctly—makes AiTM stand out like a siren. More on all of this later. It’s a much longer conversation.