The following post focuses on Azure Blob Container, its risks, how it builds, and how to attack with a specific scenario.

Before reading this post, let me ask you a few questions and know if you can answer them. Are you familiar with your Azure Blob Containers? Do you know which data exist in the Blobs? Do you know if you have a Blob exposure? Do you know the potential risks? I have a bunch of questions about Azure Blob, but let’s go into this post and realize the facts and state of your Blob exposure.

As we know, storing data is one of the common uses of the cloud. Store data in the cloud has a lot of benefits. However, cloud storage has a load of potential security risks that should be considered before moving. While most cloud storage systems have decent security measures in place, they aren’t perfect and can differ wildly from each other in terms of security coverage.

The post will get you through the Azure Storage, Blob Container architecture, Threat Matrix, and a specific attack (one from 15 Blob attacks).

What is Azure Storage?

The Azure Storage platform is Microsoft’s cloud storage solution for data storage scenarios. Azure Storage provides high availability, scalability, durability, and secure storage for various data objects in the cloud. Azure Storage data objects are accessible worldwide over HTTP, HTTPS, and REST API.

Now, it is obvious to wonder about the reasons to opt for storing in the cloud in the first place. First, you don’t need any physical space or hardware to store your data, ensuring cost savings. Cloud storage allows users to scale the storage capacity up or down according to their requirements.

Most importantly, cloud storage ensures that your data is available to you at all times. The core storage services on Azure Storage offer different options, such as disk storage for Azure VMs, messaging stores, NoSQL stores, file system services, and a massively scalable object store.

The Azure portal and Azure Storage Explorer provide user-interface tools for interacting with Azure Storage. Azure Storage also provides client libraries for developers building applications or services with .NET, Python, JavaScript, Go, and others. We can use Azure PowerShell and Azure CLI to write scripts for data management or configuration tasks.

Azure Storage Types

Users can access the different types of Azure storage through their Azure Storage account. You can find the types of Azure storage by reflecting on the data services available on the Azure Storage platform. Here are the types of Azure storage services.

Azure Blob Storage is the object storage solution of Microsoft, primarily aimed at the cloud. The design of blob storage is effectively tailored for the storage of massive volumes of unstructured data in text and binary forms. An Azure blob storage tutorial would showcase the different use cases for this. It is suitable. Blob storage is suitable for streaming video and audio, storing files for distributed access, and delivering images or documents directly to browsers.

Queue Storage is an essential addition to the Azure Storage tutorial among types of Azure storage. It can help in the storage and retrieval of messages. Queues are generally applicable for storing a list of messages for asynchronous processing. Queue messages could be up to 64 KB in size, and a queue can contain millions of messages.

Azure Storage Architecture

The final aspect of an Azure Storage tutorial would refer to its architecture. Till now, you noticed the functionalities and different services on Azure Storage. So, it is inevitable to wonder how Azure Storage is capable of achieving its functionalities. Therefore, readers need a brief overview of the architecture of Azure Storage to understand it better.

Blob storage offers three types of resources:

• The storage account
• A blob in a container
• A container in the storage account

The following diagram shows the association between these resources.

Accounts provide a unique namespace in Azure for your data. Every object that you store in Azure Storage has an address that includes your unique account name. The combination of the account name and the Azure Storage blob endpoint forms the base address for the objects in your storage account.

Containers organize a set of blobs, similar to a directory in a file system. A storage account can include an unlimited number of containers, and a container can store an unlimited number of blobs.

You can configure a container with the following permissions:

• No Public Read Access – its blobs are private and can only be accessed by the storage account owner. This is the default for all new containers.
• Public Read Access for blobs only – can be read by an anonymous Internet user. But container data is not available. Anonymous clients cannot enumerate the blobs within the container.
• Complete Public Read Access – can be read by anonymous Internet users. Clients can enumerate blobs within the container by anonymous request but cannot enumerate containers within the storage account.

Blob Naming Conventions – Like everything else on Azure, there are specific naming conventions for naming blobs and containers in a Storage Account. To begin with, the Storage Account name needs to be globally unique. The Storage Account URI generated contains the account name only, for example, https://misconfig.blob.core.windows.net.

Container naming rules – A container name must be a valid DNS name, and as such, it needs to conform to the following naming rules:

• The name must start with a letter or number and can contain only letters, numbers, and the dash character.
• Every dash (-) character must be immediately preceded and followed by a letter or number.
• Consecutive dashes are not permitted in container names.
• Only lowercase letters are allowed.
• Names can be between 3 and 63 characters long.

Blob naming rules must to the following naming rules:

• Blob names are case-sensitive
• Blob name can contain any combination of characters.
• Blob names can be between 1 and 1,024 characters long.
• Reserved URL characters must be appropriately escaped but generally should be avoided.

