SMS, voice, and basic push MFA are highly susceptible to session theft. Once authentication completes, cookies and Primary Refresh Tokens become the real target.

Preface

After sign-in, Entra issues session artifacts that maintain authenticated state. Intercepting those artifacts lets attackers clone the user's session on an unauthorized machine. The authentication event is a moment; the session it produces can last days, and that is what adversary-in-the-middle (AiTM) kits are built to capture.

Problem

Kits such as Tycoon2FA, Rockstar2FA, and Evilginx3 reverse-proxy the Microsoft login page. Credentials and MFA are relayed in real time; the proxy then captures the session cookies and tokens issued at the end of the flow. Replay bypasses the full authentication flow, including MFA. Where attackers already have code running on a device, they go further and target the Primary Refresh Token (PRT), which is why device integrity matters as much as the sign-in method.

How the attack works in practice

  1. The user receives a lure (invoice, shared document, voicemail notice) linking to an attacker-controlled domain, often behind a CAPTCHA or redirect chain to evade scanners.
  2. The proxy fetches the genuine Microsoft sign-in page and relays it to the user, so branding and prompts look correct.
  3. The user enters their password and approves the push, enters the code, or answers the call. Each step is forwarded to Entra in real time.
  4. Entra issues session cookies to the proxy, which passes a working session through to the user and keeps a copy.
  5. The attacker imports the cookies into their own browser and is signed in as the user, typically within minutes.
  6. Common follow-on actions are inbox rules that hide replies, registering a new MFA method, reading mail for invoice fraud, and sending internal phishing from the trusted mailbox.

The weak point is that SMS codes, voice calls, TOTP codes, and simple push approvals do not know which website the user is actually on. Anything the user can type or approve can be relayed.

Why common approaches fail

  • Number matching helps against MFA fatigue, not AiTM. The proxy shows the user the real number.
  • Location-based policies are bypassed. Proxies and replay infrastructure often run from cloud hosting in the user's own country.
  • Password resets alone do not end the session. Refresh tokens and cookies need to be explicitly revoked.
  • Phishing-resistant methods are deployed but optional. If the user can still fall back to push or SMS, the attacker simply requests the weaker method.

Solution

Align with NIST SP 800-63B AAL3:

  1. Enforce phishing-resistant MFA: FIDO2 passkeys, passwordless Authenticator, or CBA bound to the legitimate domain.
  2. Enable Conditional Access Token Protection: Bind tokens to the device TPM so stolen cookies cannot be replayed elsewhere.
  3. Use Continuous Access Evaluation: Revoke sessions on IP anomalies, password resets, and similar critical signals.

Design guidance

Authentication strength, not just MFA

Use Conditional Access authentication strengths and require the built-in "Phishing-resistant MFA" strength for administrators first, then for high-risk groups such as finance and executives, then for everyone. FIDO2 security keys, device-bound passkeys, and Windows Hello for Business are bound to the origin of the real site, so a proxy on another domain cannot complete the ceremony. Remove weaker methods from the authentication methods policy for in-scope users, otherwise fallback undoes the control.

Device as a second factor

Require a compliant or Entra-joined device for access to sensitive applications. A replayed cookie arriving from an unmanaged attacker browser fails the device condition even if authentication was captured. Token Protection goes further by binding sign-in session tokens to the device, so replay from another machine is rejected. Coverage depends on client platform and resource, so check current support and run it in report-only mode before enforcing.

Session lifetime and revocation

Shorten sign-in frequency for privileged roles and unmanaged devices. Enable Continuous Access Evaluation, including strict location enforcement where your network egress is well defined, so critical events such as account disablement, password change, or high user risk take effect in near real time rather than at token expiry.

Implementation checklist

  1. Inventory registered authentication methods per user and identify who has only phishable methods.
  2. Issue FIDO2 keys or enable passkeys for administrators, and enforce the phishing-resistant strength on admin roles.
  3. Enable Temporary Access Pass for secure onboarding and recovery, so users never need SMS to bootstrap.
  4. Require compliant devices for sensitive apps; pilot Token Protection in report-only mode.
  5. Enable risk-based policies so "attacker in the middle" and anomalous token detections force reauthentication or block.
  6. Expand the phishing-resistant requirement in waves and retire SMS and voice.
  7. Update the incident playbook: revoke sessions, review MFA method changes, and remove inbox rules.

PowerShell: Audit Devices for Cryptographic Bindings

Start by understanding which devices are Entra joined, hybrid joined, or only registered, since only managed, TPM-backed devices can anchor device-bound controls:

Connect-MgGraph -Scopes "Device.Read.All"
Get-MgDevice -All | Select-Object DisplayName, DeviceId, OperatingSystem, TrustType | Format-Table

TrustType values are AzureAd (Entra joined), ServerAd (hybrid joined), and Workplace (registered).

Monitoring and detection

A stolen session usually shows up as the same session used from two different networks shortly apart. In Microsoft Sentinel: 

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == "0" and isnotempty(SessionId)
| summarize IPs = make_set(IPAddress, 10), Countries = make_set(Location, 10),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SessionId, UserPrincipalName
| where array_length(IPs) > 1 and array_length(Countries) > 1

Combine this with Identity Protection detections and post-compromise behavior:

AADUserRiskEvents
| where TimeGenerated > ago(7d)
| where RiskEventType in ("attackerinTheMiddle", "anomalousToken")
| project TimeGenerated, UserPrincipalName, RiskEventType, RiskLevel, IpAddress

Also alert on new inbox rules (New-InboxRule and Set-InboxRule in OfficeActivity) and on MFA method registration shortly after a risky sign-in.

Common mistakes

  • Excluding executives from phishing-resistant MFA because of convenience, when they are the most targeted users.
  • Leaving SMS enabled as a recovery method for users who already have passkeys.
  • Responding to an AiTM alert with a password reset only, without revoking sessions and reviewing new MFA methods.
  • Enforcing Token Protection without a report-only phase, breaking unsupported clients.

Where to start

Require phishing-resistant MFA for every privileged role now, and remove fallback methods for those accounts. Then add compliant-device requirements for sensitive apps, deploy the session anomaly hunt, and plan the wider rollout of passkeys in waves.