Subdomain Takeover: When Dangling DNS Records Become Attack Surface

Every organization accumulates DNS records. Marketing launches a campaign site on an external hosting platform. Engineering spins up a staging environment on a cloud provider. A product team provisions a documentation portal through a SaaS platform. Each of these creates a DNS record — usually a CNAME — pointing a subdomain to the external service.

Then the campaign ends. The staging environment is torn down. The documentation portal moves to a different provider. The cloud resources are deleted. But the DNS records stay.

Those leftover records are dangling pointers — they reference something that no longer exists. And in many cases, an attacker can step in, claim the orphaned resource on the external platform, and serve arbitrary content under the organization's trusted domain.

This is subdomain takeover.

How DNS Records Create the Vulnerability

To understand subdomain takeover, you need to understand how custom domains work with external services.

When an organization wants blog.example.com to serve content from a cloud hosting platform, it creates a CNAME record:

blog.example.com.  CNAME  example-org.cloudprovider.net.

This tells DNS resolvers: "When someone requests blog.example.com, follow the chain to example-org.cloudprovider.net and return that IP address."

On the cloud provider's side, the organization configures the service to respond to requests for blog.example.com. The provider checks that the CNAME exists (to verify domain ownership) and begins serving content for that custom domain.

The system works. Until the organization deletes the cloud resource but leaves the CNAME in place.

Now blog.example.com still points to example-org.cloudprovider.net, but nothing exists at that endpoint anymore. The cloud provider returns an error page — something like "There is no site configured at this address" or a 404 from the platform itself.

This is the dangling state. The DNS record points somewhere, but no one controls what is at the other end.

How Attackers Claim Dangling Subdomains

The attack is remarkably straightforward:

1. Reconnaissance — The attacker enumerates an organization's subdomains through DNS zone analysis, certificate transparency logs, or passive DNS databases. They build a list of all subdomains and their CNAME targets.

2. Identification — For each CNAME, the attacker checks whether the target resource still exists. If the cloud provider returns a default error page, a "resource not found" message, or a specific status code indicating an unclaimed resource, the subdomain is a candidate for takeover.

3. Claiming — The attacker creates a new resource on the same cloud platform. They configure it with the same endpoint name (or allow the platform to assign the matching endpoint). Then they add blog.example.com as a custom domain on their newly created resource.

4. Serving content — The platform sees a valid CNAME pointing to its infrastructure and begins serving the attacker's content for requests to blog.example.com. The attacker now controls what visitors see on that subdomain.

The entire process can take minutes. Many cloud platforms require nothing more than a free account to create a new resource and bind a custom domain.

Which Services Are Vulnerable

Not every external service is susceptible to subdomain takeover. The vulnerability depends on how the platform handles custom domain registration and what happens when a resource is deleted. Several categories of services are commonly exploitable.

Static Hosting and Content Delivery

Cloud object storage services that serve static websites are among the most common targets. When the storage bucket or container is deleted, the platform returns a specific error message. An attacker can create a new bucket with the same name and host arbitrary HTML, CSS, and JavaScript.

Similarly, content delivery networks that allow custom domain binding can be exploited when the origin resource is removed. The CDN endpoint remains in DNS, but the origin no longer exists — creating a window for an attacker to bind their own origin.

Platform-as-a-Service Hosting

Application hosting platforms that assign subdomains on a shared domain (like yourapp.platform.io) are frequent targets. When the application is deleted, the platform releases the subdomain. An attacker can create a new application with the same name and add the organization's custom domain.

Documentation and Knowledge Base Platforms

SaaS documentation platforms commonly support custom domains for branded help centers and knowledge bases. When the subscription is cancelled, the platform stops serving content but the CNAME remains. Some platforms immediately release the custom domain binding, allowing an attacker to claim it on a new account.

Code Repository Hosting

Repository hosting platforms that offer static site hosting through custom domains are well-documented takeover targets. When a repository or organization is deleted or renamed, the custom domain binding is released, but the CNAME in the organization's DNS zone persists.

Email and Marketing Platforms

Landing pages created through email marketing and campaign management platforms are particularly prone to orphaned records. Marketing teams frequently create and abandon campaign-specific subdomains without coordinating with IT or infrastructure teams who manage DNS.

Impact

The consequences of subdomain takeover extend far beyond hosting a defacement page. Because the attacker controls a subdomain of the legitimate domain, they inherit significant trust.

Phishing Under a Trusted Domain

An attacker hosting a phishing page on login.example.com has an enormous advantage over traditional phishing. The domain is real. The TLS certificate is valid (the attacker can provision one through the cloud platform, since the CNAME proves domain control). Browser address bars show the legitimate parent domain. URL filters and blocklists have no reason to flag it — it is, technically, part of the organization's domain.

Cookie Theft and Session Hijacking

Cookies set on the parent domain (example.com) are sent to all subdomains by default. If an application sets a session cookie with Domain=.example.com, that cookie is included in every request to blog.example.com — even when an attacker controls it.

The attacker can serve a page that reads these cookies through JavaScript (if the HttpOnly flag is not set) or simply observe them in the HTTP request. Session tokens, authentication cookies, and CSRF tokens can all be captured.

