Pentesting - Azure Cloud infrastructure from an Ethical Hacker perspective

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 - *.blob.core.windows.net

Azure Files - *.file.core.windows.net

Azure Key Vault - *.vault.azure.net

Azure Websites - *.azure.websites.net

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 (https://github.com/NetSPI/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: https://github.com/NetSPI/MicroBurst.git (https://github.com/NetSPI/MicroBurst.git)
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

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 blueteamdefenders.blob.core.windows.net in your Powershell session
2. Make note of the IPv4 address that is returned

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

Invoke-WebRequest https://cloudipchecker.azurewebsites.net/api/servicetags/manual?ip=<IP_ADDRESS> -UseBasicParsing | Select-Object -ExpandProperty Content

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:

It looks like there is a private container misconfigured.

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

Invoke-WebRequest -Uri "https://blueteamdefenders.blob.core.windows.net/private/codes.txt" -OutFile "C:\Temp\codes.txt"

3. Read the content by executing notepad c:\temp\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 https://github.com/dafthack/MSOLSpray.git

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

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

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 https://github.com/dafthack/MFASweep.git
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 masteryoda@gijscompany.onmicrosoft.com -Password My@Password123

Conclusion

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!

Resources

• Penetration Testing Process | The Five Phases of Penetration Testing
• Karl Fossaeen author of Penetration Testing Azure for Ethical Hackers | MicroBurst
• Red, blue, purple and white teams | Responsibilities of Pentest teams