The standard advice for years was that turning on multi-factor authentication stops phishing. For the simplest phishing it still helps. But a class of toolkits with names like Evilginx, Modlishka, and Muraena turned ordinary credential phishing into something that sails past most second factors. These are adversary-in-the-middle kits, and they have become the default tooling for account takeover at scale.
The reason they work is subtle. Older phishing collected your password on a fake page and replayed it later. A one-time code defeats that, because by the time the attacker logs in, the code has expired. Adversary-in-the-middle phishing removes the delay. It relays your login to the real site live, while you are doing it, so the code is used the instant you produce it.
The Reverse Proxy Trick
A classic phishing page is a static clone: a fake login form that looks like the real thing. An adversary-in-the-middle kit is not a clone at all. It is a reverse proxy that sits between you and the genuine website and passes traffic both ways in real time.
When you load the phishing link, the kit fetches the real login page from the legitimate server and shows it to you. You are looking at the actual site's HTML, relayed through the attacker's server. Everything you type goes to the attacker, who immediately forwards it to the real site. The real site's responses come back through the attacker to you. To your eyes the login is perfect, because it is the real login, just routed through a hostile middle.
- You enter your username and password. The proxy captures both and forwards them to the real server.
- The real server prompts for your second factor. The proxy relays the prompt to you.
- You enter your one-time code or approve the push. The proxy captures and forwards it instantly, before it expires.
- The real server accepts the login and issues a session cookie. The proxy captures that cookie.
The Real Prize Is the Session Cookie
Here is the part people miss. The attacker does not really care about your password or your code after the fact. Both are single-use or about to expire. What the proxy is positioned to steal is the session cookie the server hands back after a successful login.
A session cookie is the token your browser holds that says "this person already authenticated." It is what keeps you logged in so you do not re-enter your password on every page. Once the attacker has captured that cookie, they can import it into their own browser and the server treats them as you, already past every authentication step. Your password and your MFA were both satisfied; the attacker simply walked through the door behind you holding the wristband the bouncer just gave you.
Most MFA proves a human completed a challenge. It does not bind the result to the website you intended to reach. The proxy let you complete the challenge against the real site and then stole the proof of completion. The second factor worked exactly as designed; the design just did not anticipate a live relay.
Why Most Second Factors Fail Here
The common forms of MFA are all phishable through a live relay, because all of them produce something the user hands over that can be forwarded.
| MFA type | Behavior against a live relay |
|---|---|
| SMS codes | Phishable. The code is just a string you type; the proxy forwards it. (Also exposed to SIM swapping separately.) |
| Authenticator app codes (TOTP) | Phishable. A TOTP code is still a string the user enters and the proxy relays. |
| Push approvals | Phishable. You approve a real login you triggered; the proxy captures the resulting session. |
| Security key / passkey (FIDO2) | Resistant. The signature is cryptographically bound to the real site's origin; the proxy's domain does not match, so it fails. |
The One Defense That Closes It
The fix is not "better codes." It is removing the human-relayed secret entirely and binding authentication to the website's origin. That is exactly what FIDO2 and WebAuthn, the technology behind passkeys and hardware security keys, were designed to do.
When you authenticate with a passkey or a hardware key, your device signs a challenge that includes the origin of the site asking for it. The browser enforces that the origin in the signature matches the domain you are actually on. A reverse proxy lives on a different domain than the real site, so the signature it would need to relay is one your authenticator will never produce for it. There is no code to type, no string to forward, and nothing the proxy can capture and reuse. The relay breaks.
Phishing-resistant authentication does not ask the user to be vigilant. It moves the check to the browser, which compares the real origin against the one the credential was bound to. Vigilance is unreliable; origin binding is not.
What to Actually Do
For the accounts that matter most, the priority order is clear:
- Move high-value accounts to passkeys or hardware security keys wherever they are offered. This is the only step that structurally defeats reverse-proxy phishing.
- Treat any MFA based on typed codes or push approvals as better than nothing but bypassable. Keep it where passkeys are not yet available, and do not assume it makes you phish-proof.
- Check the domain, not the page. The page will look perfect because it is the real page. The address bar is where the lie lives. A password manager that only autofills on the correct domain is a quiet, effective guard for the same reason a passkey is: it refuses to act on the wrong origin.
- Be suspicious of unexpected login links, especially urgent ones. The link is the delivery vehicle for the proxy.
The Broader Lesson
Adversary-in-the-middle phishing is a clean example of why security that depends on human alertness eventually loses. The attacker did not break any cryptography. They exploited the fact that a typed code carries no information about where it is going. The durable fixes in security tend to share this shape: bind the secret to its context so it is useless out of context, and remove the step where a human has to notice something is wrong.
That principle runs through how we build Haven, from key handling that keeps your passphrase on your device to an account model designed to minimize the tokens an attacker could relay. No product makes phishing impossible. The goal is to keep narrowing the gap where a momentary lapse turns into a full compromise, and to lean on mechanisms that do not require you to be perfect.