Even with HttpOnly cookies, the attacker can set cookies that the main application will read. This enables session fixation attacks — the attacker sets a session cookie to a known value, and the main application accepts it.

Content Security Policy Bypass

Many applications define content security policies that whitelist their own domain using wildcards:

Content-Security-Policy: script-src *.example.com

This policy allows JavaScript to be loaded from any subdomain of example.com. If an attacker controls blog.example.com, they can host a malicious script there and load it from any page on the main application that uses this CSP. The browser allows it — the script source matches the policy.

This effectively converts a subdomain takeover into a cross-site scripting vulnerability on the main application.

OAuth and SSO Token Interception

Some OAuth implementations use subdomain-based redirect URIs. If the authorization server allows redirects to any subdomain of the registered domain, an attacker controlling a subdomain can intercept OAuth authorization codes or tokens.

Prevention

Preventing subdomain takeover requires treating DNS records as infrastructure that must be managed throughout its lifecycle — not just created and forgotten.

Remove DNS Records When Deprovisioning Services

The most direct prevention: when you delete a cloud resource, delete the corresponding DNS record at the same time. This should be part of the deprovisioning process, documented in runbooks and enforced through checklists or automation.

# Deprovisioning checklist:
1. Delete the cloud resource (hosting, storage, CDN)
2. Remove the CNAME record from the DNS zone
3. Verify the subdomain no longer resolves
4. Remove the subdomain from monitoring

If your infrastructure is managed through code (DNS-as-code), the service and its DNS record should exist in the same configuration, so deleting one naturally deletes the other.

Maintain a DNS Inventory

Keep an authoritative inventory of every DNS record, the service it points to, and the team responsible for it. Periodically reconcile this inventory against your actual DNS zone and your active cloud resources. Any record that points to a resource that no longer exists is a candidate for removal.

Monitor for Dangling Records

Automated monitoring should regularly check all CNAME records and verify that the target resources still exist and are under your control. The check is straightforward: resolve each CNAME and inspect the HTTP response. Platform-specific error pages, 404 responses, and default landing pages are indicators of a dangling record.

Set up alerts for:

• CNAME targets that return error pages from cloud platforms
• Subdomains that return unexpected content
• New DNS records created without corresponding service provisioning tickets

Implement Domain Verification on External Platforms

Some cloud platforms support domain verification through TXT records or other mechanisms that go beyond simple CNAME existence. Where available, use these mechanisms — they make it harder for an attacker to claim your subdomain even if the resource is deleted.

Use Restrictive Cookie Scoping

Avoid setting cookies with Domain=.example.com unless absolutely necessary. Scope cookies to the specific subdomain that needs them. This limits the impact of a subdomain takeover by preventing the attacker from accessing cookies set by other parts of the application.

Tighten Content Security Policies

Avoid wildcard subdomain policies like script-src *.example.com. Instead, enumerate the specific subdomains that should be allowed to serve scripts:

Content-Security-Policy: script-src app.example.com cdn.example.com

This prevents a compromised or hijacked subdomain from being used to bypass your CSP.

Claim Defensive Resources

For platforms where resource names are globally unique (like cloud storage bucket names), consider maintaining placeholder resources even after deprovisioning. A minimal, empty resource that holds the name prevents an attacker from claiming it. This adds minor cost but eliminates the takeover window.

Testing for Subdomain Takeover

When assessing an organization's exposure, the testing process follows a systematic flow:

1. Enumerate subdomains through DNS zone transfers (if available), certificate transparency log searches, and passive DNS aggregation. Build a comprehensive list of all subdomains, both current and historical.

2. Resolve CNAME chains for each subdomain. Identify which subdomains point to external services rather than the organization's own infrastructure.

3. Check each external target for indicators of an unclaimed resource. Look for platform-specific error messages, default pages, and HTTP response codes that indicate the target resource does not exist.

4. Verify exploitability by checking whether the cloud platform allows creating a new resource and binding the custom domain. Some platforms have implemented protections that prevent claiming domains with existing CNAME records unless domain ownership is verified through additional mechanisms.

5. Assess impact based on what cookies, CSP rules, and trust relationships exist on the parent domain.

Key Takeaways

Subdomain takeover is a consequence of infrastructure drift — the gap between what DNS says exists and what actually exists. Every time a team provisions an external service and creates a DNS record, they create a future liability if that record is not managed through the service's entire lifecycle.

The defenses are operational, not technical:

1. Treat DNS records as infrastructure with a defined lifecycle — create and delete them alongside the services they point to
2. Maintain an authoritative inventory of DNS records and reconcile it regularly against active services
3. Monitor for dangling records and respond to them as security incidents
4. Scope cookies and content security policies to minimize the blast radius if a subdomain is compromised
5. Use domain verification mechanisms on external platforms wherever available

The vulnerability is not in the DNS protocol or in cloud platforms. It is in the gap between provisioning and deprovisioning — the operational discipline that keeps DNS records aligned with reality.

Need your application tested for this? Get in touch.