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!
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:
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.
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.
On this occasion, I've deliberately taken my domain of
megacorp.icuand set a vulnerable subdomain pointing to Azure Apps. Specifically:
myvulnerableapp.azurewebsites.net. 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
myvulnerableappis not registered in Azure Apps.
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 https://github.com/Azure-Samples/python-docs-hello-world
cdinto it, and edit the
application.pyfile (with the code from my GitHub):
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 hansolo.megacorp.icu 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!