Pentesting - Azure Cloud infrastructure from an Ethical Hacker perspective

Security, security and security. You’ll hear these words everywhere these days, especially in the financial section where attackers are trying to get access to IT systems on a daily basis. Security practitioners are quite familiar with the different types of attacks, but what about you? Even if you’re the Azure Administrator, developer or DevOps engineer, are you aware what kind of techniques hackers try to use for exploring and exploiting vulnerabilities in the Azure Cloud infrastructure? It’s always good in every technology profession to provide awareness around security threats.

Let’s explore and learn about the tools that you can use to Pentest the Azure Cloud infrastructure from an ethical point of view, also known as the Ethical hacker. You’ll be setting up the security hat and take a seat at the well-known “Red team”. Before you are going to look to these tools, let’s quickly see what Pentesting is and what teams are responsible when performing penetration testing exercises against your own organization.

What is Pentesting?

Penetration testing lets organizations evaluate the overall security of their IT landscape. Even if the company has many robust security protocols in-place, there are always holes to find. Therefore, mimicing the actions and creating real-world scenarios of malicious hackers, reveals how well the organization is doing with their current defenses. To set up these kinds of scenarios, organizations can introduce teams that attack, defend, switch between and work together by penetrating their own systems. There are many different types of Pentesting, and in this blog you’ll be focusing on Cloud Security against the Azure Cloud infrastructure. Penetration testing against the cloud often takes place in three stages: 

  1. Evaluation: engage in discovery activities and potential vulnerability exposure
  2. Exploitation: use the information from stage one exploiting vulnerabilities
  3. Remediation: penetration testers follow-up the assessment and ensure that remediation steps have been implemented.

What are the team responsibilities?

In a penetration testing exercise, multiple teams are involved. You’ve already heard about the so-called Red team, which probably gave you already a small clue that these are the bad boys. Let’s look at the responsibilities and characteristics of the different teams: 

  • Red team: takes upon the role of hostile attacks that challenges the Cyber Security 
  • Blue team: defends the IT landscape against the Red team 
  • White team: functions as a bridge between the Red and Blue team that can escalate or de-escalate attacks 
  • Purple team: has both Red and Blue team members to share knowledge on Cyber Security 

Now that you have got to know the team structure, let’s get our hands dirty. A fair warning aside. If you are going to test these tools, you should be aware that you’re actively trying to hack the system, even from an ethical point of view. Luckily, Microsoft provides guidelines for organizations that want to assess and perform these kinds of penetration attacks. You can find the Rules of Engagement on the Microsoft site. Microsoft prohibited the following activities: 

  • Scanning other assets out of your organization 
  • Gaining access to data that is not yours 
  • Performing denial of service attacks 
  • Phishing or other social engineering techniques 

Your organization might also have additional rules in place. Without further ado, many Azure services use a public DNS suffices, so let’s start with the evaluation phase to see if you can reconnaissance these services. 

Enumerating Azure PaaS services 

Microsoft keeps a partial list of Azure domains they use. Some of these endpoints are: 

Service  Subdomain 
Azure Blob Storage  * 
Azure Files  * 
Azure Key Vault  * 
Azure Websites  * 

If you want a full overview, you can visit the Azure Domains in the Microsoft docs 

Let’s get our hands a bit dirty and see if you can enumerate the services in your own Azure tenant by using MicroBurst. MicroBurst is a toolset including a bunch of Powershell scripts that you can use for multiple different attacks. 

  1. Open Powershell as an administrator 
  2. Clone the repository by typing git clone:
  3. Import the MicroBurst module into your Powershell session:
    cd .\MicroBurst\ 
    Import-Module .\MicroBurst.psm1 
  4. Execute Invoke-EnumerateAzureSubDomains -Base blueteamdefenders to identify potential targets that have this base name
    Blueteamdefenders resources have been setup prior the writing of the blog for demonstration purposes. 
  5. In the below picture, you can see the resulting output indicating that the resources are on the Azure platform 
PaaS services enumerated anonymously
Figure 1. PaaS services enumerated anonymously

Always use caution when following these examples to avoid attacking other resources outside your own Azure tenant.

If you really want to make sure that these are coming from the Azure platform, you can additionally check the IP ownership and verify it against the cloud IP checker.

    1. Type in nslookup in your Powershell session
    2. Make note of the IPv4 address that is returned
Obtaining the address from the blob storage
Figure 2. Obtaining the address from the blob storage

3. In the same Powershell console, run the following command against the Azure published IP ranges by executing:

Invoke-WebRequest<IP_ADDRESS> -UseBasicParsing | Select-Object -ExpandProperty Content

Cloud IP checker results
Figure 3. Cloud IP checker results

You can now see that the IP belongs to to Azure IP range coming from the West Europe region.

Identifying blob containers using MicroBurst

Now that you know about the domains Azure uses, you can identify with Invoke-EnumerateAzureBlobs cmdlet script from Microburst to see if there are misconfigured Blob storage services. Let’s see how that looks like.

  1. Execute Invoke-EnumerateAzureBlobs -Base blueteamdefenders in your Powershell session

