DNS Takeover Attacks: Why Your Forgotten Subdomains Are a Liability

Every organization accumulates DNS records over time. Marketing launches a campaign microsite on Heroku. Engineering spins up a staging environment on AWS. A contractor sets up a demo on Azure. The projects end, the cloud resources get deleted, but the DNS records stay. That orphaned CNAME record pointing at a deprovisioned hostname is not just clutter. It is an open door for an attacker to serve arbitrary content under your domain.

Subdomain takeover attacks are not theoretical. They have been used against major companies including Microsoft, Starbucks, and dozens of organizations that disclosed incidents through bug bounty programs. The attack is straightforward, requires no sophisticated tooling, and the consequences range from phishing campaigns that bypass email filters to full session hijacking via cookie theft.

What a Subdomain Takeover Actually Is

A subdomain takeover occurs when a DNS record, almost always a CNAME, points to an external service that no longer exists. The CNAME for staging.example.com might resolve to example-staging.herokuapp.com. If the Heroku app behind that hostname has been deleted, the CNAME still resolves, but Heroku's routing layer no longer has a registered app for that hostname. This is a dangling record.

The critical detail is what happens next. Most cloud providers allow any authenticated user to claim an unclaimed hostname. An attacker creates a new Heroku app, configures it to respond to example-staging.herokuapp.com, and Heroku happily routes traffic for that hostname to the attacker's app. Because the CNAME from staging.example.com still points there, visitors to staging.example.com now see attacker-controlled content, served under your domain, with a valid TLS certificate that the attacker obtained through the provider's automated certificate provisioning.

How Teams Create Dangling Records

The typical sequence follows a predictable pattern. A team requests a cloud resource for a project. Someone with DNS access creates the CNAME. The project ships, runs for weeks or months, then gets decommissioned. The person who tears down the cloud resource is not the same person who created the DNS record, or they simply forget that step. The record stays indefinitely because nobody audits DNS.

This happens more often than you might expect because of how organizations manage infrastructure:

• Staging and preview environments that get created per branch or per sprint and never fully cleaned up
• Marketing campaign sites hosted on platforms like Netlify, Vercel, or GitHub Pages, launched for a product release and forgotten within months
• Legacy documentation sites that were once hosted on ReadTheDocs, GitBook, or an S3 static site bucket
• Partner or vendor integrations with CNAMEs pointing to third-party SaaS platforms that the organization no longer uses
• Development and QA environments on cloud providers with ephemeral infrastructure that rotates frequently

The risk compounds in organizations that use wildcard DNS records. A wildcard entry like *.example.com pointing to a cloud load balancer means every possible subdomain resolves to that target. If the load balancer is decommissioned, every subdomain becomes vulnerable simultaneously.

Real-World Impact

The damage from a successful subdomain takeover extends well beyond hosting a defacement page. Attackers exploit the trust that browsers and email systems place in your domain.

Credential phishing under your domain. An attacker serves a login page on portal.example.com that looks identical to your real login. The URL is on your domain, the TLS certificate is valid, and your users have no reason to suspect it is malicious. Phishing filters that check domain reputation will not flag it because the domain is legitimate.

Cookie theft via parent domain scoping. If your application sets cookies on .example.com (note the leading dot, which scopes the cookie to all subdomains), every request to the attacker-controlled subdomain includes those cookies. This means session tokens, CSRF tokens, and any other cookies scoped to the parent domain are sent directly to the attacker. This can lead to full account takeover without any user interaction beyond visiting the subdomain.

SEO poisoning. Search engines index the attacker's content under your domain. If the attacker hosts spam or malware, your domain's search ranking suffers. Google may flag your entire domain as compromised, displaying warnings to users in search results.

Email spoofing enhancement. If the attacker can set TXT records or influence DNS for the subdomain (possible with some provider configurations), they can strengthen spoofed emails that appear to come from your domain by passing SPF checks on the subdomain.

Which Cloud Providers Are Vulnerable

Not every provider is equally susceptible. The vulnerability depends on whether the provider allows new users to claim hostnames that were previously in use. Here is the current landscape:

Provider	Vulnerable	Mechanism
Heroku	Yes	Custom domains can be claimed by any app
GitHub Pages	Yes	CNAME file in repo claims the hostname
AWS S3 (website hosting)	Yes	Bucket name matching subdomain can be created in any account
AWS Elastic Beanstalk	Yes	Environment CNAMEs are globally unique and reclaimable
Azure (various services)	Yes	App Service, Traffic Manager, CDN hostnames claimable
Fastly	Yes	Any Fastly customer can add an unclaimed domain
Netlify	Partial	Domain verification added but older configurations still at risk
Vercel	Mitigated	Requires DNS TXT verification for custom domains
Cloudflare Pages	No	Domain ownership verification required

