Cloud Pentesting: Azure (Common test cases in an Azure pentest engagement )

I always try to follow a general methodology when doing Azure Cloud pentest, or any type of pentest for that matter.

Below are my main go to cheat sheets during testing:
- https://hackingthe.cloud/azure/
- https://github.com/dafthack/CloudPentestCheatsheets
- https://cloud.hacktricks.xyz/pentesting-cloud/azure-security
- https://attack.mitre.org/matrices/enterprise/cloud/azuread/
- https://attack.mitre.org/matrices/enterprise/cloud/

Below is my general methodology and testing flow.

External Attack Surface Visibility (Unauthenticated Testing)

— OSINT

• Do an general OSINT on the target organization. Example test cases here is to utilized dump databases such as from Dehashed, look for list of possible users/emails that belong to the target company.

— Check for domains or subdomains that have Websites/Web Apps running

• Look for web app vulnerabilities such as SQLI, SSRF, Command Injection, XXE, etc,
• The goal is to identify vulnerabilities that enable potential RCE on Azure VMs hosting vulnerable web apps or Azure Functions, and exploit credentials or SAS tokens to pivot deeper into the Azure infrastructure. In this part, I would do a manual testing and automated testing (such a using Nuclei, among other tools ).
• I always enable Trufflehog browser extension while browsing the web app to possibly get keys.

— Domain dangling

• Look for possible domain dangling on the target org

— Perform Network Scans

• I would do a subdomain enum here using sublister or dnsx, scan the result using Naabu, Nmap, Masscan, etc. I would also use Gowitness if that are a lot hosts/web apps
• Pay attention to interesting services like databases ( exposed Mongodb, Redis, etc)

— Check for exposed git repos

• Goal is to get exposed creds and or SAS Tokens, API keys, among others.

— Exposed storage/Azure blobs

• Check for exposed or anonymous Azure blob access. Verify if this is intended. Look for possible sensitive info.

— Password Attacks

• Password Spraying
• After getting a list of users. Check what are valid users. Do a password spray on the valid users.

— Conditional Access and or MFA Bypass test cases

• If you have creds, as a result of password spraying ( if successful :) ), determine if MFA is enabled.
• Try save the creds in a variable, these may sometimes bypass MFA
• $credential = Get-Credential
  Connect-AzAccount -Credential $credential
• Try to change User Agent strings ( later you can revisit this, when you have Roadrecon results when you use “ roadrecon plugin policies “

Authenticated Testing

In Gray box testing, I normally ask for two types of credentials. One with a Reader access / Reader account to the Azure Tenant and to the specific Subscriptions that are in scope. Another user with a higher privileged. Note, there is a consensus that Black box approach in any Cloud Pentest engagement is not really recommended since its very risky ( imagine hitting an IP address that doesnt belong to your target org :) ) .

— Do an internal or authenticated recon using the low and high privileged user

— My flow is get the Users, Roles, Resource Groups, Services

— I would then generally approach my testing per Services/type of resources on the tenant.

Services/Resources:

— VMs

• Check if the role given has Owner, Contributor or Custom role ( for example, Microsoft.Compute/virtualMachines/runCommand/action). You might have permission to run commands on the VMs. If yes, try to run commands ( make sure that client has given you a green light :)
• Check if VMs have Custom Script Extension enabled ( read more on how to leverage this of priv esc or command execution on the VM)
• When you are in a VM, if possible run Mimikatz, look for Azure auth tokens, sensitive data, look for other network that the VM is connected, etc
• In VMs/Desktops, other notable things to check are .cspkg files, .publishsettings files, Keys from Storage Explorers, Web Config and App Config files, check the command history.
• When you are in a VM already, and/or you confirmed separately using az cli or Azure Portal that Managed Identities ( User-assigned/Systems-assigned ) are used in VMs, check for the Metadata ( similar when you check the IMDSv1/IMDSv2 in AWS). Reuse the Managed Identity with ScoutSuite, Roadrecon, Azurehound, etc.
• When you are in a VM already, and if hybrid setup, look for PRT

