{
	"id": "7920ed45-c58f-48f5-8f05-418edaefe53f",
	"created_at": "2026-04-06T00:10:07.962809Z",
	"updated_at": "2026-04-10T03:21:05.28929Z",
	"deleted_at": null,
	"sha1_hash": "f2c85caf5d7a823ce4bfae879f02818320886e16",
	"title": "Prevent subdomain takeovers with Azure DNS alias records and Azure App Service's custom domain verification",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 234136,
	"plain_text": "Prevent subdomain takeovers with Azure DNS alias records and Azure\r\nApp Service's custom domain verification\r\nBy msmbaldwin\r\nArchived: 2026-04-05 14:24:42 UTC\r\nThis article describes the common security threat of subdomain takeover and the steps you can take to mitigate against it.\r\nWhat is a subdomain takeover?\r\nSubdomain takeovers are a common, high-severity threat for organizations that regularly create, and delete many resources.\r\nA subdomain takeover can occur when you have a DNS record that points to a deprovisioned Azure resource. Such DNS\r\nrecords are also known as \"dangling DNS\" entries. CNAME records are especially vulnerable to this threat. Subdomain\r\ntakeovers enable malicious actors to redirect traffic intended for an organization's domain to a site performing malicious\r\nactivity.\r\nA common scenario for a subdomain takeover:\r\n1. CREATION:\r\n1. You provision an Azure resource with a fully qualified domain name (FQDN) of app-contogreat-dev-001.azurewebsites.net .\r\n2. You assign a CNAME record in your DNS zone with the subdomain greatapp.contoso.com that routes\r\ntraffic to your Azure resource.\r\n2. DEPROVISIONING:\r\n1. The Azure resource is deprovisioned or deleted after it is no longer needed.\r\nAt this point, the CNAME record greatapp.contoso.com should be removed from your DNS zone. If the\r\nCNAME record isn't removed, it's advertised as an active domain but doesn't route traffic to an active Azure\r\nresource. You now have a \"dangling\" DNS record.\r\n2. The dangling subdomain, greatapp.contoso.com , is now vulnerable and can be taken over by being\r\nassigned to another Azure subscription's resource.\r\n3. TAKEOVER:\r\n1. Using commonly available methods and tools, a threat actor discovers the dangling subdomain.\r\n2. The threat actor provisions an Azure resource with the same FQDN of the resource you previously controlled.\r\nIn this example, app-contogreat-dev-001.azurewebsites.net .\r\n3. Traffic being sent to the subdomain greatapp.contoso.com is now routed to the malicious actor's resource\r\nwhere they control the content.\r\nhttps://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nPage 1 of 6\n\nThe risks of subdomain takeover\r\nWhen a DNS record points to a resource that isn't available, the record itself should be removed from your DNS zone. If it\r\nisn't deleted, it's a \"dangling DNS\" record and creates the possibility for subdomain takeover.\r\nDangling DNS entries make it possible for threat actors to take control of the associated DNS name to host a malicious\r\nwebsite or service. Malicious pages and services on an organization's subdomain might result in:\r\nLoss of control over the content of the subdomain - Negative press about your organization's inability to secure its\r\ncontent, brand damage, and loss of trust.\r\nCookie harvesting from unsuspecting visitors - It's common for web apps to expose session cookies to subdomains\r\n(*.contoso.com). Any subdomain can access them. Threat actors can use subdomain takeover to build an authentic\r\nlooking page, trick unsuspecting users to visit it, and harvest their cookies (even secure cookies). A common\r\nmisconception is that using SSL certificates protects your site, and your users' cookies, from a takeover. However, a\r\nthreat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate. Valid SSL certificates\r\ngrant them access to secure cookies and can further increase the perceived legitimacy of the malicious site.\r\nPhishing campaigns - Malicious actors often exploit authentic-looking subdomains in phishing campaigns. The risk\r\nextends to both malicious websites and MX records, which could enable threat actors to receive emails directed to\r\nlegitimate subdomains associated with trusted brands.\r\nFurther risks - Malicious sites might be used to escalate into other classic attacks such as XSS, CSRF, CORS\r\nbypass, and more.\r\nIdentify dangling DNS entries\r\nTo identify DNS entries within your organization that might be dangling, use Microsoft's GitHub-hosted PowerShell tools\r\n\"Get-DanglingDnsRecords\".\r\nThis tool helps Azure customers list all domains with a CNAME associated to an existing Azure resource that was created\r\non their subscriptions or tenants.\r\nIf your CNAMEs are in other DNS services and point to Azure resources, provide the CNAMEs in an input file to the tool.\r\nThe tool supports the Azure resources listed in the following table. The tool extracts, or takes as inputs, all the tenant's\r\nCNAMEs.\r\nhttps://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nPage 2 of 6\n\nService Type FQDNproperty Example\r\nAzure Front\r\nDoor\r\nmicrosoft.network/frontdoors properties.cName abc.azurefd.net\r\nAzure Blob\r\nStorage\r\nmicrosoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows\r\nAzure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net\r\nPublic IP\r\naddresses\r\nmicrosoft.network/publicipaddresses properties.dnsSettings.fqdn abc.EastUs.cloudapp.a\r\nAzure\r\nTraffic\r\nManager\r\nmicrosoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.ne\r\nAzure\r\nContainer\r\nInstance\r\nmicrosoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azureconta\r\nAzure API\r\nManagement\r\nmicrosoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net\r\nAzure App\r\nService\r\nmicrosoft.web/sites properties.defaultHostName abc.azurewebsites.net\r\nAzure App\r\nService -\r\nSlots\r\nmicrosoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites\r\nPrerequisites\r\nRun the query as a user who has:\r\nat least reader level access to the Azure subscriptions\r\nread access to Azure resource graph\r\nIf you're a Global Administrator of your organization's tenant, follow the guidance in Elevate access to manage all Azure\r\nsubscriptions and management groups to gain access to all your organization's subscriptions\r\nRun the script\r\nLearn more about the PowerShell script, Get-DanglingDnsRecords.ps1, and download it from GitHub: https://aka.ms/Get-DanglingDnsRecords.\r\nReview your DNS zones and identify CNAME records that are dangling or taken over. If subdomains are found to be\r\ndangling or have been taken over, remove the vulnerable subdomains and mitigate the risks with the following steps:\r\n1. From your DNS zone, remove all CNAME records that point to FQDNs of resources no longer provisioned.\r\n2. To enable traffic to be routed to resources in your control, provision more resources with the FQDNs specified in the\r\nCNAME records of the dangling subdomains.\r\n3. Review your application code for references to specific subdomains and update any incorrect or outdated subdomain\r\nreferences.\r\n4. Investigate whether any compromise occurred and take action per your organization's incident response procedures.\r\nTips and best practices for investigating:\r\nIf your application logic results in secrets, such as OAuth credentials, being sent to dangling subdomains or if\r\nprivacy-sensitive information is transmitted to those subdomains, there is a possibility for this data to be exposed to\r\nhttps://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nPage 3 of 6\n\nthird parties.\r\n5. Understand why the CNAME record was not removed from your DNS zone when the resource was deprovisioned\r\nand take steps to ensure that DNS records are updated appropriately when Azure resources are deprovisioned in the\r\nfuture.\r\nPrevent dangling DNS entries\r\nEnsuring that your organization has implemented processes to prevent dangling DNS entries and the resulting subdomain\r\ntakeovers is a crucial part of your security program.\r\nSome Azure services offer features to aid in creating preventative measures and are detailed below. Other methods to\r\nprevent this issue must be established through your organization's best practices or standard operating procedures.\r\nEnable Microsoft Defender for App Service\r\nMicrosoft Defender for Cloud's integrated cloud workload protection platform (CWPP) offers a range of plans to protect\r\nyour Azure, hybrid, and multicloud resources and workloads.\r\nThe Microsoft Defender for App Service plan includes dangling DNS detection. With this plan enabled, you'll get security\r\nalerts if you decommission an App Service website but don't remove its custom domain from your DNS registrar.\r\nMicrosoft Defender for Cloud's dangling DNS protection is available whether your domains are managed with Azure DNS\r\nor an external domain registrar and applies to App Service on both Windows and Linux.\r\nLearn more about this and other benefits of this Microsoft Defender plans in Introduction to Microsoft Defender for App\r\nService.\r\nUse Azure DNS alias records\r\nAzure DNS's alias records can prevent dangling references by coupling the lifecycle of a DNS record with an Azure\r\nresource. For example, consider a DNS record that's qualified as an alias record to point to a public IP address or a Traffic\r\nManager profile. If you delete those underlying resources, the DNS alias record becomes an empty record set. It no longer\r\nreferences the deleted resource. It's important to note that there are limits to what you can protect with alias records. Today,\r\nthe list is limited to:\r\nAzure Front Door\r\nTraffic Manager profiles\r\nAzure Content Delivery Network (CDN) endpoints\r\nPublic IPs\r\nDespite the limited service offerings today, we recommend using alias records to defend against subdomain takeover\r\nwhenever possible.\r\nLearn more about the capabilities of Azure DNS's alias records.\r\nUse Azure App Service's custom domain verification\r\nWhen creating DNS entries for Azure App Service, create an asuid.{subdomain} TXT record with the Domain Verification\r\nID. When such a TXT record exists, no other Azure Subscription can validate the Custom Domain that is, take it over.\r\nThese records don't prevent someone from creating the Azure App Service with the same name that's in your CNAME entry.\r\nWithout the ability to prove ownership of the domain name, threat actors can't receive traffic or control the content.\r\nLearn more about how to map an existing custom DNS name to Azure App Service.\r\nBuild and automate processes to mitigate the threat\r\nIt's often up to developers and operations teams to run cleanup processes to avoid dangling DNS threats. The practices\r\nbelow will help ensure your organization avoids suffering from this threat.\r\nhttps://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nPage 4 of 6\n\nCreate procedures for prevention:\r\nEducate your application developers to reroute addresses whenever they delete resources.\r\nPut \"Remove DNS entry\" on the list of required checks when decommissioning a service.\r\nPut delete locks on any resources that have a custom DNS entry. A delete lock serves as an indicator that the\r\nmapping must be removed before the resource is deprovisioned. Measures like this can only work when\r\ncombined with internal education programs.\r\nCreate procedures for discovery:\r\nReview your DNS records regularly to ensure that your subdomains are all mapped to Azure resources that:\r\nExist - Query your DNS zones for resources pointing to Azure subdomains such as *.azurewebsites.net\r\nor *.cloudapp.azure.com (see the Reference list of Azure domains).\r\nYou own - Confirm that you own all resources that your DNS subdomains are targeting.\r\nMaintain a service catalog of your Azure fully qualified domain name (FQDN) endpoints and the application\r\nowners. To build your service catalog, run the following Azure Resource Graph query script. This script\r\nprojects the FQDN endpoint information of the resources you have access to and outputs them in a CSV file.\r\nIf you have access to all the subscriptions for your tenant, the script considers all those subscriptions as shown\r\nin the following sample script. To limit the results to a specific set of subscriptions, edit the script as shown.\r\nCreate procedures for remediation:\r\nWhen dangling DNS entries are found, your team needs to investigate whether any compromise has occurred.\r\nInvestigate why the address wasn't rerouted when the resource was decommissioned.\r\nDelete the DNS record if it's no longer in use, or point it to the correct Azure resource (FQDN) owned by your\r\norganization.\r\nClean up DNS pointers or re-claim the DNS\r\nUpon deletion of the classic cloud service resource, the corresponding DNS is reserved as per Azure DNS policies. During\r\nthe reservation period, re-use of the DNS will be forbidden EXCEPT for subscriptions belonging to the Microsoft Entra\r\ntenant of the subscription originally owning the DNS. After the reservation expires, the DNS is free to be claimed by any\r\nsubscription. By taking DNS reservations, the customer is afforded some time to either 1) clean up any associations/pointers\r\nto said DNS or 2) re-claim the DNS in Azure. The recommendation would be to delete unwanted DNS entries at the earliest.\r\nThe DNS name being reserved can be derived by appending the cloud service name to the DNS zone for that cloud.\r\nPublic - cloudapp.net\r\nMooncake - chinacloudapp.cn\r\nFairfax - usgovcloudapp.net\r\nBlackForest - azurecloudapp.de\r\nFor example, a hosted service in Public named \"test\" would have DNS \"test.cloudapp.net\"\r\nExample: Subscription 'A' and subscription 'B' are the only subscriptions belonging to Microsoft Entra tenant 'AB'.\r\nSubscription 'A' contains a classic cloud service 'test' with DNS name 'test.cloudapp.net'. Upon deletion of the cloud service,\r\na reservation is taken on DNS name 'test.cloudapp.net'. During the reservation period, only subscription 'A' or subscription\r\n'B' will be able to claim the DNS name 'test.cloudapp.net' by creating a classic cloud service named 'test'. No other\r\nsubscriptions will be allowed to claim it. After the reservation period, any subscription in Azure can now claim\r\n'test.cloudapp.net'.\r\nNext steps\r\nTo learn more about related services and Azure features you can use to defend against subdomain takeover, see the following\r\npages.\r\nEnable Microsoft Defender for App Service - to receive alerts when dangling DNS entries are detected\r\nhttps://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nPage 5 of 6\n\nPrevent dangling DNS records with Azure DNS\r\nUse a domain verification ID when adding custom domains in Azure App Service\r\nQuickstart: Run your first Resource Graph query using Azure PowerShell\r\nSource: https://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nhttps://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover"
	],
	"report_names": [
		"subdomain-takeover"
	],
	"threat_actors": [],
	"ts_created_at": 1775434207,
	"ts_updated_at": 1775791265,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f2c85caf5d7a823ce4bfae879f02818320886e16.pdf",
		"text": "https://archive.orkl.eu/f2c85caf5d7a823ce4bfae879f02818320886e16.txt",
		"img": "https://archive.orkl.eu/f2c85caf5d7a823ce4bfae879f02818320886e16.jpg"
	}
}