# How does adversary-in-the-middle phishing bypass MFA, and what stops it?

URL: https://iblockspam.com/blog/adversary-in-the-middle-phishing-mfa-bypass
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Phishing & threats
Author: iBlockSpam Team

> How AiTM phishing kits steal session cookies to get past SMS, app code and push MFA, which methods are phishing-resistant, and how to lock down Microsoft 365.

## Short answer

Adversary-in-the-middle (AiTM) phishing puts a proxy between the user and the real sign-in page. The user completes MFA as normal, and the proxy captures the session cookie, which the attacker replays to skip MFA. Codes, SMS and push approvals don't stop it. Phishing-resistant methods do: FIDO2 security keys and passkeys, Windows Hello for Business and certificate-based authentication.

Many businesses turned on MFA and assumed phishing was handled. Adversary-in-the-middle (AiTM) kits changed that. They let an attacker sign in as your user even when the user completes MFA correctly. This guide explains how the attack works, which MFA methods resist it, and the Microsoft 365 settings that limit the damage.

## What is adversary-in-the-middle (AiTM) phishing?

In an AiTM attack, the phishing page isn't a static copy of a login screen. It's a reverse proxy. Microsoft describes attackers deploying "a proxy server between a target user and the website the user wishes to visit" ([Microsoft Threat Intelligence, 2022](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/)). Everything the user sees comes from the real Microsoft or Google sign-in service, relayed through the attacker's domain.

The prize is the session cookie: "the session cookie that proves their ongoing and authenticated session with the website." With it, the attacker doesn't need the password or the second factor again. Microsoft is clear that "this is not a vulnerability in MFA". The user really did authenticate; the attacker simply collected the result. That campaign alone "attempted to target more than 10,000 organizations since September 2021."

## How does an AiTM attack bypass MFA?

1. **The lure.** An email links to a "shared document", voicemail or [fake Microsoft sign-in page](https://iblockspam.com/blog/fake-microsoft-login-phishing). Increasingly it comes from a real, compromised partner mailbox, which is how [thread hijacking](https://iblockspam.com/blog/email-thread-hijacking) and AiTM feed each other.
2. **The proxy.** The user lands on the attacker's domain, which shows the genuine sign-in page passed through from Microsoft.
3. **Password and MFA.** The user types their password and enters the code, approves the push or answers the call. Each step is relayed to the real service.
4. **The cookie.** The real service issues a session cookie. The proxy keeps a copy and sends the user on to their mailbox, so nothing looks wrong.
5. **The replay.** The attacker loads the cookie into their own browser and opens the mailbox as the user.
6. **Persistence and fraud.** Microsoft has seen attackers add their own MFA method, create [inbox rules that hide replies](https://iblockspam.com/blog/malicious-inbox-rules-auto-forwarding), and start payment fraud, in one case "as little as five minutes after credential and session theft."

## How can users spot an AiTM phishing page?

An AiTM page is hard to spot by looks, because it shows the real sign-in content: your company logo, your username, the genuine MFA prompt. The giveaways are elsewhere:

- **The address bar.** The page is served from the attacker's domain, not Microsoft's or Google's. Check the domain before typing a password, especially after following a link from an email.
- **How you got there.** A sign-in prompt reached from an email link, a QR code or a PDF attachment deserves more suspicion than one you opened from a bookmark.
- **Your password manager.** Password managers fill credentials by domain. If yours normally fills your work password and suddenly offers nothing, you may be on the wrong site.
- **An unexpected second prompt.** Being asked to sign in again to "view a document" moments after you were already signed in is a common pattern.

These checks help, but they rely on people catching every lure. Microsoft and CISA both point to phishing-resistant MFA as the fix, because it doesn't depend on the user noticing anything.

## Which MFA methods stop AiTM phishing?

The dividing line is whether the user can hand the attacker something to relay. [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) (section 3.2.5) puts it plainly: authenticators "that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant." Phishing resistance "requires single- or multi-factor cryptographic authentication" bound to the real site, which NIST calls verifier name binding, with WebAuthn as its example.

CISA's [phishing-resistant MFA fact sheet](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) ranks the methods the same way:

| Method | CISA's assessment | Stops AiTM? |
|---|---|---|
| FIDO2 security key or passkey (WebAuthn) | Phishing-resistant; "the only widely available phishing-resistant authentication" | Yes |
| PKI-based, such as smart cards or certificate-based authentication | Phishing-resistant | Yes |
| Authenticator app push with number matching | "Vulnerable to phishing attacks. Resistant to push bombing" | No |
| Authenticator app or hardware token codes (OTP) | Vulnerable to phishing | No |
| Push without number matching | Vulnerable to push bombing and user error | No |
| SMS or voice | Vulnerable to phishing; "should only be used as a last resort" | No |

CISA's summary: "any form of MFA is better than no MFA", but "phishing-resistant MFA is the gold standard and organizations should make migrating to it a high priority effort."

In Microsoft Entra ID, the built-in **Phishing-resistant MFA strength** accepts exactly three methods: Windows Hello for Business or platform credential, FIDO2 security key (passkeys), and certificate-based authentication (multifactor). Microsoft Authenticator phone sign-in counts as passwordless, but not phishing-resistant ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths)). Device-bound passkeys stored in the Authenticator app are configured through the Passkey (FIDO2) method.

