🧨 Exploiting Owner and Privileged Azure AD Role Permission

Understanding Azure AD vs Azure RBAC Roles

Azure has two distinct permission systems

• Azure AD roles: Govern identity and access to directory resources (users, groups, applications).
• Azure RBAC roles: Govern access to Azure subscription resources (VMs, storage, Key Vaults, etc).

While these systems are separate by design, poor configuration or architectural shortcuts often open up opportunities for lateral movement and privilege escalation between them.

Escalation Path #1: Exploiting Group Membership

If an attacker has the ability to modify Azure AD group memberships, they can add themselves to a group that has RBAC roles on subscriptions:

User → Adds self to group (e.g., cloud-architects) → Group has Owner role on subscription → User escalates.

To discover such paths:

• Use Get-AzureADAuditSignInLogs to identify users with access to Azure management tools.
• Review group memberships using tools like PowerZure.

ℹ️ Tip: Groups with RBAC roles tied to them are especially dangerous when group management is loosely controlled.

Escalation Path #2: Resetting User Passwords

Certain Azure AD roles (e.g., Password Administrator, User Administrator) can reset passwords for users with access to Azure resources:

1# Resetting password of a privileged user
2Set-AzureADUserPassword -ObjectId <user_id> -Password <new_password>

This allows impersonation of users who can access other subscriptions a highly intrusive attack.

⚠️ Use only with explicit permission, as this disrupts user access.

Escalation Path #3: Exploiting Service Principal Secrets

Users with permissions to modify app registrations (service principals) can escalate access by adding new credentials:

1# Add a new secret to a service principal
2New-AzADAppCredential -ObjectId <sp_id> -Password <secret>

If the service principal has Contributor or Owner RBAC roles, the attacker now inherits those privileges without disrupting the app’s existing access.

Escalation Path #4: Elevating Access to the Root Management Group

Global Administrators can use Azure’s built in “Access Management for Azure resources” to elevate themselves to the root management group:

1az login --admin
2az role assignment create --assignee <your_upn> --role "Owner" --scope "/"

This gives unrestricted access across all management groups and subscriptions total tenant compromise.

🔐 Mitigation: Monitor this setting and restrict GA assignments to a secure group.

Discovering Azure AD to RBAC Links

To spot such paths during an assessment

• Review Enterprise Applications for apps using Azure AD identities.
• Check group to role mappings in subscriptions.
• Look for non interactive sign ins in the Azure AD sign-in logs.
• Watch for service principals assigned to high privilege roles.

Elevating access

✅ Step 1: Authenticate to Azure

1az login

✅ Step 2: Get tenant level access

1az login --allow-no-subscriptions

✅ Step 3: Exploit the Global Administrator role

1az rest --method post --url "/providers/Microsoft. Authorization/elevateAccess?api-version=2016-07-01"

✅ Step 4: Sign out and then sign in again with the Global Administrator credentials

1az logout
2az login

✅ Step 5: Assign the subscription Owner role to the Global Administrator account

1userPrincipalName=$(az ad signed-in-user show --query userPrincipalName -o tsv)

1az role assignment create --role "Owner" --assignee $userPrincipalName