Anonymously Enumerating Azure Services

Microsoft makes use of a number of different domains/subdomains for each of their Azure services. We’ve previously covered some of these domains in a post about using trusted Azure domains for red team activities, but this time we’re going to focus on finding existing Azure subdomains as part of the recon process. Also building off of another previous post, where we talked about enumerating Azure storage accounts and public blob files, the script included in this post will do DNS brute forcing to find existing Azure services subdomains.

So why do we want to do this? Let’s say that we’re doing a pen test against a company (TEST_COMPANY). As part of the recon process, we would want to see if TEST_COMPANY uses any Azure services. If we can confirm a DNS host name for TEST_COMPANY.azurewebsites.net, there’s a pretty good chance that there’s a TEST_COMPANY website hosted on that Azure host. We can follow a similar process to find additional public facing services for the rest of the domains listed below.

Domains / Associated Services

Here’s a list of Azure-related domains that I’ve identified:

Domain	Associated Service
azurewebsites.net	App Services
scm.azurewebsites.net	App Services – Management
p.azurewebsites.net	App Services
cloudapp.net	App Services
file.core.windows.net	Storage Accounts-Files
blob.core.windows.net	Storage Accounts-Blobs
queue.core.windows.net	Storage Accounts-Queues
table.core.windows.net	Storage Accounts-Tables
redis.cache.windows.net	Databases-Redis
documents.azure.com	Databases-Cosmos DB
database.windows.net	Databases-MSSQL
vault.azure.net	Key Vaults
onmicrosoft.com	Microsoft Hosted Domain
mail.protection.outlook.com	Email
sharepoint.com	SharePoint
azureedge.net	CDN
search.windows.net	Search Appliance
azure-api.net	API Services

Note: I tried to get all of the Azure subdomains into this script but there’s a chance that I missed a few. Feel free to add an issue to the repo to let me know if I missed any important ones.

The script for doing the subdomain enumeration relies on finding DNS records for permutations on a base word. In the example below, we used test12345678 as the base word and found a few matches. If you cut the base word to “test123”, you will find a significant number of matches (azuretest123, customertest123, dnstest123) with the permutations. While not every Azure service is going to contain the keywords of your client or application name, we do frequently run into services that share names with their owners.

Github/Code Info

The script is part of the MicroBurst GitHub repo and it makes use of the same permutations file (Misc/permutations.txt) from the blob enumeration script.

Usage Example

The usage of this tool is pretty simple.

• Download the code from GitHub – https://github.com/NetSPI/MicroBurst
• Load up the module
  • Import-Module .Invoke-EnumerateAzureSubDomains.ps1
  • or load the script file into the PowerShell ISE and hit F5

Example Command:

Invoke-EnumerateAzureSubDomains -Base test12345678 -Verbose

If you’re having issues with the PowerShell execution policy, I still have it on good authority that there’s at least 15 different ways that you can bypass the policy.

Practical Use Cases

The following are a couple of practical use cases for dealing with some of the subdomains that you may find.

App Services – (azure-api.net, cloudapp.net, azurewebsites.net)
As we noted in the first section, the azurewebsites.net domains can indicate existing Azure hosted websites. While most of these will be standard/existing websites, you may get lucky and run into a dev site, or a pre-production site that was not meant to be exposed to the internet. Here, you may have luck finding application security issues, or sensitive information that is not supposed to be internet facing.

It is worth noting that the scm subdomains (test12345678.scm.azurewebsites.net) are for site management, and you should not be able to access those without proper authorization. I don’t think it’s possible to misconfigure the scm subdomains for public access, but you never know.

Storage Accounts – (file, blob, queue, table.core.windows.net)
Take a look at this previous post and use the same keywords that you find with the subdomain enumeration to see if the discovered storage accounts have public file listings.

Email/SharePoint/Hosted Domain – (onmicrosoft.com, mail.protection.outlook.com, sharepoint.com)
This one is pretty straightforward, but if a company is using Microsoft for email filtering, SharePoint, or if they have a domain that is registered with “onmicrosoft.com”, there’s a strong indication that they’ve at least started to get a presence in Azure/Office365.

Databases (database.windows.net, documents.azure.com, redis.cache.windows.net)
Although it’s unlikely, there is a chance that Azure database services are publicly exposed, and that there are default credentials on the databases that you find on Azure. Additionally, someone would need to be pretty friendly with their allowed inbound IPs to allow all IPs access to the database, but crazier things have happened.

Subdomain Takeovers
It may take a while to pay off, but enumerating existing Azure subdomains may be handy for anyone looking to do subdomain takeovers. Subdomain takeovers are usually done the other way around (finding a domain that’s no longer registered/in use), but by finding the domains now, and keeping tabs on them for later, you may be able to monitor for potential subdomain takeovers. While testing this script, I found that there’s already a few people out there squatting on some existing subdomains (amazon.azurewebsites.net).

Wrap Up

Hopefully this is useful for recon activities for Azure pen testing. Since this active method is not perfect, make sure that you’re keeping an eye out for the domains listed above while you’re doing more passive recon activities. Feel free to let me know in the comments (or via a pull request) if you have any additional Azure/Microsoft domains that should be added to the list.