DNS CNAME records pointing to deprovisioned Azure/AWS resources creating subdomain takeover vulnerabilities

01 Incident diagnostics

The Symptom

A marketing microsite or staging subdomain (e.g. promo.company.com) starts serving unrelated content, a parking page, or an obvious phishing clone. Security scanners flag valid TLS certificates issued for the subdomain that your team never requested. Some cases surface only as a generic Azure 404 'Web App Not Found' page or an S3 'NoSuchBucket' XML error visible to customers.

Detection

Export the zone and grep for provider default suffixes: for f in $(az network dns record-set cname list --resource-group rg-dns --zone-name company.com --query "[].cname" -o tsv); do dig +short $f; done | grep -E 'azurewebsites.net|cloudapp.net|blob.core.windows.net|s3.amazonaws.com|elb.amazonaws.com'. A CNAME resolving to NXDOMAIN, a generic 404, or a bucket 'NoSuchBucket' response confirms an orphaned pointer with no matching live resource.

Root Cause

Azure App Service hostnames and AWS S3 bucket names are allocated from a shared, tenant-independent namespace. Deleting the resource releases the name back into that pool without touching the CNAME record in your DNS zone, because the decommission workflow (az webapp delete, aws s3 rb) has no coupling to the DNS provider. Any subsequent tenant, including an attacker, can then provision an identically named resource and inherit incoming traffic for that CNAME with zero domain-ownership validation.

Prevention

Couple DNS record deletion to the same Terraform/Bicep apply that tears down the resource, using explicit depends_on so azurerm_dns_cname_record or aws_route53_record is destroyed in the identical plan. Run a daily dnsx-based dangling-CNAME sweep against the exported zone file in CI, alerting on any record resolving to NXDOMAIN or a provider 'not found' response. Maintain a CMDB tag mapping each DNS record to its owning resource ID so decommission tickets are blocked until the linked record is confirmed removed.

Blast Radius

• Any dangling CNAME can be claimed to host phishing content served over a trusted company subdomain, inheriting SameSite cookie scope and bypassing CSP domain allowlists that trust *.company.com
• Let's Encrypt HTTP-01 validation succeeds against the hijacked subdomain, producing a fully valid HTTPS certificate for the attacker's content
• OAuth redirect URIs or SAML ACS endpoints referencing the abandoned subdomain become viable token-theft targets if still whitelisted in app registrations
• Decommissioned marketing microsites, PoC environments, and vendor-integration subdomains are the highest-frequency source, since they are deleted without a DNS cleanup ticket