AZURE PENTESTING SERIES

Abusing Dynamic Groups in AzureAD [Part 1]

Nairuz Abulhul
R3d Buck3T
Published in
10 min readJan 4, 2024

--

Leveraging Dynamic Groups for Elevated Privileges

Photo by mana5280 on Unsplash

A dynamic group is a group type in Microsoft Entra ID (AzureAD) that automatically manages its members based on preset rules. These rules can be based on geographic location, department name, user type (member or guest), or any other defined string. Dynamic groups add and remove members automatically based on that specific criteria.

An attacker who has valid credentials can exploit the dynamic groups mechanism to gain access to privileged groups and move laterally within the environment.

In this guide, we will go through various attack scenarios that involve abusing dynamic groups. These attacks are considered post-exploitation, which means that the attacker has already obtained valid credentials and authenticated to the tenant. To avoid being too lengthy, the guide will be divided into multiple parts.

The labs for this guide is from the Altered Security Red Labs — AzureAD created by Nikhil Mittal. It is an excellent resource for those who want to get started with Azure pentesting assessments. The lab covers common misconfigurations in Azure environments.

Table of Contents

Acquiring the Necessary Tools

We will use the tools below to identify dynamic groups and abuse the membership rules. These steps can be completed in the portal or with the tools listed below:
Az PowerShell
Azur-eADPreview
Windows VM

Installing Az PowerShell

Azure PowerShell, also known as Az PowerShell, is a set of PowerShell commands that help manage Azure resources.

To install the module, we need to first go to the PowerShell Gallery on the Windows VM machine and search for the AZ module authored by Microsoft.

Figure 01 — shows the location of the Az module on the PowerShell Gallery. Azure, r3d-buck3t, Az, PowerShell
Figure 01 — shows the Az module on the PowerShell Gallery.

Next, open the PowerShell terminal with administrative privileges and type the below command to install the module.

Install-Module -Name Az

While installing, we will be asked to install additional packages like the NuGet package manager; this will help us manage .NET libraries and tools similar to APT in Linux. Type “Y” to install all the required packages.

We will also be asked to grant permission to install the Az module, which is categorized as an untrusted repository. This is because the PowerShell Gallery, an open gallery supported by the community, is considered untrusted by default.

Microsoft has implemented this feature to ensure that the users verify before installing any module or script from this open gallery. Even the Microsoft-developed Az module must be verified before being installed.

Get-PSRepository
Figure 02- shows the default installation policy of the PSGallery as untrusted. r3d-buck3t, Azure, PowerShell, Az, pentesting
Figure 02— shows the default installation policy of the PowerShell Gallery as untrusted.

Since Microsoft is the author of this module, we can proceed with the installation requirements by typing the letter “A”. The installation process may take a few minutes to complete.

Figure 03 — shows the installation steps for the Az PowerShell module. r3d-buck3t, Azure, Az, PowerShell,
Figure 03 — shows the installation steps for the Az PowerShell module.

To avoid being prompted for confirmation every time we install a module, we can use the -Force parameter only if we are sure that it is safe to install.

Alternatively, we can use the Set-PSRepository command to trust the entire PowerShell Gallery. I have provided both methods for reference.

Method 1: Using the Force Parameter

The -Force parameter is used during module installation to allow the operation to proceed without any prompts, such as confirmation messages or warnings.

Install-Module -Name Az -Force

Method 2: Using Set-PSRepository Cmdlet

The Set-PSRepository command enables us to set the installation policy for the entire PSGallery repository to Trusted.

This ensures that we don’t get prompted before installing modules from the PSGallery. We can also specify the source URL of the PSGallery to instruct the policy to trust only the modules coming from specific URLs.

Set-PSRepository -Name 'PSGallery' -InstallationPolicy Trusted

Set-PSRepository -Name 'PSGallery' -SourceLocation 'https://www.powershellgallery.com/api/v2'

Install-Module -Name Az
Figure 04 — shows adding the PSGallery to the trusted repositories with the Set-PSRepository command. r3d-buck3t, Azure, Az, pentesting, Microsoft
Figure 04 — shows adding the PSGallery to the trusted repositories with the Set-PSRepository command.

Authentication with Az PowerShell

To authenticate to Azure with the Az module, we need to set the execution policy to RemoteSigned to run the downloaded module from PSGallery.

The RemoteSigned policy allows only scripts signed by trusted publishers to run.

Set-ExecutionPolicy RemoteSigned -Force

💡 In order for the changes to take effect, sometimes you will need to close the elevated PowerShell terminal and then re-open it.

To connect with our Azure account, we will use the Connect-AzAccount command to establish a secure connection between our local PowerShell session and the Azure account.

