AiTM Phishing and Session Token Theft: How Attackers Bypass MFA and How to Stop Them

An AiTM phishing attack operates as a man-in-the-middle relay between the victim and the legitimate identity provider. The attacker hosts a reverse proxy server that impersonates the target login page and forwards all traffic to the real IdP.

Step 1: Lure delivery. The victim receives a phishing email containing a link to the attacker's proxy domain (e.g., login.microsoft-sso[.]com). The link is often delivered via a legitimate email service, a compromised account, or an HTML attachment to evade URL reputation filters.

Step 2: Authentication relay. The victim navigates to the proxy, which transparently forwards the login request to the real Microsoft/Google/Okta login page. The proxy captures and relays all traffic bidirectionally. The victim sees a visually identical login page because it IS the real page, proxied.

Step 3: MFA completion. When the identity provider requests MFA, the proxy forwards the challenge to the victim. The victim completes their push notification, TOTP code, or SMS OTP normally. The proxy relays this response to the IdP. MFA succeeds.

Step 4: Session cookie capture. The IdP issues an authenticated session cookie. The proxy intercepts this cookie before forwarding the response to the victim. The victim also gets a session cookie and lands on a benign redirect page (often a fake 'session expired' or decoy document) while the attacker now has a working session cookie.

Step 5: Session replay. The attacker imports the stolen session cookie into their browser using developer tools or automated scripts. They are now authenticated as the victim with a fully valid session, bypassing all MFA controls.

Common AiTM frameworks include Evilginx2, Modlishka, and Muraena. Phishing-as-a-service platforms including Greatness, Tycoon 2FA, and Storm-1167 provide AiTM infrastructure as a subscription. Tycoon 2FA specifically targets Microsoft 365 and Google Workspace and was responsible for over 1,800 domains in active campaigns as of Q1 2026.

It is important to be precise: AiTM phishing defeats specific MFA types, not MFA as a concept. Understanding which authentication methods are vulnerable and which are not is essential for designing a response.

Vulnerable to AiTM proxy attacks:

• Push notification MFA (Microsoft Authenticator, Duo, Okta Verify)
• TOTP one-time codes (Google Authenticator, any authenticator app code)
• SMS OTP (text message codes)
• Voice call OTP
• Email OTP

All of these are shared secrets or codes that the proxy can relay transparently. The victim provides the correct response; the proxy forwards it. MFA succeeds from the IdP's perspective.

NOT vulnerable to AiTM proxy attacks:

• FIDO2 hardware security keys (YubiKey, Google Titan Key)
• Passkeys (device-bound or synced)
• Certificate-based authentication (CBA) with smart cards or device certificates
• Windows Hello for Business (WHfB) with TPM-bound keys

These methods are resistant because the cryptographic response is bound to the specific origin domain (the URL in the browser). When the victim is on the attacker's proxy domain rather than the legitimate domain, the FIDO2/passkey authenticator refuses to respond because the RP ID does not match. The phishing site gets nothing useful even if the victim physically touches their security key.

This is why CISA, NSA, and NIST all explicitly classify FIDO2/passkeys as 'phishing-resistant MFA' and push notification/TOTP as 'phishing-susceptible.' The distinction is not about the strength of the second factor but about whether the factor is cryptographically bound to the legitimate origin.

Deploying phishing-resistant MFA is the structural fix. The three enterprise-viable options each have distinct tradeoffs.

Even before you fully deploy phishing-resistant MFA, these Conditional Access and session policy controls reduce the impact of a successful AiTM session theft.

Require compliant device (device compliance policy)

Configure Conditional Access to require Intune-compliant or Hybrid Azure AD-joined devices for all application access. If the attacker replays the stolen session cookie from an unmanaged device, the compliance check fails and access is denied. This is the single most effective compensating control for AiTM because attacker infrastructure is never managed or enrolled.

In Microsoft Entra ID:

• Conditional Access policy: Grant access > Require device to be marked as compliant
• Or: Require Hybrid Azure AD joined (for fully on-premises managed devices)

Token Protection (token binding) for sign-in sessions

Microsoft Entra ID Token Protection (preview/GA depending on tenant) cryptographically binds the session token to the specific device it was issued to. A stolen token replayed from a different device fails validation. Enable via Conditional Access: Session > Require token protection for sign-in sessions. Currently supported for Windows desktop apps and some web scenarios.

Continuous Access Evaluation (CAE)

CAE allows the IdP to push real-time revocation signals to resource providers (Exchange, SharePoint, Teams) within seconds rather than waiting for token expiry. When you detect anomalous sign-in behavior (impossible travel, unfamiliar device), revoke the session in Entra ID and CAE propagates the revocation to all connected services in near-real time.

Sign-in frequency and persistent browser session policies

Reduce the useful life of stolen session cookies by setting aggressive sign-in frequency (e.g., 1-hour re-authentication for sensitive apps) and disabling 'Stay signed in' persistent sessions. A stolen 1-hour session token is less valuable than a 90-day persistent session.

Conditional Access Named Locations and IP restrictions

For high-value applications (finance systems, admin portals, code repositories), restrict access to known corporate IP ranges or VPN exit nodes. Attacker infrastructure is rarely within your named location ranges.

AiTM attacks leave distinctive signals in identity and network logs. The most reliable indicator is a successful authentication from a device or IP with no prior history immediately followed by lateral movement or email access from a new location.

Microsoft Entra ID / Sentinel detection queries:

Look for impossible travel (authentication from two geographically distant locations within a short time window), which indicates the victim authenticated from one location while the attacker replayed the session from another:

SigninLogs
| where ResultType == 0
| summarize Locations = make_set(Location), IPAddresses = make_set(IPAddress)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1

Look for unfamiliar device sign-ins immediately after MFA success:

SigninLogs
| where AuthenticationRequirement == "multiFactorAuthentication"
| where DeviceDetail.isCompliant == "false"
| where DeviceDetail.isManaged == "false"
| where ResultType == 0

Risky sign-in alerts in Entra ID Identity Protection

Enable all Entra ID Identity Protection risk policies. The 'Unfamiliar sign-in properties' and 'Atypical travel' risk detections are specifically tuned for AiTM-pattern session replays. Set User Risk Policy to require MFA or block for High risk users.

Email inbox rule creation post-authentication

AiTM attacks targeting BEC typically follow session capture with immediate inbox rule creation (forwarding rules, deletion rules) to hide ongoing access. Alert on inbox rule creation within 30 minutes of a new device sign-in:

OfficeActivity
| where Operation == "New-InboxRule"
| join kind=inner (SigninLogs | where isempty(DeviceDetail.deviceId)) on $left.UserId == $right.UserPrincipalName
| where abs(datetime_diff('minute', TimeGenerated, TimeGenerated1)) < 30

Full deployment of phishing-resistant MFA typically takes 3-6 months for a mid-size enterprise. Phase the rollout by risk tier to maximize protection quickly without overwhelming the help desk.