Security Risks

Lack of Control – When you rely on a third party to store data and take responsibility. This is a double-edged sword, however. On the one hand, you won’t have to manage your data – on the other hand, and somebody else will. If something affects your storage provider, like outages or malware infections, that will directly impact access to your data. You’ll have to rely on the provider to fix the issues. The more time your data spends unprotected, the more at-risk it becomes.

Data Leakage – A large part of secure data storage is ensuring no one outside your organization tries to access your data. Another part is ensuring your data isn’t sent to anyone outside your organization (unless you send it yourself). Data leakage can cause serious problems since it could expose business-critical or private data to external sources. Even if you take steps to prevent anyone in your enterprise from leaking data, your storage provider might accidentally expose your data to the wrong person.

APIs and Storage Gateways – Some enterprises use cloud storage APIs or storage gateways to help them migrate their data onto the cloud. These tools act as a middleman between the user and the storage provider. They may help your workers access and manage the data on your cloud, but an insecure API or gateway might cause a lot of damage to your data. Choose one with reputable security features if you want or need to use a storage API or gateway.

Misconfiguration is one of the main security issues on the cloud vendors and many times we have seen how Azure Blob Container is widely open to the public networks because of a lack of knowledge, lack of visibility, and other reasons. That can leads to a massive breach and other security issues.

Threat Stages

Now that we are more familiar with the Azure Storage architecture and more about Azure Blob Container let’s cover the attack steps in order to know the ways to find the exposures and the exploitable assets.

The following Threat Matrix is part of the Azure Storage matrix for MITRE ATTACK. This matrix is great for attackers, defenders, and investigators because it provides the big picture, and from there we could dig into each part and step.

Reconnaissance

Like any other attack scenario, we should know how the architecture is built and the way to recon and discover the existing Azure Blobs that consists of techniques that involve actively or passively gathering information that can be used to support targeting on Azure Blob Container. As we know, attackers are trying to gather the information that can be used to support targeting.

• Blob Recon – Adversaries can enumerate storage account names to find an active storage account. Examples of such methods can vary from search *.blob.core.windows.net to brute-force account creations. Adversaries can also operate tools such as Microburst, BlobHunter, and others.
• Containers Discovery: Adversaries may enumerate container names for an already known storage account. Adversaries can employ crawler results or leverage public toolkits, such as Az-Blob-Attacker, Microburst, BlobHunter, GrayhatWarfare, Basic Blob Finder, etc.

Initial access

At this level, adversaries are trying to get into your network. Initial access consists of techniques that use various entry vectors to gain their initial foothold within a network. Footholds gained through initial access may allow for continued access, like valid accounts and use of external remote services, or may be limited use due to changing passwords or keys.

• Valid SAS URI: A shared access signature is a URI that grants restricted access rights to storage resources. Adversaries may steal a SAS URI using one of the Credential Access techniques or capture a SAS URI earlier in their reconnaissance process through social engineering to gain initial access.
• Valid Access Key: Adversaries may steal an access key using one of the credential Access techniques or capture one earlier in their reconnaissance process through social engineering to gain initial access.
• Authorize access to Blob with Managed Identities: Adversaries may steal account credentials using one of the Credential Access techniques or capture an account earlier in their reconnaissance through social engineering to gain initial access.
• Use of Public Access: Adversaries may leverage publicly exposed storage accounts to list containers/blobs and their properties, information that can be beneficial as the attack advances.

Persistence

Adversaries are trying to maintain their foothold. Persistence consists of techniques adversaries use to keep access to systems across changed credentials and other interruptions. Persistent techniques include access, action, or configuration changes that let them maintain their foothold on systems.

• Firewalls and VNET Configuration Changes: Storage offers built-in security features. Administrators can leverage these capabilities to restrict access to storage resources. Restriction rules can operate atOnlyonfigured. Only requests originating from authorized suRBAC’swill be served when network rules are configured. Adversaries may insert additional persistent access.
• RBAC Changes: Storage services offer built-in RBAC roles that encompass sets of permissions used to access different data types. Adversaries may leverage the RBAC’s persistent access to their owned identity objects. Definition of custom roles is also assigning the assignment of an RBAC role to an identity object the storage provider grants access to that security principal.

Defense evasion

Adversaritactics’rying to avoid being detected. Defense evasion consists of techniques adversaries use to avoid detection throughout their compromise. Techniques used for defense evasion include abuse of trusted processes to hide and masquerade their malicious intents. Other tactics’ techniques are cross-listed here and include the added benefit of subverting defenses.

