Critical Microsoft Entra Bug Bypasses Conditional Access Policies

Key Takeaways

• A critical vulnerability was discovered in Microsoft Entra Conditional Access Policies (CAPs).
• The flaw allowed attackers to bypass CAPs by exploiting Nested App Authentication (NAA) within specific first-party Microsoft applications.
• Attackers could obtain Microsoft Graph access tokens without CAP evaluation, potentially gaining unauthorized access to sensitive resources.
• The vulnerability, rated medium severity, has been patched by Microsoft.

A significant security flaw has been identified within Microsoft Entra Conditional Access Policies (CAPs), a cornerstone of security for Azure and Microsoft 365 environments. This vulnerability, uncovered by cybersecurity firm NetSPI, allowed for a bypass of these critical policies, potentially exposing organizations to unauthorized access even when robust authentication controls were mandated.

Conditional Access Policies are extensively utilized to enforce stringent security requirements, including multi-factor authentication (MFA), device compliance checks, and geographical restrictions. These policies are often relied upon as a primary defense mechanism, particularly in scenarios where user credentials might be compromised.

NetSPI’s investigation revealed that under specific circumstances, malicious actors could acquire Microsoft Graph access tokens while completely circumventing the evaluation of these crucial Conditional Access policies.

The Mechanism of Bypass

The bypass technique leverages a specific aspect of Microsoft’s custom OAuth implementation designed for Single Sign-On (SSO), particularly how refresh tokens are managed and exchanged between trusted first-party applications. This behavior builds on earlier research concerning Family of Client IDs (FOCI) and Nested App Authentication (NAA), also known as BroCI, which has been documented by various security researchers, including Secureworks and SpecterOps.

Nested App Authentication forms part of Microsoft’s SSO framework, enabling “host” applications, such as the Azure Portal, to function as authentication brokers for “nested” applications. This mechanism allows the host application to silently exchange its cached refresh token for an access token scoped to a child application, eliminating the need for users to reauthenticate when switching between services.

This process is facilitated through unique redirect URIs and additional parameters like brk_client_id and brk_redirect_uri within standard OAuth token requests, allowing tokens to be passed between applications without requiring user intervention.

The Vulnerable Components

The vulnerability specifically emerged when this NAA flow was used in conjunction with the ADIbizaUX client. ADIbizaUX is a widely used component within the Azure Portal responsible for identity and access management. This client exposes its own undocumented APIs and possesses a broad array of pre-consented Microsoft Graph permissions, granting it extensive capabilities to manage users, groups, applications, directories, and even Conditional Access policies themselves.

NetSPI’s findings demonstrated that when an Azure Portal refresh token was brokered to ADIbizaUX to request a Microsoft Graph token, the Conditional Access policies were not enforced, yet an access token was still successfully issued. This behavior contrasted sharply with similar refresh operations involving FOCI-enabled clients like Microsoft Teams, where CAPs correctly blocked access once a restrictive policy was active. This indicated the issue was specific to the NAA-based flow and certain client applications.

Further analysis by NetSPI identified two additional Microsoft Intune portal extension applications that similarly could leverage an Azure Portal refresh token via NAA to obtain Microsoft Graph tokens without Conditional Access enforcement.

Attack Scenario and Remediation

In a real-world attack scenario, an adversary would first need to compromise an Azure Portal refresh token. This could be achieved through common tactics such as a targeted phishing campaign or by employing an adversary-in-the-middle framework against login.microsoftonline.com. While the stolen token’s 24-hour fixed lifetime and non-renewable nature limit long-term persistence, it still provides a significant window for post-compromise activities within a compromised tenant.

NetSPI promptly reported the vulnerability to the Microsoft Security Response Center (MSRC), which classified it as a medium-severity issue. Microsoft has since rolled out a fix. Retesting by NetSPI has confirmed that the previously vulnerable NAA flows now correctly trigger Conditional Access blocking errors when applicable policies are in place.

This incident highlights the subtle yet impactful authorization weaknesses that can arise in cloud identity platforms due to deviations from standard OAuth protocols, even when such deviations are intended to enhance usability and Single Sign-On experiences.

What You Should Do

• Ensure all Microsoft Entra environments are updated with the latest patches from Microsoft to address this specific vulnerability.
• Regularly audit Conditional Access policies to confirm they are configured correctly and functioning as expected.
• Implement robust monitoring for suspicious activity related to token issuance and brokering within your Microsoft Entra ID logs.
• Educate users about phishing risks and the importance of secure credential handling to prevent initial token compromise.
• Consider implementing additional layers of security, such as identity protection features, to detect and remediate compromised identities proactively.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.