Reconstructing AiTM MFA Bypass: Session Token Theft in Entra ID

We spent years telling users to check the URL bar and hit approve on their authenticator apps, pretending that would be enough. The harsh reality of modern incident response is that strong authentication is only as good as the session it establishes. If an attacker can grab the ESTSAUTH cookie after a user successfully completes a number-matching prompt, your zero-trust architecture just handed them the keys to the kingdom. SOC analysts are staring at logs showing successful multi-factor authentication, while simultaneously watching mailboxes get dumped and conditional access policies bypassed.

This specific technique is known as an aitm mfa bypass, and it is entirely dominating the identity compromise landscape. Adversaries are no longer trying to guess passwords or spam push notifications until someone gives up. They are acting as a transparent proxy, letting the victim do the hard work of authenticating with Microsoft, and then plucking the resulting session token out of the HTTP response. The credential itself is almost secondary. The bearer token is the ultimate prize.

Defending against this requires shifting our focus from the point of authentication to the lifecycle of the session token itself. You cannot block what you cannot see, so we need to look at exactly what a proxy attack leaves behind in Entra ID telemetry. The evidence is always there if you know which fields to correlate and which anomalies indicate a stolen session jumping between geographic locations.

Proxying the Authentication Dance

Traditional credential harvesting sites are entirely static. They serve a fake login page, capture the POST request containing the username and password, and write it to a database. That approach fails the moment a multi-factor authentication challenge appears, because the static site cannot dynamically interact with the identity provider. To bypass this, frameworks like Evilginx, Modlishka, and Muraena operate as sophisticated reverse proxies. They sit directly between the victim and the legitimate identity provider, intercepting traffic in real time.

When a user clicks a malicious link, their browser initiates a TLS connection to the attacker server. The attacker server concurrently opens a connection to login.microsoftonline.com. Every GET and POST request the victim makes is forwarded to Microsoft. Every challenge, image, and JavaScript blob Microsoft sends back is forwarded to the victim. The proxy simply modifies the domain names in the HTTP headers and response bodies on the fly so the browser accepts the routing without triggering cross-origin resource sharing errors.

Stealing the Session Cookies

The critical compromise happens at the very end of the authentication flow. Once the victim successfully answers an MFA prompt, Microsoft generates a Set-Cookie header containing the primary refresh token and the session cookie. Because the attacker controls the infrastructure routing this traffic, they log that header in cleartext before passing it down to the victim. The user sees their actual inbox load and suspects nothing out of the ordinary.

The attacker then exports a localized configuration file containing a valid, fully authenticated session. Phishlets, the configuration files used by Evilginx, are specifically tuned to identify and capture these high-value cookies. By targeting the ESTSAUTH and ESTSAUTHPERSISTENT cookies in Microsoft 365, the adversary gains a bearer token that proves to any Microsoft service that the user has already satisfied all authentication requirements.

Why Number Matching Falls Short

Microsoft rolled out number matching to kill MFA fatigue attacks, and it worked beautifully against threat groups who relied on spamming push notifications late at night. But threat actors adapt rapidly. Major ransomware affiliates and data extortion groups immediately pivoted to adversary-in-the-middle infrastructure because it renders the authentication method irrelevant.

In a proxy scenario, number matching is useless as a defensive control. The user is actively trying to log in because they believe they are accessing a legitimate resource. They see a number on their screen, they type it into their mobile device, and the authentication succeeds. The cryptographic validation happens securely between Microsoft and the user device, but the resulting access token is handed directly back through the attacker proxy.

Post-Exploitation Tactics

Once they possess the session cookie, operators import it into a localized browser instance using standard developer tools. From there, they pivot into the Microsoft 365 portal, bypassing any Conditional Access policies that only require multi-factor authentication. The system sees a valid token and assumes the user is continuing an existing session.

Their next steps focus entirely on persistence. They register a new device to the user account, often an authenticator app they control, or they pivot to the victim cloud infrastructure if single sign-on is configured. We routinely see attackers navigating to the Entra ID security info page to add a new FIDO2 key or alternate phone number, ensuring they retain access long after the original stolen session cookie expires.

Trace Evidence in Entra ID Telemetry

Catching an in-progress session hijack requires analyzing Entra ID interactive and non-interactive sign-in logs. The primary challenge is that the initial authentication event looks entirely legitimate. The user typed their password, satisfied the MFA challenge, and logged in. The anomaly only appears when the attacker replays the stolen token from a different location or a different device configuration.

The most glaring indicator is a sudden change in network infrastructure without a corresponding new interactive authentication event. If a session is established from a residential ISP in Chicago, and ten minutes later that exact same identifier is used to query the Graph API from a commercial VPN exit node in Amsterdam, you have an active token replay scenario. Attackers use proxy networks to hide their true origin, which often results in impossible travel alerts.

