Subdomain Takeover: Finding and Claiming Dangling DNS Records Before Attackers Do

You deprovisioned a Heroku app three months ago and removed the service, but nobody deleted the CNAME record pointing to it. Right now, anyone can spin up a new Heroku app at that address and serve whatever they want from your subdomain. That is subdomain takeover, and it is more common than most security teams expect.

The attack requires no exploitation of a buffer overflow or a novel zero-day. It exploits operational hygiene — specifically, the gap between removing a cloud resource and removing the DNS record that pointed to it.

What Is a Subdomain Takeover?

A subdomain takeover happens when a DNS record (almost always a CNAME) points to an external service endpoint that no longer exists or has been unclaimed. Because the DNS record still resolves, an attacker can register that endpoint on the target service and begin serving content under your domain.

From a browser's perspective, staging.yourcompany.com is a legitimate subdomain of yourcompany.com. Cookies scoped to .yourcompany.com are sent to it. Visitors trust the TLS certificate. Phishing emails linking to it bypass many reputation filters. The damage can range from brand embarrassment to credential theft to session cookie harvesting.

• Understand why dangling CNAME records appear and which services are most vulnerable.
• Enumerate your own subdomains systematically using freely available tools.
• Identify which records are dangling and confirm exploitability.
• Claim or remediate the record before an attacker does.
• Build operational controls to prevent the problem from recurring.

Why Dangling DNS Records Exist in the First Place

DNS changes are often handled by a different team than infrastructure teardowns. A developer provisions a Netlify site for a marketing campaign, asks the DNS admin to add a CNAME, and then three months later quietly deletes the Netlify project. The DNS admin never hears about it.

Infrastructure-as-code helps here, but even Terraform-managed environments accumulate drift. DNS records are rarely included in the same destroy plan as the resource they point to. In fast-moving organizations with many external SaaS integrations, the problem compounds quickly.

The other driver is acquisition and consolidation. When a company buys a smaller team or retires a product line, DNS zones inherited from the acquisition often go unaudited for years.

Which Services Are Most Commonly Exploited

The attack only works on services that allow self-service registration of endpoints. If the target CNAME resolves to a fixed IP address owned entirely by your infrastructure, there is nothing for an attacker to claim. The dangerous pattern is a CNAME pointing to a service where anyone can register a matching hostname.

The most frequently abused platforms include:

• GitHub Pages — if the repository is deleted or made private, the custom domain becomes claimable by anyone who creates a repo with the right name.
• Heroku — deleted apps leave their *.herokuapp.com endpoint available for re-registration.
• Netlify / Vercel — similar pattern: delete the project, and the subdomain endpoint is up for grabs.
• AWS S3 static hosting — if the bucket is deleted, any AWS account can create a bucket with the same name in the same region and serve content via your CNAME. (This is also covered in detail in the context of SSRF vulnerabilities in cloud environments, which share a similar theme of cloud misconfiguration.)
• Azure / GCP storage and CDN endpoints — same class of problem as S3.
• Zendesk, Freshdesk, HubSpot — support and marketing portals with custom subdomain features.
• Fastly, Pantheon, and other CDNs — if the backend is deprovisioned but the CNAME record remains, the CDN edge will return errors or allow a new customer to claim the route.

The community-maintained can-i-take-over-xyz project catalogs hundreds of services and their current takeover status. Check it before spending time on a record — some services have added protections that make the attack no longer viable.

How to Enumerate Your Subdomains

You cannot audit what you have not discovered. Most organizations have far more subdomains than they realize, spread across acquired domains, development environments, and legacy integrations. Start with a broad enumeration before narrowing down to dangling records.

Passive enumeration

Certificate Transparency logs are the most reliable passive source. Every publicly trusted TLS certificate includes its subject alternate names (SANs), and those logs are public and searchable.

# Search crt.sh for all certificates issued to your domain
curl -s "https://crt.sh/?q=%25.yourcompany.com&output=json" \
  | jq -r '.[].name_value' \
  | sort -u