## How do you require phishing-resistant MFA in Microsoft 365?

Conditional Access needs a Microsoft Entra ID P1 license. Roll it out in phases; CISA suggests starting with administrators and other high-value targets.

1. **Enable the method.** In the Microsoft Entra admin center, go to **Entra ID** > **Authentication methods** > **Policies**, open **Passkey (FIDO2)** and enable it for a pilot group.
2. **Register users.** Have each pilot user add a security key, a passkey in Microsoft Authenticator, or Windows Hello for Business.
3. **Create a Conditional Access policy** that targets the pilot group and your Microsoft 365 apps. Under **Grant**, choose **Require authentication strength** and select **Phishing-resistant MFA**.
4. **Start in report-only mode.** Check the sign-in logs for users and apps that would fail before you enforce.
5. **Protect registration.** Microsoft notes that adding a new MFA method "by default, does not require re-authentication." Add a Conditional Access policy for the **Register security info** user action so an attacker with a stolen session can't quietly add their own method.
6. **Expand** to finance, executives and anyone who approves payments, then everyone else.

One limit to know: Conditional Access runs after the first sign-in step, so a user can still type a password into a fake page. The authentication strength stops that password, and any relayed code, from being enough.

## What else limits stolen session cookies?

Phishing-resistant MFA stops the cookie being issued to the attacker in the first place. These controls reduce what a stolen cookie can do if one gets through:

