Entra ID Privilege Escalation to Global Administrator

Entra ID Privilege Escalation to Global Administrator

Speakers: Eric Woodruff, Security Researcher, Suppress

Conference: 44CON

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

Overview

This article delves into a critical security vulnerability discovered in Entra ID (formerly Azure Active Directory) that allowed for privilege escalation to Global Administrator within a tenant. Presented by Eric Woodruff, a security researcher at Suppress, this talk, titled "Unauthorized," exposes how certain Microsoft-managed service principals, when improperly configured, could be leveraged to gain "Keys of the Kingdom" access, bypassing expected authorization controls. The research highlights a fundamental discrepancy between external OAuth2 scopes and internal Microsoft authorization models, leading to unexpected and highly privileged actions.

Eric Woodruff, drawing on over 15 years of experience as a security identity architect and sysadmin in the public sector, provides a unique blue-team perspective on red-team findings. His work underscores the often-underestimated power of application administration roles and the complex interactions within cloud identity systems. The implications of this research are profound, reminding organizations that even trusted first-party services can harbor critical vulnerabilities, necessitating vigilant monitoring and a deeper understanding of authorization mechanics in multi-cloud environments. The findings have since been remediated by Microsoft, but the lessons learned about securing workload identities and understanding the true scope of administrative roles remain highly relevant for all Entra ID customers.

Background

▶ Watch: Introduction to speaker and talk 'Unauthorized' (0:00)

Entra ID, Microsoft's cloud-based identity and access management service, has become a cornerstone for organizations leveraging Microsoft 365, Azure, and other integrated cloud services. As threat actors increasingly target cloud environments, understanding and securing Entra ID is paramount. A significant area of focus for both attackers and defenders revolves around App Registrations and Service Principals. These entities represent applications and services within Entra ID, allowing them to authenticate and interact with resources. They are frequently exploited for achieving persistence and privilege escalation, as evidenced by incidents like the "Midnight Blizzard" attacks, which utilized illicit consent grants tied to these mechanisms.

Prior research, notably by Dirk-Jan Mollema in 2019, explored vulnerabilities related to app registrations and service principals associated with Microsoft applications. Woodruff's own experience as an Azure AD security assessor, encountering inexplicable indicators around credentials assigned to Microsoft service principals, planted the seed for this research. The overarching goal for attackers in Entra ID is often to attain Global Administrator privileges, which are analogous to "Domain Admin" in a traditional on-premises Active Directory environment, granting unrestricted control over the entire Microsoft estate.

To understand the vulnerability, it's crucial to grasp how applications operate within Entra ID. The Application Administrator role (and its counterpart, Cloud Application Administrator) is designed to manage the lifecycle of applications, such as Salesforce or Workday integrations, without granting excessive privileges like Global Admin. However, the talk reveals that the boundaries of this role, particularly when interacting with Microsoft's own internal applications, were not as rigid as commonly believed.

Multi-tenant Applications are a key concept. A software developer, operating from their "publisher tenant," creates an App Registration, defining a unique Client ID and specifying Application Permissions (e.g., User.ReadWrite.All, Directory.ReadWrite.All) that their application needs. They also assign Credentials (either a secret or a certificate) for authentication. When a customer wishes to use this application, a Global Administrator in the customer's tenant performs an Admin Consent Grant. This action creates a Service Principal in the customer's tenant, representing the publisher's application. This service principal inherits the defined application permissions and acts as a security principal to which roles and permissions can be assigned. The application then uses its Client ID and credential to authenticate to Entra ID, receive an Access Token, and interact with APIs like Microsoft Graph to perform its intended actions within the customer's tenant, adhering to the granted permissions. Microsoft's own first-party services (e.g., Exchange Online, SharePoint Online, Device Registration Service) operate with similar underlying principles, though their app registrations and credentials are managed by Microsoft.

Key Findings

▶ Watch: Global Admin: The 'Keys of the Kingdom' in cloud (3:00)