"properties": {"originalIP": "192.0.2.45", "sessionId": "8a9b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"} — Entra ID raw log excerpt showing session binding details

You also need to heavily scrutinize browser fingerprint anomalies. Adversaries frequently fail to match the User-Agent string of their replay browser to the victim original browser. If the initial interactive sign-in log shows an Edge browser on Windows 11, but subsequent non-interactive logs tied to the same session show a Chrome browser on macOS, that is a high-fidelity alert for token theft. The identity platform records these variations meticulously.

Continuous Access Evaluation was designed to mitigate session theft by allowing Microsoft to revoke tokens in real time when critical events occur, such as a password reset or a location change. However, CAE relies on the specific resource provider, like Exchange Online, understanding the IP address of the client making the request. If the attacker routes their replay traffic through a proxy that matches the victim geographic region, they can often evade immediate CAE revocation, forcing analysts to rely heavily on manual anomaly detection.

Correlating Auth Events with API Access

A standalone anomalous IP alert is notoriously noisy. Users travel, corporate VPNs drop and reconnect, and mobile carriers route traffic through bizarre geographical locations. To build a reliable detection mechanism for session replay, you must pivot on the SessionId field within your security information and event management system. This specific identifier ties the interactive sign-in where the token was minted to every subsequent non-interactive API call that relies on it.

One of the major hurdles in correlating these events is that Microsoft issues different tokens for different resource providers. A session token used for Exchange Online might have a different identifier than the one used for SharePoint Online. Analysts must understand the hierarchical nature of the primary refresh token and how it delegates access across the Microsoft 365 ecosystem. Failing to track the pivot across different resource providers will result in an incomplete picture of the incident blast radius.

Tracking the Blast Radius

Start by filtering your Log Analytics workspace or Sentinel instance for the suspected SessionId. Look closely at the ResourceDisplayName field across the resulting events. You are hunting for anomalous access to high-value administrative resources. Attackers rarely stop at reading emails in Exchange Online. They use the stolen session to access the Azure portal, modify enterprise applications, and grant themselves persistent OAuth permissions.

Pay special attention to the AppDisplayName field during this correlation. If you see the Microsoft Azure CLI or Microsoft Graph Command Line Tools appearing in the log stream under a session that originated from a standard web browser login, someone is driving that session via automation. A human user reading their email does not suddenly switch to executing automated Graph API queries from the same browser session.

Architecting Resilient Defenses

You cannot train users to consistently spot a perfectly proxied login page. The domains are often highly convincing lookalikes utilizing internationalized domain names, and the TLS certificates are mathematically valid. The defense must happen at the architecture level, specifically by binding the session token to the physical device so that it becomes completely useless if stolen and exported to an attacker machine.

The most effective architectural control is configuring Conditional Access to require a compliant device or a hybrid joined device. This requires a device certificate to prove the authentication request is coming from corporate hardware. When an Evilginx proxy attempts to facilitate this flow, it fails. The proxy does not hold the necessary device certificate, and the resulting token cannot be issued or utilized outside of the trusted hardware boundary.

Implementing Token Binding and FIDO2

Microsoft is aggressively pushing Token Protection for Entra ID, which cryptographically binds tokens to the primary refresh token of the Windows device. If an attacker exports the session cookie and tries to replay it from an unmanaged machine, the cryptographic signature fails validation, and the access request is outright denied. This breaks the fundamental mechanics of the adversary-in-the-middle attack chain.

Transitioning to FIDO2 security keys or passkeys provides another layer of absolute defense. FIDO2 implements origin binding, meaning the authentication cryptographic material is tied strictly to the domain the user is visiting. If the user is on a proxied domain, the security key will refuse to provide the credentials for the legitimate Microsoft login portal, stopping the proxy attack before a session can even be established.

You must also drastically shorten session lifetimes. The default rolling window of ninety days is a massive operational liability. Implementing strict sign-in frequency policies for administrative roles and critical applications significantly reduces the utility of a stolen token. If the token expires in two hours, the adversary has a very tight window to establish persistent access before they are forcibly kicked out of the environment.

The takeaway

The shift from credential theft to session theft is a permanent evolution in adversary tradecraft. As long as we rely on bearer tokens that can be easily copied and pasted between browsers, threat actors will build highly automated infrastructure to intercept them. The defensive goal is no longer just stopping the bad login, but detecting the illegitimate use of a previously validated session. Relying on basic multi-factor authentication is a recipe for a devastating breach.

Maturing your detection engineering around session correlation and device binding is the only way to survive the current wave of identity attacks. Platforms like MailSleuth.AI provide the telemetry analysis required to streamline the investigation of these complex attack chains, but the foundation rests on understanding exactly how the tokens are stolen. Take a hard look at your architecture today. Are your Conditional Access policies actually evaluating the cryptographic identity of the device, or are they just checking a box and hoping for the best?