Topic starter
27/08/2026 8:35 am
TL;DR: Adversary in the Middle attacks can bypass MFA by intercepting credentials and session approval in real time, as Unixi’s analysis of Microsoft-reported incidents shows. The lesson is that MFA cannot be treated as a standalone control when phishing pages can proxy the login flow and capture full account access.
Editorial analysis by NHI Mgmt Group, based on content published by Unixi: “MFA Cannot Stand Alone Series – AiTM Attacks and How Unixi Deals With Them”.
By the numbers:
- Storm-1167 managed to send more than 16,000 attacks before detection, according to Unixi.
Key questions
Q: What breaks when MFA is protected by an Adversary in the Middle attack?
A: The factor still works, but the trust chain does not.
Q: Why do phishing kits with reverse-proxy flows still bypass MFA?
A: Because the attacker is not trying to defeat MFA in theory.
Q: How can security teams reduce the risk of session theft after MFA approval?
A: Reduce the value of a successful login by validating where credentials are entered, binding sessions to trusted device context, and limiting what the account can do immediately after authentication.
Practitioner guidance
- Tighten credential submission controls Block password entry on untrusted destinations and verify whether employees are sending credentials only to approved login paths.
- Add relay-resistant authentication signals Use controls that make it harder for a proxied session to look legitimate after MFA approval, including device and browser context checks tied to the login flow.
- Review post-login privilege impact Limit what a newly authenticated account can do, especially email sending and security-policy changes, so a stolen session does not immediately become an account takeover event.
Bottom line: AiTM attacks work because the attacker can relay a legitimate login and MFA approval in real time, not because the factor itself is absent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
27/08/2026 8:35 am
MFA completion is not the same as trusted authentication: AiTM attacks succeed because the user still performs the expected second-factor action inside an untrusted relay. That means the assurance boundary is the login path, not the factor prompt. The implication is that enterprise identity teams must stop treating factor success as proof of context integrity.
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: When should organisations treat MFA as necessary but not sufficient?
A: Organisations should treat MFA as necessary but not sufficient whenever users can still recover access through weaker routes, reuse credentials or operate on unmanaged devices. MFA blocks many common attacks, but it does not fix bad exception handling or weak access governance. The right standard is whether every access path is held to the same assurance level.
👉 Read our full editorial: AiTM attacks expose the limits of MFA in real enterprise logins