Identity attacks

AiTM phishing: how attackers get past MFA with a fake login page

Adversary-in-the-middle (AiTM) phishing steals the session, not just the password, so MFA doesn't stop it. Here's how the attack works, a worked example, and the man-in-the-middle prevention steps that actually help.

For years the advice was simple: switch on multi-factor authentication (MFA) and stolen passwords stop mattering. That advice is still good. But attackers have found a way around most kinds of MFA, and it doesn’t involve breaking anything. They put a fake login page in the middle of a real one.

This is adversary-in-the-middle (AiTM) phishing, and it’s one of the fastest-growing attacks on Microsoft 365 and Google Workspace accounts. Microsoft’s Digital Defense Report 2024 reported a 146% rise in AiTM phishing attacks over the previous year. Here’s how it works, what it looks like from the inside, and what actually stops it.

What is an AiTM phishing attack?

In a normal phishing attack, a fake login page collects your password. If you have MFA, the attacker still can’t sign in, because they don’t have your second factor.

An AiTM attack is smarter. The fake page sits between you and the real Microsoft or Google sign-in page and passes everything through, like a relay:

  1. You click a link in an email and land on a page that looks exactly like your normal sign-in.
  2. You type your password. The fake page passes it to the real sign-in page.
  3. The real page sends an MFA prompt to your phone. You approve it, because you really are signing in.
  4. The real page signs you in and issues a session token, the small piece of data that keeps you signed in so you don’t need MFA on every click.
  5. The fake page copies that token, then sends you on to your real inbox so nothing looks wrong.

The attacker now has a valid, already-approved session. They load it into their own browser and they’re in your account. They never needed your phone, and MFA has already been satisfied.

CISA describes it in similar terms: the attacker sends the user through a proxy and retrieves credentials or session tokens while the user thinks they are signing in to the real service.

Why ordinary MFA doesn’t stop it

MFA proves that the right person approved a sign-in. In an AiTM attack, the right person did approve it. The problem is what happens after: the session that results ends up in the wrong hands.

That’s why most common MFA methods don’t stop AiTM:

  • Text message codes: you type the code into the fake page, which passes it on.
  • Authenticator app codes: same thing.
  • Push approvals: you tap approve for a sign-in you started yourself.

It’s also why so many breaches happen to businesses that thought they were protected. Sophos found that in ransomware attacks where stolen credentials were the root cause, 97% of victims had MFA switched on in some form.

What attackers do once they’re in

The stolen session is the start, not the goal. Microsoft documented AiTM campaigns that moved straight into business email compromise. Typical next steps:

  • Hide their tracks. An inbox rule moves replies from a supplier or the bank into an unused folder.
  • Read and wait. The attacker reads weeks of email to learn who pays whom, when and how.
  • Stay in. They add their own MFA method or register a device so they can come back after the session expires.
  • Grant an app access. A malicious app gets permission to read mail and files, so the attacker keeps access even after a password reset.
  • Ask for money. From the real mailbox, they ask a client or the accounts team to pay a “new” bank account.

For more on the fraud that usually follows, read what business email compromise is.

A worked example: Tuesday morning at a 40-person firm

Here’s an illustrative example of how an AiTM attack plays out.

8:52 am. The finance manager gets an email that looks like a shared document from a regular supplier. The link goes through two redirects and lands on what looks like a Microsoft sign-in page.

8:53 am. She enters her password and approves the MFA prompt on her phone. The page shows her real inbox afterwards. Nothing seems wrong.

8:55 am. Her session is used from a hosting network in another country, from a browser her laptop has never used. Microsoft sees a valid token and lets it in.

8:58 am. A new inbox rule appears: anything mentioning “invoice”, “payment” or “bank” goes to an unused folder and is marked read.

9:04 am. A new authenticator app is added to her account.

Without anything watching sign-ins, none of this looks unusual to the tools on her laptop, because her laptop was never touched. Three weeks later a client pays a large invoice into the attacker’s account.

With identity threat detection, the session from another country, the unfamiliar browser, the new rule and the new MFA method land in one case within minutes. Every session ends, the password resets, the attacker’s MFA method and inbox rule are removed, and she gets a short “was this you?” message. The supplier email is pulled from every other inbox it reached.

Man-in-the-middle prevention: what actually helps

No single setting stops every AiTM attack, but these steps, together, close most of the gap.

1. Use phishing-resistant MFA where it matters most

