Continuous Access Evasion: Evading Microsoft CAE

Continuous Access Evasion: Evading Microsoft CAE

Speakers: Nikhil Mittal, Founder, Altered Security

Conference: BruCON

YouTube: https://www.youtube.com/watch?v=fVgUP9HQdP0

Overview

In this BruCON talk, Nikhil Mittal, founder of Altered Security and a seasoned red teamer, delivers a critical assessment of Microsoft's Continuous Access Evaluation (CAE). Introduced by Microsoft to bolster security in Entra ID (formerly Azure Active Directory) by combating access token replay attacks, CAE aims to provide near real-time revocation of access when suspicious activity is detected. Mittal's research, however, reveals significant limitations and numerous bypasses, leading him to provocatively rename the feature "Continuous Access Evasion."

The presentation delves into the mechanisms of CAE, dissects its intended protective capabilities, and then systematically demonstrates how various prevalent token theft techniques largely circumvent its controls. Mittal highlights that despite its promising premise, CAE, in its current implementation, falls short of providing robust protection against sophisticated adversaries. The talk serves as a stark reminder that even advanced security features require thorough scrutiny and consistent enforcement to be truly effective in enterprise environments.

Mittal's findings are particularly relevant for organizations heavily invested in Microsoft's cloud ecosystem, as they expose critical blind spots in identity-centric security models. His work provides invaluable insights for both red teams looking to understand and exploit these weaknesses, and blue teams striving to fortify their defenses against evolving threats in Azure and Entra ID.

Background

▶ Watch: Continuous Access Evaluation (CAE) aims to arrest token replay (5:30)

Microsoft's security strategy for Entra ID has seen significant innovation, particularly in contrast to its more stagnant on-premises Active Directory counterpart. A key development in this cloud-first approach is Continuous Access Evaluation (CAE), which became Generally Available (GA) in January 2022. CAE was specifically designed to address a critical vulnerability: access token replay attacks.

At the heart of modern web authentication, including Microsoft's identity platform, lies OAuth 2.0 and OpenID Connect (OIDC), which rely on bearer tokens, typically implemented as JSON Web Tokens (JWTs). These tokens, usually short-lived (60 to 90 minutes), act as temporary credentials. The fundamental problem identified by Mittal is that if an attacker steals an active access token, they can impersonate the legitimate user for the token's lifetime, gaining access to resources without needing the user's actual credentials. This identity impersonation is incredibly powerful because it often bypasses traditional security controls.

When an access token is replayed, there are typically no sign-in logs generated, which means crucial security features like Conditional Access (CA) policies and Entra ID Protection do not trigger. Furthermore, if the access token includes MFA claims, the attacker can even bypass resources explicitly protected by multi-factor authentication. This scenario creates a significant gap in an organization's security posture, as an attacker with a stolen token can operate silently and effectively.

CAE was introduced as a direct response to this challenge. Its core idea is to establish continuous communication between the resource provider (e.g., Azure Key Vault, an application) and the identity platform (Entra ID). If suspicious activity is detected — such as an access token being used from an unauthorized location or after a critical event like a password change — CAE aims to immediately revoke the token or block access. For CAE to function, both the client application requesting the token and the resource consuming it must be CAE capable. This capability is indicated by a specific claim, XMS_CCC set to CP1, within the JWT. A notable consequence of a CAE-enabled token is an extended lifetime, up to 28 hours, which Microsoft justifies by the presence of continuous evaluation, ostensibly enhancing user experience while maintaining security.

CAE is triggered by two main categories of events:

1. Critical Event Evaluation: Automatically triggered by events such as a user account being deleted or disabled, password changes, MFA being enabled for a user, session revocation, or a user being marked as high-risk by Entra ID Protection. The implication here is that without CAE, a token could remain valid even if the underlying user account is compromised or disabled.
2. Location-Based Conditional Access: If a Conditional Access policy restricts resource access to specific IP ranges, CAE can detect attempts to use a token from outside these allowed locations and block or revoke access in near real-time (though delays of 5-20 minutes can occur).

