How to Detect and Compromise Azure Blobs and Storage Accounts
An organisation’s cloud storage is a prime target for attackers looking to identify sensitive information for exfiltration. Depending on the settings set on Azure Storage accounts, companies could be unknowingly exposing their containers / blobs to the internet for direct access. Azure Storage is Microsoft’s solution for data management and storage in the cloud. Depending on the permissions set on an organisation’s storage account and if the access keys / shared access signature (SAS) URIs are uncovered by an attacker – attackers can connect to an organisation’s storage account and pull the data stored.
This blog post explores the methods an attacker can use to interact with Azure Storage accounts to pull/access sensitive data and what to analyse to detect these attacks. The tools I used to perform this include:
Background on Azure Storage
One of the hardest parts of learning any new topic in cybersecurity is the various names that vendors prescribe. As such, this little section is a primer on Azure Storage and what the various words mean in Azure. I hope this can give a little more context for the rest of the blog post!
Azure Storage is primarily handled by an Azure Storage Account. These accounts are used to access services such as blobs, files, tables and queues. The screenshot below taken from Microsoft’s documentation highlights the general relationship. In short, a storage account exists – in this instance “Sally”. Sally has two containers – one for pictures and one for movies (think of this like a directory or a folder). Within these folders there are files or “blobs”.
From the attack perspective, an attacker would want to know what containers exist and subsequently, what blobs exist within that container. This will allow the attacker to download / enumerate / access these files.
- No public read access
- Public read access for blobs only – this requires that an attacker KNOWS the object URL to access it. This is the setting I have chosen for my storage account.
- Public read access for container and blobs
- SV – Version of the Storage Service
- SS – What the service can access, in this instance it can access “b” for Blob and “f” for Files (there is also q for Queue, t for Table)
- SRT – What this SAS applies to and in this instance, it applies to service operations
- ST – Start time of the SAS (when it was valid from)
- SE – When the SAS expires
- SP – Operation permissions, in this instance it is “read and write”
- SIP – IP range that it will accept requests from
- SPR – Only allows HTTPs connections
- SIG – Signature
- Operation – List Storage Account Keys
- “ipaddr” Field – Shows remote IP
- Status – Shows if the request was successful or not
- Caller – What user account was utilised to perform this action
- File Access / Blobs Viewed
- Authentication Events (anonymous or with user accounts)
- Remote IP
- User Agent Strings
- Operation: GetBlob
- Blob: https://<StorageAccount>.blob.core.windows.net/<container>/<filename>
- Status Code: 200 (success)
- Take note also of the user account – depending on the permissions set on the container this may appear as AnonymousSuccess.
- ListBlobs (Returns a list of blobs under a specified container)
- ListContainers (Returns a list of containers under the account)