Why does two factor authentication fail against modern adversary in the middle phishing campaigns?

Two factor authentication fails when the attacker relays the victim’s login flow through a reverse proxy and captures both the password and the second factor before the legitimate site sees them. The user still reaches the real service, so the session appears valid. The core weakness is that the attacker steals the authenticated session, not just the password.

Why phishing kits can defeat code-based second factors

Two factor authentication is strongest when the second factor is verified by the service in a way the attacker cannot relay in real time. Modern adversary-in-the-middle phishing changes that assumption. The victim is not simply tricked into handing over a password; they are placed inside a live relay that forwards the login flow, so the attacker can collect both factors and then reuse the resulting authenticated session. That is why the weakness is less about the second factor itself and more about how the login session is established and held.

For practitioners, the important distinction is between authentication strength and session integrity. A code sent by SMS, generated by an app, or even approved in a push flow can still be relayed if the attacker is sitting in the middle of the transaction. That is why phishing-resistant methods matter more than adding another prompt. Modern guidance from CISA on current threat activity shows how often credential theft is paired with session abuse, not just password guessing, and that pattern is visible across many compromise investigations. In practice, many security teams discover the failure only after the attacker has already converted a valid login into an active session.

How the relay attack works from first click to stolen session

The attack usually starts with a convincing phishing page that mirrors the target service closely enough to keep the user engaged. When the victim enters credentials, the page forwards them to the real site rather than storing them locally. The real site then asks for the second factor, and the attacker relays that challenge back to the victim in real time. Once the victim completes the challenge, the real service issues a valid session cookie or token to the attacker-controlled relay, which can then be replayed or used immediately.

This model defeats many traditional assumptions about second factors because the user is still interacting with the genuine service through the proxy. It is also why login telemetry can look deceptively normal: correct password, correct factor, valid session, and no obvious brute-force pattern. The attacker is exploiting trust in the browser path and in the timing of the authentication exchange.

The second factor is observed and reused before it expires.
The session becomes the real prize, not the password alone.
Risk rises sharply when the service does not bind the session to a phishing-resistant authenticator or device context.

Controls that only add more codes or more confirmations do not solve the relay problem; the guidance breaks down where the factor can be proxied in real time and the session token can be stolen after authentication.

Where conventional two factor still helps, and where it does not

Tighter authentication usually increases user friction, so organisations must balance convenience against the attack path they are actually trying to stop. The nuance is that not all second factors fail equally. Time-based one-time passwords and push approvals can still be useful against password spraying and basic credential theft, but they are weaker against interactive relay attacks. Phishing-resistant authenticators such as FIDO2-based flows materially change the problem because they bind the authentication ceremony to the origin and reduce the value of a middleman relay.

There is also a governance distinction that teams sometimes miss. A broad mandate for “MFA everywhere” does not guarantee phishing resistance if the implementation still allows relayable factors on high-value accounts. That is why practitioners should treat admin access, finance systems, email, and identity control planes differently from low-risk applications. The debate is not whether second factors matter at all, but whether the chosen method can survive active interception.

Official control guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates authentication, session protection, and privileged access expectations rather than treating them as one control. The same distinction appears in identity assurance guidance from NIST when proofing and authentication are evaluated at different trust levels.

Risk and Threat Considerations

The material risk is session theft after successful interactive interception, which turns a seemingly valid login into unauthorized access. This is especially dangerous for remote work, SaaS, and identity provider sessions because the attacker does not need to crack the factor; they only need to relay it once and preserve the resulting session.

Failure mechanism: The attacker terminates the victim’s trust boundary by proxying the login flow, captures the password and second factor in real time, and reuses the legitimate session artefact before it expires or is bound to a stronger device check.

Impact: Account takeover can occur without repeated login prompts, alerts may be sparse, and downstream actions such as mailbox access, token issuance, privilege escalation, or persistence through session refresh become possible.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1557.003 — Adversary-in-the-Middle	The question centers on real-time relay phishing that intercepts authentication.
Recommendation — Map login interception to T1557.003 and hunt for proxy-based credential relay patterns.
NIST CSF 2.0	PR.AA-1 — Identity and Access Management	The topic concerns authentication strength and session trust for account access.
	PR.AA-2 — Identities and Credentials	Session theft succeeds when credentials or session artefacts are accepted after relay.
Recommendation — Use PR.AA-1 to require stronger authenticator choices for high-value access paths. Apply PR.AA-2 to reduce reliance on relayable factors and tighten credential handling.
CIS Controls v8	6.3 — Require MFA for Externally Exposed Applications	Externally reachable login surfaces are the common entry point for phishing relay.
Recommendation — Enforce 6.3 on internet-facing authentication paths and privileged accounts first.
NIST SP 800-63	AAL2 — Authentication Assurance Level 2	The question is about whether common second factors are sufficient against interception.
Recommendation — Assess whether AAL2 methods are appropriate or whether phishing-resistant options are needed.

Practitioner Guidance

What to prioritise: Treat phishing-resistant authentication as the default for high-value users and control planes, then step down to lower-assurance methods only where the business impact is genuinely limited. If a login flow can be relayed in a browser, assume it can be abused by an active intermediary.

What to verify: Check whether your strongest accounts are still protected by relayable factors, whether sessions are constrained by device or origin context, and whether your detection stack can distinguish a normal login from a valid session that began on a phishing proxy. The most important validation is not whether MFA is enabled, but whether the chosen method actually resists real-time interception.

Practitioner takeaway: The security question is no longer “did the user complete MFA?” but “did the service receive proof that cannot be proxied, replayed, or separated from the true client context?”