Mittal's research was driven by the observation that despite the promise of CAE, attackers often find ways to circumvent such controls. He illustrates the frustration of an attacker who, after considerable effort to steal an access token, finds their access blocked by a location-based CAE policy. The core of his talk is to analyze whether this "enraging" scenario is the norm or an exception, and how resilient CAE truly is against a range of contemporary token theft techniques.

Key Findings

▶ Watch: CAE triggers: critical events and location-based policies (17:40)

Nikhil Mittal's research into Microsoft's Continuous Access Evaluation (CAE) revealed a stark contrast between its intended purpose and its actual effectiveness in thwarting token replay attacks. His key findings underscore significant limitations in CAE's current implementation, providing a roadmap for adversaries and critical insights for defenders.

The most overarching finding is that CAE is not broadly effective against common token theft techniques. Mittal's extensive analysis, which examined various attack vectors against the Graph API (identity plane), Azure Resource Manager (ARM) API (management plane), and Data Plane (e.g., storage accounts), consistently showed that most methods of stealing access tokens result in non-CAE capable tokens. This means that even if an organization has CAE policies configured, many stolen tokens will simply bypass the evaluation mechanisms entirely.

Specifically, Mittal identified several critical blind spots and design choices that undermine CAE's efficacy:

• ARM API is not CAE capable: Crucially, the Azure Resource Manager (ARM) API, which governs access to virtually all Azure resources (VMs, storage accounts, key vaults, web applications), does not support CAE. This means an attacker who steals an ARM token can use it from any location globally without triggering CAE, allowing full evasion of location-based policies. This vulnerability extends further, as an ARM token could grant access to a resource that itself has a managed identity, potentially leading to the acquisition of Graph API tokens that are also non-CAE capable.
• Managed Identities are exempt from CAE: Managed Identities, a type of workload identity designed to allow Azure resources to authenticate to cloud services without hardcoded credentials, are explicitly exempted from CAE. They also bypass mandatory MFA enforcement and typically lack Conditional Access policies, or require additional, expensive licensing per identity for limited protection. With a default token lifetime of 24 hours, managed identities present a significant Achilles' heel, offering attackers long-lived, unrestricted access if compromised.
• CAE is a "best effort" and optional tool: A fundamental flaw highlighted by Mittal is that CAE is not enforced server-side. Clients must explicitly request a CAE-enabled token by sending the XMS_CCC claim with CP1 in their request. If this claim is not sent, a non-CAE token is issued. Mittal noted his frustration during the research, wishing for CAE to "wake up and work somewhere," only to find that its optional nature severely limits its widespread impact.
• Inconsistent CAE capability from active sessions/Office apps: While stealing tokens from an active session or some Office applications might yield CAE-capable tokens, this behavior was found to be inconsistent and unpredictable. Even with the same client ID (e.g., Office app), some tokens would include the XMS_CCC claim, while others would not, making reliable defense or attack planning challenging.
• Project Opel (M365 Cloud PCs) as a bypass vector: Mittal identified Project Opel, Microsoft's initiative for M365 Cloud PCs, as a significant boon for attackers. These cloud PCs are Entra-joined, company-owned, and managed, satisfying many common Conditional Access requirements. Crucially, the web page for Project Opel does not enforce MFA for login. An attacker compromising a user with an Opel license can leverage this to gain access to a fully compliant device, and any tokens obtained from within this environment would inherently bypass location-based and device-based Conditional Access policies, effectively neutralizing CAE's limited scope.

In summary, Mittal's research concludes that CAE, while conceptually sound, is largely ineffective in its current form due to its optional nature, critical exemptions (ARM, Managed Identities), and inconsistent application across various attack surfaces. The vast majority of real-world token theft scenarios would still lead to successful evasion of CAE, leaving organizations vulnerable to the very replay attacks it was designed to prevent.

Technical Deep Dive

▶ Watch: Summary of CAE effectiveness against token stealing attacks (44:30)

The core of Nikhil Mittal's research involved systematically evaluating the efficacy of Continuous Access Evaluation (CAE) against a wide array of prevalent Entra ID and Azure token theft techniques. His methodology focused on determining whether the access tokens obtained through these attack vectors were CAE capable (i.e., contained the XMS_CCC claim set to CP1) or not. The findings consistently pointed to significant gaps in CAE's coverage.

