Subdomain Takeover: How Attackers Hijack Your Forgotten Subdomains

What Is Subdomain Takeover?

Subdomain takeover is a class of vulnerability that occurs when a subdomain's DNS record points to a resource that no longer exists. When an organization creates a subdomain like blog.example.com and configures a CNAME record pointing to a third-party service like GitHub Pages or Heroku, the subdomain resolves to that service. If the organization later removes the blog from the third-party service but forgets to delete the CNAME record, the subdomain becomes "dangling" — pointing to an unclaimed resource that anyone can register.

An attacker who discovers this dangling record can register the corresponding resource on the third-party platform and serve arbitrary content under the victim's legitimate subdomain. Because the subdomain belongs to the organization's domain, users and browsers trust it implicitly.

How the Attack Works

The attack follows a predictable sequence. First, the attacker enumerates the target organization's subdomains using DNS brute-forcing, certificate transparency logs, or passive DNS databases. Next, they check each subdomain for indicators of dangling records — error pages from cloud providers, NXDOMAIN responses from the service's nameservers, or specific error messages indicating an unclaimed resource.

# Step 1: Enumerate subdomains using certificate transparency
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[].name_value' | sort -u

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

# Step 3: Verify the Heroku app doesn't exist
curl -s https://staging.example.com
# Returns: "No such app" — vulnerable to takeover

Once the attacker confirms the resource is unclaimed, they register it on the hosting platform. Within minutes, the victim's subdomain resolves to content controlled entirely by the attacker — complete with a valid TLS certificate if the platform provides one automatically.

Dangling CNAMEs Explained

A CNAME (Canonical Name) record is a DNS alias that points one domain name to another. When the target of a CNAME is decommissioned, the record becomes "dangling" because it references a destination that no longer exists. This is the most common vector for subdomain takeover, though A records, NS delegations, and MX records can also create takeover opportunities in certain configurations.

Commonly Vulnerable Services

Not all cloud services are equally susceptible to subdomain takeover. The vulnerability depends on whether the service allows new users to claim a hostname that was previously in use. Services with confirmed takeover risk include:

• GitHub Pages — Returns a 404 page for unclaimed repositories. Attacker creates a repo and configures the custom domain.
• Heroku — Returns "No such app" for decommissioned apps. Attacker creates a new app and adds the custom domain.
• AWS S3 — Returns "NoSuchBucket" for deleted buckets. Attacker creates a bucket with the same name in any region.
• Azure — Multiple Azure services (Traffic Manager, App Service, Cloud Services) are vulnerable when resources are deleted without removing DNS records.
• Shopify — Returns a branded error page for unclaimed stores. Attacker creates a store and claims the domain.
• Fastly, Pantheon, Surge.sh, Fly.io — Various CDN and hosting platforms with similar claim-based domain ownership models.

Real-World Impact

The consequences of subdomain takeover extend far beyond defacement. Because the hijacked subdomain is part of the organization's legitimate domain, attackers can:

• Host phishing pages that appear to belong to the organization, complete with valid TLS certificates and the organization's own domain in the URL bar.
• Steal cookies set on the parent domain. If example.com sets cookies with Domain=.example.com, the hijacked staging.example.com can read them.
• Bypass Content Security Policy restrictions that trust *.example.com as a script source.
• Send emails from the organization's domain if MX records are also affected, enabling highly convincing spear-phishing campaigns.
• Damage brand reputation by serving malware, offensive content, or scam pages under the organization's domain name.

Detection Methods

Detecting subdomain takeover vulnerabilities requires a combination of DNS enumeration, service fingerprinting, and continuous monitoring:

• Certificate Transparency monitoring — Track all certificates issued for your domain to discover subdomains you may not be aware of.
• DNS zone analysis — Export your DNS zone files and identify all CNAME, A, and NS records. Cross-reference each target with active service inventories.
• HTTP response fingerprinting — Known error pages from cloud services indicate unclaimed resources. Tools like Subjack, Can-I-Take-Over-XYZ, and Nuclei templates automate this check.
• Passive DNS databases — Historical DNS data reveals subdomains that may have been created and forgotten.

Prevention Strategies

Effective prevention is primarily an operational discipline. The technical fix is straightforward — remove DNS records when you decommission services. The challenge is maintaining that discipline across large organizations with distributed infrastructure management.

• DNS hygiene procedures — Establish a process that requires DNS record removal as part of any service decommission. Include DNS cleanup in your infrastructure runbooks.
• Centralized DNS management — Use infrastructure-as-code for DNS records so that service teardown automatically includes DNS cleanup.
• Domain ownership verification — Where possible, use DNS TXT record verification to prove domain ownership to third-party services, making unauthorized claims harder.
• Cookie scoping — Never set cookies on the apex domain if subdomain isolation is important. Use __Host- cookie prefix to restrict cookies to the exact origin.
• Regular audits — Schedule quarterly DNS audits that compare your DNS records against your active service inventory.

Automated Monitoring

Manual DNS audits are necessary but not sufficient. Organizations need continuous, automated monitoring to catch dangling records as they appear — especially in environments where developers can create and destroy cloud resources independently.

ShieldGraph's asset discovery engine continuously enumerates your organization's subdomains using multiple data sources, checks each one for takeover indicators, and alerts your security team when dangling records are detected. This automated approach catches vulnerabilities within hours of their introduction rather than waiting for the next quarterly audit.