Tools like subfinder aggregate multiple passive sources (VirusTotal, Shodan, DNS Dumpster, SecurityTrails, and others) in one pass:

subfinder -d yourcompany.com -o subdomains.txt

Passive enumeration will not find every subdomain, but it gives you a strong baseline without touching the target's DNS servers directly.

Active DNS brute-forcing

dnsx and massdns can resolve large wordlists against your domain quickly. Use a quality wordlist (SecLists' Discovery/DNS directory is a solid starting point) and a list of fast, reliable resolvers.

# Resolve a wordlist against the target domain
dnsx -d yourcompany.com -w wordlist.txt -o active_subdomains.txt

Combine the passive and active results into a single deduplicated list before moving to the next phase.

Checking for Dangling CNAMEs

Once you have a subdomain list, the goal is to find records that resolve to an external endpoint that returns an error indicating the endpoint is unclaimed.

Manual spot-checking

For a handful of suspicious subdomains, dig is enough to inspect the chain:

dig CNAME staging.yourcompany.com +short
# Returns: something.herokuapp.com.

curl -I https://staging.yourcompany.com
# Returns: 404 or "No such app"

The key signal is an HTTP response from the third-party platform — not a generic DNS NXDOMAIN — that says the endpoint itself does not exist. An NXDOMAIN means the CNAME's target has been deregistered at the DNS level; an application-level 404 from the platform means the DNS resolves but the resource is gone. Both are exploitable, but the application-level case is often more directly claimable.

Automated scanning with nuclei

nuclei with its subdomain-takeover template pack is the most practical way to check hundreds of subdomains in one run:

# Run nuclei takeover templates against your subdomain list
nuclei -l subdomains.txt -t takeovers/ -o takeover_findings.txt

The takeover templates are signature-based: each template knows the specific error string a given service returns when an endpoint is unclaimed (e.g., Heroku returns No such app, GitHub Pages returns a specific 404 page structure). Nuclei matches those signatures and flags the vulnerable records.

Run this regularly — a subdomain that is safe today may become dangling next week when someone deletes a project without touching DNS.

Using subjack or subzy

subjack and subzy are purpose-built for this check and are slightly simpler to run than nuclei if you want a dedicated takeover scanner:

subzy run --targets subdomains.txt --output findings.json

Both tools maintain fingerprint databases similar to can-i-take-over-xyz, so keep them updated.

Claiming the Service Before an Attacker Does

When you find a confirmed dangling record, you have two options: delete the DNS record immediately, or claim the endpoint yourself to prevent anyone else from doing so while you coordinate the cleanup.

Claiming is only appropriate if the service legitimately belongs to your organization and you have authorization to register resources on it. The steps depend on the platform:

• GitHub Pages: Create a repository under your organization's account that matches the expected path, add a CNAME file containing your subdomain, and publish a placeholder page. Then schedule proper DNS cleanup.
• Heroku: Create an app with the matching name, add the custom domain in the Heroku dashboard, and deploy a maintenance page.
• S3: Create a bucket with the exact name and region that the CNAME targets, enable static website hosting, upload a placeholder index.html. This buys you time while DNS is cleaned up.
• Netlify / Vercel: Create a project and configure the custom domain in the platform settings.

In every case, the real fix is deleting the DNS record. Claiming only reduces your window of exposure while the DNS TTL drains and the change propagates.

Do not use TTL as a reason to delay. Reduce the TTL of suspicious records to 60 seconds, make the DNS change, then delete the placeholder resource after the old TTL has expired.

Preventing Future Dangling Records

The technical fix is straightforward; the harder part is keeping clean DNS hygiene as your infrastructure evolves. A few controls that actually work in practice:

Tie DNS changes to infrastructure lifecycle

If you manage infrastructure with Terraform, include DNS records in the same module as the resource they point to. When the resource is destroyed, the record goes with it. This is the most effective single control.

# Terraform pseudostructure: DNS record lives with the resource
resource "heroku_app" "staging" { ... }

resource "aws_route53_record" "staging_cname" {
  name    = "staging"
  type    = "CNAME"
  records = [heroku_app.staging.web_url]
  # Destroyed automatically when heroku_app.staging is destroyed
}

Run subdomain audits on a schedule

Add a weekly CI job that runs your nuclei or subzy scan against your known subdomain list and alerts on any new findings. A finding that surfaces within days of a resource being deprovisioned is easy to fix; one that surfaces six months later is a potential incident.

Maintain a DNS inventory

Keep a spreadsheet or a configuration-management database (CMDB) entry for every external CNAME: what it points to, who owns the resource, and when it was last reviewed. It sounds tedious, but for most organizations the list is shorter than expected. Reviewing it quarterly takes less than an hour.

Set short TTLs on externally-pointed CNAMEs

A 24-hour TTL means an attacker can cache a valid resolution for a day after you fix the DNS record. For CNAME records pointing to third-party SaaS platforms, a TTL of 300 seconds (5 minutes) is more appropriate and makes remediation faster.

Similar operational hygiene considerations apply to other infrastructure-level vulnerabilities. For example, insecure deserialization attacks also thrive in components that have been forgotten or left unpatched — the same organizational pattern that creates dangling DNS records.

Common Pitfalls When Auditing DNS

A few mistakes that can lead you to miss real vulnerabilities or waste time on false positives:

• Assuming NXDOMAIN means safe: An NXDOMAIN on the CNAME target means the third-party DNS record is gone, but it does not mean someone cannot register that hostname on the platform again. Some platforms re-use hostname patterns.
• Ignoring wildcard records: A wildcard DNS record like *.yourcompany.com pointing to a load balancer may mask dangling records in your enumeration. Make sure your scanning resolves specific hostnames, not just relies on wildcard resolution.
• Scanning only once: DNS is not static. Resources are deprovisioned continuously. A one-time audit is better than nothing, but it degrades quickly. Automate the recurring check.
• Missing A records: Subdomain takeover is most commonly associated with CNAMEs, but direct A records pointing to deprovisioned Elastic IP addresses or floating IPs in cloud environments carry the same risk. Include A record auditing in your scope.
• Forgetting non-primary domains: Check every domain your organization owns, including country-code TLDs, acquired company domains, and product domains. Attackers will not limit themselves to your primary domain.

Authorization boundary is also worth flagging: if you are doing this audit as a bug bounty researcher rather than an internal team member, verify the scope carefully before claiming any endpoint. Registering a resource on a third-party service without authorization, even to demonstrate a vulnerability, can cross legal lines depending on jurisdiction and program rules.

On the authentication side, note that a claimed subdomain under your domain can also be used to attack session tokens. A JWT validation weakness combined with a subdomain takeover can create a compounding attack path — another reason to treat dangling DNS as a serious finding, not a cosmetic one.

Wrapping Up: Next Steps

Subdomain takeover is one of the few vulnerability classes where the remediation is genuinely cheap: delete a DNS record. The hard part is finding the records before an attacker does, and building processes so they do not accumulate again.

Here are the concrete actions to take after reading this:

1. Run a passive enumeration now using subfinder and crt.sh against every domain your organization owns. Build a baseline list.
2. Scan that list with nuclei takeover templates and review any flagged findings within 24 hours.
3. Delete or claim any dangling records immediately, prioritizing subdomains under your primary domain and any that have existing user traffic.
4. Add DNS record ownership to your infrastructure teardown checklist so that deprovisioning a resource triggers a DNS review.
5. Schedule a recurring scan in CI, even a simple weekly script, so new dangling records surface quickly rather than months later.

None of these steps require a specialized security team. Any developer with DNS access and an hour of time can close the most obvious exposure. The attackers looking for these records are running automated scanners continuously — your defense needs to be at least as systematic.