Abuse Dynamic Groups in Entra ID for Privilege Escalation

What this lab covers

You start from a credential found in storage, enumerate the directory and its administrative structure, and identify a group whose membership is calculated rather than assigned. Changing the right attribute makes you a member.

This is a good example of an escalation path that exists entirely within intended functionality. Dynamic groups are a management convenience, and their security depends on a separate question about who can write user attributes, which is rarely asked at the same time.

It suits anyone administering Entra ID as well as anyone testing it, and assumes no prior Azure experience.

How dynamic group abuse works

Dynamic groups define membership as a rule over user or device attributes, such as department, job title or an extension attribute. Entra ID evaluates the rule continuously and adjusts membership automatically, which is why they are popular for large directories.

Those groups are frequently used to grant access: application assignments, license allocation, conditional access exclusions and sometimes role eligibility. The group becomes a control boundary while remaining, in the administrator's mind, a convenience feature.

The escalation depends on write access to the evaluated attribute. Some attributes are user-writable by default, and roles such as User Administrator can modify attributes across many accounts. Administrative units are meant to constrain that scope, so their configuration determines how far a delegated administrator's write access actually reaches.

How to detect this in your own environment

Alert on attribute changes for attributes used in dynamic group rules. Most tenants have a small number of such rules, so the set of security-relevant attributes is short and the resulting alert volume is low.

Monitor group membership changes for groups that grant meaningful access, and treat additions to those groups as notable regardless of whether they were dynamic or assigned. The audit log records membership changes including those made by rule evaluation.

Watch for the combination: an attribute edit followed shortly by a membership change and then by access to something new. Individually these are administrative noise, and in sequence they are an escalation.

How to prevent it

Do not build dynamic rules on attributes that users or broadly delegated administrators can write. Use attributes populated only by your identity synchronisation or HR integration, so the value cannot be set by the person it describes.

Scope delegated administrative roles with administrative units so that a User Administrator can only modify the accounts they are responsible for, rather than everyone in the tenant.

Review what your dynamic groups actually grant. Many were created for licensing and have quietly accumulated application assignments and policy exclusions since, which changes their security significance without anyone revisiting the rule.

Real-world context

Dynamic group abuse is a recognized Entra ID escalation technique and appears in cloud identity attack path research. It persists because it sits at the boundary between two teams: whoever writes group rules and whoever governs attribute write permissions.

The wider pattern is that automation of access decisions moves the security question upstream. Once membership is calculated from data, the integrity of that data becomes an access control concern, and it is rarely treated as one.

The pattern maps to MITRE ATT&CK T1098 Account Manipulation and T1078.004 Cloud Accounts.

Applying this at work

• List your dynamic groups and the attributes their rules evaluate, then check who can write each of those attributes.
• Identify which dynamic groups grant application access, licenses or conditional access exclusions, rather than assuming they are only for organization.
• Use administrative units to scope delegated administrative roles to the accounts they should cover.
• Alert on changes to attributes used in dynamic membership rules.
• Prefer attributes sourced from your HR system or directory synchronisation over anything user-writable.

Frequently asked questions

What is a dynamic group in Entra ID?

A group whose membership is calculated from a rule over user or device attributes rather than assigned manually. Entra ID evaluates the rule continuously and adds or removes members automatically as attribute values change.

How does editing an attribute lead to privilege escalation?

If a dynamic group's rule evaluates an attribute the attacker can write, setting that attribute to a matching value adds them to the group. They then inherit whatever the group grants, which may include application access or policy exclusions.

How do administrative units help?

They scope delegated administrative roles to a subset of the directory, so a User Administrator can only modify the accounts within their unit rather than every account in the tenant. That limits whose attributes an attacker can change.

Do I need my own Azure account to practice this?

No. The lab runs in a live Azure environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.