Here’s the output:

Output result from Invoke-EnumerateAzureBlobs to find public blob containers
Figure 4. Output result from Invoke-EnumerateAzureBlobs to find public blob containers

It looks like there is a private container misconfigured.

2. Download the object from the Blob storage container by executing:

Invoke-WebRequest -Uri “” -OutFile “C:\Temp\codes.txt”

Figure 5. Download the file from the container

3. Read the content by executing notepad c:\temp\codes.txt

Content of codes.txt
Figure 6. Content of codes.txt

Interesting, you can now change the defenses and initiate your attack with the Death Star without the Rebels knowing it.

In step 1, you’ve executed the Invoke-EnumerateAzureBlobs cmdlet. MicroBurst uses a common container list name, as seen from the picture. You can find the list in the Misc folder and it is called permutations.txt. If you want to specify your own custom container name, you follow the steps below.

4. Create a file called containers.txt in the MicroBurst folder

5. Add the names you want to search for

6. In your Powershell session, execute Invoke-EnumerateAzureBlobs -Base blueteamdefenders -Folders container.txt

You’ve now learned that configuration-related vulnerabilities can cause serious harm.

Spray and pray with MSOLSpray

The most common way to gain access to an Azure tenant or subscription, is through guessed, stolen, or found credentials. One of the most famously known lists that can be found is the Have I Been Pwnded dataset. This list was published by the National Cyber Security Center (NCSC) from UK.

It’s also possible to build up your own list with information that can be found on sites like LinkedIn, Twitter or Facebook, as many organizations have a formal naming convention they use for usernames/email addresses. Hackers can perform different kind of attacks on these lists:

  • Brute force attacks: aims the cycle through as many passwords as possible
  • Target user attack: your own list usernames gathered from potentially social media platforms
  • Password spray attack: uses the same password against many usernames

Armed with this knowledge, let’s learn about MSOLSpray, another Powershell Open source project that allows password spraying against Microsoft online accounts. It also gives useful recon information relating to:

  • Multi-factor authentication status
  • Account exist
  • Locked or disabled
  • Password expired

Let’s see it in action by cloning the repository to your local drive.

1. In your Powershell session, enter the following
cd C:\pentesting
git clone

2. Import the MSOLSpray Powershell module
cd .\MSOLSpray\
Import-Module .\MSOLSpray.ps1

3. Create a username list of users you have in your Azure Active Directory

notepad use rlist.txt 

User list created before the demo
Figure 7. User list created before the demo

4. Run the MSOLSpray against the user accounts with the password you’ve created for these users 

Spraying against the user list
Figure 8. Spraying against the user list

You now have success for the users and can open the Azure Portal in an Incognito window. As mentioned earlier, MSOLSpray can also indicate if a user has MFA turned on. If you want to test this out, you’ll require P2 license for Azure Active Directory and turn on MFA on the user you want to test against.

Now that you understand how you can guess credentials, let’s take a last look to see if there are additional situations that may limit this ability in Azure.

Sweeping through Conditional Access policies

One of the advances in Azure AD security are Conditional Access policies. These can limit access to the Azure portal based on certain criteria that have been set. But of course, attackers have found ways to bypass these policies which in turn, allows access to Azure or other services.

Enter MFASweep, a Powershell script that attempts to login to various Microsoft services and will attempt to identify if MFA is enabled and Conditional Access requirements. You can imagine in one scenario where users with mobile operating systems have exceptions, based on their frequent sign-ins from different IP addresses. This gives an attacker the possibility to pretend to come from a mobile device user agent, bypassing the Conditional Access requirement.

Let’s have a look one more time. 

  1. In your Powershell session, clone the MFASweep from the Github repository
    cd C:\pentesting
    git clone
  2. Import the MFASweep module
    cd .\MFASweep\
    Import-Module .\MFASweep.ps1
  3. Run Invoke-MFASweep against the user that may have been compromised
    Invoke-MFASweep -Username -Password My@Password123


Hopefully, the darkness hasn’t taken you over like it happened with Anakin. You can now safely switch back to the Light side. You’ve now learned about Penetration testing from an ethical side and took a seat at the Red team. You’ve learned about the different kinds of teams that you can set up within your organization to perform these kinds of tests, especially against the Azure cloud. Three tools have been introduced and you know what they can do. It’s now up to you to defend against it!


Want to work with us?

About the author

Gijs Reijn
Cloud Engineer

Gijs Reijn is the DevOps Engineer at Rabobank’s ALM IT department. He primarily focusses on Azure DevOps, Azure and loves to automate processes including standardization around it. Outside working hours, he can be found in the early morning working out in the gym nearly every day, writes his own blog to share knowledge with the community and reading upon new ideas.

Related articles

5 best practices for using Azure Bicep

  • 17 August 2022
  • 12 min
By Gijs Reijn

Ready, set, go! Covering up PowerShell module development

  • 23 January 2023
  • 9 min
By Gijs Reijn