Adversary-in-the-middle attacks expose MFA’s weakest assumption

At a glance

What this is: AiTM attacks sit between the user and the real login flow, turning MFA into a relay target instead of a barrier.

Why it matters: This matters because IAM programmes that stop at second-factor enforcement can still lose authenticated sessions, affecting NHI, autonomous, and human identity controls alike.

By the numbers:

• The Canadian Centre for Cyber Security documented over 100 AiTM campaigns targeting Microsoft Entra ID accounts between 2023 and early 2025 alone.
• Obsidian Security found that 84% of the accounts compromised through these techniques already had MFA enabled.
• AiTM attacks saw a 46% increase in 2025, driven largely by this commoditization.

👉 Read WorkOS's analysis of adversary-in-the-middle attacks and MFA bypass

Context

Adversary-in-the-middle attacks are phishing attacks that proxy a real authentication session in real time, so the victim completes a legitimate sign-in while the attacker captures the session cookie. The primary keyword here is Adversary-in-the-middle attacks, and the governance problem is that MFA can be satisfied without stopping session theft.

That breaks a common IAM assumption: if the password is strong and MFA is enabled, the account is effectively protected. In practice, the attack relays the whole login ceremony, so the real security boundary moves from factor verification to session integrity and post-authentication control.

For IAM teams, this is not just a human identity problem. The same session-stealing pattern can be used to reach SaaS accounts, admin consoles, and delegated workflows that later issue tokens, make changes, or trigger downstream access for service identities and automation.

Key questions

Q: How should security teams stop adversary-in-the-middle attacks on MFA-protected accounts?

A: Prioritize phishing-resistant authentication, especially passkeys based on WebAuthn or FIDO2, because they are origin-bound and resist relay attacks. Then add conditional access, device trust, and continuous session evaluation so a stolen session cannot be reused freely after MFA succeeds. MFA alone is not enough when the attacker can proxy the login ceremony.

Q: Why do adversary-in-the-middle attacks still work when MFA is enabled?

A: Because the attacker does not need to defeat MFA directly. They relay the real login flow in real time, capture the valid session cookie after authentication succeeds, and reuse that cookie elsewhere. The control failure is at the session layer, where a trusted token outlives the original browser context.

Q: What do security teams get wrong about MFA and session theft?

A: They often assume that a successful second factor means the account is secure for the life of the session. In reality, AiTM attacks convert MFA success into session hijack, so the useful control question is whether the session can be bound, monitored, and revoked quickly enough to limit reuse.

Q: How do organisations detect a compromised session after AiTM login?

A: Watch for post-authentication behaviour that does not match the user’s normal pattern, such as new MFA device enrollment, inbox forwarding rule creation, impossible travel, unusual resource access, or a browser fingerprint change mid-session. Those signals show the attacker has moved beyond login and is using the authenticated state.

Technical breakdown

Reverse proxy phishing and real-time authentication relay

AiTM attacks use a reverse proxy between the user and the real service. The proxy forwards credentials, MFA prompts, and the resulting session response without the victim seeing a fake login page. Because the service itself issues the session cookie, the attacker receives a valid authenticated token instead of a guessed password. This is why HTTPS does not prevent the attack and why the compromise often looks normal in logs. The real vulnerability is not weak credentials, but the fact that the authentication ceremony can be copied live and replayed outside the original browser context.

Practical implication: treat session creation as a control point, not just MFA success.

Session cookie theft after MFA success

The critical asset in AiTM is the session cookie, not the password. Once the identity provider issues a cookie after MFA succeeds, the attacker can replay it from another browser and inherit the victim’s authenticated state. That lets the attacker bypass fresh prompts until the session expires or is revoked. In many environments, this works because session tokens are trusted longer than the identity event that created them. The attack is therefore a post-authentication identity abuse problem, not a login failure problem.

Practical implication: bind session validity to device, context, and continuous risk evaluation.

Why phishing-resistant authentication changes the model

Passkeys and other WebAuthn/FIDO2 flows resist AiTM because the credential is origin-bound. The browser only presents the authentication challenge to the domain it was registered for, which prevents a proxy from relaying the ceremony to a different site. That removes the attacker’s ability to copy both the proof of possession and the resulting session handoff. The practical difference is that the factor is no longer a reusable secret or relayable code. For high-risk access, this is the control class that closes the gap rather than merely detecting it afterward.

Practical implication: prioritize phishing-resistant authentication for accounts that can create or use privileged sessions.

Threat narrative

Attacker objective: The attacker wants a valid authenticated session that bypasses MFA and can be reused for persistence, data theft, or financial fraud.

