The Subdomain Someone Else Already Owned
The subdomain was cdn-assets.redacted.example. It belonged to a media technology company — a large operation with hundreds of subdomains spread across multiple cloud providers, CDN configurations, and legacy infrastructure accumulated over a decade of acquisitions and platform migrations.
I found it during routine DNS enumeration, and something about it caught my attention. Not what it was serving. What it was not serving.
The Dead End That Wasn't
Most subdomains resolve to a web server that returns a page, an API response, or at least a redirect. Some return a connection timeout or a refused connection. Those are all normal.
This one returned something different. A generic error page from a cloud provider, telling me the requested resource did not exist.
HTTP/1.1 404 Not Found
Server: <cloud-provider>
Content-Type: text/html
<html>
<head><title>404 Not Found</title></head>
<body>
<p>The specified resource does not exist.</p>
</body>
</html>
This was not a 404 from the company's application. This was the cloud provider itself saying: nothing is here. No application. No configuration. No account has claimed this resource.
That distinction matters enormously.
Following the CNAME Chain
The subdomain had a CNAME record pointing to a cloud provider resource: cdn-assets.redacted.example resolved to redacted-media.cloud-provider.example. When that cloud resource was deleted, the DNS record was left behind — still routing traffic to the cloud provider, which now had nothing to serve. This is the classic subdomain takeover pattern: a dangling CNAME pointing to a deprovisioned resource that anyone can reclaim.
The Claim
Cloud providers let customers choose resource identifiers when provisioning services. These identifiers become part of the DNS name that the CNAME points to. When a resource is deleted, the identifier is released back into the pool. Nothing prevents another account from registering the same identifier.
I needed to verify whether the resource was genuinely claimable. I opened a standard account on the cloud provider and attempted to create a resource with the matching identifier.
It worked. No verification. No ownership check. The identifier was available, and the platform let me have it.
The moment the resource was provisioned, the CNAME chain completed itself. DNS queries for cdn-assets.redacted.example resolved through the CNAME to the cloud provider, and the cloud provider now routed those requests to my newly created resource.
I uploaded a simple proof-of-concept text file:
This resource is controlled by an external security researcher.
Subdomain takeover proof-of-concept.
Contact: [redacted]
Visiting cdn-assets.redacted.example in a browser now displayed my content, served under the company's domain, with a valid TLS certificate that I had provisioned through the cloud provider's automated certificate system.
Why This Is Worse Than It Looks
A subdomain serving a text file does not sound alarming. But the implications of controlling a subdomain under a trusted domain extend far beyond hosting static content.
Cookie Scope
Cookies set with a domain scope of .redacted.example are sent to every subdomain, including cdn-assets.redacted.example. An attacker controlling this subdomain can read session cookies, authentication tokens, and any other cookies scoped to the parent domain. They can also set cookies on the parent domain — a technique that enables session fixation attacks against the main application.
TLS Certificate Legitimacy
The attacker does not need to present a self-signed or fraudulent certificate. Cloud providers offer automated TLS certificate provisioning. Because the attacker controls the DNS resolution (through the dangling CNAME), domain validation succeeds, and a legitimate, browser-trusted certificate is issued for the subdomain.
From the user's perspective, the padlock icon is green. The certificate is valid. The domain is familiar. There is nothing to indicate that the page is not operated by the company.
Phishing Under a Trusted Domain
A login page at cdn-assets.redacted.example/login would appear entirely legitimate to most users. The domain belongs to the company. The certificate is valid. Internal employees, customers, and partners would have little reason to question it — especially if the attacker replicates the company's visual design.
Content Security Policy Bypass
Many applications configure Content Security Policies that whitelist their own domain and subdomains. If the CSP allows *.redacted.example, the attacker's subdomain becomes a trusted content source. They can host malicious scripts that the main application will load and execute.
OAuth and Redirect URI Abuse
If the dangling subdomain was ever registered as an OAuth redirect URI — common for CDN and asset subdomains used during development — the attacker can intercept authorization codes and access tokens during the OAuth flow.
How This Happens
The root cause is a gap in the decommissioning process. When the media company decided to stop using that particular cloud resource — perhaps the CDN was migrated to a different provider, or the project was shut down — someone deleted the cloud resource but did not remove the DNS record.
This is not negligence. It is a process failure that is remarkably common in organizations of any significant size. Consider the lifecycle:
- A development team provisions a cloud resource for a new project
- The infrastructure team creates a DNS CNAME record pointing to it
- The project launches, runs for months or years
- The project is decommissioned or migrated
- The cloud resource is deleted
- Nobody remembers to delete the DNS record — or the person who would is on a different team, or has left the company, or the DNS zone is managed by a third party
Steps 1 through 5 involve the team that owns the project. Step 6 requires coordination with whoever manages DNS. In large organizations, these are often different groups with different ticketing systems and different priorities. The result: thousands of DNS records accumulate, many pointing to resources that no longer exist.
The Scale of the Problem
After confirming the takeover on the initial subdomain, I expanded the scope. The company had over three hundred subdomains. I resolved each one, followed the CNAME chains, and checked whether the target resources existed.
I found four additional dangling CNAMEs. Three pointed to the same cloud provider with different deprovisioned resources. One pointed to a different cloud platform entirely — a hosting service that had been discontinued years earlier, and the domain space had been reopened for registration.
Five subdomains, all claimable. Some had been dangling for what DNS record timestamps suggested was over two years.
Remediation
The fix is straightforward but requires discipline:
Delete DNS records before cloud resources. Or simultaneously. Never delete the resource and leave the DNS record in place, even temporarily. "I'll clean up the DNS later" is how dangling records are born.
Maintain a DNS inventory. Every CNAME record should be mapped to the cloud resource it points to, the team that owns it, and the project it supports. When a project is decommissioned, the inventory flags the DNS records for removal.
Audit regularly. Automated scans of DNS zones that resolve every record and check for error responses from cloud providers. A 404 from a cloud provider on a CNAME target is a finding, not a false positive.
Use reserved identifiers. Some cloud providers allow reserving resource names even after deletion, preventing reuse by other accounts. Where available, enable this.
Monitor for unexpected content. If a subdomain that should serve a CDN suddenly starts serving different content, something has gone wrong. Monitoring catches both external takeovers and internal misconfigurations.
The media company remediated all five dangling records within forty-eight hours of receiving the report. They also initiated a broader DNS audit across their other domains and subsidiaries.
The Takeaway
Subdomain takeovers are not sophisticated attacks. They require no exploitation of software vulnerabilities, no bypassing of firewalls or intrusion detection systems. They exploit a process gap — the failure to synchronize DNS lifecycle with resource lifecycle.
The attacker does not break in. They walk through a door that was left pointing to a room that no longer exists, build a new room behind it, and suddenly they are inside the house. From the outside, the door looks the same as it always did.
In an era where organizations routinely manage hundreds or thousands of subdomains across multiple cloud providers, this gap is not the exception. It is the default state for any organization that has not specifically built processes to prevent it.
The DNS record is a pointer. When it points to nothing, it is not harmless. It is an invitation.