AitM Phishing: How Reverse-Proxy Kits Bypass MFA

Classic phishing steals a password. Adversary-in-the-middle phishing steals the finished login. The victim types their password, approves their MFA prompt, lands in their real mailbox, and never sees anything wrong. Meanwhile the attacker holds a copy of the session that the login produced and can open the same mailbox from their own machine.

This guide explains how the technique works, why most MFA passes straight through it, which controls stop it, and what it looks like in sign-in logs. Our phishing overview covers the wider family of lures, and the two-factor authentication guide compares MFA methods in detail.

How an AitM phishing page works

An AitM page is a reverse proxy. Instead of hosting a fake copy of a login page, it fetches the real one and passes it to the victim, rewriting links so that every request goes back through the attacker's domain.

The sequence, described from the defender's side:

1. The lure. An email, QR code, shared document or search ad sends the victim to a lookalike domain.
2. The relay. The proxy requests the real sign-in page from the identity provider and serves it to the victim. Branding, error messages and tenant logos are all genuine because they come from the genuine site.
3. Credentials and MFA pass through. The victim enters a password, then a code or a push approval. The proxy forwards each step to the real site as it happens.
4. The real site issues a session. Once authentication succeeds, the identity provider sets a session cookie in its response. The response travels back through the proxy, which records the cookie before handing the page to the victim.
5. Replay. The attacker loads the stolen cookie into a browser and is treated as an already-authenticated user.

Microsoft Threat Intelligence summarised the effect in its 2022 analysis: the attacker obtains the session cookie and can "skip the authentication process, even if the target's MFA is enabled." The cookie replay step is the same one covered in our session hijacking guide. AitM is simply one of the most reliable ways to get the cookie.

Why TOTP codes and push approvals do not help

Time-based codes and push prompts prove that a person with the right phone approved this sign-in. They say nothing about which website the person was looking at. The proxy forwards a six-digit code within milliseconds, well inside the 30-second window, and a push approval is tied to the sign-in the proxy started on the victim's behalf. Number matching also passes through, because the number appears on the proxied page in front of the victim.

SMS codes, voice calls, email codes and most push implementations share the same property. Duo's own security guide notes that standard Duo Push "does not protect against phishing proxy attacks." Proofpoint's EvilProxy research put a number on it: at least 35% of the users compromised in that campaign had MFA enabled.

The kits: from open source to subscription

The early tools were open-source research projects. Microsoft named three in its 2022 report, Evilginx2, Modlishka and Muraena, and found the campaign it tracked used Evilginx2. Commercial phishing-as-a-service (PhaaS) operators then packaged the same idea with hosting, templates and a control panel.

A few details from that research are worth knowing because they shape detection:

• Targeting is selective. In Proofpoint's March to June 2023 EvilProxy campaign, about 120,000 emails reached hundreds of organisations, and roughly 39% of the confirmed victims were C-level executives. Traffic from Turkish IP addresses was sent to the legitimate page instead of the proxy.
• Persistence follows within minutes. Proofpoint observed attackers adding their own authenticator app as a new MFA method on compromised accounts. Microsoft saw payment fraud start as little as five minutes after cookie theft, often with inbox rules to hide replies.
• Infrastructure rotates. Sekoia counted more than 1,100 Tycoon 2FA domain names in use between late October 2023 and late February 2024. Mamba 2FA rotated its link domains weekly and, by October 2024, routed its relay servers through commercial proxies from IPRoyal.
• Kits resist analysis. Barracuda's January 2025 analysis of an updated Tycoon 2FA described code obfuscation, blocking of penetration-testing tools, disabled right-click and keystroke monitoring that stops the page if someone opens developer tools.

Scale grew accordingly. Barracuda counted more than a million PhaaS attacks in January and February 2025 and attributed 89% of the January incidents to Tycoon 2FA. Microsoft said that by mid-2025 Tycoon 2FA accounted for about 62% of the phishing attempts it blocked.

What stops AitM

Phishing-resistant MFA: FIDO2 and passkeys