Mittal categorized the attacks and token sources, examining their impact on three planes: the identity plane (Graph API), the management plane (Azure Resource Manager - ARM API), and the data plane (e.g., storage account access). Importantly, his research primarily focused on access tokens, largely excluding refresh tokens due to their tendency to generate sign-in events, which makes them less OPSEC-safe for red team operations.

Here's a breakdown of the techniques analyzed and their CAE implications:

1. Consent Phishing (Consent Fix):

• Mechanism: This technique, popularized by Push Security, relies on social engineering. An attacker crafts a phishing page that prompts a user for their username, then redirects them to a legitimate Microsoft login page pre-populated with that username. The trick is that the redirect URI points to localhost or an attacker-controlled endpoint. When the user completes authentication (including MFA), they see an error, but the attacker intercepts the authorization URL. This URL can then be exchanged at Microsoft's token endpoint for access tokens.
• Evasion: This method effectively evades both Conditional Access and MFA because the user authenticates directly with Microsoft.
• CAE Impact: Tokens obtained via consent phishing are generally not CAE capable. The flow typically does not explicitly request the XMS_CCC claim.

1. Illicit Consent Grant:

• Mechanism: Similar to consent phishing, this attack abuses the redirect URI. The user logs into a legitimate Microsoft page, completes MFA, and is then prompted to consent to an attacker-controlled application. Once consented, their tokens are redirected to the attacker's application.
• Evasion: Also evades Conditional Access and MFA.
• CAE Impact: Tokens obtained are typically not CAE capable, especially given that normal users can only consent to a limited set of permissions.

1. Device Code Phishing:

• Mechanism: This widely abused technique leverages the device code authentication flow, intended for devices with limited input (e.g., smart TVs). An attacker initiates a device code flow, obtaining a unique code. They then social engineer the victim to visit microsoft.com/device login and enter this code. The victim authenticates from their own, potentially compliant device, completing MFA. The attacker, however, receives the resulting access tokens.
• Evasion: Highly effective at bypassing Conditional Access and MFA because the authentication occurs on the victim's legitimate, often MDM-managed device.
• CAE Impact: Tokens obtained are generally not CAE capable. The authentication context does not typically include the explicit CAE request.

1. Attacker-in-the-Middle (Evilginx/EvilJinx):

• Mechanism: Tools like Evilginx (or EvilJinx) act as a reverse proxy, sitting between the victim and the legitimate login page. The attacker relays credentials, including username, password, and MFA responses, in real-time. This technique is more complex to execute but highly effective.
• Evasion: Evades Conditional Access and most forms of MFA, particularly those that are not phishing-resistant (e.g., FIDO2 keys or passkeys can defeat this).
• CAE Impact: Tokens stolen in this manner are typically not CAE capable, as the attacker is simply relaying the session, not necessarily requesting a CAE-enabled token.

1. Family of Client IDs (Folki) and Broker Client IDs (Broki):

• Mechanism: These techniques exploit Microsoft's internal application relationships. Folki abuses first-party, pre-consented applications (e.g., Microsoft Office, Teams) that have default privileges within an Entra ID tenant. An attacker with a refresh token for one application (e.g., Office) can exchange it for an access token for another related application (e.g., Teams) within the same "family" of client IDs, potentially bypassing Conditional Access or gaining broader permissions. Broki similarly abuses the ability of applications like the Azure portal to "broker" credentials to access other resources.
• Evasion: Can bypass specific Conditional Access policies or achieve a wider scope of access.
• CAE Impact: Tokens obtained through Folki/Broki are generally not CAE capable.

1. Agent Identities:

• Mechanism: Introduced by Microsoft, Agent Identities are tied to AI services. A blueprint principle can spawn multiple agent user identities that inherit permissions from the blueprint. If an attacker gains owner role on a blueprint (e.g., by adding a client secret), they can create numerous identities with inherited permissions (e.g., Policy.ReadWrite.All, Application.ReadWrite.All), creating a massive attack surface.
• Evasion: The inherited permissions and the ability to spawn many identities make this a powerful vector.
• CAE Impact: Tokens for agent identities are implicitly not CAE capable, as they are workload identities and typically not covered.

1. Primary Refresh Token (PRT):