• Firewalls and VNET Configuration Changes: Storage services offer built-in security features. Administrators can leverage these capabilities to restrict access to storage resources. Restriction rules can operate at the IP level, and only requests originating from authorized subnets will function. Adversaries may insert additional rules to masquerade and legitimatize their data exfiltration channel.
• RBAC Changes: Storage services offer built-in RBAC roles that encompass sets of permissions used to access different data types. Upon assignment of an RBAC role to an identity object, the storage provider grants access to that security principal. Adversaries may leverage the RBAC mechanism to disguise their activities as typical within a compromised environment.
• Storage Data Clone: Storage services offer different types of cloning or backup data stored on them. Adversaries may abuse these built-in capabilities to steal sensitive documents, source code, credentials, and other business crucial information.
• Data Transfer Limits: Adversaries may fragment stolen information and exfiltrate it in different size chunks to be detected by triggering potentially predefined transfer threshold alerts.
• Automated Exfiltration: Adversaries may exploit legitimate automation processes predefined by the compromised organization to have their logging traces blend in generally within the company’s typical activities.
• ACL Modification: Adversaries may adjust ACL configuration at the granularity of a specific blob or container to secure a channel to exfiltrate stolen data. These ACL modifications occur at the control-plane level, which is often overlooked.

Credential Access

Credential Access consists of techniques for stealing credentials like account names and passwords. Techniques used to get credentials to include keylogging or credential dumping. Using legitimate credentials can give adversaries access to systems, make them harder to detect, and provide the opportunity to create more accounts to help achieve their goals.

• Access query key: Adversaries may leverage subscription or account-level access to gather storage account keys and use these keys to authenticate at the resource level. Adversaries can query management APIs to fetch primary and secondary storage account keys. This technique exhibits cloud resource pivoting combined with control management and data planes.
• Access Cloud Shell profiles: Cloud Shell is an interactive, authenticated, browser-accessible shell for managing cloud resources. It provides the flexibility of shell experience, either Bash or PowerShell. To support the Cloud Shell promise of being accessible from everywhere, Cloud Shell profiles and session history are saved on the storage account.

Discovery

Adversaries are trying to figure out your environment. Discovery consists of techniques adversaries may use to gain knowledge about the system. These techniques help adversaries observe the environment and orient themselves before deciding how to act. Tools witnesses at the reconnaissance phase are often used toward this post-compromise information-gathering objective.

• Storage service discovery: Adversaries may leverage subscription/account-level access to discover storage properties and stored resources. During the reconnaissance phase, tools witnessed are often used toward this post-compromise information-gathering objective, with authorization to access storage APIs, such as the List Blobs call.

Lateral movement

Adversaries are trying to move through your environment. The lateral movement consists of techniques that adversaries use to enter and control remote systems on a network. Reaching their objective often involves pivoting through multiple systems and accounts to gain access. Adversaries may install their remote access tools to accomplish lateral movement or use legitimate credentials with native networks and operations which may be stealthier.

• Malicious content upload: Adversaries may use storage services to store a malicious program or toolset that will be executed later during their operation. In addition, adversaries may exploit the trust between users and their organization’s Storage services by storing phishing content.
• Malware distribution: Storage services offer mechanisms to support auto-synchronization between various resources and the storage account. Adversaries may leverage access to the storage account to upload malware and benefit from the auto-sync built-in capabilities to have their payload populated and potentially weaponize multiple systems.
• Trigger cross-service interaction: Adversaries may manipulate storage services to trigger a compute service, where an attacker already has a foothold on a storage container and can inject a blob that will initiate a chain of computing processes.
• Data manipulation: Content stored on a storage service may be tainted by adding malicious programs, scripts, or exploits to otherwise valid files. Upon execution by a legitimate user of harmful content, the malicious portion runs the adversary’s code on a remote system. Adversaries may use harmful shared content to move laterally.
• Access Cloud Shell profiles: Cloud Shell is an interactive, authenticated, browser-accessible shell for managing cloud resources. It provides the flexibility of shell experience, either Bash or PowerShell. Adversaries may leverage the legitimate use of Cloud Shell to impersonate account owners and potentially obtain additional secrets logged as part of session history.

Malicious tools can be stored on *.blob.core.windows.net and downloaded when required. The risk could be a scenario where attackers can choose a customized subdomain on *.blob.core.windows.net for blob storage. Attackers abuse this function they have hosting. HTML files using the blob.core.windows.net subdomain, creating fake login pages that capture credentials.

Exfiltration

Adversaries are trying to steal data. Exfiltration consists of techniques adversaries may use to steal data from your network. Once they’ve collected data, adversaries often package it to avoid detection while removing it. Getting data out of a target network typically involves transferring it over their command-and-control or alternative channel.

