IAM the Captain Now – Hijacking Azure Identity Access

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://trustedsec.com/blog/iam-the-captain-now-hijacking-azure-identity-access
• Blog Title: IAM the Captain Now – Hijacking Azure Identity Access
• Suggested Section: Azure Pentesting -> Az - Privilege Escalation -> Az - Azure IAM Privesc (Authorization) (add/extend a subsection for RBAC escalation primitives: roleAssignments/write, roleDefinitions/write, and federatedIdentityCredentials/write)

🎯 Content Summary

What the post is about (and why it matters)

The post explains how Azure IAM/RBAC misconfigurations (especially in custom roles) can be abused to escalate privileges by granting an attacker the ability to change authorization itself. Azure IAM answers “who can do what to which resources” and is implemented primarily via RBAC (Role-Based Access Control), where identities (users, service principals, managed identities) receive permissions through built-in r...

🔧 Technical Details

Trick 1 — RBAC escalation by writing role assignments (RoleAssignment/Write): If a compromised principal has Microsoft.Authorization/roleAssignments/write at some scope, the attacker can directly create new role bindings at that scope. Practical flow: authenticate to the tenant (az login / az account show), confirm current access (az role assignment list), optionally confirm the role’s allowed actions (az role definition list --name <roleDefinitionName>), then escalate by granting a privileged role (e.g., Owner) using az role assignment create --assignee <PRINCIPAL-ID> --role <ROLE> --scope <SCOPE>. This converts credential compromise into effective admin over sensitive resources (e.g., Key Vault).

Trick 2 — Permission inflation by editing role definitions (RoleDefinition/Write): If a principal has Microsoft.Authorization/roleDefinitions/write, they ...

🤖 Agent Actions

I’m mapping the Azure section first, then I’ll read the most relevant IAM/RBAC files before deciding whether this belongs in an existing privesc page or a narrower subsection.
I found the existing Azure IAM privesc page the blog maps to. Next I’m reading that page plus adjacent Azure IAM and federation content to check what’s already documented and where the missing detail belongs.
The existing page already covers the three permissions, but only at a very high level. I’m pulling the original article and Microsoft references now so I can tighten the abuse paths without duplicating what’s already in the federation-abuse page.
I’ve got enough context to patch the existing authorization privesc page directly. The gap is mainly sharper operator guidance: enumeration steps, the “modify already assigned role” shortcut for roleDefinitions/write, and a concise FIC hijack/persistence primitive without re-copying the longer federation page.
I’m editing az-authorization-privesc.md now. The change keeps the existing structure but adds the missing RBAC escalation primitives, tighter CLI workflow, and a proper ## References section at the end.
I spotted two small quality issues in the existing page while verifying: the sample JSON had a trailing comma and one sentence had a typo. I’m cleaning those up before closing this out.
Updated az-authorization-privesc.md.

The change stays in the existing Azure IAM privesc page and adds the missing technical value from the TrustedSec post without creating a new page: a clearer explanation of RBAC authorization-as-privesc, a practical enumeration and abuse flow for Microsoft.Authorization/roleAssignments/write, the immediate-effect abuse path for Microsoft.Authorization/roleDefinitions/write when the role is already assigned, and a tighter FIC hijack/persistence section for Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write with az identity federated-credential create plus a pointer to the existing federation-abuse page. I also added a proper ## References section at the end and fixed a sample JSON syntax issue while verifying.

Verification: reviewed the final file content and diff; no other files were modified.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://trustedsec.com/blog/iam-the-captain-now-hijacking-azure-identity-access

Content Categories: Based on the analysis, this content was categorized under "Azure Pentesting -> Az - Privilege Escalation -> Az - Azure IAM Privesc (Authorization) (add/extend a subsection for RBAC escalation primitives: roleAssignments/write, roleDefinitions/write, and federatedIdentityCredentials/write)".

Repository Maintenance:

• MD Files Formatting: 584 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0