Even though Microsoft Azure is the second largest cloud solution after Amazon Web Services (AWS) from a market share perspective, it should be noted that approximately 95% of Forbes 500 companies use Azure. This does not mean that these companies use only Azure, or that Azure is the main cloud solution used by them, many use a combination of cloud providers based on their business needs.

The main reason behind this large adoption has been Azure Active Directory (Azure AD), and the desire for many companies to implement a more scalable and redundant Hybrid Active Directory architecture.

Before diving into some of the enumeration techniques that can be leveraged by an unprivileged user in order to escalate privileges or for lateral movement within Azure, we need to go over some of the key elements defining the structure of Microsoft Azure.

Roles

The first and one of the most important things that sets Azure apart from other cloud solutions is the fact that it has two access control systems each defining roles for controlling access within a specific scope.

Therefore, the first type of access control roles that we can assign to a user are Azure RBAC roles (also called Azure roles) that control access to all the Azure Resources (such as Virtual Machines, Key Vaults, Storage Accounts, Automation Accounts, App Services, Databases, ets.). But, because Azure AD is such an invaluable service, we also have Azure AD roles that define access within the Active Directory hierarchy, allowing us control over AD objects.

So when conducting a security assessment the objective is to escalate privileges within both scopes.

Resource Management Hierarchy

Azure provides four levels of management for a more flexible and scalable way of organizing your resources into a hierarchy:

• Management groups allow easier access and policy management for subscriptions.
• Subscriptions can be used to manage costs, associate user account with the resources they created and set resource quotas.
• Resource groups are logical containers where we can deploy and manage multiple Azure resources like VMs, databases, etc.
• Resources are the underlying services that you can create (VMs, Web Apps, databases, etc.)

The service in charge or deploying and managing resources is called Azure Resource Manager. It provides a management layer that enables you to create, update, and delete resources in your Azure account.

Security Principals

Another basic element that needs understanding is the Security principal which is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources. Basically security principals are objects that we can assign a role to, and because of misconfigurations when allocating permissions, we can often leverage them in order to escalate our privileges.

The main cause that leads to compromising an Azure environment is misconfigurations. This is the reason why deep prior understanding of how Azure works is a requirement for any Azure Administrator or Owner in charge of changing or allocating permissions, but also for users that can make changes to resources such as Contributors.

In the following paragraphs we will be going through the tools and techniques that we can use to identify sensitive information or misconfigurations using an account with unprivileged access such as reader permissions.

Enumerating Azure with unprivileged permissions (Reader role)

It should be specified that interacting with Azure can be done through multiple ways:

• Azure Portal
• Azure Shell – command line available in the Azure Portal
• Azure CLI – command line tool available for both Windows and Linux for managing Azure Resources
• PowerShell modules – the Az and AzureAD PowerShell modules offer a set of cmdlets for managing Azure resources directly from PowerShell
• Azure REST API – a set of API endpoints that can be used to perform operations on identities and resources

If we do not have any privileged access and can only read information in the tenant about subscriptions or specific resources, the main thing we can try to do is look for disclosed sensitive information within a resource. This can be done manually through the Azure Portal graphical interface by going to the “All Resources” page and exporting to CSV, but I personally prefer to leverage the MicroBurst toolkit.

MicroBurst uses the Azure PowerShell modules, so we have to install them first by executing the following commands in a PowerShell session:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
Install-Module AzureAD

We can now authenticate to out Azure Tenant with our user that has reader permissions, import MicroBurst module and dump all the information that we can access:

#Executing the Connect-AzAccount will open a window for authentication
Connect-AzAccount

#Importing the microburst module
Import-Module .\MicroBurst.psm1

#Dumping tenant information
Get-AzDomainInfo -Verbose -Folder dump

Now we can inspect all these files and folders to get a better grasp of the tenant configuration, identities and resources while trying to spot anything of value. Even though all of these files can contain useful information, there are some common places where we can find hardcoded credentials.

A place where we can often find sensitive information is in Automation Account Runbooks (Resources->Automation Accounts). Runbooks are powershell/python scripts that can be used for automating tasks such as backups and updates, and sometimes they contain hardcoded credentials for connecting to remote systems.