- **Device-based Conditional Access.** Microsoft's 2022 guidance recommends policies "such as compliant devices or trusted IP address requirements." An attacker replaying a cookie from their own laptop fails a compliant-device check.
- **Token protection.** This binds sign-in tokens to the device so "even if a threat actor steals the token, it can't be used from another device" ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection)). It's enforced for native apps on supported devices for Exchange Online, SharePoint Online and Teams. Browser support is limited to a preview for Azure Resource Manager, so don't rely on it to protect Outlook on the web.
- **Risk-based policies and continuous access evaluation.** Microsoft's 2023 guidance recommends both, along with hunting for sign-ins from unusual locations, ISPs, user agents and anonymizers.
- **Inbound filtering.** Every AiTM attack starts with a message. Blocking the lure is cheaper than cleaning up the session. Our guide to [stopping phishing in Microsoft 365](https://iblockspam.com/blog/stop-phishing-emails-microsoft-365) covers the built-in options.

## What should you do if an AiTM attack succeeds?

Microsoft's 2023 write-up says it plainly: "since the sign-in session is compromised, password reset is not an effective solution." Work through all of these:

1. **Disable the account and revoke sessions.** In the Entra admin center, go to **Entra ID** > **Users** > **All users**, select the user and choose **Revoke sessions**, or run `Revoke-MgUserSignInSession` ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)). Access tokens already issued can stay valid until they expire, by default one hour, unless the app supports continuous access evaluation.
2. **Reset the password** from a clean device.
3. **Remove MFA methods** the user doesn't recognize. Attackers add their own phone or authenticator to get back in.
4. **Delete malicious inbox rules and forwarding.** See [malicious inbox rules and auto-forwarding](https://iblockspam.com/blog/malicious-inbox-rules-auto-forwarding).
5. **Check app consents**, in case the attacker approved an app for lasting access. See [OAuth consent phishing](https://iblockspam.com/blog/oauth-consent-phishing-microsoft-365).
6. **Review sent mail and contacts.** Warn anyone who received phishing or payment requests from the account, by phone for anything financial.

Our [compromised account guide](https://iblockspam.com/blog/signs-email-account-compromised) has the full response checklist for Microsoft 365 and Google Workspace.

## Next steps

1. List who has admin roles or approves payments, and move them to phishing-resistant MFA first.
2. Turn on number matching and remove SMS where you can while the rollout continues. It's an improvement, even though it doesn't stop AiTM.
3. Rehearse the response steps above, including session revocation, so they happen in minutes, not hours.
4. Cut the lures. iBlockSpam filters phishing and spoofing at the MX before mail reaches Microsoft 365 or Google Workspace; see [how it works](https://iblockspam.com/how-it-works). Use the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) to check where a suspicious message really came from.

Browse our other [phishing and threat guides](https://iblockspam.com/blog/topic/threats).

## Frequently asked questions

### Does AiTM phishing mean MFA is useless?

No. Microsoft says MFA remains "an essential pillar in identity security" and still stops a wide range of attacks, such as password spraying and reused passwords. AiTM defeats the methods where a person types a code or taps approve on a page the attacker controls. The fix is to move to phishing-resistant MFA, not to drop MFA.

### Why does a passkey stop AiTM when an authenticator code doesn't?

A passkey or FIDO2 key is cryptographically tied to the real website's domain. On a proxy domain, the browser won't use the credential for the genuine site, so there's nothing to relay. A six-digit code has no such binding: the user types it into the fake page and the proxy passes it on within seconds.

### Does number matching stop AiTM phishing?

No. Number matching stops MFA fatigue, where attackers spam push requests hoping you tap approve. In an AiTM attack, you started the sign-in yourself on the fake page, so you see a real number and approve it willingly. CISA lists push with number matching as resistant to push bombing but still vulnerable to phishing.

### Is resetting the password enough after an AiTM attack?

No. The attacker holds a session, not just a password. Microsoft states that password resets alone are insufficient. Revoke the user's sessions, remove any MFA method the attacker registered, delete inbox rules they created, and check app consents. Then review what was sent from the mailbox while the attacker had access.

### How do I know if my users were hit by an AiTM kit?

Look for sign-ins from unfamiliar locations, ISPs or anonymizers shortly after a user reports a phishing email, new MFA methods registered without a helpdesk ticket, and new inbox rules that hide or delete mail. Microsoft Defender XDR also raises specific alerts for stolen session cookies where it has the signals.

## Sources

- [Microsoft Threat Intelligence: From cookie theft to BEC (July 2022)](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/)
- [CISA: Implementing Phishing-Resistant MFA (October 2022)](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf)
- [NIST SP 800-63B-4: Authentication and Authenticator Management, section 3.2.5](https://pages.nist.gov/800-63-4/sp800-63b.html)
- [Microsoft Learn: Overview of Conditional Access authentication strengths](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths)
- [Microsoft Learn: Token protection in Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection)
- [Microsoft Threat Intelligence: Detecting and mitigating a multi-stage AiTM phishing and BEC campaign (June 2023)](https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/)
- [Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/adversary-in-the-middle-phishing-mfa-bypass (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt