General
This check detects role assignable groups where the owners do not have the roles assigned to the group. This creates a privilege escalation vulnerability because group owners can add themselves as members of the group to gain elevated permissions.
Role assignable groups are a special type of Azure AD group that can be used to assign Azure AD roles. Instead of assigning a role directly to a user, you can assign a role to a group and make users members of that group. This simplifies the management of role memberships.
Rationale
Role assignable groups provide a powerful way to manage Azure AD roles, but can pose a serious security risk when the owners of these groups don't have the same permissions as the group itself. The problem arises when a user owns a role assignable group but doesn't have the role(s) assigned to that group.
A malicious or compromised owner can simply add themselves as a member of the group to directly gain elevated privileges. This is a classic privilege escalation attack. The owner only needs to modify group memberships - something group owners can do by default - and thereby gains access to powerful roles like Global Administrator, Privileged Role Administrator, or other critical administrative roles.
This check filters out TIER0 users who already have high privileges. Owners with any of the following roles (active or eligible via PIM) are not reported, as they already have similar or higher privileges:
- Global Administrator
- Privileged Role Administrator
The focus is on identifying regular users who have unintentionally been given a privilege escalation path through group ownership. This can arise from legitimate business needs (for example, an HR manager who owns a group for user management), but represents a significant risk that must be addressed.
Manual instruction
Follow these steps to remediate the privilege escalation risks:
- Review the detected groups: Check the list of role assignable groups and their owners in the check output. For each group, you'll see which roles are assigned and which owners don't have those roles.
-
Determine if ownership is legitimate: Ask yourself whether this person has a legitimate business reason to own this group. Consider:
- Does this person have a valid reason to manage group memberships?
- Is there an alternative way to achieve this without ownership?
- Should this person actually have the role assigned to the group?
-
Choose a remediation strategy:
- Option 1 - Remove ownership: If ownership is not necessary, remove the user as owner of the group via Azure AD Groups [group name] Owners.
- Option 2 - Assign the role directly: If the person legitimately needs the role to perform their duties, assign the required role(s) directly to the user. This makes the ownership no longer a privilege escalation risk.
- Option 3 - PIM configuration: If the person only needs the role temporarily, configure Privileged Identity Management (PIM) to make the role eligible instead of permanent ownership of a role assignable group.
- Option 4 - Change group type: If the group doesn't need to be used for role assignment, disable the "Azure AD roles can be assigned to the group" option (this can only be done when creating the group).
- Document the decision: Make a note of why you chose this configuration, so that future audits or reviews understand the context.
Impact
The impact of remediating this vulnerability depends on the chosen remediation:
- Removing ownership: The user can no longer add or remove group members. Ensure there are alternative group owners who can perform these tasks.
- Direct role assignment: The user permanently receives the elevated permissions. This should only happen if the person legitimately needs these permissions for their role.
- PIM configuration: The user must activate the role when needed, which provides just-in-time access and better audit trails.
Comments
0 comments
Please sign in to leave a comment.