How Dangling CNAME Records Enable Subdomain Takeover

In 2025, researchers at watchTowr Labs registered hundreds of abandoned Amazon S3 buckets that organizations had deleted but never removed from their DNS records. Those buckets received millions of HTTP requests, including requests from government agencies, military networks, Fortune 500 companies, and major banks. Some requests were attempting to download software updates and deployment templates. All it took was a few dollars in S3 registration fees to intercept them.

The root cause was simple: CNAME records still pointed to resources that no longer existed. This is the dangling CNAME problem, and it is one of the most common and most underestimated vulnerabilities in modern DNS infrastructure.

This article explains what dangling CNAME records are, how attackers exploit them, why they are dangerous, and how to detect and fix them before someone else does.

What Is a Dangling CNAME Record?

A CNAME (Canonical Name) record is a DNS record that maps one domain name to another. When a browser resolves blog.example.com and finds a CNAME record pointing to example.wordpress.com, it follows the chain and resolves the WordPress address instead. CNAMEs are how organizations connect their branded subdomains to third-party services like cloud platforms, CDNs, SaaS products, and hosting providers.

A dangling CNAME is a CNAME record that points to a destination that no longer exists. The DNS record is still live and still responds to queries, but the resource it references has been deleted, deprovisioned, or abandoned.

The lifecycle is predictable. A team provisions a cloud resource, like an Azure Web App or an S3 bucket. They create a CNAME record so their subdomain points to it. Later, they decommission the resource but forget to remove the DNS record. Now the CNAME points at nothing. The subdomain is dangling.

While CNAME records are the most commonly exploited type, other DNS records can dangle too. A records can point to IP addresses that have been released back to a cloud provider. MX records can reference mail servers that no longer exist. NS records can delegate to nameservers that have been decommissioned, enabling a particularly dangerous variant where an attacker gains full control of a DNS zone. This article focuses on CNAMEs because they are the most frequent vector, but the same principles apply to any DNS record that outlives the resource it references.

How Attackers Exploit Dangling CNAMEs

The attack is straightforward. An attacker finds a subdomain with a CNAME pointing to a deprovisioned resource and registers that resource under their own account. The DNS record now resolves to infrastructure the attacker controls, and they can serve any content they want under the victim's subdomain.

Here is the step-by-step flow:

1. Enumerate subdomains for a target domain using certificate transparency logs, DNS brute-forcing, or passive data sources.
2. For each subdomain, resolve its DNS records and identify CNAME targets that point to cloud services or SaaS platforms.
3. Check whether the CNAME target is available for registration by the attacker.
4. Register the resource (create the S3 bucket, claim the Heroku app name, register the GitHub Pages repository) and serve attacker-controlled content.
5. Optionally, obtain a valid SSL/TLS certificate for the hijacked subdomain using a free certificate authority like Let's Encrypt, since the attacker now controls the content served at that domain.

Attackers detect vulnerable CNAMEs using two primary methods. The first is NXDOMAIN detection: if a CNAME target returns an NXDOMAIN response (indicating the domain does not exist), the underlying resource has been fully deleted. This is common with Azure services, where deleting a Web App removes the .azurewebsites.net subdomain entirely. The second is HTTP fingerprint detection: some services always resolve to an IP address even when the specific resource does not exist, but they return a distinctive error page. Amazon S3 returns NoSuchBucket, WordPress.com shows "Do you want to register," and Ghost displays "Site unavailable." Each fingerprint confirms the resource is claimable.

Once the resource is claimed, the attacker can obtain a valid SSL certificate because they control the endpoint behind the CNAME. Certificate authorities verify domain ownership by checking that a specific token is served at the domain. Since the attacker controls the response, domain validation succeeds. The result is a fully trusted HTTPS connection to an attacker-controlled subdomain.

Why Dangling CNAMEs Are Dangerous

A hijacked subdomain is not just a defacement risk. Because the attacker operates under the victim's domain, the browser treats it as same-site, inheriting all the trust that the parent domain has accumulated.

Cookie and Session Hijacking

Cookies set on a parent domain with a wildcard scope (e.g., .example.com) are sent to every subdomain automatically. If blog.example.com is hijacked, the browser sends the parent domain's cookies, including session tokens and authentication cookies, to the attacker's server on every request. The attacker can capture these cookies and use them to impersonate users on the legitimate application. Even cookies with the Secure flag are sent, since the attacker has a valid SSL certificate.

Phishing Under Your Brand

An attacker who controls support.yourcompany.com can serve a pixel-perfect login page with a valid SSL certificate and a URL that looks completely legitimate. Employees, customers, and partners have no visual indicator that something is wrong. The URL is on the correct domain, the certificate is valid, and the page looks real. This is far more effective than a lookalike domain because it requires no typosquatting and passes every casual inspection.

OAuth and SSO Token Theft

Many OAuth and SSO configurations use redirect URLs that accept any subdomain under the organization's domain. If the authorization server's allowlist includes a pattern like *.example.com, an attacker controlling a hijacked subdomain can register it as a redirect target, intercept OAuth authorization codes, and exchange them for access tokens. This gives the attacker authenticated access to the victim's accounts on connected services.

E-mail Spoofing via SPF and DKIM

If a CNAME target was a service that also handled e-mail, or if the organization used broad SPF records, the attacker may be able to send e-mail as the hijacked subdomain. By registering the expired CNAME target and configuring MX records and SPF, the attacker can send e-mail that passes DMARC validation. Phishing e-mails from noreply@support.yourcompany.com with valid DKIM signatures are extremely difficult for recipients to identify as fraudulent.

Supply Chain Attacks

