UnOAuthorized: A Technique to Privilege Escalation to Global Administrator

UnOAuthorized: A Technique to Privilege Escalation to Global Administrator

Speakers: Eric Woodruff, Senior Security Researcher, Semperis

Conference: Black Hat USA

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

Overview

In the realm of modern cloud identity management, achieving Global Administrator privileges within a Microsoft Entra ID (formerly Azure Active Directory) tenant represents the ultimate compromise for an attacker. Eric Woodruff, a Senior Security Researcher at Semperis, presented "UnOAuthorized" at Black Hat USA, a talk detailing a novel technique that allows an attacker with the seemingly scoped Application Administrator role to escalate their privileges to Global Administrator equivalent. This research sheds critical light on the often-misunderstood complexities of application registrations and service principals in Entra ID, demonstrating how misconfigurations or overlooked functionalities can create pathways for significant privilege escalation.

Woodruff's presentation introduces the concept of "UnOAuthorized" as a portmanteau of "unauthorized" and "OAuth 2," reflecting the core nature of the vulnerability: an unauthorized privilege escalation via the mechanisms of modern cloud authorization. The talk is particularly timely, following incidents like the "Midnight Blizzard" attacks, which underscored the critical importance of securing cloud identity infrastructure. For organizations heavily invested in Microsoft 365, Azure, and other components of the Microsoft cloud ecosystem, understanding and mitigating this attack vector is paramount, as a compromise of Global Administrator means "game over" for the entire digital estate.

This article delves into Woodruff's findings, exploring the technical intricacies of Entra ID roles, multi-tenant applications, and service principals that enable this attack. It provides a comprehensive breakdown of the methodology, the underlying mechanisms, and crucial defensive implications for security professionals aiming to protect their cloud environments from such sophisticated threats.

Background

▶ Watch: Introduction and UnOAuthorized concept explained (0:00)

The landscape of cloud identity management, particularly within Microsoft Entra ID, is notoriously complex, often leading to gaps in understanding even among seasoned identity professionals. Central to this complexity are application registrations and service principals, which govern how applications interact with and are authorized within a tenant. Prior research has extensively explored these areas, highlighting their potential as initial footholds for attackers. However, the specific nuances of how delegated administrative roles interact with these components remained fertile ground for discovery.

Eric Woodruff’s research builds upon this existing body of knowledge, focusing on the Application Administrator role (which includes both "Application Administrator" and "Cloud Application Administrator"). This role is designed to manage the lifecycle of applications within a tenant, enabling tasks such as onboarding SAML and OpenID Connect applications, integrating SaaS providers like Salesforce and Workday, and generally overseeing application functionality. Crucially, these roles are intended to operate within strict "swim lanes," meaning an Application Administrator in a default, "greenfield" tenant should be blocked (receiving a 403 Unauthorized error from Microsoft Graph) from managing other administrative roles. This segregation of duties is a fundamental security principle, preventing lower-privileged administrators from elevating their own permissions or those of others.

The talk emphasizes the analogy of the Windows Services Control Panel: just as a Windows user doesn't need to understand every background service for the OS to function, Entra ID tenants contain hundreds, if not thousands, of service principals that represent Microsoft's own internal applications (e.g., Exchange Online, SharePoint Online, Teams, Azure Portal, M365 Admin Portal). These are essential for the Microsoft cloud estate to operate but are largely opaque to tenant administrators. A key distinction is made between an app registration, which is the global definition of an application, and a service principal, which is the local instance of that application within a specific tenant. When a multi-tenant application (like a SaaS product) is consented to by a customer, an admin consent grant process creates a service principal in the customer's tenant, inheriting the permissions defined in the original app registration. These service principals are security principals themselves, capable of being assigned permissions and roles.

The vulnerability hinges on the intersection of the Application Administrator's delegated authority and the implicit trust placed in these system-level, Microsoft-owned service principals. While an Application Administrator cannot directly elevate their own user role, the research explores whether they can manipulate the credentials of existing service principals in a way that bypasses their intended "swim lane" restrictions, ultimately leading to a Global Administrator equivalent compromise. The motivation for such an attack is clear: in the cloud, gaining Global Administrator is the equivalent of achieving Domain Administrator in an on-premises Active Directory environment, signifying complete control over the organization's Microsoft cloud assets.

Key Findings

▶ Watch: Understanding the Application Administrator role and its limits (2:00)

The core discovery presented in "UnOAuthorized" is that an attacker with the Application Administrator role can achieve a privilege escalation to Global Administrator equivalent within a Microsoft Entra ID tenant. This bypasses the intended security boundaries of the Application Administrator role, which is designed to prevent direct manipulation of other administrative roles or high-privileged entities.

