AiTM phishing: you passed MFA. So did the attacker.

How an AiTM attack works

1. A link arrives: a shared file, a voicemail, a DocuSign-style request, a QR code. It often goes through several redirects and a “checking your browser” page that filters out security scanners.
2. The kit loads the real sign-in page from Microsoft (or Google, Okta and others) and shows it to you through its own server, on its own domain.
3. You type your e-mail and password; the kit forwards them to the real service.
4. The real service asks for MFA; you approve it; the kit forwards your approval.
5. The real service issues a session cookie. The kit captures it and lets you continue, often straight to your real mailbox, so nothing seems wrong.
6. The attacker replays the cookie from their own browser and is in: mail, files, then often a new MFA method, mailbox rules and invoice fraud.

Why your current controls may not see it

• The page is pixel-perfect because it is the real one, relayed. Looks-wrong training does not help.
• Push, SMS and app codes are relayed. Only phishing-resistant methods, bound to the real site’s address, break the relay.
• Domains are fresh and short-lived, and anti-bot pages hide the kit from automated scanners.
• The stolen session looks normal unless sign-in risk detection catches the new location or device.

What actually stops it

1. Phishing-resistant MFA (passkeys, FIDO2 security keys, Windows Hello for Business). The key checks the real address, so a proxy cannot use it. Roll it out to administrators and finance first.
2. Conditional Access that requires a compliant or managed device, and token protection where available, so a stolen cookie is worth less elsewhere.
3. Fast response: revoke sessions, remove unknown MFA methods and check mailbox rules as soon as a user reports a suspicious sign-in.
4. A check in the browser, where the proxied page is actually rendered, before the user types anything.

How ByteMantle helps

• The proxied page is recognised. ByteMantle recognises the structure of the real Microsoft sign-in page, and of ten more identity providers, when it is served from a host that does not belong to them, and warns before the password is typed.
• New infrastructure is flagged. Sign-in forms on domains registered days ago, fake browser windows (browser-in-the-browser) and pages built in memory (blob URLs) raise their own signals.
• The whole path is visible. The console shows the e-mail or site the user came from and every redirect and cloaker on the way, and groups pages of the same kit into one campaign.

More on phishing protection.

Questions people ask

Can phishing bypass MFA?

Yes. Adversary-in-the-middle kits relay codes and push approvals and steal the session cookie issued afterwards. Phishing-resistant methods such as passkeys and FIDO2 keys are not relayed, because they check the site’s real address.

How can I tell if a Microsoft sign-in page is fake?

Look at the address bar: Microsoft sign-in happens on login.microsoftonline.com, login.microsoft.com or login.live.com. A page that looks like Microsoft’s on any other address is fake, however perfect it looks.

What is Tycoon 2FA?

A phishing-as-a-service platform that sold AiTM kits targeting Microsoft 365 and Gmail. A Europol-coordinated action disrupted it in March 2026, but similar kits continue to operate.

I entered my password and approved MFA on a fake page. What now?

Tell IT immediately. They should revoke all sessions, reset the password, remove MFA methods you did not add and check mailbox forwarding rules and recent sign-ins.