MFA interception attacks, explained

1) Phishing lure — an email, text, or search ad sends you to a fake login page that is really a reverse proxy (Evilginx, Modlishka, EvilProxy). 2) You enter your username and password on what looks like the real site (Microsoft, Google, IRS, your bank). The proxy instantly forwards them to the real site. 3) MFA challenge — the real site sends a push, SMS, or TOTP prompt to your phone. Because the proxy is relaying everything, the prompt looks normal and you approve it. 4) Session token theft — once MFA passes, the real site issues an authenticated session cookie. The proxy captures that cookie before it fully lands in your browser. 5) Account hijack — the attacker pastes the stolen cookie into their own browser and is now logged in as you, without ever needing your password again. The entire chain often completes in under a minute.

Push approvals and TOTP codes prove you can complete a challenge — they do not prove which site you completed it on. Because the AiTM proxy is sitting in the middle of a live session with the real service, anything you approve goes to the real service. Only origin-bound factors (passkeys / WebAuthn / hardware security keys) refuse to sign for the wrong domain.

Yes, by design. A passkey signs a challenge that includes the relying party's origin. If the page is hosted on a phishing domain, the origin doesn't match the registered credential, and the browser/authenticator refuses to produce a valid signature. The attacker gets nothing usable. Edge cases exist (cross-device flows, downgrade to a weaker factor), so keep passkeys as the only enabled factor where possible.

Pixel-perfect copies of Microsoft 365, Google, Okta, exchange logins, and government portals (passport renewal, tax accounts, benefits). The domain is usually a fresh registration (under 30 days), uses a free SSL certificate, and may sit on a typosquat (rnicrosoft.com), a homoglyph (microsоft.com with Cyrillic 'о'), or a long deceptive subdomain (login.microsoft.security-verify.com). Run the URL through the GACS website checker before you type anything.

Assume the session is stolen. From a different device: sign out all sessions, reset the password, remove any unknown MFA methods, check email forwarding rules and OAuth app grants, and rotate recovery email and phone. For work accounts, tell IT — they can revoke tokens centrally so a stolen cookie stops working. Then report the phishing site at /report so other people don't fall for the same kit.

Often, yes. The same AiTM kits are repurposed for government impersonation: a Google ad for 'passport renewal' or 'tax refund status' points to a proxy of the real .gov portal. You log in, complete identity verification (sometimes including ID upload and MFA), and the attacker walks away with your session plus your identity documents. The defense is the same: navigate directly to the official .gov site, and use passkeys where the agency supports them.