Passkeys and FIDO2 security keys tie each sign-in to the real website’s address. A fake page on a different address can’t use them, so the relay trick fails. CISA treats FIDO2 and WebAuthn as phishing-resistant, and says text-message MFA is not. Start with admins, finance and anyone who can approve payments.

2. Limit where sessions can be used

Microsoft 365 and Google Workspace both let you set sign-in rules, such as requiring a managed device or blocking sign-ins from places you don’t operate. Microsoft also offers a Conditional Access setting called token protection, which ties a session to the device it was issued to, and continuous access evaluation, which lets Microsoft cut off a session quickly after a password reset. Check Microsoft’s current guidance for which devices and apps support them.

3. Watch sign-ins, not just laptops

An AiTM attacker never touches your laptops, so endpoint protection won’t see them. You need something watching the sign-ins themselves: sessions from new places, browsers that don’t match the person’s device, and sign-ins from hosting networks. Read what ITDR is for how this works.

4. Watch what happens after the sign-in

New inbox rules, mail forwarded outside the company, new MFA methods and new app consents are the attacker’s footprints. Catching them is often the fastest way to spot a takeover that got past everything else.

5. Be able to end every session, fast

Resetting a password isn’t enough on its own if the attacker’s session stays alive. Make sure someone can end every session, remove the attacker’s MFA method and delete their rules within minutes, at any hour.

6. Train people on the one sign that matters

Fake login pages look perfect. The giveaway is the address bar. Teach people to stop and check the web address when they’re asked to sign in from an email link, and to report it if anything looks off.

Checklist: are you protected against AiTM?

  • Admins and finance staff use passkeys or security keys, not text codes.
  • Sign-in rules block or challenge sign-ins from places and devices you don’t use.
  • Every sign-in is watched for sessions from new places and unfamiliar browsers.
  • Sign-ins from hosting and anonymising networks raise an alert.
  • New inbox rules and forwarding to outside addresses are flagged.
  • A new MFA method or registered device raises an alert.
  • New app consents to mail and files are reviewed.
  • Someone can end every session for an account in minutes, at any hour.
  • A phishing email and the sign-in that followed it end up in one case.
  • Staff know to check the address bar before signing in from an email link.

How Centeye stops AiTM takeovers

Centeye Gatewatch watches every sign-in across Microsoft Entra ID and Google Workspace. It spots stolen sessions replayed from someone else’s machine, impossible travel, sign-ins from anonymising networks, new admins and sign-in methods, hidden inbox rules and risky app consent. When it finds a takeover, it ends every session, resets the password and sign-in methods, and removes what the attacker added, at the setting you choose. Every fix is checked afterwards at Microsoft or Google.

Centeye Lighthouse follows suspicious links through every redirect in an isolated browser, so it can catch the fake sign-in page before anyone clicks, and pulls every copy of the email from every inbox. Kavach, Centeye’s security operations agent, joins the email, the sign-in and the mailbox changes into one case, so the attack is seen as one story rather than three separate alerts.

Frequently asked questions

What does AiTM stand for?

Adversary-in-the-middle. It’s a form of man-in-the-middle attack where a fake page relays a real sign-in and steals the session that results.

Does MFA stop AiTM phishing?

Most kinds don’t, because the person really does approve the sign-in. Phishing-resistant MFA, such as passkeys and FIDO2 security keys, does stop the relay, because it only works on the real website’s address.

How is AiTM different from MFA fatigue?

In MFA fatigue, the attacker already has the password and floods the person with prompts until they approve one. In AiTM, the person starts the sign-in themselves on a fake page. Read how to stop MFA fatigue attacks for the other side.

Will resetting the password kick the attacker out?

Not always on its own. End every session as well, remove any MFA method or device the attacker added, delete their inbox rules and revoke any app they connected.

Can antivirus or EDR catch AiTM?

Usually not. The attack happens in the browser and in the cloud sign-in, not on the laptop. Read ITDR vs EDR for why identity needs its own watch.

New to these terms? Our security glossary has plain-English definitions. Want to see stolen-session detection on your own Microsoft 365 or Google Workspace? Start a free trial.


Figures cited from the Microsoft Digital Defense Report 2024 and the Sophos State of Ransomware 2026 report. MFA guidance per CISA. Microsoft session controls per Microsoft Learn. The worked example is illustrative.

See one attack, end to end.

A 30-minute intro call on sample data, or a free trial on your own tenant.