Adversary-in-the-Middle Phishing: Why OTP Codes Stopped Being Enough

For a decade the security advice was simple: turn on two-factor authentication and most phishing stops working. That advice is now dangerously out of date. A class of attack called adversary-in-the-middle has industrialized the theft of one-time codes, and it does it without malware, without cracking anything, and without the victim making an obvious mistake. The attacker simply stands between the victim and the real website, relaying everything in real time, including the code the victim correctly enters. In payments this matters twice over: AiTM steals the OTPs that guard banking logins and, increasingly, the verification codes that gate mobile wallet enrollment and 3-D Secure challenges.

Quick answer: Adversary-in-the-middle (AiTM) phishing uses a reverse-proxy server that sits between the victim and the genuine site. The victim enters credentials and the one-time code into a page that looks real; the proxy relays them to the real site instantly and captures the resulting session cookie, logging the attacker in even though MFA succeeded. Because SMS, app, and email codes are all relayable, the durable defense is phishing-resistant authentication (FIDO passkeys and security keys) that cryptographically binds the login to the real site’s origin.

How does an AiTM attack actually work?

Older phishing captured a static password on a fake page; the OTP defeated it because the stolen password alone was useless. AiTM closes that gap by proxying the whole session live:

1. The victim clicks a link to a convincing fake domain. Behind it runs a reverse proxy, not a static clone.
2. The proxy fetches the real login page and relays it, so the victim sees the genuine site’s actual content.
3. The victim enters username and password; the proxy passes them to the real site in real time.
4. The real site demands the one-time code; the victim receives a genuine code and enters it; the proxy relays it within its validity window. From the real site’s view, a correct login with correct MFA just occurred.
5. The real site issues a session cookie; the proxy captures it. The attacker imports that cookie and is now inside the authenticated session, MFA already satisfied, often able to add their own authenticator for persistence.

The victim typically sees a successful login and suspects nothing. What was stolen is not the password or even the code as such; it is the authenticated session itself. Ready-made phishing-as-a-service kits have turned this into a point-and-click product, which is why it moved from nation-state tradecraft to commodity fraud within a couple of years.

Why doesn’t MFA stop it?

Because the common MFA factors are all shared secrets that can be relayed. An SMS code, an authenticator app’s six digits, an emailed link, even a push approval the user taps: each is something the victim can transmit, which means something the proxy can transmit on their behalf. The factor did its job (it proved the user had it) but it proved it to the attacker’s proxy, not to the user directly. This is the mechanism behind the push-fatigue and OTP-relay fraud our MFA requirements guide flags as the reason SMS sits at the bottom of the assurance ladder, and it is the precise technique behind the real-time code phishing that drives the wallet provisioning fraud covered this month.

How is AiTM used specifically against payments?

• Banking session takeover: a relayed login yields an authenticated banking session, from which attackers move money, harvest stored card data, or enroll their own access, the account-compromise outcome detailed in our account takeover guide.
• Wallet enrollment: the verification code gating a card’s addition to a wallet is just another relayable OTP; AiTM harvests it to provision stolen cards onto attacker devices.
• 3-D Secure challenge phishing: a fake checkout triggers a real 3DS challenge, relays the victim’s response, and completes a fraudulent purchase authenticated as the cardholder, blunting one of the defenses our 3DS 2 article relies on.
• Credential harvesting at scale: proxied sessions feed the enriched-credential supply behind broad fraud, and sit alongside the SIM-swap playbook for defeating phone-based factors.

What actually resists AiTM?

The defense has to break the relay, not strengthen the secret, because any secret can be relayed. Ranked by durability:

1. Phishing-resistant authentication (FIDO2 passkeys, hardware security keys). These bind the authentication cryptographically to the real site’s origin: a passkey registered for the genuine domain simply will not authenticate to the proxy’s domain, so there is nothing for the attacker to relay. This is the structural fix, and the reason our passkey article treats origin binding as the headline property rather than the passwordless convenience.
2. Token-binding and device-bound sessions: tying the session cookie to the device that authenticated so a stolen cookie fails elsewhere; strong but less universally deployed.
3. Risk and behavior signals: impossible travel, new-device heuristics, and short session lifetimes can catch imported-cookie use after the fact, the detection layer in modern fraud models. Useful, but reactive.
4. User vigilance: checking the domain helps against sloppy kits but fails against good ones on lookalike domains; treat awareness as a supplement, never the control. The honest message to users is simpler: possessing a passkey means there is no code to be tricked out of you.

For payment organizations, the priority order is clear: move the highest-value gates (banking login, wallet enrollment, administrative access to the cardholder data environment) to phishing-resistant methods first, and treat every remaining OTP as relayable until it is replaced.

Frequently asked questions

Is AiTM the same as a man-in-the-middle attack?

It is a specific, application-layer form of one: rather than intercepting network traffic, the attacker runs a reverse proxy that victims connect to willingly, relaying the full authentication and stealing the session. The goal is the session cookie, not the raw packets.

Does app-based MFA protect against AiTM?

Authenticator codes and simple push approvals are relayable and so offer limited protection. Number-matching push with context, and especially FIDO-based methods, are far stronger; only origin-bound cryptographic authentication truly breaks the relay.

Can passkeys really stop it completely?

Against the credential-relay mechanism, yes: a passkey will not sign a challenge for the wrong origin, so the proxy gets nothing usable. Residual risk shifts to device compromise and account-recovery paths, which then become the places to harden.

How would a victim know they were hit?

Often they would not at the moment; the login looks successful. Later signs include unexpected new authenticators or devices on the account, unfamiliar sessions, or fraudulent transactions. Enrollment and login alerts are the fastest warning.

What is the single highest-impact step for a payment business?

Move administrative and high-value customer authentication to phishing-resistant factors, starting with access to systems that touch card data and with wallet-enrollment verification. Everything else is mitigation around an OTP that can still be relayed.

AiTM ended the era when turning on two-factor was the finish line. The code was never the asset; the authenticated session was, and any secret the user can type is a secret the proxy can forward. The fix is not a better secret but an authentication that knows which website it is talking to.