The watchTowr Labs research demonstrated the most alarming scenario. Their abandoned S3 buckets received requests for software updates, JavaScript libraries, WSDL configurations, CloudFormation templates, and SSL VPN server configurations. If the researchers had been malicious actors, they could have served backdoored software updates to government systems, injected malicious JavaScript into production web applications, or modified infrastructure-as-code templates to compromise cloud deployments. The trust placed in a domain name extends to everything served under it.

Real-World Incidents

Subdomain takeover is not a theoretical risk. It has been demonstrated at scale against some of the largest organizations in the world.

Microsoft has been one of the most visible targets. Security researchers reported hundreds of Microsoft-owned subdomains vulnerable to takeover. Despite Microsoft's security resources, the sheer number of cloud services and DNS records across their infrastructure made it impossible to track every deprovisioned resource manually.

Certitude Consulting demonstrated the scope of the problem by identifying and responsibly disclosing vulnerable subdomains belonging to major news organizations, universities, and government agencies. Their research showed that even organizations with dedicated security teams routinely leave dangling CNAMEs in production DNS zones.

Bug bounty platforms have paid out on thousands of reports for subdomain takeovers. Starbucks, Roblox, and the United States Department of Defense have all had subdomain takeover vulnerabilities reported through HackerOne and Bugcrowd.

watchTowr Labs went beyond individual subdomains. By registering hundreds of abandoned S3 buckets, they received millions of HTTP requests. The requests came from government networks, Fortune 500 companies, military systems, banks, and payment card networks. The research demonstrated that dangling CNAMEs are not isolated oversights but a systemic problem across the internet.

Academic research has confirmed the scale. A study analyzing subdomain hijacking across 12 major cloud platforms over a three-year period identified thousands of confirmed hijacks affecting organizations of all sizes. Separately, RedHunt Labs estimated that hundreds of thousands of subdomains across the internet are currently vulnerable to takeover, with many belonging to financial institutions, healthcare providers, and government agencies.

How to Detect Dangling CNAME Records

Detection requires resolving every CNAME in your DNS zones and checking whether the target still exists. There are three approaches, ranging from manual to fully automated.

Manual DNS Audit

Export your DNS zone files and look for CNAME records pointing to third-party services. For each one, resolve the target and check if it returns NXDOMAIN or a known error page. This works for small zones but does not scale. Most organizations have hundreds or thousands of DNS records across multiple zones and registrars, making manual review impractical as a regular process.

Open-Source Tools

The can-i-take-over-xyz project on GitHub maintains a list of services with their takeover fingerprints and current exploitability status. Tools like Nuclei include subdomain takeover detection templates that automate the fingerprint-matching process. These tools are powerful but require setup, ongoing maintenance, and integration into your scanning workflow.

Automated Scanning

SubAnalyzer checks for subdomain takeover vulnerabilities on every scan. The detection engine covers 37 services across Azure, AWS, and SaaS platforms, using both NXDOMAIN detection for services where the resource is fully deleted and HTTP fingerprint detection for services that always resolve but return identifiable error pages when the resource does not exist. When a vulnerable CNAME is found, it is flagged with the affected service name so you know exactly which resource needs attention.

Integrating takeover detection into your regular subdomain scanning means dangling CNAMEs are caught automatically as part of your routine attack surface monitoring, rather than requiring a separate audit process. For details on how SubAnalyzer discovers subdomains in the first place, see How Subdomain Discovery Works.

How to Prevent and Fix Dangling CNAMEs

The fix is simple in principle: remove DNS records when you decommission the resource they point to. The challenge is making this happen consistently across teams, cloud accounts, and years of accumulated infrastructure.

Remove DNS Records Before Deprovisioning

The safest approach is to delete the CNAME record before or immediately after deleting the cloud resource. If you delete the resource first and forget the DNS record, you have created a dangling CNAME. Build "remove DNS entry" into your decommissioning checklists and runbooks as a mandatory step, not an optional cleanup task.

Maintain a DNS Record Inventory

Know which CNAME records exist, which team owns each one, and what resource each record points to. Without an inventory, records accumulate over years and nobody knows which ones are still needed. A shared spreadsheet or a proper CMDB entry for each DNS record is better than nothing.

Scan Regularly

Even with good processes, records slip through. People leave the company, teams reorganize, and documentation gets stale. Regular automated scanning catches dangling CNAMEs that manual processes miss. Run scans on a schedule so new vulnerabilities are detected quickly rather than sitting in your DNS for months.

Use Cloud Provider Safeguards

Some cloud providers offer protections against dangling CNAMEs. Azure supports alias records that automatically update when the underlying resource changes, and domain verification tokens that prevent other tenants from claiming your custom domain. AWS Route 53 alias records similarly stay linked to the lifecycle of the resource. Use these features when available rather than raw CNAME records.

Audit Your SPF Records

Review your SPF records to ensure they do not include domains that could be taken over. A broad include: directive pointing to a service you no longer use gives an attacker the ability to send authenticated e-mail as your domain if they claim that service. Tighten your SPF to only include currently active senders.

Conclusion

Dangling CNAME records are one of the easiest vulnerabilities for attackers to exploit and one of the easiest to prevent. The fix is a single DNS deletion. But without visibility into what CNAME records exist and whether their targets are still active, organizations accumulate dangling records over time until someone finds them.

The consequences of a hijacked subdomain go far beyond defacement: cookie theft, credential phishing, OAuth token interception, e-mail spoofing, and supply chain compromise are all on the table. The organizations hit hardest are the ones that never knew the subdomain was vulnerable in the first place.

Want to find out if your domain has dangling CNAMEs? Scan your domain and SubAnalyzer will check every subdomain against 37 known vulnerable services automatically.