Skip to content
Forestall

AZ_ELEVATE_ACCESS

Copy page

Summary
Forestall ACL Alias AZ_ELEVATE_ACCESS
Entra ID (Azure AD) Alias Elevate Access
Affected Object Types Tenant Root Management Group (transitively every Management Group, Subscription, and Resource)
Edge Direction Global Administrator principal (User or Group) -> Tenant Root Management Group
Exploitation Certainty Certain
Graph Permission / Role Membership in the built-in Global Administrator directory role

Description

AZ_ELEVATE_ACCESS represents Microsoft’s built-in Elevate access capability. A Global Administrator can call POST /providers/Microsoft.Authorization/elevateAccess to grant themselves the User Access Administrator ARM RBAC role at the Azure root scope (/).

Global Administrator is a Microsoft Entra ID directory role and, by default, has no Azure Resource Manager (ARM) permissions. Elevate access is the bridge between the two planes: after elevating, the Global Administrator holds User Access Administrator at the root of the ARM hierarchy, which inherits down to every management group, subscription, resource group, and resource in the tenant through the existing AZ_PARENT chain.

The collector draws this edge from each Global Administrator principal to the Tenant Root Management Group (whose ARM name equals the tenant id). Service principals and applications are deliberately not given this edge, because the elevateAccess REST endpoint rejects non-user principals.

This edge turns tenant-level identity compromise into full Azure resource-plane compromise, so it is a critical privilege-escalation and lateral-movement path.

Identification

PowerShell (Az / REST)

Connect-AzAccount


# Who holds Global Administrator (these principals can elevate access)
$globalAdminRoleDefinitionId = "62e90394-69f5-4237-9190-012177145e10"
$uri = "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?`$filter=roleDefinitionId eq '$globalAdminRoleDefinitionId'&`$expand=principal"
(Invoke-AzRestMethod -Uri $uri).Content


# Check whether elevate access is currently in effect (root-scope role assignments)
$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token
Invoke-RestMethod -Method GET `
  -Uri "https://management.azure.com/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01&`$filter=atScope()" `
  -Headers @{ Authorization = "Bearer $token" }

Exploitation

Elevate to User Access Administrator at root scope

# As a Global Administrator, grant yourself User Access Administrator at "/"
az rest --method post \
  --url "https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"

After elevation the principal can assign any ARM role (including Owner) at any scope:

# Assign Owner over a subscription to a controlled identity for persistence
az role assignment create --assignee "<ObjectId>" --role "Owner" --scope "/subscriptions/<SubscriptionId>"

Related Attack Paths:

Mitigation

  • Keep the number of Global Administrators as low as possible and prefer eligible (PIM) assignments over permanent ones.
  • After any legitimate use of elevate access, remove the root-scope User Access Administrator assignment (Azure Portal -> Properties -> set access management for Azure resources back to No, or az role assignment delete at scope /).
  • Alert on Microsoft.Authorization/elevateAccess/action in the Activity log.
  • Use Conditional Access and phishing-resistant MFA for privileged roles.

Detection

Use the Azure Portal:

  1. Open Azure Portal -> Monitor -> Activity log (or the root scope Activity log).
  2. Filter Operation name for Assigns the caller to User Access Administrator role (Microsoft.Authorization/elevateAccess/action).
  3. Review Caller, Time, and Source IP for unexpected elevation.
  4. Filter for Microsoft.Authorization/roleAssignments/write at broad scopes (/, management group, subscription) that follow an elevation.

References

Was this page helpful?

Thank you for your feedback.