For many years, Multi-Factor Authentication has been one of the most effective controls against account compromise. Organizations have invested heavily in MFA rollout, and security teams have largely treated it as a near-bulletproof layer of defense. This assumption, while understandable, has long been proven incomplete. This is exactly what an AiTM MFA bypass exploits — and it is the scenario this article dissects.
Let's be clear from the outset: MFA is not optional. Any account left without it remains trivially exposed – brute-force attacks and credential stuffing are as prevalent as ever, and require no sophistication from an attacker. The question this article addresses is not whether to enforce MFA, but what comes after – because Adversary-in-the-Middle (AiTM) techniques have long demonstrated that MFA, in its traditional form, can be silently bypassed, leaving organizations at risk.
This is where the Swiss Cheese Model becomes a useful mental framework. No single security layer is perfect – each one has holes. But when you stack enough well-chosen layers together, the probability of an attacker finding a straight path through all of them drops dramatically. The challenge lies in choosing the right layers and understanding the operational constraints that come with each.
In this article, we will:
- Break down how AiTM attacks work in the context of Microsoft Entra ID, and why they succeed against traditional MFA
- Walk through the defensive layers that can meaningfully reduce your attack surface – from Phishing-resistant MFA and Conditional Access policies to Continuous Access Evaluation (CAE)
Whether you are reading this following an incident debrief or proactively reviewing your identity security posture, the goal is to give you the concepts and the tools to make the attacker's job significantly harder.
How does AiTM work?
At its core, an Adversary-in-the-Middle attack is straightforward: rather than stealing a user's password, the attacker positions themselves between the victim and the legitimate authentication service, transparently proxying the entire authentication flow, MFA included. Once the user has completed authentication, the attacker captures the resulting session token, which is already fully authenticated and can be replayed independently of any credential or second factor. The password becomes largely irrelevant; the session is the prize.
TLS remains intact throughout – the victim holds a valid encrypted connection to the proxy, and the proxy holds another to the legitimate service – meaning transport-layer encryption offers no protection against an attacker operating above it, at the application layer. In contrast, passkey-based authentication introduces an additional cryptographic challenge bound to the legitimate domain origin itself: the authenticator signs a server-provided challenge that is cryptographically tied to the relying party's domain, which can satisfy the origin integrity checks enforced by the WebAuthn/FIDO2 model.
The following scheme illustrates the complete scene of an AiTM MFA bypass in Entra that we'll going to explain step by step.
Getting the Victim to the Proxy
Before any token can be stolen, the attacker must first bring the victim to their infrastructure. This initial delivery phase can take several forms, and threat actors have progressively technical diversified their lure techniques to evade both user suspicion and filtering:
- Malicious hyperlinks embedded in emails remain the most common vector, typically dressed up as legitimate notifications from Microsoft, a shared document platform, or an internal IT communication
- QR codes embedded directly in emails or in attachments, a technique that has grown significantly in prevalence – in part because many email security gateways do not decode and inspect QR code content, effectively allowing the malicious URL to bypass link-scanning controls, and force users to use their smartphone which is far less protected or even managed by the organization. The use of attachments add a further layer of indirection to reduce the likelihood of automated detection
- Adversarial abuse of legitimate redirect services (open redirectors, trusted SaaS platforms), used to mask the final destination URL behind a reputable domain
This list is not exhaustive, and regardless of the delivery vector, the end goal is the same: redirect the victim to an attacker-controlled page that acts as a proxy in front of the genuine Microsoft Entra login portal.
The Proxy Mechanism in Practice
Once the victim lands on the attacker's infrastructure, the proxy forwards every request to Microsoft's real authentication endpoint and relays the responses back to the victim in real time during authentication. The user enters their credentials, receives and completes their MFA prompt, and is ultimately redirected to the expected application. Nothing feels wrong.
Behind the scenes, however, the attacker has captured both the credentials in transit and – more critically – the authenticated session cookies issued by Microsoft upon successful authentication. These cookies can then be injected into an attacker-controlled browser, granting full access to the victim's account without any further authentication requirement. At this point, MFA has provided no meaningful protection.
The account access
Finally, the malicious actor will use the claimed token to establish persistence and maintain access for as long as possible for further exploitation. This may include email rules (such as forwarding or deletion) and the enrollment of a new MFA device alongside the legitimate one. In a future article, we will explain in detail how to detect and remediate an account compromise on Microsoft Entra.
Attacker Infrastructure: More Sophisticated Than It Appears
A common misconception is that AiTM campaigns are straightforward, opportunistic operations. In practice, more capable threat actors invest considerably in protecting and sustaining their infrastructure:
- Anti-bot and CAPTCHA mechanisms are frequently deployed on phishing pages to prevent automated crawlers and security sandboxes from analyzing the infrastructure prematurely
- Victim filtering logic ranging from basic checks on the visitor's IP geo location and user-agent, to more targeted validation of the victim's email domain or even specific email address allows attackers to ensure only intended targets interact with the page, while presenting decoy content or dead links to anyone else
- Traffic distribution systems are used to use victim country servers in order to claim possible conditional access in place
The level of sophistication varies significantly between threat actors. Commodity phishing-as-a-service operators may implement only rudimentary filtering, while more advanced groups tailor their infrastructure carefully to the intended target organization. Platforms such as Evilginx, Modlishka, gold Muraena – as well as commercially operated phishing-as-a-service offerings like Tycoon 2FA gold Rockstar 2FA – provide ready-made, configurable proxy frameworks that abstract away the technical complexity.
Protections against AiTM attacks
The good news is that meaningful protections exist. The less comfortable truth is that none of them works in insulation – and several come with operational constraints that make them non-trivial to deploy at scale.
The Swiss Cheese Model applies here more directly than anywhere else in identity security. Each control has a defined scope, a set of prerequisites, and edges where it simply does not apply. The goal is not to find the one layer that eliminates the risk entirely, but to stack enough well-calibrated layers so that a successful end-to-end attack becomes operationally implausible for most threat actors.
Licensing – The Architectural Prerequisite
Before any meaningful control can be deployed, one constraint must be addressed that is often overlooked until it blocks implementation: licensing. The majority of the controls discussed in this section require Microsoft Entra ID P1 at minimum, and several of the most impactful ones are gated behind P2.
Conditional Access policies – even if it is a paid option which is the backbone of identity-centric defense – require at least an Entra ID P1 license. Entra ID P2 unlocks Identity Protection, which is particularly relevant to AiTM detection: it surfaces such signals as anomalous token characteristics – unusual lifetime, atypical issuance geography – that correlate directly with proxy-based session theft. Without P2, these detection are unavailable, and an AiTM campaign may run entirely undetected until the attacker takes a visible action on the compromised account.
Conditional Access – The Policy Enforcement Layer
Conditional Access is the primary enforcement mechanism within Microsoft Entra and, when properly configured, allows organizations to define granular conditions under which access is granted, challenged, or blocked. However, its effectiveness is entirely dependent on coverage and configuration quality – a partial or poorly scoped policy set creates exploitable gaps.
Global authentication coverage is the starting point. Conditional Access policies are only effective against the authentication flows they explicitly cover. Any uncovered user, or authentication method represents a potential bypass path. Coverage should be treated as a hard requirement, not a best-effort.
Blocking Device Code Flow is a specific and actionable recommendation. The device code authentication flow – designed for input-constrained devices – is regularly abused in social engineering scenarios and sits outside the standard interactive authentication flow that Conditional Access most naturally governs. Microsoft explicitly recommends blocking device code flow wherever possible.
Geolocation-based restrictions offer a meaningful signal when scoped correctly. Restricting authentication to expected countries or regions raises the cost for attackers operating from foreign infrastructure. That said, this control requires careful calibration: border regions, roaming users, and VPN usage can all generate false positives that erode trust in the policy if it is not anticipated.
Network-based restrictions enforcing the access from known, trusted IP ranges adds another layer of context. The same operational caveats apply: guest Wi-Fi networks, split-tunnel VPNs, and mobile data connections must be factored in to avoid disrupting legitimate users.
Managed versus unmanaged device enforcement allows organizations to apply differentiated policies depending on device compliance state. Requiring a managed, compliant device for access to sensitive applications significantly raises the bar for an attacker who has stolen a session token from a personal or unmanaged device.
Risk-based step-up authentication — requiring stronger authentication or blocking access entirely when sign-in risk is elevated. This requires Entra ID P2 and Identity Protection, but when in place, it allows the platform to respond dynamically to suspicious token characteristics or atypical sign-in patterns rather than relying solely on static policy conditions.
Enforcing phishing-resistant MFA authentication methods through Conditional Access is the strongest policy-level control available. Requiring FIDO2 keys, certificate-based authentication, or passkeys for specific user populations or application tiers ensures that the authentication method itself is immune to proxy interception regardless of how convincing the phishing lure may be.
Enforcing token protection allows to bind sessions to devices. It blocks the token portability across devices by using a cryptographic binding for the authentication token from the device which it was originally issued. When enforced, even a successfully captured token (from a stealer or AiTM framework) cannot be replayed on attacker-controlled infrastructure – the binding verification will fail. The Token Protection feature is currently in preview, supports native applications only (browser-based applications are not yet covered), and is available for Exchange Online and SharePoint Online at this stage. Windows support is available, with macOS and iOS in preview. This is a promising and directly relevant control, which can already be deployed because Exchange Online is by far the most targeted application
Continuous Access EvaluationCAE) allows to revoke trust in real time. Traditional token-based access models carry an inherent weakness: once a token is issued, it remains valid for its full lifetime. Continuous Access Evaluation addresses this by enabling Microsoft Entra to push real-time revocation signals to supported applications, allowing sessions to be terminated immediately when a risk event is detected – rather than waiting for the token to expire naturally. In the context of AiTM, CAE becomes particularly relevant when combined with Identity Protection risk signals. If an anomalous token usage is flagged mid-session, CAE-capable applications can be instructed to re-evaluate access immediately, forcing re-authentication and potentially blocking the attacker's active session. A notable recent development is the preview of Conditional Access policy enforcement through CAE – extending the real-time evaluation model beyond simple revocation to include policy condition checks during an active session. This further tightens the window in which a stolen session can be exploited before defensive controls can act.
Phishing-Resistant MFA — Closing the Proxy Gap
All of the controls described above reduce risk meaningfully – but none of them addresses the root cause as directly as phishing-resistant MFA. The defining characteristic of phishing-resistant authentication methods is that they are cryptographically bound to the origin of the authentication request. A proxy sitting between the victim and Microsoft cannot intercept a credential that only proves valid for the legitimate point of origin – the authentication simply will not succeed against a spoofed endpoint.
One important point about phishing resistant MFA is that it is phishing resistant only if there is no downgrade mechanism that allows to authenticate without it.
Three primary methods qualify as phishing-resistant within the Microsoft Entra ecosystem:
FIDO2 security keys are hardware devices that implement the FIDO2/WebAuthn standard. Authentication is performed through a challenge-response mechanism tied to the registered origin, making it inherently resistant to relay attacks. They are well-suited to shared workstations, privileged accounts, or environments where software-based authentication is undesirable.
Certificate-based authentication (CBA) relies on PKI-issued client certificates, stored on smart cards or hardware tokens. It is a mature and auditable mechanism, well-established in regulated and government environments, through it carries meaningful deployment overhead in terms of PKI infrastructure and certificate lifecycle management.
Windows Hello for Business (WHFB) with passkey provides phishing-resistant authentication anchored to a Windows device (managed or unmanaged), using either biometrics or a PIN backed by a TPM chip. It is the most seamless option for managed Windows environments — but as noted earlier, its dependency on device management has historically limited its applicability to BYOD and external user scenarios.
The mid-March 2025 general availability of passkeys in the Microsoft Authenticator application for unmanaged devices is, in our assessment, the single most impactful development for AiTM risk reduction available today in the Microsoft Entra ecosystem. To understand why, it is worth stepping back. One of the longstanding friction points in driving phishing-resistant MFA adoption has been the registration of a secondary personal device or a physical key as an authentication factor – a step that many users resist, for entirely legitimate reasons, and that introduces its own security considerations around device hygiene and personal data boundaries. WHFB elegantly sidesteps this problem: the authentication factor is the device the user is already working on. As long as it is equipped with a TPM chip, which is now a baseline hardware requirement across modern Windows devices, the passkey is generated, stored, and used locally, bound to that specific hardware. No additional device. No personal phone enrolled in a corporate directory, no push notification to intercept, and more important, no human behavior in the cryptographic chain of trust that can be fooled. The user authenticates with a biometric or PIN, the cryptographic challenge is resolved on-device, and the result is an authentication flow that an AiTM proxy infrastructure simply has no surface to attack. What was once a deployment challenge reserved for privileged or managed populations is now a realistic and operationally straightforward option for a significantly broader user base.
Conclusion
AiTM attacks expose a fundamental truth: in the identity perimeter, MFA alone is not sufficient. A stolen session token is as good as a stolen password — in some ways better, because it arrives pre-authenticated and carries none of the friction that typically triggers suspicion.
Microsoft's response to this threat is not a single control but a layered architecture. Conditional Access enforces context-aware decisions at every sign-in. Token Binding and Continuous Access Evaluation close the gap between initial authentication and persistent session abuse by anchoring tokens to verified device state and revoking them in near-real time when signals deteriorate. Phishing-resistant MFA — whether through FIDO2 passkeys or certificate-based authentication — removes the very credential that AiTM proxies are designed to intercept. And Identity Protection quietly sits beneath all of this, correlating behavioral signals across the tenant to surface the anomalies that a well-crafted phishing kit will inevitably produce.
No single one of these controls is a silver bullet. But an organization that has deployed comprehensive Conditional Access coverage, enforced phishing-resistant MFA where feasible, enabled CAE, and holds the appropriate license tier to surface Identity Protection signals has built a defensive posture that makes a successful AiTM campaign from initial phish to persistent access genuinely difficult to execute and harder still to sustain undetected.
About the CERT Intrinsec
This analysis was produced by the CERT Intrinsec — our incident response and digital forensics team. As a PRIS-qualified CERT (member of InterCERT France and the Campus Cyber), we investigate identity compromises like the AiTM scenarios described above every day, from the initial phish to persistent access, and help organizations detect, contain, and remediate them.
Wherever you are on that journey, our teams can help:
Facing a suspected account compromised or active intrusion? Our CERT mobilizes immediately, with an optional 24/7 on-call service.
Continuous detection & response across your cloud and SaaS environments — including Microsoft Entra ID — to catch anomalous token usage before it escalates.
targeted phishing and vishing campaigns to measure your teams' real-world resilience against AiTM-style lures.
