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.
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.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.