Dangling Records
Azure Web App Subdomain Takeover
CNAMEs that still point to deleted Azure resources are claimable. That includes Web Apps, Blob endpoints, Traffic Manager, and older cloud service hostnames.
How it happens
- You create a subdomain pointing to
appname.azurewebsites.net. - You decommission the Azure resource.
- The CNAME stays in DNS.
- An attacker creates an Azure resource with the same name.
- Your subdomain serves their app.
Common Azure dangling targets
azurewebsites.net(Web Apps)blob.core.windows.net(Blob Storage)trafficmanager.net(Traffic Manager)cloudapp.azure.com(Cloud Services)
How to check
Run DomainPreflight Dangling Records to scan your CNAMEs and compare against known Azure takeover fingerprints.
How to fix
Delete any dangling CNAMEs immediately. If you still need the hostname, recreate and verify the Azure resource first.
Fix it step by step
Scan your domain for dangling provider records
Open Dangling Records Scanner →FAQ
What is an Azure subdomain takeover?
It happens when a CNAME points to a deleted Azure resource and someone else claims that resource name.
How do I know if my subdomain is vulnerable?
Run DomainPreflight Dangling Records. It checks CNAME targets against known Azure fingerprints.
What are common Azure dangling targets?
Common targets include azurewebsites.net, blob.core.windows.net, trafficmanager.net, and cloudapp.azure.com.
How do I fix an Azure dangling CNAME?
Delete the DNS CNAME. If you need the subdomain, recreate the Azure resource first.
Can I prevent this from happening again?
Always delete DNS records when decommissioning services. Run Dangling Records scans quarterly.