The core discovery of Eric Woodruff's research, dubbed "Unauthorized," revolves around the ability to impersonate or act as certain Microsoft-managed Service Principals within an Entra ID tenant. The critical insight was that an attacker, or in this case, a compromised Application Administrator, could assign their own Credentials (a password secret or certificate) to specific Microsoft service principals that were designed for multi-tenant use. By then authenticating via the OAuth2 Client Credential Grant Flow (CCGF) using these newly assigned credentials, the attacker could effectively "borrow" the identity of these Microsoft applications.

The most striking finding was that even when the obtained access tokens explicitly showed no scopes or permissions, these compromised Microsoft service principals could perform highly privileged actions. This contradicted the conventional understanding that OAuth scopes dictate an application's capabilities. Microsoft later clarified that this behavior was due to multiple, internal authorization systems at play, which could override or supplement the publicly exposed OAuth scopes.

Specifically, the research uncovered three Microsoft service principals that could be abused for privilege escalation:

1. Device Registration Service: This service principal, when a credential was assigned to it by an Application Administrator and then used in a CCGF, allowed the attacker to manage any role within the tenant, including Global Administrator. This meant adding or removing members from the Global Administrator role, effectively granting "Keys of the Kingdom" access. Microsoft rated this as an "Important" severity privilege elevation, and it was resolved in early March.
2. Viva Engage Yammer: Exploiting this service principal through the same method enabled the deletion and permanent deletion of any user, including privileged users like Global Administrators. An attacker could potentially evict all Global Admins from a tenant. Microsoft rated this as "Medium" severity, resolved shortly after Device Registration Service.
3. Rights Management Service: This service principal, despite showing no explicit write permissions, could be used to create new users within the tenant. Microsoft rated this as "Low" severity.

Woodruff initially encountered resistance from Microsoft regarding the severity of these findings, particularly the ability to delete all Global Admins via Viva Engage Yammer. However, after demonstrating the full attack paths, Microsoft re-evaluated and ultimately remediated these vulnerabilities by blocking the ability to use the Client Credential Grant Flow for these specific service principals. The research highlights a significant blind spot in how external (OAuth scopes) and internal authorization models interact within complex cloud platforms.

Technical Deep Dive

▶ Watch: Introduction to the Application Administrator role and its limits (4:00)

The technical heart of this vulnerability lies in the manipulation of Service Principals and the OAuth2 Client Credential Grant Flow (CCGF). The objective was to "impersonate Microsoft applications" by leveraging their existing trust within the Entra ID ecosystem.

The attack path began with an attacker or compromised Application Administrator identifying a specific Microsoft-owned service principal. The key was that on these service principals, it was possible for a tenant administrator (specifically, an Application Administrator) to define and assign an additional credential – either a password secret or an asymmetric key pair (certificate). This is distinct from the credentials managed by Microsoft on the underlying app registration.

Once a credential was assigned, the attacker could use this credential along with the service principal's Client ID to authenticate directly to Entra ID via the Client Credential Grant Flow. This flow is designed for applications to authenticate themselves without a signed-in user, receiving an Access Token in return. Woodruff primarily used the Microsoft Graph PowerShell SDK for this, employing commands like Connect-MgGraph.

A crucial observation was made when inspecting the access token obtained via Get-MgContext. For the vulnerable service principals, particularly Device Registration Service, the access token consistently showed no scopes whatsoever. According to the OAuth2 specification, scopes define the permissions an application has. The Default Scope in CCGF typically represents the application permissions defined in the app registration. The absence of scopes in this context should, in theory, mean the application has no permissions.

However, Woodruff's critical divergence from prior researchers was to attempt actions despite the lack of explicit scopes. He devised a system of tests targeting common privilege escalation vectors in Entra ID:

• Disabling regular and privileged users.
• Changing privileged user passwords.
• Managing role assignments (e.g., adding/removing Global Admins).
• Creating/deleting users.
• Permanently deleting privileged users (users are soft-deleted by default).
• Creating groups eligible for role assignment.
• Creating administrative units.
• Managing role-assigned group membership.

The most impactful finding was with the Device Registration Service. The technical steps for escalating to Global Administrator were demonstrated using PowerShell:

1. Identify Target Service Principal: Get-MgServicePrincipal -Filter "DisplayName eq 'Device Registration Service'"
2. Assign Credential: A new password credential was created and assigned to the Device Registration Service service principal. This was done using New-AzureADServicePrincipalPasswordCredential (from the older Azure AD PowerShell module, as it was easier at the time than Graph SDK for this specific task).
3. Authenticate via CCGF:

