What 2FA you trusted does not protect against

AiTM is a reverse proxy phishing attack. The attacker's server transparently forwards every victim request to the real Microsoft or Google login and every response back. You enter your password and 2FA code; the proxy forwards both; Microsoft completes authentication and sets the session cookie on the proxy's domain. The attacker harvests the cookie, replays it from their browser, and is logged in as you. The flaw is not the codes; it is that everything you sent went through someone else.

The 3 tool families running AiTM in 2026

Three open-source frameworks have packaged the attack into kits, all actively maintained.

1. Evilginx2

By far the most widely used. The Evilginx2 GitHub repository ships "phishlets" (YAML configs) for Microsoft, Google, Okta, Citrix, GitHub, and dozens more. It handles the reverse proxy, Let's Encrypt TLS, cookie extraction, and live session management. Microsoft Threat Intelligence has named Evilginx in multiple AiTM advisories as the framework behind real-world Microsoft 365 BEC.

2. Modlishka

Released in 2019 by Polish researcher Piotr Duszynski, Modlishka pioneered the "no templates needed" approach. It acts as a generic HTTPS proxy that rewrites URLs on the fly, so any login can be phished without a pre-built copy.

3. Muraena

An Italian framework paired with NecroBrowser, a headless automation tool that takes the captured cookie and immediately enumerates mailbox rules, pulls contacts, sets up forwarding, and downloads drive contents. Muraena automates the post-authentication half of the kill chain.

All three bypass TOTP (Google Authenticator, Authy), SMS, and push prompts (Microsoft Authenticator, Duo). Whatever the real site asks for, the proxy relays.

The 4-step AiTM flow

Step 1: Register a lookalike domain and stand up Evilginx2

The domain is typically a typosquat (login-microsoft-secure.com), a homograph (microsoftonline with Cyrillic characters), or a subdomain on a compromised host. Evilginx is loaded with the Microsoft phishlet, Let's Encrypt issues the cert, and the proxy is live within minutes.

Step 2: The victim clicks a phishing link and lands on the proxy

The link arrives via email, Teams, LinkedIn DM, or a QR code in a PDF. The browser loads what looks like the real Microsoft login page; it is the real Microsoft login page, fetched server-side and forwarded byte-for-byte. Only the URL bar shows the attacker's domain.

Step 3: Email, password, and 2FA code all flow through the proxy

The victim types email and password; the proxy forwards both. Microsoft prompts for 2FA; the victim types six digits or taps Approve; the proxy forwards that too. Microsoft completes authentication and issues a session cookie in the response back to the proxy.

Step 4: The attacker captures the session cookie and replays it

Evilginx parses the cookie and alerts the operator, who imports it into their own browser with a Cookie-Editor extension, refreshes outlook.office.com, and is signed in as the victim with no password or 2FA prompt. The attacker can now read and send mail, create forwarding rules, register new MFA devices, and pivot to other Microsoft 365 resources.

Why this matters in 2026 specifically

The Microsoft Digital Defense Report 2024 recorded AiTM climbing through the year, and Microsoft Threat Intelligence reported a roughly 146% jump in AiTM attempts in H1 2025 versus the prior half. Microsoft 365 BEC is now overwhelmingly AiTM-driven, because attackers do not need to defeat 2FA when they can walk around it. Once inside a mailbox, the attacker creates a hidden forwarding rule, monitors invoice traffic, and inserts themselves into a real wire transfer thread with revised banking details. The CISA advisory on AiTM and MFA bypass documents the same pattern in federal incidents.

The phishing-resistant 2FA that defeats AiTM

Not all 2FA is equal. The factor that matters is whether the protocol verifies the origin (the domain in the URL bar) as part of the handshake. If it does, the proxy cannot relay the response because the response is bound to the wrong domain.

FIDO2 and WebAuthn passkeys

FIDO2 is a W3C and FIDO Alliance standard where the browser signs a challenge with a key tied to the exact origin. If you are on login-microsoft-secure.com and the signed origin is login.microsoftonline.com, Microsoft rejects the assertion. The proxy cannot rewrite the origin without breaking the signature. KnowBe4's AiTM research and Microsoft both point to FIDO2 as the only widely available factor that breaks the AiTM chain at the protocol level.

Hardware security keys

YubiKey, Solo, Titan, and other FIDO2 keys implement WebAuthn on a physical device. The private key never leaves the chip and the origin check is enforced by the browser.

Platform passkeys

Apple, Google, and Microsoft all support platform passkeys, where the FIDO2 credential lives in the OS keychain and syncs via the user's cloud account. Phishing resistance matches a hardware key; the prompt is Touch ID, Face ID, or Windows Hello.

