First Time Hacking The Cloud

4 min readJan 31, 2022


What’s going on hacker folks, this is shellbreak back again with another blog post, but this time, it will be about how I found my first bug in an azure cloud storage service.

The vulnerability was a Massive Information Disclosure due to a publicly accessible container hosted on an azure storage blob.

I found this bug in one of my engagements, and when I was pentesting the client’s applications, I had no idea about Azure (my only cloud related background is some AWS knowledge gained from solving “Bucket” machine from HackTheBox). However, with real dedication, there’s nothing we can’t learn ;)

Enough talking and let’s get into the fun stuff.

Since I have found this vulnerability in a real prod environment , I will be obfuscating some output in the screenshots.

When I was viewing the source of the main page, I found a URL like:

I knew it was an Azure blob, but I didn’t have any idea how to enumerate it to see if I can find any sensitive data.

I spent sometime googling and eventually I found this blog post:

The blog mentions a tool that can be used to automate the process of enumertating the blobs to find accessible containers.

So, let’s get started.

The tool takes a username as an argument and looks for containers by brute forcing using a given wordlist.

As I was only interested in Azure at this moment, I used the--disable-aws and--disable-gcp arguments to ignore fuzzing for storage services related to AWS and Google.

python3 -k USERNAME --disable-aws --disable-gcp

And I found that there’s a container called test , and the URL to access its content is

But the tool already does that for us, and you can see that we have 2 juicy files, one of them is the zip and the other is bacpac file.

These files can be downloaded just by visiting their URLs.

However, I wanted to enumerate even more, so I tried the following:


Not what I expected :\

But then I remembered that in order to see a container’s content, some parameters need to be provided ?restype=container&comp=list , so using the almighty ffuf to do so,

ffuf -u -w /path/to/wordlist

I have found another container, but I wasn’t lucky enough to find any sensitive files in it :P

The blog I linked above has mentioned another powershell-based tool.

The tool uses a built-in wordlist, that’s why it managed to find only one container, while using the ffuf method described above we have found 2 containers.

Fun thing about this engagement. I spent 2 weeks trying to find critical vulns like RCE and SQLi, but didn’t find any. Eventually instead of finding a SQLi that probably would take a lot of time to exploit (especially if it’s time-based), a single misconfiguration gave me the ability to download the entire database of the client. remember the bacpac file? ;)

A BACPAC file is a ZIP file with an extension of BACPAC containing the metadata and data from the database. A BACPAC file can be stored in Azure Blob storage or in local storage in an on-premises location and later imported back into Azure SQL Database, Azure SQL Managed Instance, or a SQL Server instance

Besides, the logs I’ve found in the zip file saved me a lot of time, as it contained a ton of logs related to the back-end service in use :)

So, that was it for now, I hope you guys enjoyed reading it, and I’ll see you all in the next write up.





Offensive Security Engineer | Threat Intelligence Analyst | Cloud/Web App Penetration Tester | CTIA | eWPTXv2 | OSWE | CTF Lover