By: Vedant Bhalgama (@ActiveXSploit)

• Microsoft Azure is a cloud computing platform that provides a wide range of services, including Virtual Machines, databases, container services, and application hosting. Among these services, Azure Storage Accounts are used to store and manage data in the cloud.
• An Azure Storage Account offers several services, including Blob Storage, File Storage, Queue Storage, and Table Storage. In many cases, developers unintentionally misconfigure Blob Storage by enabling anonymous access to containers. When this happens, attackers can list the blobs (files) within a container and potentially read the stored data without authentication.
• For example, a developer might unintentionally configure a Blob Storage container to allow anonymous access while it contains critical or confidential data. An attacker could abuse this exposure to gather sensitive information that may help them gain further access within the cloud environment or facilitate lateral movement. In many cases, such containers may also store sensitive data, including personally identifiable information (PII).
• In this blog, we will walk through a practical demonstration that mimics a real-world scenario where an Azure Blob Storage service is intentionally misconfigured and populated with a few sample files. We will then use a tool called MicroBurst to automatically enumerate these misconfigured Azure Blob containers and identify exposed data.

0x01 : A quick introduction to Azure Blob Storage Service —

• As discussed earlier, Microsoft Azure provides a variety of cloud services, including Virtual Machines, App Services, Databases, and Storage Accounts. Storage Accounts in Azure are used to store and manage data in the cloud.
• When a Storage Account is created, it provides four different storage services: Blob Storage, File Storage, Queue Storage, and Table Storage. Each storage service is assigned a unique subdomain for identification. Azure follows a specific naming format for these services. For example, if a storage account is created with the name “samplestgaccount123”, the following subdomains would be assigned to the four storage services mentioned earlier:

• While File Storage, Queue Storage, and Table Storage require authentication to access them, Blob Storage can be configured to allow anonymous access to containers within the service. However, anonymous access is disabled by default.
• A Blob Storage service is organized into containers, which function similarly to folders that store files. These files stored within the containers are referred to as blobs. These containers within the service offer three different types of access levels :
  - Private : No anonymous access is allowed to the container.
  - Blob : When access is configured to allow anonymous access to blobs, an attacker must know the exact container name and blob name in order to access the file.
  - Container : Container-level access allows attackers to list all the blobs within a container if they know a valid container name. This is considered the most dangerous configuration, as it enables attackers to enumerate and access multiple files stored within the container.
• Now, let us look at a practical demonstration where we will set up a vulnerable Azure Blob Storage service within an Azure tenant. After setting it up, we will use automated tools to discover and enumerate files stored within the exposed containers.

0x02 : Setting up a vulnerable Azure Blob Storage Service —

• Note : Before starting the practical setup, ensure that you have access to a valid Azure tenant and an active subscription where you are permitted to provision resources. Do not perform the following activities unless you have authorized permission to test within the target tenant. Do not perform the following configurations in an active production environment, as they can pose a significant risk to your data.
• First, log in to the Azure Portal using valid credentials. Then, use the search bar to look for “Storage Accounts” and create a new storage account if you do not already have one.

• Click on the “Storage Accounts option”, then click on “ + Create” option located on the top left.

