TL;DR: Adversary-in-the-middle attacks relay a real login session through an attacker-controlled proxy, letting victims complete MFA and hand over valid session cookies anyway, according to WorkOS, with the Canadian Centre for Cyber Security documenting over 100 campaigns and Obsidian Security finding 84% of compromised accounts already had MFA enabled. MFA only protects if the authentication ceremony itself cannot be proxied.
NHIMG editorial — based on content published by WorkOS: Adversary-in-the-middle attacks and why MFA can be bypassed
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
WorkOS's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step anatomy of AiTM phishing infrastructure, including the reverse proxy relay and session-cookie capture flow.
- Detection patterns for impossible travel, mid-session user-agent changes, and post-login MFA device enrollment.
- Mitigation guidance for passkeys, conditional access, and token binding across common enterprise identity stacks.
- Examples of phishing infrastructure indicators such as new domains, wildcard certificates, and email lure patterns.
👉 Read WorkOS's analysis of adversary-in-the-middle attacks and MFA bypass →
Adversary-in-the-middle attacks: are your MFA controls keeping up?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Adversary-in-the-middle attacks expose MFA’s weakest assumption