June 26, 2026 · Ironimo Security Team

Subdomain Takeover: How to Discover, Test, and Prevent Dangling DNS Vulnerabilities

A subdomain that used to point to your Heroku app still lives in DNS — but the Heroku app was deleted six months ago. An attacker registers that Heroku app name, claims the subdomain, and suddenly staging.yourcompany.com serves their content under your brand. They can issue phishing pages, steal session cookies scoped to *.yourcompany.com, bypass your Content Security Policy, and strip your HSTS preload. The subdomain never changes in your users' eyes. Only the content behind it does.

This is subdomain takeover. It is one of the most underrated vulnerabilities in the attack surface of any company that has used cloud services, run experiments, or spun up and torn down environments over time. Most organisations have at least one dangling DNS record. Many have dozens.

Why Subdomain Takeover Is a Serious Risk

The impact goes well beyond defacement. Consider what an attacker controls once they claim a subdomain under your apex domain:

• Phishing at first-party trust. Users see login.yourcompany.com in the address bar. There is no visual indicator that anything is wrong. Credential harvesting becomes trivial.
• Cookie theft. Cookies set with Domain=.yourcompany.com are sent to all subdomains, including the one the attacker now controls. Session tokens, auth cookies, and CSRF tokens are all in scope.
• CSP bypass. If your Content-Security-Policy whitelists *.yourcompany.com as a trusted script source, an attacker serving a taken-over subdomain can inject arbitrary JavaScript into your main application by getting it to load a script from their controlled endpoint.
• HSTS and STS bypass. HSTS preloading applies to the apex domain and its subdomains. A taken-over subdomain can serve content over HTTP, downgrading the security posture of users who navigate to it directly.
• TLS certificate issuance. Most CAs will issue a certificate for a domain if the requester can serve a challenge file from it. An attacker controlling the subdomain can obtain a valid TLS certificate for it, making their phishing page indistinguishable from a legitimate HTTPS site.

How It Happens: Abandoned Cloud Service CNAMEs

The root cause is always the same: a DNS record is left pointing to a third-party service after the resource on that service has been deleted. The typical lifecycle looks like this:

1. Engineer creates api-staging.yourcompany.com CNAME myapp-staging.herokuapp.com
2. Staging environment is decommissioned. The Heroku app is deleted.
3. Nobody deletes the DNS record.
4. Heroku app name myapp-staging is now available for anyone to register.
5. Attacker registers the Heroku app and claims the subdomain.

This pattern applies to a wide range of services. The following table shows the most commonly exploited platforms and how to identify a vulnerable CNAME target:

The can-i-take-over-xyz project maintains a comprehensive, community-updated list of services with their takeover status and fingerprint strings. It is the definitive reference for this class of vulnerability.

Detection: Finding Dangling DNS Records

Detection has two phases: enumerate all subdomains, then check each one for a dangling CNAME pointing to an unclaimed resource.

Phase 1 — Subdomain Enumeration

subfinder is the fastest passive enumeration tool. It aggregates results from certificate transparency logs, DNS datasets, and passive DNS providers:

# Install
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# Run against target
subfinder -d example.com -o subdomains.txt -silent

# With provider API keys configured for deeper coverage
subfinder -d example.com -all -o subdomains.txt

amass provides both passive and active enumeration, including brute force and DNS zone walking where zone transfers are misconfigured:

# Passive only (safe, no direct queries to target)
amass enum -passive -d example.com -o subdomains-amass.txt

# Active enumeration with brute force
amass enum -active -brute -d example.com -o subdomains-amass-active.txt

# Merge and deduplicate results
cat subdomains.txt subdomains-amass.txt | sort -u > all-subdomains.txt

For an accurate picture, combine at least two enumeration sources. Certificate transparency logs (via crt.sh or Censys) alone often surface subdomains that passive DNS databases miss.

Phase 2 — CNAME Chain Analysis and Fingerprinting

Once you have a subdomain list, check each entry for a CNAME that resolves to an unclaimed third-party endpoint. Do this manually for a small scope or with an automated tool for anything larger.

Manual CNAME inspection with dig:

# Check for CNAME records
dig CNAME staging.example.com +short
# Returns: myapp-staging.herokuapp.com.

# Verify whether the target resolves
dig A myapp-staging.herokuapp.com +short
# Returns nothing (NXDOMAIN) — potential takeover candidate

# HTTP fingerprint
curl -s -o /dev/null -w "%{http_code}" https://staging.example.com
# Returns 404 with "No such app" body — confirmed dangling

subjack automates this at scale. It checks CNAMEs against a fingerprint database and flags potentially vulnerable subdomains:

# Install
go install github.com/haccer/subjack@latest

# Run against subdomain list
subjack -w all-subdomains.txt -t 100 -timeout 30 -ssl -c /path/to/fingerprints.json -v

# Output vulnerable findings only
subjack -w all-subdomains.txt -t 100 -timeout 30 -ssl -o vulnerable.txt

nuclei with the subdomain takeover template pack provides the most up-to-date fingerprint coverage and integrates with a broader scanning workflow:

# Update nuclei templates
nuclei -update-templates

# Run subdomain takeover templates only
nuclei -l all-subdomains.txt -t /root/nuclei-templates/http/takeovers/ -o takeover-findings.txt

# With rate limiting and headers
nuclei -l all-subdomains.txt \
  -t /root/nuclei-templates/http/takeovers/ \
  -rate-limit 50 \
  -H "User-Agent: Mozilla/5.0" \
  -o takeover-findings.txt \
  -json

