Subdomain Takeover: How a Deleted Cloud Resource Can Hijack Your Domain

Subdomain takeover is one of those vulnerabilities that sounds unlikely until you understand exactly how it happens — at which point it becomes clear why it's still found in production environments at large, well-resourced companies.

The Setup: A Dangling CNAME

It starts innocently: a team points a subdomain — say, blog.example.com — at a third-party platform like GitHub Pages or Heroku, using a CNAME record. Later, the project ends and someone deletes the GitHub Pages site or Heroku app, but nobody removes the CNAME record pointing to it.

The Takeover

Many platforms let anyone claim an unused project name. An attacker who finds that dangling CNAME can register the exact same resource name on the third-party platform — and suddenly their content is being served under blog.example.com, with your domain's trust and, often, your valid SSL certificate.

What It's Used For

A taken-over subdomain can host phishing pages that look completely legitimate (since the URL really is yours), serve malware, or bypass domain-based security checks and allowlists that assume anything under your domain is trustworthy.

Prevention Is Simple, Once You Know

The fix is straightforward: whenever a third-party-hosted project is decommissioned, delete the DNS record pointing to it in the same step, not as an afterthought. Periodically auditing your DNS zone for CNAME records pointing at deleted or unclaimed resources closes the gap for good.

A realistic example

A marketing team spins up a landing page on a static hosting platform, points `promo.example.com` at it via CNAME, the campaign ends after a month, and someone deletes the hosting project — but nobody removes the CNAME record, because DNS changes usually require a different team or a change-request process that gets skipped for something that 'isn't important anymore.' Weeks or months later, an attacker who routinely scans for exactly this pattern registers the same project name on that hosting platform, and `promo.example.com` now serves their content, under the company's own domain and, often, a valid SSL certificate.

Common mistakes that create this exposure

Deprovisioning a cloud resource (a storage bucket, a hosting project, a load balancer) without a checklist step to also remove the DNS record pointing at it — this is almost always a process gap, not a technical one, which is why recurring subdomain audits catch what manual deprovisioning steps miss.

Check for Dangling Records

Nexora Shield's Subdomain Takeover Checker tests a subdomain's CNAME target against known vulnerable service fingerprints to flag this exact risk.