Woodruff identifies a critical vulnerability stemming from the Application Administrator's ability to manage credentials (both secrets and certificates) for service principals within the tenant, even for those service principals that represent Microsoft's own multi-tenant applications. While an Application Administrator is typically restricted from assigning highly privileged roles to users or modifying the permissions of other administrative roles, they are not restricted from adding credentials to existing service principals, regardless of the service principal's inherent permissions or its owner.

The key findings can be summarized as follows:

1. Credential Management Scope: The Application Administrator role, despite its "swim lane" design, possesses the capability to add new secrets or certificates to any service principal within its scope of management. This includes service principals that are created as part of an admin consent grant for multi-tenant applications, even if those applications are owned by Microsoft.
2. Microsoft-Owned Service Principals as Targets: Entra ID tenants contain hundreds of service principals representing core Microsoft services (e.g., Exchange Online, SharePoint Online, Teams, Azure Portal, M365 Admin Portal). These are identifiable by their appOwnerTenantId being set to Microsoft. Many of these service principals inherently possess very high permissions required for their functionality across the Microsoft cloud estate.
3. Bypassing Role Restrictions: By adding a new credential (a secret/password) to a high-privileged, Microsoft-owned service principal, an Application Administrator effectively gains control over that service principal's identity. They can then use this newly acquired credential to obtain an access token on behalf of the service principal.
4. Implicit Privilege Inheritance: Once an attacker has an access token for a service principal, they can perform any actions that the service principal itself is authorized to do. If the targeted Microsoft-owned service principal holds permissions equivalent to or exceeding those of a Global Administrator (e.g., Directory.ReadWrite.All, User.ReadWrite.All), the attacker effectively inherits these elevated privileges without ever directly assigning themselves the Global Administrator role. This is the mechanism of privilege escalation.
5. Stealthy Persistence: The addition of a new credential to an existing service principal can be a relatively stealthy operation compared to direct role assignments, potentially allowing attackers to maintain persistence with elevated privileges.
6. Attack Surface: The sheer number of Microsoft-owned service principals (Woodruff observed 573 in one tenant) presents a significant attack surface, as many of these likely possess permissions that could be abused for privilege escalation.

In essence, the "UnOAuthorized" technique leverages a design flaw or an overlooked permission interaction within Entra ID. While Application Administrators are restricted from direct role management, their ability to manage credentials for any service principal, combined with the often-overlooked high privileges of Microsoft's own service principals, creates an indirect but highly effective path to Global Administrator equivalent control.

Technical Deep Dive

▶ Watch: Deep dive into multi-tenant applications and permissions (4:00)

The technical foundation of the "UnOAuthorized" attack lies in understanding the interplay between application registrations, service principals, multi-tenant applications, and the permissions model within Microsoft Entra ID.

At its core, a multi-tenant application is software published by a SaaS provider that can be used by multiple Entra ID tenants. The process begins with the SaaS provider (developer) creating an app registration in their own Entra tenant. This app registration serves as the global blueprint for the application, defining its identity, capabilities, and the permissions it requires to function. For example, a typical application might request permissions such as User.ReadWrite.All (to read and write all user profiles), Directory.ReadWrite.All (to read and write directory data), and Group.Read.All (to read all groups). The developer then assigns credentials to this app registration, which can be either a secret (effectively a password) or an asymmetric key pair (certificates). These credentials allow the application to authenticate itself to Entra ID.

When a customer tenant wishes to use this multi-tenant application, a Global Administrator in the customer's tenant performs an admin consent grant. This critical step creates a service principal within the customer's tenant. The service principal is the local representation of the multi-tenant application and inherits all the permissions defined in the original app registration. Importantly, a service principal is itself a security principal, meaning it can be assigned roles and permissions, just like a user or a group. In this scenario, the service principal is effectively authorized to perform the actions (e.g., User.ReadWrite.All) within the customer's tenant.

The vulnerability identified by Woodruff exploits the delegated authority of the Application Administrator role. While this role is intended for managing application lifecycles and onboarding, it retains the ability to add new credentials (secrets or certificates) to any service principal it can manage. The critical insight is that this capability extends to service principals that are Microsoft-owned multi-tenant applications. These service principals, such as those for Exchange Online, SharePoint Online, Teams, the Azure portal, or the M365 admin portal, are essential for the Microsoft cloud ecosystem and often possess highly privileged permissions by default. Woodruff notes that a typical tenant can have hundreds of these Microsoft-owned service principals – one tenant he examined had 573. These are readily identifiable by checking if their appOwnerTenantId matches the Microsoft tenant ID.

The attack sequence unfolds as follows:

