Microsoft Entra Privilege escalation
The title probably got your attention, and it should. This finding was reported to Microsoft in April 2022 and has never been picked up. Therefor this is still exploitable in all Azure AD environments using Privileged Access Groups.
How it started
Well, like most of the time, it all starts with a simple question, and in my case, it was no different. The simple question that I asked myself is: “What is the risk of PIM”
This might sound strange because Privileged Identity Management (PIM) is a service to make the Azure Active Directory (AAD) more secure right?!
What is PIM
According to the Microsoft documentation Privileged Identity Management (PIM) is a service in Azure Active Directory (Azure AD) that enables you to manage, control, and monitor access to important resources in your organization.
Simply said PIM is a service that can be used assign just-in-time and just-enough-admin permissions to privileged accounts.
So What are Privileged Access Groups (PAM)
Good question, I’m always getting confused with all the Microsoft abbreviations for products. Privileged Access Groups are Azure AD groups that can have one ore more roles assigned. This can be convenient to use for a time-based assignment of multiple roles. But also to easy the assignment of permissions based on groups in stead of individual users.
Looking at the configuration of Privileged Access Groups, there are two assignment levels which are owners and members.
The owners are the eligible users that can elevate their permissions to add group members to the Privileged Access Group.
The members are the eligible users that can request temporary membership of the Azure AD Group that has a role assigned. The PAM group.
Escalating our privileges
Okay, this all sounds very good, secure and well thought of, so what’s the risk here. Glad you asked!
When looking at the Azure Active Directory we can see that there is a large amount of privileged roles available. When a user has a privileged role assigned, a less privileged user is not able to reset the password of this higher privileged user, which obviously makes sense.
To see this in practice I will show a sample of how this works.
Scenario 1 (Reset Privileged Account)
In our Azure Active Directory I have a user named Alex Wilber who has the User Administrator role assigned.
Alex want’s to reset the password of the user Lidia Holloway who is Eligible to the Global Administrator role through PIM.
When hitting the Reset Password button on her account the portal will first check if our account is allowed to reset her password.
As we can see in the image below, an error is shown that Alex does not have enough permissions to reset her account.
To look a bit more into detail what is actually happening, I have opened the dev tool (F12 key), we can see that and API endpoint is called and returned a 403 error telling us we don’t have permissions.
The validation in done by the API endpoint: /api/PasswordReset/IsRessetPasswordByObjectIdAllowed and the objectId being parsed belongs to the user Lidia.
What we have seen is that the Azure AD has a API in place to validate if we are eligible to reset the password of a user. 👍
The second scenario that we want to test is, what if the user is the owner of a Privileged Access Group
Scenario 2 (Reset Azure AD Group Owner)
In our next scenario we will try to reset the password of the user Patti Fernandez who is owner of the Azure AD Group called Retail.
In this case being owner of an AD Group isn’t a role but a permission, so this will probably work, but let’s try it out.
As we can see here is that the same API is called again and returned a status 200 which means we are allowed to reset her account. Again thumbs up, because it works as expected. 👍
Scenario 3 (Reset Owner of Privileged Access Group)
To see if we can take it one step further let’s try to reset the password of an owner of a Privileged Access Group. And in this case the Privileged Access Group with the Global Administrators role🔥
Looking at the image below we can see that the user Adele Vance is an active owner of the group called Global Administrators.
In this second image you can see that Adele is actually assigned the owner through eligibility.
Let’s go back to our user Alex who still is a User Administrator and try to reset the password of Adele.
Okay, this is interesting. As you remembered from Scenario 2 we were allowed to reset the password of an Azure AD Group owner. But is this case this in now denied because we are trying to reset the password of a user who has access to a highly privileged AD Group!
The only real other difference between Adele and Patti from Scenario 2 is that the owner role of Adele was assigned using the PIM proces of eligibility. Would this implicate that we cannot reset users who has roles assigned through PIM just like Lidia Holloway from Scenario 1?
Scenario 4 (Bypassing the system)
In this scenario we have a user with the name Grady Archie who is an Eligible owner of the Privileged Access Group Global Administrators.
Again we log in as Alex with the User Administrator role assigned and browse to the profile of Grady Archie. The expectation is that Grady password cannot be reset because he is eligible to a role comparable with Adele Vence from the previous test in scenario 3
What, did this just really happen?
As we just witnessed we are able to reset the password of an Eligible Owner of a Privileged Access Group! So thinking out loud, this essentially means that Alex who is a User Administrator can now add his own account to the Privileged Access Group that has Global Administrator permissions.
Looking at the image above confirms that we actually were able to reset the password through the /api/PasswordReset/ResetPasswordByUpn endpoint.
After we have resetted the password of Grady we are able to login using the new password and assign the owner role. Once that is done, Bad Alex can add his own account to the Privileged Access Group and become king of the castle
How is this possible
I’ve been thinking about this for a while and came to the conclusion that along the way Microsoft forgot to implement an extra validation in their process.
If we look back at the first scenario we have seen that, if a user is Eligible to a privileged role like Global Administrator, a flag is set on the user account preventing that the password can be reset by a lower privileged user.
According to the last test it seems that there is no flag set on the user account if this has an Eligible role to a Privileged Access Group. This means that the user is seen as a normal user and therefor can be reset.
