AiTM attacks: what they are, how they work, and how to stop them

An adversary-in-the-middle (AiTM) attack is a phishing technique where an attacker positions a reverse proxy between the victim and a legitimate login page. The victim interacts with the real site through the proxy, entering credentials and completing MFA checks normally. The proxy captures the resulting session token, giving the attacker authenticated access without needing the password or MFA device.

AiTM is distinct from traditional man-in-the-middle attacks, which intercept network traffic. AiTM operates at the application layer — the victim sees a genuine-looking login flow, completes real authentication, and the proxy captures the session cookie. Because the attack captures a valid session token post-MFA, the access survives password and MFA resets until the token expires or is explicitly revoked.

The user completes MFA on the real identity provider page because the proxy relays the authentication flow in real time. The MFA challenge is satisfied legitimately, and the resulting session token is captured by the attacker's proxy. The attacker doesn't need the MFA device because they capture the session token that MFA is supposed to protect.

There are two implementation approaches. Automated reverse proxies (Evilginx, Tycoon 2FA, Sneaky 2FA) programmatically relay traffic between the victim and the identity provider. Human-operated relay panels (like Doko's Panel) use a live operator who guides the victim through authentication in real time. Both achieve the same outcome — MFA is satisfied and the session token is stolen.

Users with FIDO2-based authentication methods — passkeys and hardware security keys — cannot be phished via AiTM (unless a backup method is configured, in which case it is vulnerable to downgrade attacks), but remain vulnerable to authorization phishing methods like device code phishing (increasingly provided alongside AiTM by phishing kit vendors).

Stopping AiTM requires detection at the phishing page itself — inside the browser — rather than at the delivery channel or network layer. AiTM infrastructure rotates faster than blocklists update, and kits like Evilginx and Tycoon 2FA use bot protection to serve benign content to automated URL scanners while showing the real phishing page only to human visitors.

Email security can reduce the volume of lures that reach users, but it can't analyze the destination page — and roughly one in three AiTM lures now arrive outside email entirely, via search ads, messaging platforms, and social media. Network tools see traffic metadata but can't observe the rendered DOM where AiTM proxy behavior is visible.

Behavioral detection in the browser — targeting AiTM kit behavior at the rendered-page level regardless of domain or delivery channel — is the most effective preventive control. Push provides this detection, analyzing page structure and phishing kit mechanics in real time as the user visits the page.

A tool that operates inside the browser session and detects AiTM phishing behaviorally — analyzing page structure and kit behavior rather than matching against domain blocklists or threat intelligence feeds. Indicator-based detection misses AiTM by design: the infrastructure is new, the domains are short-lived, and bot protection blocks automated scanning.

The standard stack has structural gaps here. EDR sees a normal browser process navigating to a website — it can't observe reverse proxy behavior inside the rendered page. Email security may flag the lure, but can't analyze the destination page, and a growing share of AiTM lures arrive outside email entirely. SWGs rely on URL categorization that doesn't exist for freshly spun-up phishing infrastructure.

Push provides browser-based behavioral detection, identifying AiTM kits by their technique-class signatures at the rendered-page level regardless of the domain or delivery channel.

No. EDR monitors OS-level processes, file system activity, and endpoint behavior — it cannot see what happens inside a browser session. An AiTM attack appears to EDR as a normal browser process navigating to a website. There is no malicious file, no suspicious process execution, and no exploit. The session token theft happens entirely within the browser's rendering engine.

Push complements EDR by operating inside the browser session — the layer that endpoint tools structurally cannot see. Read why EDR misses browser-based attacks.

Not reliably. AiTM phishing infrastructure rotates rapidly, outpacing URL reputation updates. AiTM kits increasingly use bot protection to defeat automated URL scanning — serving benign content to scanners while showing the phishing page to real users. And phishing is increasingly multi-channel, arriving via SMS, QR codes, social media, and search ads rather than email.

Email security reduces the volume of lures that reach users, but it can't analyze the destination page. Push detects the phishing page itself, regardless of how the user arrived at it. The two are complementary.

Partially — the strongest conditional access controls can block AiTM or limit its impact, but configuration gaps frequently create openings.

Compliant Device prevents the AiTM proxy from presenting a TPM-bound Primary Refresh Token, blocking token theft entirely — but requires full MDM enrollment, and BYOD, guest access, Linux devices, and break-glass accounts all force exclusions. Compliant Network (Global Secure Access) forces authentication through a managed cryptographic tunnel the proxy can't replicate, but requires Entra Suite licensing that's out of reach for many organizations. CAE with strict location enforcement rejects replayed tokens from untrusted IPs near-instantly, but requires a specific configuration toggle that's easy to miss. Risk-based CA and Defender XDR disruption add probabilistic detection, but attackers using residential proxies may never trigger heuristics.

Some controls provide limited AiTM protection. Token Protection binds refresh tokens to devices but doesn't cover browser sessions, where AiTM attacks occur. Sign-in frequency reduces the exploitation window but a fast-moving attacker can establish persistence first.

Conditional access constrains the blast radius after compromise. Push detects the phishing page before compromise occurs. The two are complementary — and Push compensates for the BYOD, licensing, and configuration gaps that CA policies frequently have in practice.

Traditional man-in-the-middle (MitM) attacks intercept network traffic between two communicating parties. AiTM operates at the application layer — a reverse proxy sits between the user and a legitimate login page, relaying the authentication flow in real time to capture the session token.

Network MitM is largely mitigated by TLS/HTTPS encryption. AiTM bypasses this because the user interacts with a phishing page that proxies requests to the real site — TLS is established between the user and the proxy, and separately between the proxy and the legitimate site. AiTM is a phishing technique, not a network attack, and requires browser-level detection rather than network encryption.

The major kits include Tycoon 2FA, Evilginx, Sneaky 2FA, FlowerStorm, NakedPages, EvilProxy, Gabagool, and many more. Human-operated relay panels like Doko's Panel enable a different approach where a live operator guides the victim through authentication in real time. These operate as Phishing-as-a-Service platforms with subscription-based access.

The kits vary in approach — some use automated reverse proxies, others provide operator panels for real-time phishing sessions — but the underlying AiTM technique is the same. Pretty much every kit packages sophisticated detection evasion techniques and out-of-the-box functionality for standing up and rotating infrastructure, adapting to different target apps, templating different lures, and so on. Push detects at the technique-class level, targeting behavioral signatures that remain consistent across kits rather than maintaining a finite list of known kits.

Credential phishing captures the user's password via a fake login page. AiTM captures the session token by proxying the real login page — the user completes genuine authentication including MFA, and the attacker receives the authenticated session. Credential phishing gives the attacker a password (which MFA can block); AiTM gives them a post-MFA session token. AiTM is the standard phishing method today, having largely replaced password-only credential harvesting in the wild.

The distinction matters for remediation. After credential phishing, resetting the password revokes access. After AiTM, the stolen session token remains valid until explicitly revoked — a password reset alone doesn't help. The attacker can also register a new MFA method during the session, establishing persistence that survives both resets and revocation.

Evilginx is a commercial red team tool used by both security professionals and criminals. It is an AiTM phishing framework that acts as a reverse proxy between the victim and a legitimate login page. The attacker hosts Evilginx on their own infrastructure, configures it to proxy a target service (Microsoft 365, Google Workspace, Okta), and sends the victim a link. The victim authenticates through the proxy — completing MFA on the real IdP — and Evilginx captures the resulting session token.

Evilginx popularized the AiTM technique and remains widely used, but it's now one of many options. Commercial PhaaS have industrialized the approach. Push detects AiTM attacks at the technique-class level — targeting reverse proxy behavior regardless of whether the kit is Evilginx or a commercial alternative.

Evilginx is purpose-built to evade the standard detection stack, with multiple detection evasion features. Its BotGuard feature fingerprints visitors using JA4 TLS signatures and JavaScript telemetry, serving a decoy site to any automated scanner or safe-link detonation service that tries to inspect the page. URL path and query rewriting strips the patterns that Google Safe Browsing matches against. Multi-tier JavaScript and HTML obfuscation defeat static analysis of the proxied page source, CSS canary token evasion neutralizes the tracking pixels that Microsoft and Google embed to detect proxy-based page loading, and AES-256 encryption of lure URL parameters eliminates what was previously a reliable Evilginx fingerprint for defenders. On the infrastructure side, short-lived URLs, Cloudflare proxying, wildcard TLS certificates, and automated DNS management across multiple providers enable rapid rotation that IOC-based blocklists can't keep pace with.

What Evilginx can't change is what makes it work: the page still has to function as a reverse proxy to the real login page. That proxy behavior — the page structure, network requests to the legitimate identity provider, and credential-interception mechanics — creates behavioral signatures that are detectable at the rendered-page level inside the browser, regardless of what the domain, URL path, or obfuscated source code looks like.

Push detects the AiTM technique itself at this layer, catching Evilginx alongside every other reverse-proxy phishing kit without relying on the indicators Evilginx is specifically engineered to defeat.

There are several distinct techniques, each exploiting a different part of the authentication and session lifecycle:

• AiTM phishing captures post-MFA session tokens by proxying the real login page through a reverse proxy or human-operated relay panel — the user completes genuine authentication and the attacker intercepts the resulting session.
• Device code phishing is an authorization-layer attack that occurs after the user has already authenticated on the real IdP domain. The user logs in legitimately, but the attacker intercepts the resulting authorization token through the OAuth device authorization grant flow.
• Consent phishing and OAuth abuse trick users into granting attacker-controlled apps access to their account through legitimate consent flows, including techniques like ConsentFix that combine clipboard injection with OAuth authorization code grants to achieve MFA bypass without proxying credentials at all.
• Session hijacking replays tokens stolen by infostealers or malicious browser extensions — the attack is entirely post-authentication and invisible to login controls.
• SIM swapping intercepts SMS-based MFA codes by porting the victim's phone number to an attacker-controlled SIM.

“Phishing-resistant” MFA methods like Passkeys defeat the techniques that rely on proxying a login page (AiTM, credential phishing) because the login is cryptographically bound to the legitimate domain. But they don't help against attacks that operate after or outside the authentication event — device code phishing and consent phishing are authorization-layer attacks that succeed after the user has already logged in, and session hijacking replays tokens stolen post-authentication. And where passkeys are configured but legacy methods haven't been removed, downgrade attacks can sidestep them.

Push is designed to detect and block all of these attacks as they happen in the browser through behavioral detections targeting the specific techniques used.

MFA methods that can't be intercepted, replayed, or socially engineered during the login flow. In practice this means FIDO2-based authentication — passkeys and hardware security keys — which bind the credential to the legitimate domain cryptographically. If the user is on a phishing page, the credential won't bind to the fake domain and authentication fails.

Phishing-resistant MFA defeats credential phishing and AiTM attacks that rely on reverse proxies on attacker-controlled domains, but can still be bypassed through:

• Device code phishing and consent phishing are authorization-layer attacks — the user authenticates successfully on the real IdP domain, but the attacker redirects the resulting tokens or tricks the user into granting OAuth access post-login.
• Session hijacking replays tokens stolen post-authentication by infostealers or malicious extensions — the passkey login completed successfully, but the session was stolen afterward.
• MFA downgrade attacks can sidestep passkeys entirely if weaker methods (SMS, TOTP) remain configured on the same account — the attacker forces fallback to the weaker method rather than challenging the passkey.

The common thread is that phishing-resistant MFA protects the authentication event itself, but a growing number of attack techniques operate after or outside that event.

Push detects all of these techniques in the browser, complementing phishing-resistant MFA where it has gaps.

Yes — against attacks that target the login flow. Passkeys use FIDO2 authentication, which cryptographically binds the credential to the legitimate domain. If a user lands on an AiTM reverse proxy on a different domain, the passkey won't authenticate because the domain doesn't match. This makes passkeys highly effective against credential phishing and AiTM.

But passkeys don't protect against techniques that operate after or outside the authentication event:

• Device code phishing — an authorization-layer attack that occurs after the user has already authenticated on the real IdP domain. The passkey works as intended during login, but the attacker redirects the resulting authorization token.
• Consent phishing and OAuth abuse — the user grants access through a legitimate consent flow, no credential entry involved.
• Session hijacking — the attacker replays a token stolen post-authentication by infostealers or malicious extensions.
• MFA downgrade attacks — if weaker methods (SMS, TOTP) remain configured alongside a passkey, the attacker can force fallback to the weaker method and bypass the phishing-resistant credential entirely.

The net effect is that passkeys raise the bar significantly for attacks targeting the login page, but the threat landscape has already shifted toward techniques that don't need to defeat the login at all. Push detects the attack types passkeys can't prevent — device code phishing via in-browser warnings, consent phishing through OAuth monitoring, session hijacking through marker injection, and downgrade through login method visibility.