MFA was supposed to end credential phishing. For a while, it mostly did. Then adversary-in-the-middle (AiTM) phishing kits made MFA prompts irrelevant by stealing what comes after the prompt: the session token.
This post covers how AiTM kits work and the specific Entra ID configurations that raise the cost of these attacks. Architecture and policy only, no query language.
How AiTM Phishing Works
An AiTM kit is a reverse proxy sitting between the victim and the real Microsoft sign-in page. Kits like Evilginx, Modlishka, and Muraena have made this pattern turnkey:
- Victim clicks a phishing link and lands on an attacker-controlled domain that mirrors login.microsoftonline.com.
- The proxy relays requests to Microsoft and responses back to the victim in real time.
- Victim enters credentials and completes MFA. The proxy relays both.
- Microsoft issues session cookies (ESTSAUTH, ESTSAUTHPERSISTENT) to the proxy, which captures them before forwarding to the victim.
- The attacker imports those cookies into their own browser and is authenticated as the victim, MFA already satisfied.
The critical insight: MFA authenticates the user at sign-in. The session token authenticates every request afterward. Steal the token and you skip the MFA prompt for the lifetime of that token. SMS, voice, push, and TOTP MFA are all vulnerable, the user completed a real challenge, the token is real, and Microsoft has no way to know it was handed to an attacker.
Why Common Countermeasures Fall Short
Number matching and additional context in Microsoft Authenticator help against MFA fatigue but do nothing against AiTM. The user is genuinely signing in.
Geo-based conditional access fails because the proxy is often hosted in the victim's country, or attackers replay tokens through residential proxies.
IP allowlisting works but is impractical for hybrid workforces.
The real defenses live in three categories: binding tokens to the device that requested them, shortening how long stolen tokens remain useful, and eliminating password-based sign-in as the entry point.
Countermeasure 1: Token Protection in Conditional Access
Token protection cryptographically ties a sign-in session to the specific device it was issued to. An attacker who steals the cookie cannot use it from another machine because the token is bound to a device-specific key that never leaves the original device.
Configure through a Conditional Access policy:
- Assignment: pilot ring first, IT admins, security team, executives.
- Cloud apps: Office 365 (Exchange Online and SharePoint Online are the current supported workloads; more are being added).
- Session controls: enable Require token protection for sign-in sessions.
Requires Entra-joined or hybrid Entra-joined devices running supported clients (Outlook, Teams, OneDrive). Deploy in report-only mode first, token protection breaks unsupported client scenarios, and you need visibility into who those users are before enforcing.
Countermeasure 2: Sign-In Frequency and Persistent Browser Controls
Even without token binding, you can shrink the useful lifetime of a stolen token. Entra ID refresh tokens have long default lifetimes (up to 90 days of inactivity for public clients), and session cookies persist across browser restarts, a stolen token can grant access for weeks.
Two session controls change this:
- Sign-in frequency: forces reauthentication after a defined interval. Set to match workload sensitivity, 1 hour for privileged access, 4 to 8 hours for standard users, 12 to 24 hours for baseline productivity.
- Persistent browser session: set to "Never persistent" for high-risk apps so cookies drop when the browser closes.
Scope by user risk, resource sensitivity, or device trust. A blanket 1-hour policy across the tenant will crater user experience without materially reducing risk for low-sensitivity workloads. Enforce sign-in frequency "Every time" for privileged actions like accessing the Azure portal or Entra admin center.
Countermeasure 3: Phishing-Resistant Authentication
The strongest control against AiTM is one that cannot be proxied. Phishing-resistant methods use cryptographic proof of possession bound to the legitimate relying party origin. If the origin doesn't match, because the user is on an AiTM proxy domain then authentication fails.
Entra ID supports:
- FIDO2 security keys (YubiKey, Feitian, Token2)
- Passkeys in Microsoft Authenticator (device-bound and synced passkeys have different trust properties)
- Windows Hello for Business (cloud trust deployment model)
- Certificate-based authentication with hardware-backed private keys
Rollout path:
- Authentication methods policy: enable FIDO2, passkeys, and Windows Hello for Business. Disable SMS and voice call except for break-glass accounts.
- Authentication strengths: create a custom strength called "Phishing-resistant MFA" that includes only the methods above.
- Conditional Access: apply the phishing-resistant strength to admin roles first highest blast radius, smallest user count.
- Expand: executives, finance, HR, sensitive-data groups, then general workforce.
For admin accounts, this is not optional in 2026. Microsoft is deprecating password-based sign-in for privileged roles, and every serious guideline (CISA, Microsoft's Secure Future Initiative) treats phishing-resistant MFA for admins as baseline.
Countermeasure 4: Continuous Access Evaluation
Continuous Access Evaluation (CAE) lets Entra ID revoke access mid-session instead of waiting for token expiry. When CAE-enabled apps receive a critical event, user disabled, password changed, high user risk, location change, device compliance change they reject the token immediately and force reauthentication.
Without CAE, a stolen token remains valid until expiry, even if you disable the account. With CAE, disabling the account can invalidate live sessions in near real time.
CAE is enabled by default for most tenants and Microsoft workloads (Exchange Online, SharePoint Online, Teams, Microsoft Graph). Two things worth checking:
- Confirm CAE is enabled in the Conditional Access tenant defaults.
- Configure Conditional Access policies for location and device compliance with strict location enforcement. This tells CAE clients to reevaluate access on network location change a strong signal of token replay from a different IP.
CAE is what makes account disablement fast enough to matter during incident response.
Layering It Together
- All admins: phishing-resistant MFA, sign-in frequency "Every time," token protection where supported, CAE with strict location enforcement.
- High-value users (execs, finance, HR, engineering with production access): phishing-resistant MFA, sign-in frequency 1 to 4 hours, token protection, persistent browser disabled for sensitive apps.
- General workforce: phishing-resistant methods as the preferred path, sign-in frequency 8 to 12 hours, token protection for supported apps, CAE enabled.
- Break-glass accounts: two accounts, FIDO2 keys in physical safes, excluded from all Conditional Access except a monitored allowlist, alerting on any sign-in.
What This Doesn't Cover
Infostealer malware on the endpoint can scrape cookies directly from browser storage. Token protection helps because the bound key is not exfiltrated with the cookie, but endpoint hygiene, EDR, and browser hardening are separate conversations.
Session controls only apply to workloads that honor them. Legacy authentication (basic auth, older EWS clients) bypasses most modern Conditional Access — blocking it remains a prerequisite for everything above.
Phishing-resistant MFA is only as strong as the enrollment process. If a user can self-service reset from FIDO2 back to SMS, an attacker who compromises the reset flow downgrades the method. Lock down authentication method registration with a Conditional Access policy that requires a trusted network or compliant device to change methods.
AiTM has been in the wild since 2022, industrialized since 2023, and normalized as the default credential-phishing technique in 2025 and 2026. The controls that stop it have been available for years. The gap is configuration and rollout discipline, not technology.