Absuing Dynamic groups for Entra ID privileg escalation

Ahmad Mansour
4 min readOct 30, 2024

--

As cloud adoption accelerates, so does the importance of robust cloud security. In Azure, misconfigured dynamic groups can open doors for privilege escalation attacks, allowing attackers to exploit automated membership changes for unauthorized access. This post dives into how these vulnerabilities emerge in Azure, their risks, and essential strategies for securing dynamic group configurations.

Entra ID

In this blog, we will take a look about dynamic groups in azure ad, how to enumerate and abuse them.

Before we start talking about the exploitation and enumeration part, let’s understand what are dynamic groups exactly.

Simply a dynamic group is a way to make a group of users, based on specific properties, like user attributes, job title, location, OS .. let’s take a small scenario, you are an IT admin at a company and you want to automate your work so anyone from Finance department ( by their Department attribute ), automatically gets a specific permission or license.

and these rules are simply and direct, or example

(user.department -eq “Finance”)
or for example
(user.city -eq “Beirut)

So lets create an example,
whenever the department is Finance, you will be added to this group as a user, and this group has a permission of Contributor on the whole subscription ! ( yes abit unreal that a finance guy has a Contributor role, but i think you got the idea )

Dynamic group rule example

After this example, i will assume that the idea of exploitation is in your mind ;p

So these rules will decide if to add the user to that Dynamic group or not, and this group will have a permission/ license or whatever

Now let’s go to the hacking part,
scenario is that you got access into an AzureAd valid account through phishing, stolen creds, or whatever the technique you used, after that you will start by enumerating the existent Dynamic Groups and their rules !

Lets say we got access into mansourtest@****** ( hiding for privacy purposes )
This is the breached account where the attacker has access to,

First we will enumerate all the Dynamic groups available ( after connecting sure ) , through the following one liner:

Get-AzADGroup -Filter “groupTypes/any(c:c eq ‘DynamicMembership’)” | Select-Object Displayname,MembershipRule

Different groups and there rules

Looks great, but let’s extend that so it also lists the permessions or roles that this group has,
Get-AzADGroup -Filter “groupTypes/any(c:c eq ‘DynamicMembership’)” | ForEach-Object {
$groupId = $_.Id
$groupName = $_.DisplayName
$membershipRule = $_.MembershipRule
$resourceRoles = Get-AzRoleAssignment -ObjectId $groupId | ForEach-Object { “$($_.RoleDefinitionName) on $($_.Scope)” }
[PSCustomObject]@{
GroupName = $groupName
MembershipRule = $membershipRule
ResourceRoles = $resourceRoles -join “; “
}
} | Format-Table -AutoSize

Showing rules and their permessions

Well as we can see the rule is around having Department as Finance,
Besides that an Admin can let users change these info, in the end it would depend on what sort of acccess you got,so all you have to do now, change your Department to Finance, and quick win to Contributor role !

Let’s give a more realestic scenario, that the

Now, a membership rule that would check the UPN of the user ( consider it like the email of the user ),
i know what you are thinking, this is nearly impossible to be exploitable, to change your UPN in a tenant.

i agree with you, we won’t change our UPN, but create one !

Invitation feature !

remember that ANY user by DEFAULT can invite any email ( which is the UPN )
so lets take the following scenario;

You are an IT admin, looking for automating the process of a third party permission vendor that works with your company, so you decide to make a rule, any UPN contains supportxyz will gets assigned to a Dynamic group which have Contributor access to the subscription.

Simply as an attacker, invite a new user, and let that user email be supportxyztstt@gmail.com

and here’s a quick win, attacker invites that user (that he personally made ), and the rule will apply on that user -> privilege escalated ( as that group as contributor perm ) .

And that’s it for this article, feel free to comment or add any ideas, i will be adding more Azure/Entra ID scenarios soon.

--

--