What breaks when MFA can be proxied through a reverse proxy?

Why Proxied MFA Stops Proving Session Trust

When MFA is relayed through a reverse proxy, the login ceremony can still complete while the attacker sits in the middle and captures the authenticated session. That means the security boundary shifts from “did the user pass MFA” to “is this session bound to the right device, origin, and trust context?” The practical failure is not factor theft alone, but trust in a session that can be replayed elsewhere.

In a proxy-mediated flow, the attacker does not need to defeat the second factor after the fact. They only need to forward it once, then keep the resulting session artifact. That is why phishing-resistant authentication, session binding, and replay detection matter more than a checkbox view of MFA success.

How an AiTM Proxy Turns Authentication Into Session Theft

An adversary-in-the-middle proxy preserves the appearance of a normal sign-in while silently relaying requests between the victim and the real identity provider. The victim sees a legitimate page, enters credentials, completes MFA, and receives no obvious warning. The proxy then extracts the session cookie or equivalent token and can reuse it without repeating the second factor.

This breaks assumptions in systems that treat MFA completion as proof of ongoing trust. It also weakens downstream controls that only inspect authentication state at login, because the attacker is operating with an already-issued session rather than reauthenticating in a way the user can notice.

What Stops Working After the Cookie Is Stolen

Once the session is replayable, the defender loses the protection that MFA was supposed to provide for the rest of the session lifetime. Conditional access may still help if it reevaluates risk during use, but static trust decisions made at login can be bypassed. The weaker the session binding, the easier it is for the captured token to act like a full sign-in.

That is why the real control question is whether the session can be reused outside the original browser, device, or network context. Controls that make token theft harder, shorten token value, or detect abnormal session reuse are more relevant than authentication success alone.

Risk and Threat Considerations

Proxyable MFA creates a high-confidence path for account takeover because the attacker converts a one-time authentication event into a reusable session. The risk is especially material for remote access, admin portals, and high-value SaaS applications where a valid session can expose mail, data, secrets, or privileged actions.

Failure mechanism: The attacker relays the login in real time, captures the issued session token, and reuses it from a separate location or browser context without needing the second factor again.

Impact: Organizations may believe MFA is protecting the account while an attacker is already acting as the user, which can lead to stealthy persistence, data access, privilege abuse, and delayed detection.

Practitioner Guidance

What to verify: Check whether your MFA method is phishing-resistant and whether the resulting session is bound tightly enough to the device or context to make replay difficult. If the answer is no, assume a proxy can turn successful login into successful takeover.

Decision rule: If an application accepts a reusable bearer session with no strong binding, treat that application as vulnerable to AiTM-style replay even when MFA is enforced. Prioritise controls that reduce session reuse value, not just login friction.

What good looks like: The environment should make stolen sessions short-lived, context-sensitive, and anomalous when replayed. A user completing MFA should not be the end of the trust decision when the session itself can later be copied and reused.

Practitioner takeaway: Do not measure MFA effectiveness by successful prompts completed, measure it by whether the resulting session can survive theft and replay.

Related resources from NHI Mgmt Group

• What breaks when a reverse proxy becomes the only access gate?
• What breaks when attackers get a legitimate login through vishing or MFA abuse?
• Why do phishing kits with reverse-proxy flows still bypass MFA?
• How should security teams stop reverse proxy phishing from bypassing MFA?