What does not work against AiTM: push notifications, SMS, TOTP, and number matching. Every code-based or approval-based factor is relayable. Only origin-bound cryptographic signatures are not.

How to spot an AiTM phishing page

The tell is always the URL bar. The page content is real, the branding is real, the padlock is real, because the proxy serves real Microsoft or Google content. But the domain belongs to the attacker, either a typosquat or a homograph, and on a phone the hostname is often truncated. The discrepancy between the URL bar and the page is the entire detection surface. Modern users check the URL once at the start of a session and then stop, which is the gap AiTM exploits. The fix is mechanical: every time a login form appears, look at the URL bar before typing. The same discipline applies to spotting Microsoft phishing emails and the related browser-in-the-browser attack, which fabricates a fake popup inside the page rather than proxying the real one.

For organizations: hardening against AiTM

If you run Microsoft 365 or Google Workspace, three changes move the needle.

  • Enforce passkey or FIDO2 for high-value accounts. Start with admins, finance, HR, and anyone with mailbox forwarding rights. Microsoft Entra ID and Google Workspace both support Conditional Access policies that require phishing-resistant MFA. The attacker can phish the password; the login still fails.
  • Tighten Conditional Access policies in Microsoft 365. Block legacy authentication (no IMAP, POP, SMTP basic auth), require a compliant device, geo-fence to expected countries, and require token protection where supported. Each policy narrows the replay window.
  • Monitor for sign-in anomalies. Impossible travel, new user agents, new ASN or VPN provider, and sudden mailbox rule creation are all worth alerting on. Defender for Cloud Apps, Sentinel, and Google Workspace's Alert Center all expose these. See also our breakdowns of LinkedIn spear phishing and CEO wire transfer whaling.

If your session was hijacked

Assume full mailbox access from the moment you submitted credentials. Speed matters.

  • Revoke all active sessions. Microsoft: Entra ID for admins, account settings for users. Google: Account, Security, Your devices, Sign out everywhere. This invalidates the cookie.
  • Reset the password from a different device, not the one that hit the phishing page.
  • Audit mailbox forwarding rules and delegations. Attackers create rules that auto-forward replies and mark them read. Delete anything you did not create.
  • Check OAuth grants. An attacker may have granted persistent third-party access so a password reset does not lock them out. Microsoft Entra, Enterprise applications; Google Account, Security, Third-party access.
  • Reset MFA factors and re-enroll with a passkey. The attacker may have added their own authenticator app.

How SafeBrowz fits in

AiTM lives or dies on the URL bar discrepancy, and the browser is the last place to catch a lookalike domain before the user types into the proxy. SafeBrowz inspects the destination URL against our brand-impersonation engine the moment the page loads and blocks the AiTM reverse proxy before the real Microsoft or Google content renders inside it. The strongest setup is SafeBrowz at the browser layer paired with FIDO2 at the protocol layer. The SafeBrowz extension is free for phishing and brand-impersonation blocking on Chrome, Firefox, and Edge.

FAQ

Does my TOTP code protect me against AiTM?

No. The proxy relays your six-digit code to the real site in real time. It is valid thirty seconds and the attacker only needs one. Microsoft Authenticator, Google Authenticator, Authy, and 1Password TOTP all behave identically through AiTM.

What about push notifications and number matching?

Both are relayable. The proxy triggers the real push and you approve it. Number matching shows a number that also appears in the authenticator app, but it came from the real site the proxy is talking to. Neither verifies the origin.

Will a password manager help?

Yes, more than most users realize. 1Password, Bitwarden, Apple Passwords, and Google Passwords bind credentials to the exact origin. On an AiTM domain autofill will not fire. The refusal is the signal; do not type manually.

How long does a stolen session cookie last?

Microsoft 365 access tokens last about an hour; refresh tokens up to ninety days depending on Conditional Access. Without token protection, an attacker can refresh the session repeatedly. Revoking sessions invalidates the cookie immediately.

Is FIDO2 the same thing as a passkey?

Passkeys implement FIDO2 and WebAuthn. A hardware passkey lives on a YubiKey. A platform passkey lives in your Apple, Google, or Microsoft account and syncs. Both verify the origin and both defeat AiTM.

If I have a passkey on my account, am I safe?

Safer, but only if the account enforces passkey-only sign-in. If password and TOTP fallback is still accepted, the attacker phishes those and bypasses the passkey. In Microsoft Entra this is configured via Authentication strengths and Conditional Access.