Privilege Escalation in Entra ID (formerly Azure AD)

Privilege escalation attacks are one of the most pressing issues for security teams worldwide and are commonly used as a part of lateral movement. Threat actors know privileged accounts are harder to compromise because they are typically monitored and protected. However, attackers can employ privilege escalation vulnerabilities to take control of less monitored accounts and subsequently give themselves a high level of access – all while staying under the security team’s radar.

In today’s hybrid environment, enterprises are increasingly shifting their sensitive resources to SaaS apps. Azure Active Directory is one of the leading cloud Identity Providers that enables enterprises to centrally manage access and use of such apps.

We have recently discovered a privilege escalation issue within Entra ID (formerly Azure AD) that could allow an attacker to bypass a password-resetting safeguard, enabling lower-level admins to become fully privileged ones. We’ve reported this issue to Microsoft Security Response Center (MSRC), which validated it and applied a fix. While it no longer poses a risk to Entra ID (formerly Azure AD) users, we believe the wider security community can benefit from viewing our analysis and findings.

Technical Analysis

The Entra ID (formerly Azure AD) privileged role system works as a hierarchy, preventing lower-privileged admins from resetting the password of higher-privileged admins. In addition to the operational logic, this also safeguards against a scenario where a lower-privileged admin account is compromised by ensuring the attacker cannot modify those with higher privileges.

This safeguard applies when the user’s role is set to either “eligible” or “active”. However, Entra ID (formerly Azure AD) also allows user accounts to be assigned for future use; i.e., the higher-level privileges are granted on a predefined date and time.

We discovered that in this case, the password safeguard doesn’t apply. This exposes Entra ID (formerly Azure AD) to the following scenario:

1. Initial compromise: An attacker compromises an admin account with low privileges.
2. Future role assignments discovery: The attacker scans Entra ID (formerly Azure AD) to find accounts that are scheduled to become highly privileged admins in the future.
3. Password reset: The attacker now resets the password of these accounts, compromising them before role assignment takes place. Ideally, the attacker would perform this reset as close as possible to the time of the role change.
4. Privilege escalation: The role change takes place, providing the attacker with full control over an active highly privileged admin account.

Let’s go over these stages one by one:

Initial Compromise

For the purpose of this analysis, let’s assume this has already taken place. The attacker has compromised the account of “Shay Katz”, which has an active assignment of “Helpdesk Administrator”.

Screenshot 1: Shay Katz’ assigned roles screen

The following table, taken from Entra ID’s (formerly Azure AD)built-in role webpage, shows password reset rights of various roles within Entra ID (formerly Azure AD). We can see that “Helpdesk Administrator” cannot reset passwords of “Authentication Admin” and “Password Admin” roles.

Screenshot 2: Entra ID (formerly Azure AD) password reset permissions table

The attacker is now logged in to Entra ID (formerly Azure AD) as the user “Shay Katz”.

Future role assignment discovery

Prior to Microsoft’s fix, there were two options to discover future admin assignments for less privileged users:

1. Through Entra ID (formerly Azure AD) portal, by checking the “pending request” page for a future role assignment of a higher-tier admin.
2. Via a script, using the Resource Graph.

a) Required permissions:

List scheduled role eligibility requests: Requires: ReadWrite.AzureAD

A list with:

1. DeviceManagementApps.Read.All
2. DeviceManagementApps.ReadWrite.All
3. Directory.Read.All
4. Directory.ReadWrite.All
5. User.Read.All
6. User.ReadBasic.All
7. User.ReadWrite.All

b) Run the “https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests” query to get the scheduled request.
Filter on status = ‘provisioned’ AND scheduleInfo[‘startDateTime’] > currentTime AND roleDefinitionId in protectedRoleIdList.

c) Run the “https://graph.microsoft.com/beta/users?$select=displayName,id” query to get the user’s display_name using the principalId key.

Using the Entra ID (formerly Azure AD) portal (option A), the attacker discovers a sample test account which currently has no “Active” or “Eligible” role assignments.

Screenshot 3: ‘Test’ account without ‘eligible’ or ‘active’ assignments

However, the “Request time” and “Start time” fields show us that this test account does have a pending request to be added as Global Administrator in the future.

Screenshot 4: Pending request for test account to become Global Administrator

The attacker now has found a worthy target: a low-privileged account with a future role assignment. We can now move to the next stage.

Password Reset

The attacker can now reset the test account password using the Entra ID (formerly Azure AD) portal:

Screenshot 5: Password reset for test account

Privilege Escalation

Mission accomplished. When the defined start time comes, the test account will be upgraded to a Global Administrator account – and the attacker will have full control.

Microsoft’s Fix

Microsoft has addressed the issue by implementing the following controls:

• A low-privileged admin can no longer see pending requests in the portal.
• If you try to reset password for a future privileged role assignment, you are met with an error. (Usually, if you are not allowed to reset a password, the reset password button is locked.)

Conclusion

As stated, Microsoft has fixed this issue, so this attack technique is no longer effective. It should be noted, however, that these types of issues within Just-in-Time access safeguards are known to attract attackers. In this case, there was a gap between the privilege assignment and the actual enablement of a security measure built to protect it. As enterprises become more cloud-oriented, threat actors’ desire to search for such weaknesses in SaaS management infrastructure is rising. We’re pleased to have had this opportunity to mitigate an exposure in the attack surface and wish to acknowledge our appreciation to Microsoft for their efficient and rapid response.