• Mechanism: The Primary Refresh Token (PRT) is considered the "bomb" of tokens on Entra ID-joined or hybrid-joined machines. If compromised, a PRT grants access to virtually any cloud resource the user can access, and sometimes even on-premises resources. While its theft is restricted by TPM on modern devices, it remains a cakewalk on non-TPM machines (e.g., using tools like Mimikatz).
• Evasion: A PRT is the ultimate credential, granting comprehensive access.
• CAE Impact: Tokens derived from a PRT are generally not CAE capable in the context of CAE's specific triggers.

1. Stealing from Virtual Machines (VMs) and Endpoints:

• Browser Sessions: Attackers can steal ESTS Ostar or ESTS persistent cookies from authenticated browser sessions to replay them or exchange them for access tokens.
• Disk Storage: Azure PowerShell and Azure CLI store tokens in ~/.azure/ in the user profile. Office applications (like Word, Teams) store tokens in Local AppData\Microsoft\TokenBroker\Cache. While these are DPAPI protected, an attacker with user context on a compromised VM can easily decrypt them. Notably, for workload identities using token-based logins, tokens can still be cached in cleartext in ~/.azure/ if not explicitly logged out.
• Memory Dumping: For applications like Microsoft Teams and Office, access tokens are often not protected in memory. An attacker can dump the memory of these processes, exfiltrate it, and then extract tokens. While this takes time, machine speeds can make it viable before token expiration.
• Traffic Interception: With TLS interception, tools like MITM dump can capture access tokens directly from network traffic.
• Abusing Existing Sessions: Any process running in the user's context or with the user's privileges on a VM can leverage an existing Azure CLI or Azure PowerShell session without requiring re-authentication.
• CAE Impact: Only tokens stolen from active sessions or, inconsistently, from some Office applications were found to be CAE capable. The vast majority of tokens obtained through disk, memory, or traffic interception were not CAE capable.

The "Summary Table" (as described by Mittal):

Mittal synthesized his findings into a summary table (not explicitly provided in the transcript, but described in detail). This table indicated that for almost all the discussed attack techniques, the resulting access tokens for Graph API, ARM API, and Data Plane access were not CAE capable. The only exceptions were "active session" token theft and, randomly, some tokens from "Office applications" which might or might not have the XMS_CCC claim. This led to his conclusion that CAE's current implementation is largely ineffective.

Demo / Proof of Concept

▶ Watch: Fundamental CAE flaws: optional, managed identities exempted (50:00)

While Nikhil Mittal's talk did not feature a live, step-by-step demonstration of an attack, his presentation served as a comprehensive analytical proof of concept for his research findings. He illustrated the practical implications of CAE's limitations through a combination of conceptual diagrams and direct evidence from his testing.

Mittal showed a screenshot of a scenario where CAE did trigger, displaying the message "Location condition evaluation satisfied." This depicted the frustration of an attacker attempting to use a stolen token from an unapproved location, confirming that CAE can block access under specific, configured circumstances. However, the core of his "proof" lay in the extensive analysis summarized in his (described) table, which systematically mapped various token theft techniques against their ability to yield CAE-capable tokens for different API planes (Graph, ARM, Data Plane). This analytical approach, backed by his red teaming experience, demonstrated that the vast majority of these attack vectors resulted in non-CAE tokens, effectively proving CAE's widespread evasion.

Defensive Implications

▶ Watch: Recommendations to improve CAE effectiveness and enforcement (55:00)

Nikhil Mittal's research presents critical defensive implications for organizations relying on Microsoft's cloud security features, particularly Continuous Access Evaluation (CAE). His findings underscore that CAE, in its current state, is largely insufficient as a standalone control against sophisticated access token replay attacks.

Microsoft's official guidance typically advocates for a layered defense strategy, involving multiple security products and licensing tiers. While this approach is sound in principle, Mittal's work reveals that CAE, positioned as a "detect plus mitigate" control against token replay, has significant blind spots that even a layered defense might miss if not properly configured or if the underlying CAE limitations persist. The speaker also explicitly mentions that Global Secure Access (GSA) does not inherently protect against CAE evasion if a token is stolen from a GSA-protected resource; the stolen token can still be used from outside the protected perimeter.

