As a penetration tester or bug bounty hunter, subdomain takeovers are one of the most common vulnerabilities to show up but they are also one of the quickest to be snapped up in bug bounties due to modern automation.
Subdomain takeovers are simple, something has a DNS record pointing to it for legitimate purposes but at some point, the resource is deleted without the DNS record being removed. This leaves the resource name available to be taken by someone else and exploited.
In this post, we will explore Azure services that can be taken over. For a deeper look at subdomain takeovers as a whole, check out our post on it. To detect them easily, check out our tool designed specifically for this purpose on GitHub.
Services are always being added to Azure so more may become available, but these are all known services vulnerable to takeover:
Azure CDN: azureedge.net
Azure CloudApp: cloudapp.net
Azure Websites: azurewebsites.net
Azure VM: cloudapp.azure.com
Azure Traffic Manager: trafficmanager.net
Azure Blob Storage: blob.core.windows.net
Azure API Management: azure-api.net
Azure SQL Server: database.windows.net
Azure Data Lake Store: azuredatalakestore.net
Azure AI Search: search.windows.net
Azure Container Registry: azurecr.io
Azure Container Instance: azurecontainer.io
Azure Redis Cache: redis.cache.windows.net
Azure Service Bus: servicebus.windows.net
We have gone through every service, created examples, and shown how to take it over, step by step. Click on a specific service above to jump straight to it.
Azure CDN Takeover (azureedge.net)
Azure CDN is the Azure Content Delivery Network for service content over the web via edge nodes for high performance and low latency. Lucky for bug hunters, this makes it a common service to be put in front of a web application and then deleted to allow subdomain takeover vulnerabilities.
We will start this tutorial by creating an example that mimics real life. First, we created a CDN hosted at stratus-poc.azureedge.net, mapped the custom domain cdn-poc.stratussecurity.com to it and then deleted the resource without deleting the DNS record to enable subdomain takeovers.
To start, let's validate the vulnerability exists and the service is hosted on Azure CDN using dig.
As you can see in the screenshot, the service is hosted on stratus-poc.azureedge.net and returning an NXDOMAIN status, this indicates that it is vulnerable. Next, we need to jump in the Azure portal and create a CDN. Type "CDN" into the search bar, click "Front Door and CDN Profiles" and then "Create" to get to the creation screen, once there we have a stack of options but we need to pick the right ones to get an azureedge.net domain.
Select "Explore other offerings" and then "Azure CDN Standard from Microsoft (classic)". This will create the right kind of CDN.
On the next screen you don't need to do much config, just give it any name and more importantly, tick the box that says "Create a new CDN endpoint", this endpoint is what points to azureedge.net. Below I have shown an example configuration, this will just sit in front of our website but you may want to put it in front of a PoC page instead.
Once this is done, click through and create the CDN profile. Next, we just need to map the domain so it routes properly, so we need to hit "Custom domain" on the overview page of the resource and put in our subdomain (cdn-poc.stratussecurity.com).
Once done, we can browse to cdn-poc.stratussecurity.com and it will take us to www.stratussecurity.com, proving we have taken over the subdomain! To deploy a custom PoC, you can deploy an app service with it and just point the CDN to it.
Azure Cloud Services Takeover (cloudapp.net)
Azure CloudApp (otherwise know as Cloud Services) is a service for creating highly available, infinitely-scalable cloud applications and APIs. It is in the process of being deprecated so it can be found under Cloud Services (Classic) in the Azure portal but will be removed at the end of August 2024.
Only this service points to cloudapp.net so if you're reading this after August, you're too late! We will create an example for this under the DNS name stratus-poc.cloudapp.net and point to it with a CNAME from cloudapp-poc.stratussecurity.com. We deleted the cloud app resource before starting here so we are looking at a typical takeover scenario.
To start, we need to validate the subdomain cloudapp-poc.stratussecurity.com is vulnerable. We can manually do this by using dig to check the DNS records and status as seen below.
The command returns an NXDOMAIN status and points to stratus-poc.cloudapp.net so we know it's vulnerable. Perfect! The next step is to go to the Azure portal and register the domain stratus-poc.cloudapp.net:
Hit Review + create, then create and you will have claimed the resource and therefore the subdomain! It will take a moment to deploy, then you can just deploy a PoC by following the Microsoft documentation and then you can go collect your bug bounty.
Azure App Service Takeover (azurewebsites.net)
Azure App Service is a platform for deploying and managing fully managed web applications. It is the second most common subdomain takeover we see in Azure since it's easy to use and convenient for modern dev teams to deploy and scale.
We will create a similar example to the previous services by making an app on appservice-poc.stratussecurity.com, mapping the DNS record from it to stratus-poc.azurewebsites.net and then deleting the VM but not the DNS record to simulate a real-life subdomain takeover vulnerability.
Now that we have our target, we will validate the DNS records to make sure it is vulnerable.
When vulnerable it will return an NXDOMAIN status and have a CNAME pointing to <name>.azurewebsites.net as shown above.
Now we know it's vulnerable, we just need to create the app service. Note that the only setting that matters here is the name which is directly mapped to the azurewebsites.net subdomain you want to register.
Create it and you now own the subdomain! You should see a default page when you browse to it, if you want to create a better PoC then you can follow the instructions from Microsoft on deploying to an app service.
Azure Virtual Machine (VM) Takeover (cloudapp.azure.com)
Azure Virtual Machines are as the name suggests, a cloud-based service for the deployment and management of computers. This is one of the most common vulnerable Azure services we see here due to the flexibility and ease of use for businesses to use at scale.
For this example, there is a virtual machine deployed in Canada Central. Note that the name of the virtual machine doesn't matter but the region does. We created a VM, mapped a custom domain (vm-poc.stratussecurity.com) to it and deleted the VM to simulate a typical subdomain takeover vulnerability.
Let's start like usual by investigating the DNS state for the subdomain.
Just like every other service, this will return a status of NXDOMAIN when vulnerable and we can see that our subdomain is pointing to stratus-poc.canadacentral.cloudapp.azure.com. The domains will always point to <dns-name>.<region>.cloudapp.azure.com for this service, in some rare cases you will see it without the region but these are legacy deployments that can't be taken over.
Now that we identified the region (Canada Central) and DNS label (stratus-poc), we need to create any VM in the region.
Once it is created we can do the final validation of the takeover and take the stratus-poc.cloudapp.azure.com subdomain. To do it, click "Configuration" on the sidebar and you will be given a screen with a few settings. All that's needed here is to set the DNS name label to your identified label (stratus-poc) as seen below.
Hit save and your VM will be shown on the subdomain! Now that we own it, all that's left is to deploy your PoC. To do that, simply follow the Microsoft documentation on deploying to a VM and you're done.
Azure Traffic Manager Takeover (trafficmanager.net)
Azure Traffic Manager is a DNS-based load balancer. It is used to distribute traffic across many instances of an application to prevent them from being overloaded. This makes it a common target for DNS records and common to get taken over, although they can end up with false positives.
For this example we created a traffic manager profile called stratus-poc in the Azure portal, mapped a custom domain (trafficmanager-poc.stratussecurity.com) to it and then deleted the resource without deleting the DNS record to simulate a real takeover.
To validate the vulnerability, you can simply dig it like the other services:
As you can see, the subdomain has a CNAME to stratus-poc.trafficmanager.net but it returns an NXDOMAIN status, this means it is likely to be vulnerable but there are some edge cases where it will appear to be vulnerable when it's not, like when there are no endpoints configured but the resource is deployed.
Next, we need to go to the Azure portal to attempt the takeover. If you can see the little green tick when you type in the name, it's confirmed vulnerable!
Create this resource and you will have claimed stratus-poc.trafficmanager.net, but it will still appear to be vulnerable until you create an endpoint.
To do this, you will first need a resource to point to. I recommend deploying an app service which is where your traffic manager profile will direct traffic. Once created, go to the Endpoints tab in the sidebar on the left, hit create and point it to your app service like shown below.
Once this is up, you are done and will see your app service content on trafficmanager-poc.stratussecurity.com! The DNS lookup will also no longer return an NXDOMAIN.
Azure Blob Storage Takeover (blob.core.windows.net)
Blob Storage is used to host static files, one of its primary uses is to host website frontends which makes it a very common service to apply custom domains.
We have reproduced this scenario to walk through how it works. For this walkthrough, we have identified a vulnerable takeover on blob-poc.stratussecurity.com.
To validate where the subdomain is pointing, we can manually dig it:
As you can see in the dig, the domain has a cname which points to stratuspoc.blob.core.windows.net but as you can see in the screenshot, it returns an NXDOMAIN status, additionally browsing to it returns an invalid response (shown below), this means it is vulnerable!
Now to exploit it we need to create the resource in Azure and add the custom domain in the Azure portal. Since the blob storage is at stratuspoc.blob.core.windows.net, the storage account needs to be called stratuspoc.
First, go to the portal and open the page to create a storage account. The only part of this config that matters is the "storage account name" which must be stratuspoc as shown below.
Next, just hit review, wait a moment for it to validate and click create.
Once this is completed, the subdomain will give us a different error message but it's not complete yet. To finish the takeover, go to the resource and click "Networking" in the sidebar on the left, click the "Custom Domain" tab and enter the domain in the box (blob-poc.stratussecurity.com) as shown below and hit save.
Once it's saved, you have now taken over the domain! To validate, browse to it over HTTP and it should look like below (or via HTTPS to get a different error):
The risk of this can vary pretty significantly, a static website could be hosted for phishing or content could be served to users (or is likely already being served). I won't go into detail on exploiting this here, Microsoft provides great documentation on deploying a site to blob storage.
Azure API Management Takeover (azure-api.net)
Azure API Management is a hybrid, multi-cloud management platform for APIs across all environments. It covers a huge range of use cases, pretty much anything you can think of for an API including caching, networking, identity and more.
Lucky for us, most of this doesn't matter here. When you create an API Management resource, the resource name is used to create a custom subdomain. For example, a resource called "stratus-poc" would be assigned "stratus-poc.azure-api.net".
To do a takeover we don't need to deal with all the extra stuff, first we just need to identify a DNS record pointing to a deleted instance. Next, create a resource with the needed name as show below.
Deployment will take a while (mine took ~20 minutes) but when it's done, you will be able to see the service is now deployed on https://stratus-poc.azure-api.net.
As far as a PoC goes, we don't need to worry about any of that extra stuff. All you need to do is publish a basic API, since that is quite the process I would recommend just following the documentation from the pros.
Azure SQL Server Takeover (database.windows.net)
Azure SQL Server is exactly what it sounds like, a managed Microsoft SQL Server. If an application is still attempting to use this database, it's possible to take over the subdomain it's pointing to and retrieve all the data trying to go to the database and potentially exploit the application via injection vulnerabilities like Cross-Site Scripting (XSS).
The subdomain is created along with the server even if it has no databases, so for example, to exploit an application pointing to stratus-poc.database.windows.net, all someone would need to do is register a database service called stratus-poc like shown in the screenshot below.
Once taken over, the attacker will need to work for it a little and figure out what the expected database, table and column names are based on the logs but once they reproduce it, the application will leak plaintext data straight to it. Note that you can reserve the subdomain without creating any databases for bug bounty purposes and it will be free.
Azure Data Lake Storage Takeover (azuredatalakestore.net)
Azure Data Lake Storage is a cloud-based, enterprise data lake solution. If you don't speak big tech, this means it manages lots of data for you. This like many of the other takeovers allow mass-leaking of data if taken over and still in use but it only applies to Data Lake Storage Gen 1, which is being retired on February 29th, 2024.
Since this vulnerability will not be possible soon, it's not being documented completely here but you should have no trouble if you follow along with the official documentation.
Azure AI Search Takeover (search.windows.net)
Azure AI Search is an AI-powered information retrieval platform, which helps developers build rich search experiences and generative AI apps. Like some of the other services in this list, it is not something for traditional subdomain hosting but is still able to be taken over by bad actors.
If an application is trying to use something on *.search.windows.net that has been deleted, it could be taken over to serve false results for phishing end users of the legitimate application. The subdomain is dictated by the name of the search service. For example, to exploit something pointing to stratus-poc.search.windows.net, all someone would need to do is register a search service called stratus-poc as shown below.
This takeover may generally have the lowest impact of the bunch but in the right circumstances, it could still be used to phish a large number of users.
Azure Container Registry Takeover (azurecr.io)
Azure Container Registry is Microsoft's solution to manage docker containers. There is no support for custom domains but if an existing repo is still actively used by automation or documented on the internet, it provides an opportunity to take it over and serve malicious containers to gain access to networks.
The domain is generated based on the registry name in the portal, so assuming we want to take over stratuspoc.azurecr.io, all we need to do is create a registry called stratuspoc like below:
Once this is done, the malicious containers can be hosted here and when downloaded they can be used to gain a foothold in networks and further compromise businesses.
Azure Container Instance Takeover (azurecontainer.io)
Azure Container Instance is very similar to the container registry, the difference is that instead of holding container images it lets you actually create container instances from a private registry like ACR or elsewhere.
This is now created secure by default so finding a takeover is unlikely, but still possible.
When creating resources and selecting a subdomain (the DNS name label) there is an option for scope reuse, instances will only be vulnerable when they are created with "Any reuse".
If you create a resource with the DNS label you want to take over and deploy your chosen container, you will have the domain takeover!
Azure Redis Cache Takeover (redis.cache.windows.net)
Azure Redis cache is a service that is not designed to be hosted on custom domains so it probably won't exist in the same way. Despite this, applications may still attempt to use a deleted instance so taking it over can still pose a direct threat of data leaks.
We will do a simplified process here since it is difficult to develop an end-to-end poc, assuming we find an app storing user information at stratus-poc.redis.cache.windows.net.
All we need to do is register a Redis Cache in Azure as below:
Now you control the Redis Cache, the application pointing here will be leaking the user information from the app straight to it. Note that you may need to read some logs and get the password the app is using to make sure they match, but this will give you a nice password leak while you're there!
Azure Service Bus Takeover (servicebus.windows.net)
Azure Service Bus is technically vulnerable to takeover, but it also doesn't have native support for custom domains so it's unlikely it will be found in a wild CNAME. This doesn't mean it will never be vulnerable though, a company may be DIYing it or more likely, you can take over a service bus that an application is pointing (or reading from) to leak data going to it or allow you to generate fake data that the app will ingest.
Creating an end-to-end POC for this is quite the process so I won't go through the whole thing but it's as simple as identifying a service bus being used and if it doesn't resolve, you should be able to take it over.
For my example, imagine there is a service bus at stratus-poc.servicebus.windows.net that is being sent user registration information but it has been deleted. All you need to do is go into the Azure portal, create an Azure service bus and name it stratus-poc as shown below.
After registering this, you will own it! To get the data being sent to it, you will also need to create queues based on the URL you identified, once this is done you will be collecting the leaked data in these queues.
I believe there are probably a lot of data leaks around the internet because of this but detecting them will require some serious luck or a large-scale data set.