1. entry: The attacker delivers a phishing lure that routes the victim to a proxy infrastructure that forwards traffic to the real identity provider in real time.
2. credential_harvested: The victim enters credentials and completes MFA, and the attacker captures the valid session cookie issued by the service.
3. escalation: The attacker reuses the cookie to access mail, cloud storage, or admin portals, then creates persistence through new MFA devices or forwarding rules.
4. impact: The compromised session is used for business email compromise, document theft, and downstream abuse of trusted access paths.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach — Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA is no longer the control that fails first. Session integrity is. AiTM attacks do not defeat authentication by guessing a password or bypassing a second factor in the traditional sense. They satisfy the factor and then steal the authenticated session, which means the governance boundary has moved from login assurance to token protection and session trust. IAM programmes that still measure success mainly by MFA adoption are therefore measuring the wrong layer. Practitioners should treat session replay resistance as part of the core identity control plane.

Session replay assumes the browser that authenticated is the browser that will continue using the session. That assumption was designed for stable client context, not proxy-mediated relay. AiTM breaks it by separating the human from the authenticated session at the moment of issuance, so the token survives while the original trust context does not. The implication is that conditional access, token binding, and device trust are not add-ons here, they are the actual line between identity proof and identity reuse.

Phishing-resistant authentication is not a stronger MFA checkbox, it is a different trust model. Passkeys change the attack economics because the credential cannot be relayed in the same way as a code or push approval. That matters for human identities today and for any delegated access path that still depends on human-issued sessions to create downstream privileges. The practitioner conclusion is to stop treating “MFA enabled” as a complete control statement and start measuring whether the factor can be proxied.

Identity blast radius is the real exposure metric here. AiTM turns one successful sign-in into a chain of post-authentication actions that can reach email, storage, admin panels, and business processes. The more an identity can create new trust artifacts after login, the larger the blast radius becomes. This is especially relevant in environments where human credentials can mint access for service accounts, automation, or administrative workflows. Teams should review every path where one session can create another.

Real-time detection must look for behavioural discontinuity, not just failed logins. AiTM campaigns often appear successful at the authentication layer, so the useful signal is what changes immediately after sign-in: new MFA device registration, forwarding-rule creation, impossible travel, or a user agent shift mid-session. Those are the moments where the compromise becomes governable. Practitioners should treat these as session abuse indicators, not generic anomalies, and route them into identity response workflows.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That visibility gap is not just about third parties, because 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, according to the same study.
• For a broader breach lens, 52 NHI Breaches Analysis shows how weak lifecycle controls turn one exposed identity into repeated downstream compromise.

What this signals

Session trust has become the new identity boundary. As AiTM grows, IAM programmes need to watch for controls that assume the authenticated browser remains trustworthy after MFA. That assumption is increasingly false, which means session risk, device binding, and behavioural monitoring now belong in the same governance conversation as authentication policy.

Identity teams should expect attacker playbooks to move faster than manual review cycles. Once a session cookie is stolen, the compromise can progress before humans can recertify or investigate it, especially in environments that rely on delayed alerts. The practical response is to instrument the session layer so response can happen while the compromise is still active.

The same pattern reinforces why the OWASP NHI Top 10 matters for modern identity design: trust decisions are only as strong as the point at which they can be relayed, replayed, or delegated. Teams that manage both human sign-in and non-human access need one policy view of session abuse, not separate silos.

For practitioners

• Deploy phishing-resistant authentication for high-risk accounts Use passkeys or equivalent WebAuthn/FIDO2 flows for administrators, finance users, and any account that can create downstream privileges. Keep password and OTP fallback paths under review because AiTM kits target the weakest remaining path.
• Bind sessions to device and risk context Require device compliance, continuous access evaluation, and token binding where available so a stolen cookie cannot be replayed on another endpoint without triggering revocation.
• Alert on post-login persistence moves Create high-priority detections for new MFA device registration, inbox forwarding rules, user agent changes mid-session, and access to admin consoles from accounts that have never used them before.
• Harden email and link analysis before the proxy stage Inspect destination chains, not just sender reputation, and flag authentication-themed lures that route through trusted file-sharing services before reaching an SSO page.

Key takeaways

• AiTM attacks turn MFA into a relay target, so a successful second factor no longer guarantees session safety.
• The evidence is already at scale, with more than 100 documented campaigns and 84% of compromised accounts already protected by MFA.
• The control that changes outcomes is phishing-resistant authentication combined with session binding and post-login behavioural detection.

Key terms

• Adversary-in-the-Middle Attack: A phishing technique where an attacker proxies a real login session between the user and the identity provider. The victim completes a genuine authentication flow, but the attacker captures the resulting authenticated session and reuses it elsewhere.
• Session Cookie: A token that tells a service the user has already been authenticated. In AiTM scenarios, the cookie is the primary prize because it can be replayed from another browser to inherit the victim's session without re-entering MFA.
• Phishing-Resistant Authentication: An authentication method that cannot be easily relayed by a proxy, typically because the proof is origin-bound and cryptographically tied to the registered site. For human identities, this changes the trust model from shared secret verification to device-anchored proof of possession.
• Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.

Deepen your knowledge

Adversary-in-the-middle attacks, session hijack risk, and phishing-resistant authentication are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still treats MFA success as the end of the trust decision, it is worth exploring.

This post draws on content published by WorkOS: Adversary-in-the-middle attacks and why MFA can be bypassed. Read the original.