On 22-Oct-2019 I spoke at Boston Azure about network security and focused on some of the edges of using Azure DNS, and included some DNS subdomain hijacking awareness.
The command
dig CNAME bostonazuredemo.azuresecurely.com +short
will check public DNS records for a CNAME, returning whatever it is mapped to, if anything.

In the above screenshot:
- nothing returned from dig – this is before any DNS entry was created for the demo subdomain
- a cascade of CNAMES are returned from dig – this is after a DNS entry was created for the demo subdomain – and it pointed at an Azure Web App — the cascade here includes my subdomain => an azurewebsites.net subdomain (bostonazuredemo.azurewebsites.net) => a second azurewebsites.net subdomain (waws-prod-dm1-139.sip….) => a cloudapp.net domain => and finally an IP address
- a single CNAME is returned from dig – this is after the Azure Web App was deleted (), but the DNS subdomain entry (bostonazuredemo.azuresecurely.com) was left intact – creating a dangling subdomain at risk of being hijacked — anyone who registered bostonazuredemo.azurewebsites.net (and it was open for anyone) would automatically have bostonazuredemo.azuresecurely.com already wired up to it.
- a cascade of CNAMES are returned from dig – but different than the first – this is after bostonazuredemo.azurewebsites.net was registered again, by a hacker, and bostonazuredemo.azuresecurely.com was hijacked
Some other notes from the session:
Subdomain takeover examples:
Like this:
Like Loading...