# Compromising Azure Blobs and Storage Accounts

Storage Accounts are high-value targets in a tenant if an attacker is looking to exfiltrate sensitive data. What we'll focus on in this section is a common misconfiguration that exposes access keys for the storage account itself allowing an attacker to download files and data from it.

Storage Accounts are organized with a hierarchy:

* Accounts
  * Containers
    * Blobs

In the SA (Storage Account) we might have a `otter` account with 4 containers, each storing different kind of files.

Upon creation, every storage account can be interacted with using a default endpoint: `https://<storage_account_name>.blob.core.windows.net`. Just like a normal website, we are able to navigate the containers and blobs by appending `/<container_name>/<blob_name>`. When a SA is created, the user is given 3 choices of Public Access Level

1. No public read access
2. Public read access for blobs only
3. Public read access for both containers and blobs

Of course, the recommended setting is the first one but (at the time of writing this) the second one is the default setting.

Once we discover a SA, this can be done with DNS enumeration as well as other methods, we need to find out what containers are stored inside it

```powershell
PS /home/otter> az storage account keys list --subscription <subscription_id> --account-name <storage_account_name>
```

If the account has been set up with the before-mentioned misconfiguration, this command will return Storage Access Keys we can use to pull data from the SA; it will look something like this

```json
[
	{
		"creationTime": "<some_creation_time>",
		"keyName": "key1",
		"permissions": "FULL",
		"value": "<storage_access_key>"
	}
]
```

With this information we can list the files stored in the SA

```powershell
PS /home/otter> az storage blob list --subscription <subscription_id> --account-name <storage_account_name> --account-key "<storage_access_key>" --container-name "<container_name>"
```

To download files / blobs from the container we discovered we can use a SAS (Shared Access Signature) URI or the AZCli; SAS URIs are sometimes "leaked" by companies on websites or other common locations so it's good practice to look out for those, they usually have the following format

```
https://<something>.blob.core.windows.net/?restype=service&comp=properties&sv=<somehing>&ss=<somehing>&st=<somehing>&se=<somehing>&sr=<somehing>&sp=<somehing>&sip=<somehing>&srp=<somehing>&sig=<somehing>
```

| Parameter |                                         Meaning                                        |
| :-------: | :------------------------------------------------------------------------------------: |
|     SV    |                             Version of the storage service                             |
|     SS    |                               What the service can access                              |
|    SRT    |                               What the SAS URI applies to                              |
|     ST    |                              Validity date of the SAS URI                              |
|     SE    |                             Expiration date of the SAS URI                             |
|     SP    |                               Operation permissions (R/W)                              |
|    SIP    | IP range the requests will be accepted from (similar to a Conditional Access Policies) |
|    SPR    |                              Only allows HTTPS connections                             |
|    SIG    |                                        Signature                                       |

This format might be used along with regular expressions to scrape possible SAS URIs.

If the SAS with the signature value is not exposed already, we can generate one

```powershell
PS /home/otter> az storage blob generate-sas --subscription <subscription_id> --account-key <storage_access_key> --account-name <storage_account_name> --continer-name <container_name> --permissions acdrw --name <file_name>
```

Now we can use [Azure Storage Explorer](https://azure.microsoft.com/en-us/products/storage/storage-explorer/) with the Connection string of

```
DefaultEndpointsProtocol=https;AccountName=<some_name>;AccountKey=<storage_account_key>;<generated_sas>
```

All of this can be skipped if we already know what files are present in which containers (this is a more unrealistic scenario but it can happen) and download the file with a simple web request

```powershell
PS /home/otter> Invoke-WebRequest -Uri "https://<some_storage_name>.blob.core.windows.net/<container_name>/<file_name>" -OutFile otter.txt
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://otter.gitbook.io/red-teaming/notes/aad/compromising-azure-blobs-and-storage-accounts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
