This is a very simple example of pivoting into infrastructure through Azure’s “management plane”, which is used by legitimate users to manage infrastructure. This scenario is dependent on an adversary compromising an account in AAD that has privileges to run commands on VMs within the Azure infrastructure.

This may seem like a somewhat naïve and simple example given the requirement for a pre-compromised AAD account with special permissions in Azure. However, commonly successful techniques such as phishing, password cracking or identification of leaked secrets can lead to the compromise of an AAD account. If an account compromised using one of those techniques does not have administrative permissions, then the goal of the adversary is to identify some privileged escalation that helps them gain higher permissions.

The remainder of this blog post focuses on the topic of elevating privileges in Azure infrastructure with a previously compromised Azure AD account. A full summary of previous work on this topic will be contained in a future post, whereas this post will focus on a new technique targeting AAD dynamic groups.

Some background on Azure Active Directory

Let’s start by clearing the air about Azure vs Azure Active Directory (Azure AD or AAD).

When we talk about Azure, many folks jump straight to thinking about Azure Active Directory, or even Office 365. This is a common point of confusion. Microsoft has a large cloud ecosystem that is tied together with identity management and authentication through Azure Active Directory.

Azure Active Directory uses “tenants” to represent different organizations and environments within a company’s Microsoft cloud ecosystem, and includes a collection of users, groups and rights. Any one tenant may be connected to a single Office365 account, any number of Azure subscriptions, Dynamics365, Outlook, and other Microsoft cloud services.

So while the same Azure AD users may be used for all of these services, Azure AD is not a part of Azure nor a part of Office 365. Azure AD is a separate entity that handles user management and authentication, and has tight integrations with other Microsoft services.

With this straight, let’s briefly cover a few other basic topics that are relevant for the privilege escalation technique.

Azure AD Roles

Roles in Azure AD are top-level roles in the Microsoft Azure AD tenant for Azure AD users. At the time of writing this article, the assignment of some admin roles to Service Principal objects is also in preview. Azure AD roles allow users or service principals to perform actions including, but not limited, to:

• Managing security groups
• Managing users
• Accessing Azure infrastructure
• Creating and managing Azure AD applications (Service Principals)

The following screenshot illustrates some of these Azure AD Roles in Azure Portal:

Azure RBAC Roles

Azure RBAC (role-based access control) roles govern access to the infrastructure deployed within Azure. This is a large and complicated topic, but the important thing to understand here is that RBAC roles determine what actions an Azure AD principal can take on specific resources deployed in Azure. For example, to deploy a VM, a user must be assigned an RBAC role that includes that action, such as owner or contributor.

Azure AD Security Groups

In Azure AD, users can be added into logical groups to help with user and access management. Azure RBAC roles and Azure AD roles can then be assigned to these groups (Azure AD role assignments to groups is in preview at the time of writing). This means that any user that is added to a group will then inherit the roles assigned to that group.

The technique - abusing dynamic groups

While researching and testing Azure deployments, I stumbled upon an interesting privilege escalation vector: the abuse of dynamic groups in Azure AD.

What are dynamic groups?

Dynamic groups in Azure AD allow administrators to automatically assign group memberships to users based on attributes of that user. For example, if a company has two offices in Oslo and London, they may create security groups for each of their offices. They can use dynamic groups based on the user’s “city” attribute for this purpose, so that whenever a new user is added to Azure AD, they will automatically be added to one of these two groups.

The following picture shows how you would do this with a dynamic group rule:

This use case is fairly innocent. But let’s think of a more security sensitive case.

A real-world scenario for the attack

An organization creates a dynamic group called VM Contributors, which has VM Contributor Access scoped to the subscription:

Now, this organization outsources all VM management to a company called “Bluefish”, and Bluefish uses the following naming convention:

[email protected]

To automate the process of Bluefish users being assigned VM Contributor, a rule is added to dynamically add any user with “bluefish” in the userPrincipalName (UPN) to the VM Contributor group. Seems reasonable and innocuous, since users cannot modify their UPN without appropriate access rights, and the organization has locked these down.

Time to escalate some privileges

Let’s assume for our scenario that an adversary gains access to a low-privileged user in Azure AD, which resides in no groups or Azure RBAC roles. The compromised user has the “Global Reader” role, so the attacker can read configurations in the directory, but cannot change settings, and therefore cannot use traditional methods to change access rights to their own user, or to other users.

The attacker finds the dynamic membership rule, and wants to find a way to trigger the dynamic rule for an account they control. In short, the attacker needs to get the name “bluefish” in the UPN attribute of their user:

Since users with the Global Reader role cannot edit any configurations, the attacker cannot edit their own UPN and is stuck.

UPN

User Principal Names are based on user email addresses. I have identified dynamic groups based on this attribute in the past, and on the surface seems to be okay because users generally cannot change their own email addresses. This requires administrative privileges within Azure AD and a role such as “User Administrator”. However, there is a way around this…

Abusing Guest Accounts

By default, users in Azure AD can invite guest users to the directory. Since the UPN of a guest user is still based on email addresses, an adversary can simply create a new email address from any email provider, such as Gmail, that contains “bluefish” in the address. For example:

[email protected]

If the attacker invites this email to the azure tenant:

And then accepts the invite, the user will become a user in the local directory with an interesting UPN:

Now we can go into the portal and check our group assignments:

Now the attacker has access to the testDynamicGroup, which assigns the VM contributor role through a dynamic group membership.

To summarize:

1. The attacker starts with a Global Reader in Azure AD
2. The attacker finds a dynamic group with the VM Contributor role assigned
   • Membership is dynamic based on the string “bluefish” existing in the UPN
3. The attacker can invite guests, as per the default setting
4. The attacker invites a guest Gmail account with bluefish in the address - [email protected]
5. The guest account triggers the dynamic group after accepting, and inherits the VM Contributor role in Azure RBAC

Notes on dynamic group abuse

In this example, we show how dynamic groups based on a UPN can be abused using a guest account. However, there are many other attributes for determining dynamic group membership, and different types of attackers could abuse each. When setting up dynamic groups, consider whether lower privileged users or external attackers could modify the attributes that define that group.

The following are other potential attack paths to modify user attributes on dynamic groups:

• AD Connect Sync – An attacker may modify user attributes in an on-premise system, and Azure AD Connect would sync those attributes up to the cloud
• Access to other administrative accounts in Azure AD – Some Azure AD administrative roles would allow an attacker to modify other user’s attributes. This would require a pre-compromised administrative account
• Automated/custom creation of Azure AD accounts, with user-defined attributes

Preventing dynamic group abuse

If your Azure tenant uses dynamic groups for security sensitive use cases in Azure AD, it may be worth looking into your group membership rules. The root cause of this type of attack is the ability of an adversary to spoof or tamper with the attributes used by dynamic group membership rules. A basic guideline for preventing this may include:

• Do not base dynamic group membership rules on user-controlled attributes
• Identify which users have the privileges required to edit user-controlled attributes in Azure AD. This may be another privilege escalation path
• Consider if any custom internal applications in Azure AD or on-premise may allow users to modify these attributes
  Note that AD Connect may sync some of these attributes if they are modified in your on-premise infrastructure

Additionally, related to the specific technique discussed in this article:

• Don’t allow all users to invite guest accounts

While this is not the root cause of this issue, it is still best practice to disable this functionality for all users in Azure AD

Conclusion

While dynamic groups are powerful tools for Azure Administrators, they also present an interesting and perhaps easy to overlook attack vector. Based purely on heuristics, I have seen an uptick in the use of dynamic groups during my security assessments, and I suspect that this trend will continue as Azure deployments grow and become more complicated to manage.