Phishing-resistant MFA, on the wire

Most "MFA" is still replayable. This lab models the four failure modes that matter in the field: real-time adversary-in-the-middle proxies, helpdesk-led re-enrollment, post-auth cookie theft, and soft fallback abuse. Change the factor and the recovery/session controls, then watch the attack outcome rerun live.

How this works. Pick a factor and an attack path, then change the recovery and session controls. The lab scores whether the attacker is blocked, forced into a degraded path, or fully compromises the account/session.

Attack replay

Evilginx / EvilProxy style kits relay the exact login ceremony to the real site and steal whatever the victim can replay.

References: Microsoft, 'EvilProxy phishing as a service' · NIST SP 800-63B §5.1 phishing resistance

Live controls

Primary factor

Origin-bound public-key auth. The phishing site gets a signature for the wrong origin.

allow fallback to a weaker factor when the primary rail failshelpdesk can reset or re-enroll the factor with weak identity proofingprivileged session uses sender-constrained tokens / DPoPpush approvals require number matching / user confirmation context

Outcome

Blocked

Primary factor — FIDO2 / WebAuthn passkey
Attacker relays sign-in in real time — The reverse proxy forwards credentials, second factor, and any session cookie the real site issues.
Authenticator signs origin — The phishing origin is wrong, so the WebAuthn assertion does not validate at the real relying party.

Findings (1)

infoMFA02 — Origin binding stops real-time relay

This is the property NIST means by phishing resistance: the authenticator signs the origin the browser is actually on.

fix: Keep passkey-only for high-value roles and block weaker fallback factors.