Subdomain Takeover

This Vulnerability Explain post covers Subdomain Takeover. It is an infrastructure flaw rather than a code bug, but it lets attackers host content on your trusted domain – perfect for phishing, cookie theft, and bypassing security controls. Let’s see how a forgotten DNS record becomes a serious risk.

What is Subdomain Takeover?

Subdomain Takeover happens when a DNS record for a subdomain points to an external service (a cloud host, CDN, or SaaS) that is no longer claimed by the organization. An attacker registers that service and gains control of content served from your subdomain.

Imagine blog.example.com was set up on a hosting platform with a CNAME, then the hosting account was deleted but the DNS record left behind. The subdomain now points to an unclaimed resource. An attacker signs up for that platform, claims the same resource name, and now controls blog.example.com.

How does Subdomain Takeover work?

A subdomain takeover follows this lifecycle:

• Service Provisioned
  • A subdomain is pointed via CNAME or other record at a third-party service.
• Service Decommissioned
  • The underlying service is removed, but the DNS record is not cleaned up – it now dangles.
• Dangling Record Discovered
  • An attacker enumerates subdomains and spots the record pointing to an unclaimed resource.
• Attacker Claims the Resource
  • The attacker registers the same resource name on the provider, capturing the subdomain.
• Abuse
  • The attacker serves content on your trusted subdomain for phishing, cookie theft, or bypassing same-site protections.

Subdomain takeover is a hygiene problem with outsized impact. The trust users and systems place in your domain is exactly what the attacker inherits.

How subdomain takeover works: a dangling DNS record points to a service an attacker can claim.

Tools and Techniques for Subdomain Takeover Testing

Testing centers on enumerating subdomains and checking for dangling records and fingerprints.

Manual Testing Methodologies

• Subdomain Enumeration – Gather subdomains from DNS, certificate transparency, and passive sources.
• Dangling Record Detection – Identify CNAMEs pointing to providers with unclaimed resources.
• Fingerprint Matching – Match provider error pages (the telltale “no such bucket/app” responses) to known takeover signatures.
• Safe Claim Verification – Confirm takeover potential carefully and responsibly, without disrupting service.

Automated Scanning Tools

• subfinder – Fast passive subdomain enumeration.
• Nuclei – Ships templates that detect takeover fingerprints.
• subjack – Checks subdomains for takeover conditions.
• tko-subs – Detects and helps confirm dangling records.

Subdomain Takeover Protection Mechanisms

Best Practices for Secure Coding

• Decommission DNS With the Service
  • Description: Remove DNS records as part of tearing down any service.
  • Benefits: There is never a dangling record to claim.
  • Implementation Tip: Make DNS cleanup a required step in decommissioning runbooks.
• Inventory DNS Continuously
  • Description: Maintain an accurate, monitored inventory of all DNS records and their targets.
  • Benefits: Dangling records are caught quickly.
  • Implementation Tip: Automate scanning for unresolved or unclaimed targets.
• Claim Before Pointing
  • Description: Only create the DNS record after the target resource exists and is owned.
  • Benefits: Avoids windows where the record points at nothing.
  • Implementation Tip: Tie record creation to verified resource ownership.

Best Practices for Organizations

• Asset Management
  • Keep a single source of truth for domains and services.
  • Assign ownership for every subdomain.
• Continuous Monitoring
  • Run scheduled subdomain takeover scans.
  • Alert on new dangling records.
• Provider Hygiene
  • Track which third-party services back which subdomains.
  • Reclaim or remove resources promptly when offboarding.

Top Subdomain Takeover payloads used by Security Researchers

As a security researcher, knowing the most common payloads helps you detect and prevent these attacks. Use this knowledge ethically and only on systems you are authorized to test. Some sample payloads are shown below.

// Enumerate then check CNAME targets
subfinder -d example.com -silent | httpx -silent

// A dangling CNAME example
blog.example.com.  CNAME  myapp.herokuapp.com  (app no longer exists)

// Typical takeover fingerprint (provider error)
"There is no app configured at that hostname"
"NoSuchBucket"  /  "The specified bucket does not exist"

// Scan for takeover with nuclei
nuclei -l subdomains.txt -t http/takeovers/

Real-World Example: Phishing From a Trusted Subdomain

An organization had once hosted a campaign site at promo.example.com via a cloud platform, then shut the site down but left the CNAME in DNS pointing to the platform.

An attacker enumerating subdomains found the dangling record, signed up on the same platform, and claimed the resource name. They then hosted a convincing login page at promo.example.com – a genuinely trusted domain – and used it to phish employees and capture cookies scoped to example.com.

The fix removed the dangling record and added continuous takeover monitoring. Subdomain takeover shows that security is not only in your code – forgotten infrastructure can hand attackers your good name.

Vulnerable and secure code of Subdomain Takeover

The following example shows the contrast between vulnerable and secure code for Subdomain Takeover. It helps you see how the flaw creeps into real code and the changes that shut it down.

🥺 Vulnerable Code:

# Vulnerable: a dangling DNS record left after decommissioning
# DNS zone for example.com:
promo   IN  CNAME  example-promo.herokuapp.com.
# The Heroku app "example-promo" was deleted, but this record remains.
# Anyone who registers "example-promo" on Heroku now controls
# https://promo.example.com

• The service was removed but its DNS record was left pointing at an unclaimed target.
• An attacker can claim that target and serve content on the trusted subdomain.

😎 Secure Code:

# Secure: decommissioning runbook removes DNS first, plus monitoring
# 1) Remove the DNS record as part of teardown:
#    (delete the promo CNAME from the example.com zone)
# 2) Continuously scan for dangling records, e.g.:
subfinder -d example.com -silent | nuclei -t http/takeovers/
# 3) Only create a CNAME AFTER the target resource exists and is owned.

• DNS records are removed as a required step when a service is decommissioned.
• Automated scanning catches any dangling record before an attacker can claim it.

Conclusion

Subdomain Takeover is a reminder that your attack surface includes infrastructure you have forgotten about. Remove DNS records as part of every decommissioning, keep a monitored inventory of records and their targets, only point a record at a resource you already own, and scan continuously for dangling entries. A tidy DNS zone protects the trust your domain carries.