Modern adversary tooling executes what security researchers call a real-time phishing relay, sometimes referred to as an adversary-in-the-middle (AiTM) attack. The mechanics are precise.
An adversary builds a reverse proxy that sits between the victim and the legitimate service. When the victim enters credentials on the spoofed page, the proxy forwards those credentials to the real site in real time.
The real site responds with an MFA challenge. The proxy forwards that challenge to the victim. The victim responds — because the page looks legitimate and the MFA prompt is real. The proxy forwards the response. The adversary receives an authenticated session.
Push notification MFA, SMS one-time codes, and TOTP authenticator apps are all vulnerable to this relay. They authenticate the exchange of a code. They do not verify that the individual completing the exchange is the authorized account holder. They cannot distinguish a direct session from a proxied one. //
The deeper problem is that the authentication architecture most organizations have deployed was not designed to answer the question that actually matters in a post-breach environment: was the authorized individual physically present and biometrically verified at the moment of authentication?
Push notifications do not answer this question. SMS codes do not answer this question. TOTP does not answer this question. USB hardware tokens answer a related but different question — they prove the registered device was present, not the authorized person. //
FIDO2/WebAuthn gets cited frequently in this conversation, and it is a meaningful step forward — but it is not sufficient on its own. Standard passkey implementations bind the credential to a device or cloud account.
Cloud-synced passkeys inherit the vulnerabilities of the cloud account: SIM swap attacks against the recovery phone number, account takeover via credential phishing, recovery flow exploitation. Device-bound passkeys prove device possession. They do not prove human presence.
Phishing-resistant authentication that closes the relay attack vector requires three properties simultaneously:
- Cryptographic origin binding: the authentication credential is mathematically tied to the exact origin domain. A spoofed site cannot produce a valid signature because the domain does not match. The attack fails before any credential is transmitted.
- Hardware-bound private keys that never leave secure hardware: the signing key cannot be exported, copied, or exfiltrated. Compromise of the endpoint does not compromise the credential.
- Live biometric verification of the authorized individual: not a stored biometric template that can be replayed, but a real-time match that confirms the authorized person is physically present at the moment of authentication.
When all three properties are present, a relay attack has no viable path. The adversary cannot produce a valid cryptographic signature from a spoofed site. They cannot relay a session because the cryptographic binding fails the moment the origin changes.
They cannot use a stolen device because the biometric verification fails without the authorized individual. They cannot social-engineer an approval because there is no approval prompt — the authentication either completes with a live biometric match at the registered hardware, or it does not complete.