Connect-AzAccount 
Figure 05 — shows changing the Execution Policy and authenticating with the Azure account. r3d-buck3t, az, PowerShell, pentesting
Figure 05 — shows changing the Execution Policy and authenticating with the Azure account.

After the authentication is complete, the command will return account information that includes the email that we connected with the tenant ID to confirm that the authentication was successful.

Figure 06 — shows the output of the Connect Azure command (account email and Tenant ID). r3d-buck3t, az, PowerShell, pentesting
Figure 06 — shows the output of the Connect Azure command (account email and Tenant ID).

Installing AzureADPreview

AzureADPreview is a PowerShell module that helps manage Azure AD resources. To install, follow the same steps as Az PowerShell, replacing the module name with AzureADPreview.

Install-Module AzureADPreview -Force
Figure 05 — shows installs Azure AD Preview module.

We can verify the module was installed by running the Get-InstalledModule and providing the module’s name.

Get-InstalledModule -Name "AzureADPreview"
Figure 07 — shows verifying the installation of the AzureADPreview module. r3d-buck3t, az, azure, powershell, pentesting, hacking
Figure 07 — shows verifying the installation of the AzureADPreview module.

To connect with our Azure account, we will use the Connect-AzureAD command and provide the credentials when prompted.

Connect-AzureAD
Figure 08 — shows authenticating with Azure AD module. r3d-buck3t, azure, az, PowerShell, pentesting
Figure 08 — shows authenticating with Azure AD module.

After authentication, the command returns account information, including the email connected with the tenant ID to confirm successful authentication.

Figure 09 — shows the authentication output with the Azure AD module. r3d-buck3t, azure, pentesting, hacking
Figure 09 — shows the authentication output with Azure AD module.

Identifying Dynamic Groups

As a default, all standard authenticated users have read access to most of the information in Microsoft Entra ID (Azure AD) through the web portal or PowerShell. This information includes data on all users, groups, computers, apps, licenses, AzureAD roles, etc.

To locate Dynamic groups through the Azure portal, log in to the Azure portal and search for “Microsoft Entra ID” in the search bar. Once you find the service option, click on it.

Figure 10 — shows searching for the Microsoft Entra ID (AzureAD). r3d-buck3t, pentesting, azure, az
Figure 10 — shows searching for the Microsoft Entra ID (AzureAD).

Navigate to the Groups option under the Manage section, which is available on the overview side panel. Click on Groups to access the Dynamic groups.

Figure 11 — shows selecting Groups under the manage section. r3d-buck3t, azure, az, PowerShell
Figure 11 — shows selecting Groups under the manage section.

The Groups section displays all available groups in the directory. To view only dynamic groups, we can filter membership types and select Dynamic.

Figure 12 — shows the search for Dynamic groups by adding a filter for Membership Types. Azure, PowerShell, R3dbuck3t, pentesting
Figure 12 — shows the search for Dynamic groups by adding a filter for Membership Types.

Dynamic Membership Rules

To review the rules, choose one of the groups, and then click on Dynamic Membership rules under the Manage section. The syntax rules are logical expressions that decide which groups to add based on the specified attributes. The syntax structure includes a property name, an operator, and a value.

(PropertyName - Operator 'PropertyValue')

In the example provide in the lab below, the rule adds users to the ASabgjlomhte2965698 group if their department attribute value is exactly equal to the string “tWqxpbhNCFYXvzR.

  • user.department: Targets the "department" property of user objects.
  • -eq: Equal operator to check for the exact match.
  • "tWqxpbhNCFYXvzR": The specific value to compare against.
(user.department -eq "tWqxpbhNCFYXvzR")
Figure 13 — shows the Rule syntax of a dynamic group. r3d-buck3t. azure, az, powershell
Figure 13 — shows the Rule syntax of a dynamic group.

Examples of Common Rules

Rules can become more complex in real-world scenarios, depending on the logic expressions used. Below are some common examples:

Targeting specific departments, for example, a rule that adds users to a group if they are part of the Sales or Marketing department and are located in the US.

(user.department -eq "Sales" -or user.department -eq "Marketing") -and user.country -eq "US"

Another use case of rules is managing device enrollment. A rule can be set to target devices with specific operating systems, such as Windows 2016, and add them to a group for easy management.

(device.operatingSystem -startsWith "Windows 2016")

Furthermore, rules can also be used to handle contract workers in large organizations. A rule can be set up to add guest users to a specific group that usually has limited permission, streamlining their access management.

user.userType -eq "Guest" -and user.accountEnabled -eq true

Retrieving Dynamic Groups with AzureADPreview

We can use the AzureADPreview module in the portal to filter dynamic groups and display their defined rules after authentication with the Get-AzureADMSGroup command.