The pattern is clear: older platforms that were built before subdomain takeover was a well-known attack tend to allow hostname claiming without verification. Newer platforms and updated configurations on existing platforms are moving toward mandatory domain ownership verification, but the transition is incomplete.

Detection Methods

Finding dangling DNS records before an attacker does requires a systematic approach. The process has three stages: subdomain enumeration, CNAME resolution, and fingerprint matching.

Step 1: Enumerate all subdomains. You need a complete inventory. Certificate Transparency logs are the most reliable source because every TLS certificate issued for your domain is publicly logged. Tools like crt.sh, subfinder, and amass aggregate CT logs, DNS brute-forcing, and passive DNS datasets. Your DNS provider's zone export is the authoritative source for records you control, but CT logs will reveal subdomains created through other means.

Step 2: Resolve CNAME chains. For each subdomain, resolve the full CNAME chain using dig or nslookup. You are looking for CNAMEs that point to external provider hostnames. A record like staging.example.com CNAME staging-example.herokuapp.com is a candidate. Resolve the final target and check if it returns an IP address or an NXDOMAIN.

Step 3: Fingerprint the response. Even if the CNAME resolves to an IP, the service behind it might be unclaimed. Each provider has a characteristic response when a hostname is not configured. Heroku returns a page stating "There's nothing here, yet." GitHub Pages returns a 404 with specific HTML. AWS S3 returns a NoSuchBucket XML response. Tools like subjack and nuclei maintain fingerprint databases that automate this matching.

A practical detection command sequence looks like this:

Use dig staging.example.com CNAME +short to get the CNAME target. Then curl -sI https://staging.example.com to check the HTTP response. If the CNAME points to a known provider hostname and the HTTP response matches the provider's "not found" fingerprint, you have a dangling record.

Remediation and Cleanup

Once you identify dangling records, the fix is straightforward but requires coordination:

1. Delete the DNS record immediately. If the cloud resource is gone and there is no plan to recreate it, remove the CNAME. This is the only guaranteed fix. Do not wait for a maintenance window. A dangling record is an active vulnerability.
2. If the resource needs to exist, reclaim it first. If you plan to recreate the service, create the cloud resource and configure the hostname before an attacker can. Then update the DNS record to point to the correct target.
3. Audit parent domain cookie scoping. Check if any of your applications set cookies on .example.com instead of the specific subdomain like app.example.com. Broad cookie scoping multiplies the damage of any subdomain takeover. Tighten cookie domains to the most specific scope possible.
4. Review wildcard DNS records. If you have a wildcard entry, evaluate whether it is truly necessary. Replace it with explicit records for each subdomain that needs to resolve.
5. Verify the cleanup. After deleting records, confirm they no longer resolve using dig from multiple locations. DNS propagation delays mean the old record might still resolve from cached resolvers for hours.

Prevention: Making This a Process, Not a One-Time Fix

Cleaning up existing dangling records solves today's problem. Preventing new ones requires process changes:

Maintain a DNS record registry. Every DNS record should have a documented owner, purpose, and the cloud resource it points to. This can be a spreadsheet, a Confluence page, or a dedicated tool. The key requirement is that it is consulted when decommissioning infrastructure. When someone deletes a cloud resource, the checklist must include "remove associated DNS records."

Automate quarterly DNS audits. Schedule a recurring task that enumerates all subdomains, resolves their CNAME targets, and flags records pointing to provider hostnames that return error pages. This should run automatically and file tickets for any findings. Quarterly is a reasonable cadence for most organizations. High-change environments should audit monthly.

Use providers with domain verification. When choosing cloud platforms for new projects, prefer providers that require domain ownership verification (TXT record or equivalent) before accepting a custom hostname. Cloudflare Pages and Vercel both enforce this. This eliminates the takeover vector entirely because an attacker cannot verify ownership of your domain.

Implement Infrastructure as Code for DNS. Managing DNS through Terraform, Pulumi, or similar tools ties DNS records to the infrastructure lifecycle. When a Terraform resource is destroyed, the associated DNS record is destroyed with it. This eliminates the human error of forgetting to clean up records because the records and resources are managed as a unit.

Add CNAME validation to your monitoring. Your uptime monitoring should include checks that verify CNAME targets are responding with expected content, not provider error pages. A synthetic check that loads each subdomain and asserts on expected page content will catch takeovers quickly if prevention fails.

Subdomain takeover is one of those vulnerabilities that sits at the intersection of DNS management, cloud operations, and security. No single team owns it, which is precisely why it persists. The fix is not technical complexity but organizational discipline: track what you create, clean up what you decommission, and verify regularly that nothing slipped through.

Scan your domain for dangling DNS records and takeover risk →