AiTM Phishing Proxies: Detecting Adversary-in-the-Middle Sessions

Modern phishing kits do not just steal passwords — they proxy the entire login in real time, relay the MFA prompt to the genuine victim, and pocket the session token your server issues at the end. The victim authenticated correctly, and the attacker walked away with the keys.

Adversary-in-the-middle attacks are the reason MFA alone no longer guarantees a safe login. Defeating them means spotting the proxy relaying the session and the token replay that follows, neither of which the phishing kit can hide from a server-side device check.

Why MFA does not save you here

In an AiTM attack, the second factor is satisfied by the real user in real time. The victim sees a convincing clone, enters their password and their OTP or approves their push, and every one of those steps is genuine. Your server issues a session token to what it believes is a completed, MFA-verified login.

The catch is where that login came from. The victim never touched your server directly — the reverse proxy did. And when the attacker later replays the captured token, it arrives from yet another device. Two seams, both visible to device and network intelligence.

Seam one: the proxy’s own infrastructure

Because an AiTM kit is a reverse proxy hosted on attacker infrastructure, the connection reaching your server carries that infrastructure’s characteristics, not the victim’s:

• A datacenter or hosting-provider ASN where you expect a residential network
• TLS and header characteristics that cluster differently from a real browser on a real device
• A geography that matches the phishing host, not the customer’s normal region
• A new device identity with no history on the account

Prynt evaluates network reputation and device signals server-side. When a login that is otherwise MFA-perfect arrives over a hosting ASN with a device you have never seen, the proxy is showing through. Explore how network origin factors into risk on the network page.

Seam two: the token replay

AiTM attackers usually harvest the token first and use it later, from their own machine. That replay is a second, independent chance to catch them — and it looks exactly like session-cookie theft:

1. Bind each session to a device identity at the moment it is issued.
2. On sensitive requests, re-resolve the device and compare it to the bound identity.
3. A mismatch — session issued to the proxy-relayed login, now used from the attacker’s device — is your signal.
4. Force re-authentication with a phishing-resistant factor rather than trusting the token.

The factor that actually resists AiTM

Detection buys you time; the durable fix is a factor the proxy cannot relay. Passkeys and FIDO2 hardware keys bind the authentication to your real origin, so a login served from a phishing domain simply fails the cryptographic check. Push and OTP do not have that property, which is why AiTM kits target them.

Use device scoring to decide when to demand the stronger factor. A login from a trusted device on a residential network proceeds normally; a login carrying proxy fingerprints gets pushed to a passkey challenge that the AiTM kit cannot satisfy.

Grade the response with reason codes

When you step up or block, record why: hosting ASN, unrecognized device, token replayed from a second machine. Those reason codes let your team confirm the AiTM pattern and tune thresholds without blinding themselves to legitimate travel or new hardware.

Close both seams

AiTM defeats MFA by relaying it, but it cannot relay away the network it runs on or the device that replays the stolen token. Scoring both, server-side, turns an invisible proxy attack into a login you can challenge or decline.

Prynt is free to start. See how device and network origin shape a risk verdict in the playground, then wire the checks into your login and sensitive-action paths.