1. Initial Compromise/Privilege: An attacker gains the Application Administrator role, either through a phishing attack, social engineering, or by exploiting another vulnerability.
2. Enumeration of Service Principals: The attacker, acting as an Application Administrator, enumerates all service principals within the target tenant. A key filter here is to identify service principals where the appOwnerTenantId is Microsoft, indicating they are part of Microsoft's core services. This can be done using PowerShell or Microsoft Graph API calls.
3. Identification of High-Privilege Targets: From the enumerated list, the attacker identifies Microsoft-owned service principals that possess broad, high-impact permissions, such as Directory.ReadWrite.All, User.ReadWrite.All, or other permissions that could lead to administrative control.
4. Credential Addition: The Application Administrator then uses their legitimate permissions to add a new secret (a password-like string) or a certificate to the chosen high-privilege service principal. This action is permitted because the Application Administrator role has the scope to manage credentials for service principals.
5. Access Token Acquisition: With the newly added credential, the attacker can now authenticate to Entra ID as the targeted service principal. They obtain an access token that represents the service principal's identity and its full set of permissions.
6. Privilege Escalation: Using this access token, the attacker can now perform any action that the compromised service principal is authorized to do. If the service principal has permissions like Directory.ReadWrite.All, the attacker can then create new users, modify existing users (e.g., reset passwords for Global Administrators), assign roles to users or themselves, or even create new application registrations with Global Administrator equivalent permissions. This effectively provides Global Administrator equivalent access without the attacker ever directly being assigned the Global Administrator role.

Woodruff explicitly mentions focusing on secrets but also validating the attack with certificates, noting that behavior could sometimes differ. The crucial point is that the Application Administrator can modify the authentication mechanism of a highly privileged entity that they are not supposed to control, thereby inheriting its power. This technique bypasses the explicit role-based access controls designed to keep Application Administrators in their "swim lanes" and highlights a subtle but profound gap in the delegation model.

Demo / Proof of Concept

▶ Watch: Admin consent process and service principal creation (5:40)

While the talk did not feature a live, interactive demo in the traditional sense, Eric Woodruff described the methodology and "poor code" he used to develop his Proof of Concept (PoC), which validated the "UnOAuthorized" technique. This PoC demonstrated the feasibility of the privilege escalation path by programmatically interacting with Microsoft Entra ID.

The core of Woodruff's PoC involved a script, likely written in PowerShell or leveraging the Microsoft Graph API, designed to perform the following steps:

1. Enumerate Service Principals: The script would first query the Entra ID tenant to retrieve a comprehensive list of all existing service principals.
2. Identify Microsoft-Owned Service Principals: A key filtering step in the script was to identify service principals whose appOwnerTenantId was that of Microsoft. This allowed the PoC to target the specific category of multi-tenant applications that are implicitly trusted and often hold high privileges within a tenant. Woodruff noted that in one tenant, this yielded 573 such service principals, indicating a substantial attack surface.
3. Add Credential to a Target Service Principal: The script would then select a target service principal from the filtered list (presumably one known or suspected to have high permissions) and, using the permissions of the Application Administrator role, programmatically add a new credential to it. Woodruff specifically mentioned focusing on adding secrets (passwords for applications) but also tested with certificates. This is the critical step where the Application Administrator's power to manage credentials for any service principal is leveraged.
4. Export Credentials: The script would then "very poorly dump" the newly created credential (the secret) out to a CSV file for later use. This step serves to extract the "key" to the compromised service principal.
5. Simulated Post-Exploitation: Although not explicitly detailed as part of the live PoC description, the logical next step (and the implied outcome of the PoC) would be for the attacker to use this newly acquired secret to obtain an OAuth 2.0 access token on behalf of the compromised service principal. With this token, the attacker could then execute privileged actions, such as listing all users, modifying user attributes, or assigning administrative roles, effectively demonstrating Global Administrator equivalent control.

Woodruff's description of his "poor code" and the "dumping it out to a CSV" highlights the practical, iterative nature of security research. The intent was not to showcase polished exploit code but to demonstrate the underlying mechanism and its effectiveness in proving the "UnOAuthorized" attack vector. The PoC successfully validated that an Application Administrator could indeed add credentials to Microsoft-owned service principals, and by doing so, gain the ability to impersonate those highly privileged entities. This practical demonstration underscores the severity of the finding and the need for organizations to reassess their Entra ID security posture.

Defensive Implications

▶ Watch: Focus on adding credentials (secrets) to service principals (6:20)

The "UnOAuthorized" privilege escalation technique presents significant defensive challenges for organizations utilizing Microsoft Entra ID. Mitigating this risk requires a multi-faceted approach, focusing on robust identity governance, continuous monitoring, and strict least privilege principles.

1. Implement Strict Least Privilege for Application Administrators:

