Topic starter
06/06/2026 11:06 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Adversary-in-the-middle attacks: The threat that makes your MFA useless”.
Key questions
Q: What breaks when MFA can be proxied through a reverse proxy?
A: What breaks is the assumption that completing MFA proves the session is trustworthy.
Q: Why do phishing-resistant factors reduce AiTM risk more than OTP codes?
A: Phishing-resistant factors such as passkeys are origin-bound, so the authentication exchange cannot be transparently relayed to an attacker domain in the same way as OTP or push-based methods.
Q: What are the signs that an account has been taken over through AiTM?
A: Look for new MFA device registration, unexpected inbox forwarding rules, unusual cloud storage access, and session activity that changes user agents or locations after successful sign-in.
Practitioner guidance
- Deploy phishing-resistant authentication Prioritise passkeys and other WebAuthn-based methods for user populations that routinely handle sensitive data or privileged workflows.
- Bind sessions to the originating device Use device-aware controls, token binding where available, and conditional access checks that re-evaluate device posture during the session.
- Watch for post-authentication persistence signals Alert on new MFA device registration, inbox forwarding rules, unusual user-agent changes, and access to cloud resources the account has never touched.
Bottom line: AiTM attacks succeed because they proxy the real authentication ceremony and capture the resulting session, which makes MFA completion an insufficient security endpoint.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 11:43 am
MFA is not the control boundary that many programmes still assume it is: AiTM attacks prove that a completed second-factor challenge does not guarantee a trustworthy session. The real boundary is whether the authentication ceremony can be proxied and the resulting session reused elsewhere. For human IAM programmes, that means the security model must shift from login approval to session integrity and replay resistance.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: How should teams respond when a valid session is reused from an unexpected location?
A: Treat it as a session integrity incident, not a simple password event. Revoke the session, review recent MFA device changes, inspect mail rules and cloud access, and check whether the account has started privileged or finance-related activity. The objective is to stop persistence before the attacker completes lateral abuse from the stolen session.
👉 Read our full editorial: Adversary-in-the-middle attacks expose MFA’s weakest assumption