Azure Storage Accounts can contain blobs, file shares, queues, tables, and disks, and all of these objects can potentially contain valuable information stored by employees or applications. If we do not have read access for storage accounts we can try to brute-force blobs (blob format: https://<StorageAccountName>.blob.core.windows.net/<container>/<blob>) using MicroBurst (more details https://www.netspi.com/blog/technical/cloud-penetration-testing/anonymously-enumerating-azure-file-resources/):

Invoke-EnumerateAzureBlobs -Base <StorageAccountName> –Folders ContainerFuzzList.txt

Another type of information collected by MicroBurst that can contain credentials is regarding App Services (Resources->AppServices.CSV). The App Service functionality offers the ability to setup a web server to host a web application, therefore we might be able to find config files containing database connection strings or log files containing potential sensitive information.

Function Apps are similar to App Services, but they offer a serverless alternative of hosting a web application. A Function App can contain code and application files that can be reviewed through the Azure Portal in order to identify potential secrets.

MicroBurst also collects information regarding deployment history (Resource->Deployments.txt) which can contain credentials that were previously used in deployment templates to automate the creation of a service. If previous deployments contained secrets stored as String instead of SecretString in the deployment templates, even if this mistake was corrected in newer deployments, secrets might still exist in the history of older deployments or in their output.

Azure Container Registry (ACR) is a private registry for storing container images. Normally, because of the data plane and access plane separation, a user would require explicit permissions to view data stored in services, but this does not apply to the ACR. So we can try to access container images and review their contents for secrets. This can be done using Azure CLI (https://docs.microsoft.com/en-us/cli/azure/install-azure-cli)

//List container registries in the subscription using Azure CLI 
az login -u [email protected] -p pass
az acr list -o table

//Login to the Registry (replace <ACRName> with the name from the previous command) 
acr=<ACRName>
server=$(az acr login -n $acr --expose-token --query loginServer -o tsv) 
token=$(az acr login -n $acr --expose-token --query accessToken -o tsv) 
docker login $server -u 00000000-0000-0000-0000-000000000000 -p $token 

//List the images in the ACR
az acr repository list -n $acr 

//List version tags for an image (older versions may also contain sensitive info) 
az acr repository show-tags -n $acr --repository mywebapp

//Connect to the container registry from a PowerShell console, set the $server and $token variables, and pull the image from the registry
$token="<AccessToken>"
$server="<LoginServer>"
docker login $server -u 00000000-0000-0000-0000-000000000000 -p $token
docker pull $server/mywebapp:v1

After we downloaded the image we can create a container locally and enumerate for sensitive information in places such as the Environment Variables where we can find secrets about the managed identity.

Even though the user that we control is unprivileged we also need to enumerate for applications where the current user is owner, this is because we might not have permissions to make changes to services owned by others but we might have permissions to create some specific services, resulting in owner permissions for that service principal. This situation can lead to privilege escalation if an Administrator has assigned a higher-privileged role for the application we own.

In order to perform this enumeration we will be using the PowerZure framework:

#Similar to MicroBurst, PowerZure requires the Az and AzureAD powershell modules
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
Install-Module AzureAD

#Executing the Connect-AzAccount will open a window for authentication
Connect-AzAccount

#Importing the microburst module
Import-Module .\Powerzure.psd1

#List apps where the current user is owner
Get-AzureAppOwner

#Ownership of an app means we can add a new secret to the app, this way we can authenticate as the service principal; the following command adds a new secret to the app
Add-AzureSPSecret -ApplicationName <AppName> -Password <Password>

#Using Azure CLI we can authenticate as the service principal (use <ApplicationId> and <TenantId> from previous command)
az login --service-principal --username <ApplicationId> --password <Password> --tenant <TenantId> 

#Verify the roles for the service principal
az role assignment list --assignee <ApplicationId> --include-groups --include-inherited --query '[].{username:principalName, role:roleDefinitionName}' 

If the service principal has been given a role with more permissions that those of the current user, we can escalate privileges using this technique.

Wrap-up

The basic enumeration techniques that we covered were meant to give an introductive approach to Azure penetration testing. Depending on the assigned permissions and available Azure Resources there are many other enumeration techniques and exploits that can lead to a compromised Azure infrastructure.

PowerZure and MicroBurst are robust frameworks that contains multiple commands that can be leveraged for information gathering and exploitation:

• https://powerzure.readthedocs.io/en/latest/Functions/infogathering.html
• https://github.com/NetSPI/MicroBurst/wiki/Az-Functions#functions-information