Escalation by Design: How I Inherited Blob Access in Azure Without Direct Permissions

Written by:

The Challenge

In this project, I set out to simulate a real-world privilege escalation path in Azure using nothing more than group nesting and RBAC misconfiguration. My goal was to prove that a mid-tier user (manager) could access sensitive blob data without ever being granted direct access.

Lab Environment Setup

ComponentDetails
Azure TenantFree-tier Azure AD tenant
Usersmanager (Target user)
GroupsMidLevelGroup, tempAdminGroup, StorageAccessGroup
ResourceAzure Storage Account (ctfstorage12345)
ContainerPrivate blob container (ctf-container)
Fileflag.txt (sensitive data marker)

Group Nesting Trap

The manager user was only a member of the MidLevelGroup. However, through nested groups, this membership eventually lead to Storage Blob Data Contributor access.

Here is the Group Structure:

manager
└── MidLevelGroup
└── tempAdminGroup
└── StorageAccessGroup (assigned to Storage Blob Data Contributor role)

This group structure mirrors real enterprise IAM drift, where access is granted through layers of nested groups, sometimes without direct oversight.

Attack Simulation

I created a private Azure blob container with a sensitive file (flag.txt) and attempted to access it using the manager account:

Access attempts:

  • ❌ Azure Portal – “Access Denied”
  • ❌ Browser URL – “Public access not permitted”
  • ✅ Azure CLI – Eventually Succeeded

CLI Access Test

After waiting fo Azure to propagate token claims (approx 1hr), I ran this command:

az storage blob list \
–account-name ctfstorage12345 \
–container-name ctf-container \
–auth-mode login \
–output table

Result: Flag.txt was listed in the terminal, Proving manager had successfully inherited access without ever being directly assigned any role.

Even with proper group nesting and role assignment, Azure RBAC propagation lag can cause invisible permission mismatch, which highlights how slow privilege changes can expose security blind spots.

Detection & Remediation

How to detect this in the real world:

  • Audit nested group memberships regularly
  • Use Azure AD group membership reports
  • Monitor storage access via diagnostic settings
  • Run RBAC effective access checks with az role assignment list

Remediation actions:

  • Flatten excessive group nesting
  • Apply least privilege access at the role assignment level
  • Use Conditional Access to limit inherited permissions

What I Learned

  • IAM is not just about assigning roles, its about understanding how roles flow through identity structures
  • Group nesting can create blind spots in even well managed cloud environments
  • Azure’s propagation delays can open windows of unexpected access

Leave a comment