Mittal proposes several crucial improvements to make CAE truly effective:

1. Mandatory Server-Side Enforcement: The most impactful recommendation is to shift CAE from an optional, "best effort" client-side request to a mandatory, server-side enforcement. If an API endpoint or resource is CAE-capable, it should always and without exception issue and accept only CAE-capable tokens. This would force clients to explicitly request CAE tokens and ensure that resources consistently evaluate them, eliminating the current loophole where a non-CAE token is issued by default if not explicitly requested. Mittal challenges Microsoft to implement this, acknowledging it might initially upset users but is necessary for robust security.

1. Microsoft's Internal Adoption: Microsoft itself needs to consistently use and enforce CAE across its own services and applications. The inconsistency observed (e.g., some Office app tokens being CAE-capable, others not) undermines confidence and predictability.

1. Expanded Trigger Events: Currently, CAE primarily triggers on critical events (user disabled, password change, etc.) and location-based Conditional Access. Mittal suggests expanding the scope of triggers to include more granular and impactful identity-related events. For example, changes in group membership or role assignments (both in Entra ID and Azure) should trigger CAE, as these can lead to significant privilege escalation, vertically or horizontally. Tying CAE into features like Privileged Identity Management (PIM), where temporary role activations could be immediately evaluated, would also greatly enhance its utility.

1. Coverage for Managed Identities: Managed Identities are identified as a critical Achilles' heel. They are currently exempt from CAE, mandatory MFA, and often lack comprehensive Conditional Access policies (requiring expensive premium workload identity licenses for limited protection). With their 24-hour token lifetime, they represent a high-value target for attackers. CAE, MFA, and Conditional Access policies must be extended to cover managed identities comprehensively to close this significant security gap.

1. Report-Only Mode for CAE: Similar to Conditional Access policies, CAE should introduce a "report-only" mode. This would allow organizations to deploy and monitor CAE policies without immediately enforcing blocks or revocations, helping them understand the potential impact and refine configurations before full enforcement.

In essence, Mittal argues that until these fundamental changes are implemented, defenders cannot fully rely on CAE to protect against access token replay. Organizations must assume that stolen tokens, particularly those obtained through the common methods detailed in his talk, will likely bypass CAE. Therefore, defenses must focus on preventing token theft in the first place, enhancing monitoring for post-exploitation activity that doesn't involve traditional sign-ins, and implementing robust Conditional Access policies that are not easily circumvented by token replay.

Key Takeaways

• CAE is Currently Ineffective: Despite its promising concept, Microsoft's Continuous Access Evaluation (CAE) is largely ineffective in its current implementation against a wide range of common access token replay attacks.
• Optional by Design: CAE is a "best effort" control; clients must explicitly request CAE-enabled tokens. If not, a non-CAE token is issued, allowing full evasion.
• Major Exemptions Exist: The Azure Resource Manager (ARM) API and Managed Identities are critical blind spots, being entirely exempt from CAE. This provides attackers with significant avenues for persistent, undetected access to Azure resources.
• Inconsistent Coverage: Even when CAE might apply (e.g., active sessions, some Office apps), its application is inconsistent, making it unreliable as a security control.
• MFA and CA Bypass: Many token theft techniques successfully bypass both Multi-Factor Authentication (MFA) and Conditional Access (CA) policies, even when CAE is intended to supplement them.
• Proposed Improvements: For CAE to be truly valuable, Microsoft must enforce it server-side, expand its trigger events beyond critical user actions and locations, and extend its coverage to include Managed Identities.

About the Speaker(s)

Nikhil Mittal is the founder of Altered Security, a company specializing in red teaming and security training. With over 15 years of experience in offensive security, Nikhil is a recognized expert and passionate researcher in the realm of Microsoft technologies, particularly Azure Entra ID and other identity-based attacks. He is a prolific and recurring speaker at major security conferences such as Defcon, Blackhat, and BruCON, where he has been presenting and training since 2016. His work consistently focuses on feature abuse—exploiting inherent functionalities rather than traditional vulnerabilities—across technologies like Active Directory, Entra ID, and now, Copilot. Through Altered Security, Nikhil is also committed to providing high-quality, affordable security training, aiming to make advanced knowledge accessible to a broader audience.