• Next, select an active subscription you have access to, choose a resource group to organize the resource, specify a storage account name (in our case it will be “developertesting06"), and select the region where you want to deploy the resource. Then, click on “Next”

• Next, enable the “Allow enabling anonymous access on individual containers” option. This is a crucial step, as without enabling it you will not be able to configure anonymous access for containers within the Blob Storage service. Once done, click on “Review + Create”

• Now, review the storage account configuration. Once everything looks correct, click on “Create” to provision the storage account.

• Once the storage account is successfully deployed, the next step is to create a container within the Blob Storage service and configure it to allow “Container” level anonymous access.

• Click on your newly created storage account. Then navigate to the “Data storage” section, select “Containers”, and click the “+ Container” option at the top. Assign a name to the container (in our case it will be “dev”) and, from the “Anonymous access level” dropdown menu, select “Container” level access. This is the step where the actual misconfiguration occurs.

• Now, the final step is to upload files to the container to mimic a real-world environment. In this example, we will upload two sample files, one of which contains fake credentials.

• Click on the newly created container, then select the “Upload” option at the top left. Next, drag and drop your desired files or browse to select them, and finally click the blue “Upload” button to upload the files. In my case I have two sample files named “prod_server_access.csv” and “prod_test_creds.txt” mimicking real files.

• And that’s it! Although the process may seem a bit lengthy, we have now successfully set up an intentionally misconfigured Azure Blob Storage service that allows “Container” level anonymous access to the public. Next, we will move on to using a tool called “MicroBurst” to discover and enumerate such Azure Blob Storage services and determine whether they are misconfigured.

0x03 : Using MicroBurst to discover and enumerate misconfigured Azure Blob Services —

• MicroBurst is a collection of tools written in PowerShell, designed for pentesting Azure environments. In this demonstration, we will use this toolkit to enumerate potential storage accounts and identify Azure Blob services that allow container-level anonymous access.
• Firstly, clone the MicroBurst repository on your Windows Pentest VM using the following command :

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

• Once the repository is cloned, open a PowerShell prompt and import the MicroBurst.psm1 module into your current session using the following command. Note that you must install the Az, AzureAD, and MSOnline PowerShell modules for the toolkit to function properly.:

Import-Module .\MicroBurst.psm1

• Once the module is imported, we will use the Invoke-EnumerateAzureBlobs command along with the -Base parameter, which specifies the base name used to discover potential Azure Storage Accounts.
• MicroBurst uses a default permutation list file that contains a collection of common words and suffixes. The script combines these entries with the provided base name to generate possible storage account names.
• For example, if the base name foocorp is provided, MicroBurst will append different words from the permutation file (present in the Misc/ folder) to generate variations such as foocorpdev and devfoocorp if the word dev exists in the list. By generating these combinations, MicroBurst helps identify additional storage accounts that may exist within the target environment.
• You can also provide your own custom permutation list using the -Permutations parameter. When specified, MicroBurst will use this custom list to enumerate potential storage account names instead of relying on the default permutation list.
• Similarly, to enumerate container names, MicroBurst relies on its default permutation list file. If you want to use a custom permutation list for discovering potential container names, you can specify it using the -Folders parameter.
• For this demonstration, we will rely on the default permutation lists for both storage account enumeration and Blob Storage container discovery. We provide “developertesting06” as the base name to the command, after which MicroBurst immediately begins enumerating potential storage accounts and Blob Storage containers.

• As shown in the output, MicroBurst quickly discovers a storage account named “developertesting06”. It then begins enumerating common container names using its default permutation list. When a valid container name is identified (“dev” in our case), the tool checks whether it can list the blobs available within that container.
• Once access is confirmed, MicroBurst lists the blobs that are publicly accessible. These blob URLs can then be copied and opened directly in a browser to view or download the exposed files.

• And just like that, as an anonymous user, we were able to access and view the previously uploaded “prod_test_creds.txt” file that was added while setting up this lab environment.
• Instead of using MicroBurst, an attacker could also use tools such as GoBuster, FFuF, or even write custom scripts, to enumerate valid container names within a Blob Storage service. Now, what if we want to manually list the contents of a container? In that case, you can append the following GET parameter to the end of the Blob Storage URL to retrieve the list of blobs within the container.

?restype=container&comp=list

• In our case, the full URL would become the following :

https://developertesting06.blob.core.windows.net/dev/?restype=container&comp=list

• When viewing this in the browser, you will receive an XML response. As shown in the output, this response reveals the blobs (files) stored within the container. From here, the URLs of the blobs can be copied and accessed directly, just as we demonstrated earlier.

• Phew! That was a long one, but I hope you enjoyed reading the article and learned something new. As demonstrated, misconfigured Azure Blob Storage services can become a critical attack surface for exposing sensitive data. Such exposures can potentially be leveraged by attackers to gather valuable information, facilitate lateral movement within cloud environments, or even lead to serious data breaches. Make sure to follow Avyukt Security for the latest cybersecurity-related content and updates, Thank you! ❤