The nuclei takeover templates cover 50+ services and are updated frequently to match current fingerprint strings. They are the most reliable automated detection method available.

Exploitation Demo: What a Takeover Looks Like

This walkthrough is deliberately high-level and educational. The goal is to understand the attacker's perspective so you can assess real risk during a pentest or bug bounty engagement — not to compromise systems you do not have permission to test.

Assume the following has been confirmed during enumeration:

• docs.example.com has a CNAME pointing to example-docs.netlify.app
• Fetching https://docs.example.com returns Netlify's "Not found" error page
• The Netlify site name example-docs is unregistered

An attacker's steps to claim it:

1. Create a free Netlify account.
2. Create a new site. Under site settings, set the Netlify subdomain to example-docs.
3. Deploy any content to the site — a static HTML file is sufficient.
4. Netlify now serves that content at example-docs.netlify.app.
5. Because docs.example.com still CNAMEs to example-docs.netlify.app, the attacker's content is now served at docs.example.com.

No credentials to the victim organisation are needed. No exploitation of a software vulnerability is required. The attack succeeds entirely because a DNS record was not cleaned up.

The attacker can now add a custom domain in Netlify and request a TLS certificate for docs.example.com via Let's Encrypt — which will be issued successfully because the attacker controls the HTTP challenge endpoint. The resulting page is served over HTTPS with a valid certificate, fully under the victim's domain.

Prevention: DNS Record Hygiene and Decommissioning Process

Subdomain takeover is entirely preventable. The fix is procedural, not technical:

Delete DNS before deleting the service

The cardinal rule: remove the DNS record first, then decommission the cloud resource. This eliminates the window during which the record is dangling. Most organisations do it backwards — delete the app, forget the DNS record — which is why the vulnerability persists.

Establish a decommissioning checklist

Any decommissioning runbook for cloud services must include a DNS audit step:

# Check all CNAMEs pointing to a service before decommissioning
# Example: find all records pointing to Heroku before deleting apps
grep -i "herokuapp.com" dns-export.txt

# Verify each one resolves before deletion
while IFS= read -r subdomain; do
  cname=$(dig CNAME "$subdomain" +short)
  if [[ -n "$cname" ]]; then
    echo "$subdomain -> $cname"
  fi
done < subdomains.txt

Export and audit DNS regularly

Export your full DNS zone at least monthly and run subjack or nuclei against every CNAME record. Automate this in CI or as a scheduled scan. The list of cloud services your organisation has ever used is longer than anyone remembers.

Use service-specific protections where available

Some cloud providers have introduced mechanisms to reduce takeover risk:

• Azure introduced the "Domain Verification" step for App Service custom domains — requiring a TXT record that proves ownership before a custom domain can be added. Ensure this is enabled on all App Service deployments.
• GitHub Pages supports verified custom domains via a TXT record at the apex, preventing another GitHub user from claiming the CNAME target.
• AWS does not offer automatic protections for S3 static hosting — bucket names are globally unique and first-come-first-served.

Implement continuous monitoring

One-time audits are insufficient. Subdomains are created constantly by engineering teams, often without a corresponding decommissioning plan. Integrate subdomain takeover scanning into your continuous attack surface monitoring:

• Run subfinder + nuclei takeover templates on a weekly or daily schedule against all registered apex domains.
• Alert on any new CNAME pointing to a known cloud-service pattern that returns an unclaimed fingerprint.
• Track subdomain inventory alongside infrastructure — not just in DNS, but in your CMDB or asset management system.

Real-World Disclosed Cases

Subdomain takeover is not theoretical. High-profile organisations have been caught by it in public bug bounty disclosures and security research:

Microsoft (2021). Security researchers identified multiple Microsoft subdomains pointing to unclaimed Azure resources. Several *.microsoft.com subdomains resolved to Azure endpoints that could be registered. Microsoft has since tightened its DNS hygiene process, but the incident illustrated that even organisations with mature security programmes accumulate dangling records at scale.

Starbucks. A researcher discovered that russia.starbucks.com pointed to an unclaimed Heroku app. The researcher was able to claim the Heroku app name and demonstrate control over the subdomain, serving arbitrary content at a Starbucks-branded URL. This was disclosed responsibly and awarded a bug bounty.

Uber. Multiple Uber subdomains were found pointing to unclaimed resources across Heroku, GitHub Pages, and other platforms as part of their HackerOne programme. The recurring pattern across Uber's asset base reflected rapid growth and team turnover — common in any fast-scaling engineering organisation.

US government (.gov) domains. The Cybersecurity and Infrastructure Security Agency (CISA) published an advisory noting that multiple federal agency subdomains were vulnerable to takeover, primarily via Azure and AWS. The advisory recommended immediate DNS audits across all .gov apex domains.

The pattern is consistent: organisations grow quickly, teams create subdomains for experiments and integrations, those experiments end, and nobody deletes the DNS records. The attack surface accumulates invisibly.

Summary: What to Do This Week

Subdomain takeover requires no exploit, no credentials, and no technical sophistication to execute. It requires only that your DNS outlives your cloud resources. The remediation is equally straightforward:

• Run subfinder against all your apex domains and pipe the output through nuclei's takeover templates today.
• Immediately remove any CNAME pointing to an unclaimed third-party resource.
• Rewrite your decommissioning runbook to put DNS deletion before resource deletion.
• Schedule a weekly automated scan so new dangling records are caught within days, not years.

An hour of DNS hygiene work now eliminates an entire class of vulnerability permanently.