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

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.

Why This Matters for Security Teams

Adversary-in-the-middle attacks succeed because MFA authenticates the user, not the browser session after the fact. If the session token is issued to a compromised, proxied, or cloned context, the attacker can inherit the authenticated state without ever knowing the factor itself. That is why session binding, token lifetime, and device or context checks matter as much as the login prompt. The pattern shows up repeatedly in identity breaches, including cases tracked in the The 52 NHI breaches Report, where valid credentials or tokens were reused after initial compromise.

From an operational standpoint, this is not just a human identity problem. The same weakness applies to secrets, service tokens, and automated workflows when trust is concentrated in a bearer token. Current guidance suggests that zero trust controls, strong session governance, and continuous verification must extend beyond the login event, as described in the Ultimate Guide to NHIs — Key Challenges and Risks and CISA cyber threat advisories. In practice, many security teams encounter AiTM only after a legitimate session has already been abused rather than during the original MFA challenge.

How It Works in Practice

The attacker stands between the user and the real identity provider, often using a convincing phishing page or reverse proxy. The victim enters credentials and completes MFA against the genuine service, so the login succeeds normally. The proxy then captures the resulting session cookie, refresh token, or similar bearer artifact and forwards it to the attacker, who can replay it from another system. This is why MFA alone does not stop the attack: the control was satisfied, but the post-authentication token was not protected by stronger session assurances.

Effective mitigation is layered. Security teams should combine phishing-resistant MFA, short session lifetimes, conditional access, and reauthentication for sensitive actions. They should also look at device binding, token protection, and anomaly detection for impossible travel, new user agents, or suspicious IP transitions. For identity governance, Top 10 NHI Issues is useful because the same bearer-token weakness appears in API keys and automation secrets. On the standards side, the MITRE ATLAS adversarial AI threat matrix is relevant where phishing, proxying, and automated abuse are chained with AI-assisted tradecraft, while Anthropic — first AI-orchestrated cyber espionage campaign report shows how attackers can scale social engineering and session theft.

• Prefer phishing-resistant factors such as FIDO2/WebAuthn where possible.
• Bind sessions to device, network, or application context when the platform supports it.
• Reduce token lifetime and revoke refresh tokens quickly after risk signals.
• Monitor for replay patterns, not just failed logins.

These controls tend to break down in legacy single sign-on environments because long-lived cookies, weak device signals, and shared browsers make session replay difficult to distinguish from normal use.

Common Variations and Edge Cases

Tighter session controls often increase user friction and operational overhead, so organisations must balance theft resistance against support burden and application compatibility. That tradeoff is especially visible in older VPNs, embedded web views, and partner portals where modern token binding or continuous access evaluation is not available. Best practice is evolving, but there is no universal standard for this yet, which is why many teams use risk-based step-up checks rather than forcing every session through the same level of scrutiny.

A second edge case is token theft from endpoints rather than proxy phishing. If malware or a compromised browser extension can extract cookies from the local profile, MFA has already completed and the attacker skips the login path entirely. The Microsoft Midnight Blizzard breach is a reminder that identity compromise often becomes a persistence problem, not a password problem. In NHI-heavy environments, the same pattern applies to API keys, service account tokens, and CI/CD secrets, so organisations should revisit Ultimate Guide to NHIs — Why NHI Security Matters Now alongside session policy reviews. The practical lesson is that MFA reduces credential stuffing, but it does not by itself prevent bearer-token replay or post-authentication takeover.

Related resources from NHI Mgmt Group

• Why do man-in-the-middle attacks still succeed when HTTPS is enabled?
• How can organizations counter AI-driven cyber attacks?
• Why do still-valid secrets matter after public disclosure?
• Why do phishing-resistant methods still fail against man-in-the-middle attacks?