Security Bloggers Network 
SBN

Privilege Escalation in Azure AD

by Shay Katz on September 1, 2022

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 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 Azure AD users, we believe the wider security community can benefit from viewing our analysis and findings.

Technical Analysis

The 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, 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 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 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”.

Shay Katz Assigned Roles

Screenshot 1: Shay Katz’ assigned roles screen

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

Azure AD password reset permissions table

Screenshot 2: Azure AD password reset permissions table

The attacker is now logged in to 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 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:

i) List scheduled role eligibility requests:

    1. Requires: ReadWrite.AzureAD

ii) List users requires one of the following permissions:

    1. Read.All
    2. ReadWrite.All
    3. Read.All
    4. ReadWrite.All
    5. Read.All
    6. ReadBasic.All
    7. 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 Azure AD portal (option A), the attacker discovers a sample test account which currently has no “Active” or “Eligible” role assignments.

'test’ account without ‘eligible’ or ‘active’ 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.

: password reset for test account

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 Azure AD portal:

reset password

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.

The post Privilege Escalation in Azure AD appeared first on Silverfort.

*** This is a Security Bloggers Network syndicated blog from Blog - Silverfort authored by Shay Katz. Read the original post at: https://www.silverfort.com/blog/privilege-escalation-in-azure-ad/

Shay Katz