Get-AzureADMSGroup -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -All:$true | Select-Object Displayname,MembershipRule
Figure 14 — shows using the Get-AzureADMSGroup to filter out only dynamic group types. r3d-buck3t, azure, az, powershell, pentesting
Figure 14 — shows using the Get-AzureADMSGroup command to filter out only dynamic groups type.

We can export the data to a CSV file using Export-CSV command and suppress unnecessary CSV headers with the -NoTypeInformation parameter.

Get-AzureADMSGroup -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -All:$true | Select-Object Displayname,MembershipRule | Export-Csv -Path "C:\Users\user\Desktop\Output.csv" -NoTypeInformation
Figure 15 — shows the exported output in a CSV file. r3d-buck3t, azure, az, powerahell
Figure 15 — shows the exported output in a CSV file.

From here, we can review the rules to see how to leverage them to add ourselves to any of the retrieved groups.

Abuse Dynamic Groups

Now that we have a clear understanding of dynamic groups, their purpose, and how the rules are structured, we can explore attack vectors related to common misconfigurations.

I have gathered AzureAD labs related to dynamic group abuse to help us understand the cases where we can exploit them. The guide will be divided into several parts, each lab focusing on a scenario.

Scenario 1: Modifying User Properties

In AzureAD 04 lab, we came across a dynamic group that has a rule that adds users to the ASsjltxnvywg3158310 group only if their department attribute value is equal to bxAmNUBtMHDlLQX.

(user.department -eq "bxAmNUBtMHDlLQX")

Since in this scenario our user has the authority to modify their profile information, we can simply edit the profile and add the value specified in the rule to the field’s department to meet the rule’s condition and get added to the mentioned group.

To do so, navigate to the Microsoft Entra ID, select Users, search for the authenticated user as ASozikmacspg3158295, and verify the edit permissions by clicking on the Edit Properties button.

In the Figure 16 below, the user has edit permissions and they are not part of any groups (Group membership is 0)

Figure 16 — shows that the authenticated user has no group memberships. r3d-buck3t, powershell, az, azure, pentesting
Figure 16 — shows that the authenticated user has no group memberships.

In the user’s profile, under Job Information, add the same value defined in the rule in the department field and save it.

Figure 17 — shows adding the value defined in the rule into the user’s department field. r3d-buck3t, az, azure
Figure 17 — shows adding the value defined in the rule into the user’s department field.

When adding new members to a dynamic group, it may take some time for the update to take effect. The time required for the update to complete depends on the number of users in the directory and the size of the group created as a result of the rule. In some cases, it may take anywhere from a few minutes to 30 minutes or even longer for the update to fully populate.

To verify that we’re added to the group, we go back to our profile, and see if we got added to the group.

Figure 18 — shows that a new group membership was added to the user. r3d-buck3t, azure, pentesting
Figure 18 — shows that a new group membership was added to the user.
Figure 19 — shows that the user ASozikmacspg3158295 was added to the group. r3d-buck3t, azure, powershell, pentesting
Figure 19 — shows our user was added to the group.

PowerShell Solution

To replicate the steps taken in the portal, we will be using the AzureADPreview module. We will begin by authenticating with the Azure account using the Connect-AzureAD command. After that, we will check the user’s current group by using the Get-AzureADUser command before making any changes.

Since the user had no group membership, the command returned nothing.

Connect-AzureAD

Get-AzureADUser -ObjectId "EMAIL" | Get-AzureADUserMembership
Figure 20 — shows the authenticated user group memberships. r3d-buck3t, azure, pentesting
Figure 20 — shows the authenticated user group memberships.

Using the Set-AzureADUser command, we will set the user’s department to the defined rule and then confirm the user’s addition to the group using the Get-AzureADUser command.

As seen below in Figure 20, we successfully added the user to the group.

Set-AzureADUser -ObjectId 'EMAIL' -Department 'CIGjiMbtrfPvTYV'

Get-AzureADUser -ObjectId "EMAIL" | Get-AzureADUserMembership
Figure 20 — shows the authenticated user group memberships. r3d-buck3t.com, azure, pentesting
Figure 20 — shows the authenticated user group memberships.

Mitigation Strategies

  • Review dynamic group membership rules that use user-controlled attributes, such as department, location, or custom attributes.
  • Restrict who can modify user attributes utilizing least privilege principles.

In this post, we learned about Azure dynamic groups and how they work. We also explored the first attack scenario, which involved adding a user to a group based on the defined membership rules. In upcoming articles, we will cover other attack scenarios that we can use during Azure pentesting assessments. These scenarios can be a part of our lateral movement methodology.

💡 A cheat sheet on Abuse Dynamic Groups has been created for this post on R3dbuck3t Notion.

Thanks for stopping by!

--

--

Nairuz Abulhul
R3d Buck3T

I spend 70% of the time reading security stuff and 30% trying to make it work !!! aka Pentester [+] Publication: R3d Buck3T