— Network

• Check for internal IPs
• Check the Network Security Group ( incoming RDP/other services from all IPs allowed? Is this intended ? Tools such as ScoutSuite or Prowler can automate the tasks but you can also do this in Azure Portal/az cli, etc.
• In services/servers such as SQL Server, check the Security > Networking then the “Firewall rules” section. There is a feature, which is off by default as per Microsoft, that says “ Allow azure services and resources to access this server”. This is basically a firewall rule exemption that allows connections from ALL IPs allocated to all Azure services including those that are coming from Subscriptions of other customers. Ensure that this is disabled, unless there is a good business use case and risks are accepted.

— Storage (VHD)

• Check if you have permission to create snapshots or backup disks.
• If yes, snapshot it, download the disk then forensicate manually. If with appropriate permission in the tenant, you may spin up a VM, then attach the disk. You may also backdoor a VM through the disk.
• If with permission to mount disk try to use Dism to add files, add roles, set scheduled tasks, etc,

— Storage (Blobs)

• Check all the Storage accounts, check if there are blobs or containers under those accounts that allows anonymous access. If yes, browse it from outside ( sometimes, Storage accounts set up by org can be very random and you cant bruteforce them from outside)
• If you got an STS , review if it has too much permission for a blob ( check for the value of “sp”)

— Database

• Check what database is used ( CosmosDB?), It can be accessed using the Read Only Key(CosmosDB endpoint can be accessed using a connection string or and an Entra ID user that has privilege to access the instance).

— Cloud Shell

• Check if your user has storage account contributor permission; this can enumerate storage accounts used for Cloud Shell. We can try to steal tokens or deploy a backdoor

— KeyVaults

• Check if client uses KeyVaults, check your permission, if you have Owner, Contributor or custom role. If Contributor, you can change your permission to give you access to the KeyVaults

— Runbooks/Automation Accounts

• Check if your user has Azure Automation Accounts and / or Automation Account Hybrid Workers permission / if has permission to read/create Runbooks

— Function Apps

• Check if client deploys Function apps. Perform abuse on Function apps.

— Logic Apps

• Check if client deploys Logic apps. Perform abuse on Logic apps.

— ACR

• Check if client uses ACR, check your permission. Read more on possible Priv esc scenario using ACR

— IAM

• Check for Managed Identities for possible priv esc
• Check for dynamic group (Misconfigured Dynamic Rules)
• Security Groups, Check if default users are allowed to create Security Groups. best practice to disable it
• App Consent, Check if default users are allowed to consent apps ( read more on app consent phishing if your are not familiar with it )
• Guest user. Check if guest user invite is set to default, depending on the business use case, client may choose the most restrictive option.

— Other post recon activities

• Utilize Roadtools/Roadrecon to get more details on the subscriptions
• check for conditional access policies, among other things
• For priv esc, utilize Azurehound. Also, check if your permission has a Contributor or Owner permission on each service available. If yes, try to escalate and do the recon again.

— Primary tools:

• az cli
• AADInternals
• MicroBurst
• PowerZure
• cloud_enum
• ScoutSuite
• Prowler
• Roadrecon
• Azurehound

References:

• https://hackingthe.cloud/azure/abusing-managed-identities/
  - https://github.com/dafthack/CloudPentestCheatsheets
  - https://cloud.hacktricks.xyz/pentesting-cloud/azure-security
  - https://attack.mitre.org/matrices/enterprise/cloud/azuread/
  - https://attack.mitre.org/matrices/enterprise/cloud/

Disclaimer:

The information provided on this blog is for general informational purposes only. While I always aim for accuracy, some details may be inaccurate and the list provided may not be complete. Having said this, I strongly recommend verifying any critical information against industry-standard documents and official sources (some are listed in the Reference section above) before making any decisions or taking action.

All opinions expressed here are my own and do not reflect the views or positions of my employer.