• Storage data clone: Storage services offer different types of cloning or backup data stored on them. Adversaries may abuse these built-in capabilities to steal sensitive documents, source code, credentials, and other business crucial information. This technique has been employed as part of data theft previously.
• Data transfer size limits: Adversaries may steal information and exfiltrate it in different size chunks to be detected by triggering potentially predefined transfer threshold alerts.
• Automated exfiltration: Adversaries may exploit legitimate automation processes predefined by the compromised organization to have their logging traces blend in generally within the company’s typical activities.
• ACL modification: Adversaries may adjust the ACL configuration granularity of a specific blob or container to secure a channel to exfiltrate stolen data. These ACL modifications occur at the control-plane level, which is often overlooked.

Impact

Adversaries are trying to manipulate, interrupt, or destroy your systems and data. Impact consists of adversaries’ techniques to disrupt availability or compromise integrity by manipulating business and operational processes. Adversaries might use these techniques to follow through on their end goal or provide cover for a confidentiality breach.

• Data corruption: Adversaries may corrupt data stored on storage services to disrupt the availability of systems or other lines of business.
• Data Encryption: Adversaries may encrypt data stored on storage services to disrupt the availability of systems or other lines of business. They make resources inaccessible by encrypting files or blobs and withholding access to a decryption key. This may be done to extract monetary I’llensation from a victim in exchange for decryption or a key (ransomware).

Exploiting Blob

There are around 15-20 to recon, discover and exploit Azure Blob Containers, and it depends on the permissions and configuration level of each Azure Storage. Let’s go into a scenario in which anonymous permissions are configured on a blob, and we are totally external to the Azure environment (not from an insider attacker).

To get the right insecure blob that can be abused, we need to search and discover, and one of the easiest ways to perform discover and search is a mix of a few tools. Tools such as MicroBurst, AAD Internals, and even Google Dorks, and we need to add a few network commands.

• Google Dorks – To find and search for the relevant domains and blobs. (optional)
• AAD Internal – To search and find the primary artifacts such as domain, tenant, and subscription.
• MicroBurst – Search the storage account name to check if the containers exist based on a wordlist saved in the permutations.

Let’s play with the tools and exploit the insecure blob.

First, we must discover the relevant assets with AAD Internal based on a known domain name. The command below provides the tenant domain we are looking for and will be relevant for later use with MicroBurst.

The command: Get-AADIntTenantDomains -Domain cloudefense.io

Now we know who’s the domain that we need to discover.

ℹ️ You must know that blobs can get random names and are not related to the domain name, project, or environment. In this kind of situation, we need to search with other tools that I mentioned and tools that are part of the references. 

The following command will search for a specific Blob name and provide a public Container.

The command Invoke-EnumerateAzureBlobs -Base cloudefense

Now that we know the Blob name and the Container, we can get a list of the containers under this blob with List Blob (RestAPI).

It lists all of the files within the container. Each file is represented in its XML <blob> tag, which contains the name, URL, and properties of the file (blob). You can then access these files by visiting the url.

The Invoke-WebRequest command parses the response and returns collections of links, images, and other significant HTML elements. It’s optional but provides more info that can be useful for the attack.

So far, we have got a complete Azure Blob Container with structure and data. A Container can contain a lot of data but also could be suitable for websites and FTP, so we need to take the Container name or the IP address and check if there are additional open ports.

A quick search with Shodan provides more information about open ports and Raw Data.

ℹ️ A Blob Container often contains keys, secrets, sensitive information, static page files, and much more.

Now that we have all of this information, we could download the data, or if we have a secret/token, we can continue the process with lateral movement, etc.

Stuff

Clone and Run – A quick way to clone and run the MicroBurst command. If you have Windows 11 with WSL, you can clone, import, and run the MicroBurst command in seconds with the following commands from PowerShell.

wsl git clone https://github.com/NetSPI/MicroBurst.git

cd .\MicroBurst\

Import-Module ./MicroBurst.psm1

Inside Discovery – If you want to check your Container for a Public exposure, you can export the Container to a list and then run it based on a list with the following command.

Invoke-EnumerateAzureBlobs -Base StorageAccountName –Folders ContFuzzList.txt

As we saw in this post, the exposure of a Blob Container can lead to a breach, wide enum, and other scenarios. Those actions were part of discovery and recon.

References

Introduction to Azure Storage

Threat matrix for storage services – Microsoft Security Blog

Authorize access to blob data with a managed identity

How to Detect and Compromise Azure Blobs and Storage Accounts (inversecos.com)

LOTS Project – Living Off Trusted Sites (lots-project.com)

Anonymously Enumerating Azure File Resources (netspi.com)

Azure Blob Attack Tools

Gobuster tool to brute-force account names using the DNS module.

ffuf tool to brute force container names.

Microburst or CloudScraper to brute-force the azure storage and containers.

Az-Blob-Attacker helps you perform Blob operations if you have a storage account name and key.