Phishing that beats MFA: adversary-in-the-middle for defenders
How a relay phishing page captures a one-time code and the session that follows, what ATT&CK, CISA and NIST say, and the controls that hold against it.
Multi-factor authentication stops the attack it was built for: a stolen password on its own no longer opens the account. It does not stop a phishing page that sits between the user and the real login and relays everything, including the one-time code, in real time. This article explains that class of attack at the level a defender needs to recognise it, names what the references say, and lays out the two controls that actually hold: a factor bound to the real origin, and a session bound to the device that earned it. It is written for defenders; it contains no kit, no configuration for building a relay, and no evasion.
The mechanism
A classic phishing page is a static copy of a login form. It collects a password and shows an error, and if the account has MFA the attacker is stuck, because they do not have the second factor. The relay variant removes that wall. Instead of a static copy, the attacker's server acts as a reverse proxy: it forwards the victim's inputs to the real site and forwards the real site's responses back to the victim, in real time. The victim sees the genuine site's pages, because they are the genuine site's pages, passed through. When the real site asks for a one-time code, the victim supplies it, the relay forwards it, and the real site accepts it. At that moment the real site issues a session cookie, and the relay is holding it.
MITRE ATT&CK describes the position in T1557, Adversary-in-the-Middle: adversaries "position themselves between networked devices" to enable follow-on actions including "interception of authentication tokens and session cookies". What the attacker walks away with is described in T1539, Steal Web Session Cookie: cookies that "can bypass multi-factor authentication protocols", because the authentication already happened and the cookie is proof of it. The one-time code was consumed in the exchange and is now worthless; the cookie is the prize.
The reason this defeats most MFA is structural, not a matter of user carelessness. Any factor the user reads and types, a code from an app, an SMS code, a push they approve, can be relayed, because it is a value that travels over a channel the attacker controls. NIST SP 800-63B says this directly in Section 3.2.5: "authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant."
Why one class of factor survives
NIST defines phishing resistance in Section 3.2.5 as "the ability of the authentication protocol to prevent the disclosure of authentication secrets ... to an impostor verifier", achieved by channel binding or verifier name binding. FIDO2 and WebAuthn provide verifier name binding: the credential is scoped to the real site's origin, and the browser will only use it on that origin. When the victim lands on the relay's look-alike domain, the browser looks for a credential for that domain, finds none for the real site, and the ceremony cannot complete. There is no code to relay, because nothing readable is produced; the signature is over the origin the browser actually connected to, and that origin is the attacker's, so the real site rejects it.
CISA's guidance names the same conclusion. Its phishing-resistant MFA material calls FIDO/WebAuthn and PKI-based methods the "gold standard" and states that "the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication". Everything else, including number matching, is ranked lower precisely because a relay can carry the human-entered value. Number matching still stops push bombing, which is a different attack covered elsewhere on this site; it does not stop a real-time relay.
The second control: bind the session
Phishing-resistant login closes the front door, and it should be the priority. But defence in depth assumes some sessions will still be stolen, by relay where a weaker factor is in use, or by malware after a legitimate login (the stealer-log article on this site covers that path). ATT&CK's mitigations for T1539 are about limiting what a stolen cookie is worth:
- M1032, hardware-backed factors and Conditional Access that restrict logins to enrolled or authorised devices, so a cookie replayed from an unrecognised device is challenged again.
- M1054, software configuration that minimises cookie lifetime and enables regular deletion, shrinking the window a stolen cookie is valid and increasing the chance a replay coincides with a re-authentication.
- M1047, audit, monitoring authentication and flagging impossible-travel and anomalous use of a session from a new location or user agent without re-authentication.
Concretely, on your own application: set short idle and absolute session lifetimes, regenerate the session identifier on privilege change, and bind sessions to signals that a relay cannot cheaply reproduce, such as requiring a fresh phishing-resistant re-authentication for sensitive actions rather than trusting the cookie alone. The session-token article on this site covers the cookie flags in full.
Detection
A relay attack leaves traces on the real site, because the login it drives is real. The signals ATT&CK associates with T1557 and T1539 translate to these queries against your own logs:
-- a session used from a second, distant location shortly after login (possible stolen cookie)
SELECT session_id, user_id,
array_agg(DISTINCT source_ip) AS ips,
array_agg(DISTINCT country) AS countries,
min(event_time) AS first_seen, max(event_time) AS last_seen
FROM session_events
WHERE event_time > now() - interval '24 hours'
GROUP BY session_id, user_id
HAVING COUNT(DISTINCT country) > 1; -- one session, two countries
Also watch for logins where the reported client hints (user agent, language) shift mid-session, for a spike of successful logins referred from domains that resemble yours, and for authentications that complete from data-centre IP ranges rather than consumer networks. None of these is proof on its own; together they prioritise which sessions to challenge or revoke.
Detection and fix
- Move phishing-resistant MFA (FIDO2 security keys or platform passkeys) to the front of the queue for every account that can take it, and make it mandatory for administrators, finance, and anyone with access to customer data. This is the only control that stops the relay itself.
- For accounts still on app or SMS codes, treat those factors as relay-vulnerable and compensate: short sessions, device binding, and re-authentication for sensitive actions.
- Shorten session lifetimes, regenerate identifiers on privilege change, and require a fresh strong authentication for high-impact operations rather than trusting a long-lived cookie.
- Alert on one session used from two countries, on mid-session client changes, and on logins from hosting ranges, and give support a one-click session revoke.
- Teach users the single durable habit: reach the site through a bookmark or typed address, not a link in a message, and register a security key so the browser refuses the wrong origin for them.
The limitation to state plainly: user training reduces relay phishing but does not end it, because the relay shows the user the genuine site and asks for nothing unusual. The durable fix is to remove the readable factor from the critical path, which is what phishing-resistant authentication does, and to make the session that follows worth as little as possible if it is ever taken.