FIDO2 security keys and passkeys defeat the relay at the protocol level. When the browser asks the authenticator to sign a login challenge, it includes the origin it is actually on. A passkey registered for the real identity provider is scoped to that domain, so on a lookalike domain the browser will not offer it, and any signature produced would name the wrong origin and fail verification. The victim cannot hand over something that does not exist on the phishing page. Microsoft's 2022 guidance named FIDO2 and certificate-based authentication as the phish-resistant options. Passkeys Explained covers the user experience and FIDO2 vs WebAuthn vs Passkeys untangles the terms.

The control only works when it is required. If an account can still fall back to SMS or a push prompt, the proxy can steer the victim to that weaker method.

Device compliance and conditional access

A conditional access policy that requires a managed, compliant device makes the replayed cookie less useful, because the attacker's browser runs on a device the tenant does not recognise. Microsoft lists compliant devices and trusted network locations as mitigations, and recommends requiring interactive phishing-resistant reauthentication for medium or higher sign-in risk.

Token binding

The longer-term fix is to make the session itself unusable on another machine.

• Token Protection in Microsoft Entra conditional access accepts only refresh tokens cryptographically bound to the device they were issued to. Microsoft's documentation lists support for Windows native applications connecting to Teams, SharePoint and Exchange, with coverage still expanding.
• Device Bound Session Credentials (DBSC) in Chrome binds a session cookie to a key held on the device. Google made it generally available in Chrome on Windows and announced on 28 May 2026 that it is on by default for Workspace and personal Google accounts.

Both narrow the replay window. Neither yet covers every application or browser, so they complement phishing-resistant MFA without replacing it.

Detection signals

AitM sign-ins leave a recognisable pattern because the same session is used from two places within minutes.

• Impossible or atypical travel right after a successful sign-in. The victim signs in from home, then the same session appears from another country or provider seconds or minutes later.
• A session that appears on an unfamiliar device. The session cookie shows up with a browser, operating system or device ID that did not complete the original sign-in.
• Sign-ins from hosting providers and VPS ranges. Proxies and replay browsers often run on cloud infrastructure. Mamba 2FA's switch to commercial proxies shows operators know this, so treat ASN as one signal among several.
• Lookalike domains in mail and proxy logs. Recently registered domains that contain the brand name, plus redirect chains through legitimate services, often precede the sign-in.
• Fast post-login changes. A new MFA method, new inbox rules, mailbox forwarding or OAuth app consent shortly after the first sign-in from a new location.

In Microsoft Entra ID Protection, the relevant risk detections include:

Microsoft Defender XDR adds the alerts "Stolen session cookie was used" and "Possible AiTM phishing attempt" when the relevant connectors are deployed.

How to defend against AitM phishing

For organisations

1. Require phishing-resistant MFA (FIDO2 keys, passkeys, certificate-based authentication) for administrators first, then finance and executives, then everyone. Remove weaker fallbacks for those groups.
2. Require compliant or managed devices in conditional access for access to email and core SaaS.
3. Enable token binding where supported, such as Entra Token Protection for supported apps and DBSC for Google accounts in Chrome.
4. Turn on risk-based policies that force reauthentication or block access at medium and high sign-in risk, and route Attacker in the Middle and anomalous token detections to the SOC.
5. Alert on post-login persistence: new MFA registrations, inbox rules, forwarding and OAuth consents within an hour of a risky sign-in.
6. Monitor for lookalike domains of your brand and identity provider, and block newly registered domains at the mail and web gateway where practical.
7. Rehearse the response: revoke sessions, reset credentials, remove attacker MFA methods, then hunt for mail sent from the account.

For individuals

1. Use passkeys or a security key wherever a service offers them. They are the one control the proxy cannot relay.
2. Treat unexpected sign-in links with suspicion, especially from shared-document notifications and QR codes. Go to the site directly instead.
3. Check active sessions after any doubtful sign-in. The session kill switch lists where to revoke sessions on each major platform.
4. Let a password manager fill credentials. It matches the saved domain, so it will not autofill on a lookalike site, which is an early warning.

Related guides

• What Is Phishing
• Two-Factor Authentication Guide
• Session Hijacking Explained
• Passkeys Explained
• FIDO2 vs WebAuthn vs Passkeys
• MFA Fatigue Attacks Explained
• Best Hardware Security Keys