1. Verify Context: Get-MgContext was run. This command confirmed the authentication as Device Registration Service and, critically, showed no scopes available.
2. Enumerate Roles and Users:

• Get-MgDirectoryRole to list all directory roles.
• Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id to enumerate existing Global Admins.
• Get-MgUser -UserId "[email protected]" to obtain the object ID of a target user.

1. Assign Global Administrator Role:

This command, surprisingly, did not return a 403 Unauthorized error but rather a successful response.

1. Verify New Global Admin: Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id confirmed that the target user, Megan Bowen, had been successfully added as a Global Administrator.
2. Remove Global Administrator Role: The Device Registration Service also had the power to remove existing Global Admins using Remove-MgDirectoryRoleAssignment.
3. Audit Log Verification: Audit logs confirmed "Add member to role" activity for Global Administrator, explicitly attributed to Device Registration Service.

This detailed walkthrough illustrates how an Entra ID Application Administrator, typically not considered Tier Zero, could chain this vulnerability to gain unrestricted Global Administrator access, bypassing the expected security model based on OAuth scopes. Microsoft later explained that this behavior stemmed from "multiple authorization systems" operating behind the scenes, where an internal authorization model permitted these actions despite the lack of public OAuth scopes.

Demo / Proof of Concept

▶ Watch: Unseen Microsoft internal service principles in every tenant (5:00)

While a live demonstration of the vulnerability was not possible at the conference due to Microsoft having already remediated the findings, Eric Woodruff effectively conveyed the Proof of Concept through detailed screenshots and a step-by-step walkthrough of the PowerShell commands and their expected outputs. The presentation included visual evidence of:

• Assigning a new password credential to the Device Registration Service service principal.
• The Connect-MgGraph session context (Get-MgContext) explicitly showing authentication as Device Registration Service with no scopes.
• The successful execution of New-MgRoleManagementDirectoryRoleAssignment to add a user to the Global Administrator role.
• Subsequent Get-MgDirectoryRoleMember output confirming the new Global Administrator.
• Audit log entries clearly indicating that Device Registration Service performed the "Add member to role" action.

These visual aids and command-line outputs served as a compelling demonstration of the vulnerability's impact, illustrating how an attacker could leverage this unexpected behavior to achieve full Global Administrator privileges without triggering a 403 Unauthorized error, despite the apparent lack of permissions in the access token.

Defensive Implications

▶ Watch: Explaining multi-tenant applications, app registrations, and credentials (6:00)

The "Unauthorized" research provides critical insights for defenders managing Entra ID environments, even though Microsoft has remediated the specific vulnerabilities found in Device Registration Service, Viva Engage Yammer, and Rights Management Service. The underlying lessons about authorization models and the security posture of workload identities remain highly relevant.

Firstly, the finding highlights that Application Administrator is a highly privileged role that must be treated as Tier Zero. Historically, this role has often been underestimated, but its potential for abuse, as demonstrated, can lead directly to Global Administrator compromise. Organizations must enforce strict controls around who holds this role and ensure robust security practices like multi-factor authentication (MFA) and privileged access management (PAM) are applied.

The most immediate defensive actions after such a vulnerability disclosure involve detection and auditing. Defenders should proactively look for historical abuse:

1. Suspicious Credential Assignments: Organizations should query their Entra ID tenants for any custom credentials (password secrets or certificates) assigned to Microsoft-owned service principals. While Microsoft has blocked new CCGF usage for the vulnerable principals, checking for existing or past assignments is crucial.

• PowerShell: Use Get-MgServicePrincipal and filter for keyCredentials (certificates) or passwordCredentials that might have been added by an unauthorized party. Look for CreatedDateTime to identify when credentials were added.
• KQL Example (for Sentinel/Log Analytics):

1. Suspicious Actions by Microsoft Service Principals: Monitor for any actions performed by Microsoft service principals that fall outside their documented functionality. For instance, Device Registration Service's sole purpose is device management; it should never be managing roles.

• KQL Example:

