Azure Apps for Command and Control

Azure Apps are often subject to subdomain takeovers, or you might even want to use Azure Apps for Command and Control!

Why Azure Apps?

Azure applications are often used by organisations to host websites. We can see many significant sites using them; the market share is quite large. We often hear and see Azure Apps appearing in bug bounties via. the likes of subdomain takeover vulnerabilities, see:

What are we doing here?

Although you might be thinking, "I can't take over people's domains and use it as command and control or for phishing in our engagements!". Sure, but it could very well be possible that your customer's subdomains are vulnerable - it's always worth checking.

To exploit and use a subdomain takeover, you would've had to write some code and deploy it on Azure apps; I gave up. I went and just wrote a Python script to proxy all the traffic to my selected host over HTTPS. This way, we can re-use this code as many times as we want, for dynamic content feeding through Azure Apps.

Subdomain Takeover via. Azure App Overview

A subdomain takeover state via. Azure App is when a customer of Azure uses Azure Apps, configures their domain to point to the Azure App, has some fun with it, and then one day decides that they don't want to use it anymore, so decide to kill off the Azure App - but they don't delete the record pointing to Azure.

You might be wondering why this happens? There are many reasons, we're not here to discuss, but the basic ones I hear of are:

  1. Cloud infrastructure deployment team is not the same team as the DNS management team. Hence lost in communication pipelines somewhere.

  2. The person does not know that the DNS record still pointing to Azure would be an issue.

  3. "Why does it matter if someone's hosting stuff on our subdomain? They aren't hacking us."

Whatever the reason may be, you can be sure that these vulnerabilities often prop up on assessments and can be used to hide under the radar of the blue team. Let's be clear; I've found the following types of organisations to be vulnerable:

  • Airline subdomains

  • Big Four / Large consultancy subdomains

  • Energy company subdomains

  • Global and local bank subdomains

  • Global retailer subdomains

  • Government subdomains

  • Insurance subdomains

  • Microsoft subdomains

  • Phone manufacturer subdomains

  • Telecom subdomains

  • Transport subdomains

So yeah, it's not exactly a small issue. For the unethical, it's a big surface. For the professionals doing Attack Simulation engagements, we still have a good chance our customer might have an associated domain's subdomain that might be vulnerable.

How does it work?

On this occasion, I've deliberately taken my domain of and set a vulnerable subdomain pointing to Azure Apps. Specifically: Azure websites are not the only Azure App domain extension, the ones I generally look out for (when it comes to Azure Apps specifically) are:

Take a look at the following vulnerable DNS record:

You can see that there's a missing slot, and no A name record for the final IP to connect to. Ths is because the myvulnerableapp is not registered in Azure Apps.

Let's exploit it

To exploit this, login to the Azure console, and create a new Azure App:

Make sure that you create an F1 instance, in my opinion. Unless of course you're mega rich and don't mind paying like per hour for the premium instance (which I did, and ended up being billed US$200 before I even knew what happened).

After the instance is ready, I like to start with a template:

git clone

Then cd into it, and edit the file (with the code from my GitHub):

Add urllib2 to the requirements.txt file:

Save the file. To skip the previous steps of picking F1 and using the GUI, you can create the whole app and deploy from CLI:

az webapp up -p F1 --sku F1 -n myvulnerableapp

Test that the page works by visiting the URL:

Once it's working, you can go to the Azure portal and configure the custom domains as shown below:

Once you've added the record, you can do a DNS lookup again, and you will see that it's now completed changed. See following screenshot:

Visit the domain we took over of and you can see our content from our C2 server:

If you want to use HTTPS, you will need to upload your SSL certificate to the Azure portal and bind the SSL certificate to it.


For those that prefer a video to learn from, here you go!

Git the goods


To better understand Subdomain takeovers, Patrik Hudak has an excellent blog resource:

Last updated