• Review Existing Assignments: Immediately audit all users and groups assigned the Application Administrator or Cloud Application Administrator roles. Determine if these assignments are truly necessary and if the individuals holding these roles require such broad permissions over all service principals.
• Just-in-Time (JIT) Access with PIM: For critical administrative roles like Application Administrator, implement Privileged Identity Management (PIM) in Entra ID. This ensures that the role is activated only when needed, for a limited time, and with proper approval workflows. This significantly reduces the window of opportunity for an attacker to exploit a compromised Application Administrator account.
• Custom Roles: Where possible, create custom Entra ID roles with the absolute minimum permissions required for specific application management tasks, rather than relying on the broad built-in Application Administrator role. This can help segment administrative duties more granularly.

1. Enhanced Monitoring and Alerting for Service Principal Credential Changes:

• Audit Log Surveillance: Organizations must implement robust monitoring of Entra ID audit logs. Specifically, look for events related to the addition or modification of credentials (secrets or certificates) on service principals. Key audit events to monitor include:
• Add application password
• Update application (specifically for credential changes)
• Add service principal certificate
• Update service principal (specifically for credential changes)
• Focus on High-Value Targets: Prioritize alerting for credential changes on service principals that are identified as Microsoft-owned (appOwnerTenantId of Microsoft) and those with highly privileged permissions (e.g., Directory.ReadWrite.All, User.ReadWrite.All, Application.ReadWrite.All).
• Baseline and Anomaly Detection: Establish a baseline of normal credential management activities. Any deviation, especially the addition of new credentials outside of planned operational changes, should trigger high-severity alerts.

1. Comprehensive Inventory and Assessment of Service Principals:

• Identify Microsoft-Owned Service Principals: Regularly inventory all service principals in your tenant and clearly identify those owned by Microsoft. Understand their purpose and the permissions they hold.
• Review Permissions of All Service Principals: Conduct periodic reviews of the permissions granted to all service principals. Challenge and remove any excessive or unused permissions. This is crucial as a compromised service principal can only act within its granted permissions.
• Understand Entra ID Application Ecosystem: Gain a deeper understanding of how multi-tenant applications are consented to and how their associated service principals operate within your environment.

1. Strengthen Authentication for Administrative Accounts:

• Multi-Factor Authentication (MFA): Enforce strong MFA for all administrative roles, especially Application Administrators. This makes it significantly harder for an attacker to gain initial access even if they compromise credentials.
• Conditional Access Policies: Implement Conditional Access policies to restrict administrative sign-ins to trusted devices, locations, or network segments.

1. Regular Security Audits and Penetration Testing:

• Simulate Attack Scenarios: Conduct regular security audits or penetration tests that specifically include scenarios for privilege escalation from roles like Application Administrator. This can help uncover similar or related vulnerabilities specific to your tenant's configuration.

By adopting these defensive measures, organizations can significantly reduce their exposure to attacks like "UnOAuthorized" and strengthen the overall security posture of their Microsoft Entra ID environment against sophisticated privilege escalation techniques.

Key Takeaways

• Application Administrator Role is a High-Value Target: Despite being perceived as a "swim lane" role, the Entra ID Application Administrator (or Cloud Application Administrator) role can be leveraged for significant privilege escalation, making it a critical target for attackers.
• Credential Management is a Critical Attack Vector: The ability of an Application Administrator to add new secrets or certificates to any service principal, including highly privileged Microsoft-owned ones, is the core vulnerability.
• Microsoft-Owned Service Principals Pose a Hidden Risk: Tenants contain hundreds of Microsoft-owned service principals that often possess extensive permissions. These become prime targets for attackers looking to inherit elevated privileges.
• Privilege Escalation to Global Administrator Equivalent: By adding a credential to a high-privileged service principal and then using it to obtain an access token, an attacker can achieve effective Global Administrator control without direct role assignment.
• Robust Monitoring of Service Principal Changes is Essential: Organizations must actively monitor Entra ID audit logs for any additions or modifications of credentials on service principals, especially those owned by Microsoft or with high permissions.
• Strict Least Privilege and PIM are Imperative: Implementing Just-in-Time (JIT) access via PIM for Application Administrator roles and reviewing all existing assignments to ensure least privilege is crucial for mitigation.

About the Speaker(s)

Eric Woodruff is a Senior Security Researcher at Semperis, a company specializing in identity-driven cyber resilience. Woodruff brings a "blue team" perspective to his research, focusing on understanding and defending against sophisticated attacks. He is actively engaged in the security community and encourages individuals with questions about his research or identity-related topics to reach out via his social media channels. His work, including "UnOAuthorized," contributes valuable insights into the complex and evolving threat landscape of cloud identity platforms like Microsoft Entra ID.