Such queries can help identify if this vulnerability was exploited prior to its remediation.

Beyond detection, the research also sheds light on self-inflicted vulnerabilities that organizations can create:

• Risky Application Permissions: Two permissions were highlighted as particularly dangerous for custom applications:
• RoleManagement.ReadWrite.Directory: This permission directly allows an application to read and manage role-based access control settings for the directory, including role membership. If an application has this, it can add/remove members to any role.
• AppRoleAssignment.ReadWrite.All: While not directly managing roles, this permission allows an application to manage permission grants for application permissions to any API, including Microsoft Graph. Crucially, an application with this permission can grant RoleManagement.ReadWrite.Directory to itself or another application without requiring an administrator's intervention, effectively achieving the same end result.

Organizations must rigorously review applications with these permissions and ensure they are absolutely necessary and tightly controlled.

• App Instance Property Lock: Microsoft introduced this setting to mitigate such credential manipulation. When enabled on an app registration or service principal, it blocks the ability to assign new credentials to that service principal. For highly privileged custom applications or those with risky permissions, enabling App Instance Property Lock on their credentials is a crucial hardening step. This prevents a compromised Application Administrator from adding their own credentials to the application's service principal for malicious purposes.

• Workload Identity Premium: This is a powerful, though cost-incurring, feature for securing workload identities. It extends capabilities like Conditional Access and Identity Protection to applications and service principals.
• Conditional Access for Workloads: Allows defining policies based on location, IP ranges, or other conditions. For instance, an application's service principal might only be allowed to authenticate from trusted network locations. If an attempt comes from an untrusted network, authentication can be blocked, preventing an attacker from using a stolen credential.
• Identity Protection for Workloads: Provides risk detection capabilities for workload identities. It can profile normal application behavior and detect anomalous activities, such as unusual credential additions or authentication attempts from suspicious locations. High-risk events can trigger alerts or block authentication, providing a robust layer of defense against sophisticated attacks. Organizations should prioritize enabling Workload Identity Premium for their most critical and highly privileged applications.

The speaker emphasizes that this is not just a Microsoft cloud vulnerability; it's a reminder of the need for absolute authorization principles. Defenders must assume that any entity capable of modifying application credentials or permissions, whether a user or another application, represents a significant attack surface. Proactive monitoring, strict access controls for privileged roles, and leveraging advanced security features like Workload Identity Premium are essential for maintaining a secure Entra ID environment.

Key Takeaways

• Microsoft Service Principals Can Be Abused: Specific Microsoft-managed service principals in Entra ID historically allowed for privilege escalation to Global Administrator by assigning custom credentials and using the OAuth2 Client Credential Grant Flow, even without explicit scopes.
• Authorization Models Are Complex: OAuth scopes are not the sole determinant of an application's permissions in Entra ID; internal Microsoft authorization systems can grant capabilities beyond what is publicly visible, creating a potential blind spot.
• Application Administrator is a Tier Zero Role: The Application Administrator role, often underestimated, can be leveraged to achieve Global Administrator privileges, making it a critical target for attackers that must be secured with the highest level of scrutiny and controls.
• Monitor for Suspicious Credentials and Actions: Defenders must actively audit Entra ID for unauthorized credentials assigned to Microsoft service principals and monitor audit logs for any actions performed by these service principals that fall outside their normal, documented functions.
• Harden Custom Applications with Risky Permissions: Be extremely cautious with custom applications granted RoleManagement.ReadWrite.Directory or AppRoleAssignment.ReadWrite.All permissions, as these can be self-abused to gain extensive control.
• Leverage Advanced Security Features: Employ App Instance Property Lock to prevent credential manipulation on highly privileged service principals and utilize Workload Identity Premium for critical applications to enable Conditional Access and Identity Protection for workload identities.

About the Speaker(s)

Eric Woodruff is a Security Researcher at Suppress. With a rich background spanning over 15 years, Eric has extensive experience on the "blue side" of security, having worked as a security identity architect and a sysadmin in the public sector. His deep understanding of identity systems and security operations informs his research, bringing a practical, defensive perspective to uncovering and analyzing vulnerabilities. He is active on social media with the handle @EricOnIdentity.