WSTG - Latest

Home > Latest > 4-Web Application Security Testing > 02-Configuration and Deployment Management

Subdomain Takeover

ID
WSTG-CONF-10

Summary

A successful exploitation of this kind of vulnerability allows an adversary to claim and take control of the victim’s subdomain. This attack relies on the following:

  1. The victim’s external DNS server subdomain record is configured to point to a non-existing or non-active resource/external service/endpoint. The proliferation of XaaS (Anything as a Service) products and public cloud services offer a lot of potential targets to consider.
  2. The service provider hosting the resource/external service/endpoint does not handle subdomain ownership verification properly.

If the subdomain takeover is successful, a wide variety of attacks are possible (serving malicious content, phishing, stealing user session cookies, credentials, etc.). This vulnerability could be exploited for a wide variety of DNS resource records including: A, CNAME, MX, NS, TXT etc. In terms of the attack severity, an NS subdomain takeover (although less likely) has the highest impact, because a successful attack could result in full control over the whole DNS zone and the victim’s domain.

GitHub

  1. The victim (victim.com) uses GitHub for development and configured a DNS record (coderepo.victim.com) to access it.
  2. The victim decides to migrate their code repository from GitHub to a commercial platform and does not remove coderepo.victim.com from their DNS server.
  3. An adversary discovers that coderepo.victim.com is hosted on GitHub and claims it using GitHub Pages and their own GitHub account.

Expired Domain

  1. The victim (victim.com) owns another domain (victimotherdomain.com) and uses a CNAME record (www) to reference the other domain (www.victim.com –> victimotherdomain.com)
  2. At some point, victimotherdomain.com expires, becoming available for registration by anyone. Since the CNAME record is not deleted from the victim.com DNS zone, anyone who registers victimotherdomain.com has full control over www.victim.com until the DNS record is removed or updated.

Test Objectives

  • Enumerate all possible domains (previous and current), including wildcard-covered names.
  • Identify any forgotten or misconfigured domains, and any dangling-service signature not covered by a known response fingerprint.
  • Where a takeover is confirmed feasible, assess whether the parent application’s cookies, CORS policy, OAuth redirect validation, or CSP allowlist extend trust to the claimed subdomain.

How to Test

Black-Box Testing

Subdomain takeover testing follows three phases: subdomain enumeration, automated fingerprint-based detection, and manual validation.

A dangling DNS record occurs when a DNS entry points to an external resource that no longer exists or has been deprovisioned. For example, a CNAME record pointing to a GitHub Pages site that the owner deleted still resolves, but the underlying resource is unclaimed. An attacker can register that resource and take control of the subdomain.

Subdomain Enumeration

Use subfinder to discover subdomains for the target domain: subfinder -d victim.com -o subdomains.txt

This produces a list of subdomains to use in the detection phase.

Resolve and filter the list to only subdomains with a CNAME, NS, or MX record before fingerprinting, since these are the record types most commonly left dangling. dnsx can do this in bulk: dnsx -l subdomains.txt -cname -resp -o resolved.txt

Fingerprint-Based Detection

Fingerprint-based detection works by comparing each subdomain’s HTTP response against a database of known vulnerable service responses. The can-i-take-over-xyz project maintains this database, cataloging the specific response strings returned by service providers such as GitHub Pages, AWS S3, Heroku, and Fastly when a resource is unclaimed.

Use subzy for a quick initial scan: subzy run --targets subdomains.txt

Follow up with nuclei using the dedicated takeover templates for a more accurate result: nuclei -l subdomains.txt -t takeovers/

A positive result from either tool indicates that a subdomain’s response matched a known vulnerable fingerprint, suggesting a dangling DNS record pointing to an unclaimed resource on a third-party service.

For example, a subdomain pointing to an unclaimed GitHub Pages site returns the following response:

HTTP/1.1 404 Not Found
...
<p>There isn't a GitHub Pages site here.</p>

This specific string is listed in can-i-take-over-xyz as the GitHub Pages fingerprint. When subzy or nuclei matches this response, it flags the subdomain as potentially vulnerable.

Manual Validation

Automated tools produce false positives. Validate each finding manually before reporting it.

  1. Confirm the DNS record and where it points: dig CNAME subdomain.victim.com
  2. Confirm the response matches the expected fingerprint for that service provider as listed in can-i-take-over-xyz: curl -i http://subdomain.victim.com
  3. Confirm the resource is unclaimed on the service provider’s platform. Do not claim it.

For NS records specifically, check whether a delegated nameserver is unregistered: dig NS subdomain.victim.com, then check whether the returned nameserver’s own domain is available for registration. An unregistered nameserver domain means anyone can register it and answer DNS queries for the delegated zone, the highest-impact takeover variant.

Cloud-Specific Takeovers

Major cloud providers and PaaS/JAMstack services have distinct takeover patterns worth specific attention. This list changes as providers patch verification gaps, so cross-check current status against can-i-take-over-xyz before reporting:

  • AWS S3: A CNAME pointing to an S3 bucket URL (for example, bucket.s3.amazonaws.com) where the bucket no longer exists returns a NoSuchBucket response. Anyone who creates a bucket with the same name in any AWS account can claim the subdomain.
  • Azure: Dangling CNAMEs pointing to deprovisioned Azure resources such as App Services, Azure CDN/Front Door endpoints, or Traffic Manager profiles can be claimed by registering the same resource name in a different Azure subscription.
  • GCP: Similar patterns exist for Cloud Storage buckets and Firebase Hosting endpoints.
  • GitHub Pages: covered above under GitHub; still one of the most common findings in the wild.
  • Vercel and Netlify: A CNAME pointing to a project domain (e.g. *.vercel.app, *.netlify.app) that has been deleted or renamed can typically be re-claimed by creating a new project with the matching name.
  • Cloudflare Pages / Workers custom domains: dangling CNAMEs to *.pages.dev can sometimes be claimed depending on account-level protections; verify current behavior, as Cloudflare has tightened this over time.
  • Heroku: A CNAME to *.herokuapp.com for an app that has been deleted returns a “No such app” response and can be re-claimed by creating an app with the matching name (subject to Heroku’s naming rules).
  • Fastly and Shopify: both have historically appeared in takeover reports for dangling custom-domain configurations; treat any hit against their fingerprints in can-i-take-over-xyz the same as the providers above.

Dangling Service Signatures

Beyond the response-string fingerprints already covered above, a dangling record can also surface through signals that are not themselves an HTTP body match:

  • A NXDOMAIN, SERVFAIL, or empty A record answer when resolving a service’s own hostname that a target’s CNAME points to (for example, the CNAME target itself fails to resolve) is a stronger signal than an HTTP fingerprint match, since it shows the upstream resource is gone entirely rather than just returning a “not found” page.
  • TLS certificate errors (hostname mismatch, certificate for an unrelated domain) on a subdomain that should be served by a specific provider can indicate the provider no longer has a certificate provisioned for that hostname, consistent with a deprovisioned resource.
  • Provider-specific error pages that don’t match a known can-i-take-over-xyz fingerprint yet (new or less common services) still warrant manual investigation using the same dig/curl validation steps; treat the fingerprint database as a starting point, not an exhaustive list.

Wildcard CNAME Risk

A wildcard DNS record (for example, *.victim.com CNAME target.example-paas.com) that points to a takeover-prone service multiplies the impact of a single dangling configuration: any subdomain an attacker chooses to request (anything.victim.com, admin.victim.com, login.victim.com) resolves through the wildcard, so claiming the target resource grants control over an unbounded set of subdomains rather than one. When enumerating, check for wildcard records explicitly (dig CNAME nonexistent-random-string.victim.com, comparing the result against a known real subdomain), since wildcard-covered names are often absent from passive-recon subdomain lists and only appear by testing an arbitrary label directly.

Impact Beyond Content Control

A successful takeover is not limited to serving attacker-controlled content on the reclaimed subdomain; because the subdomain shares the parent domain’s trust boundary in several browser and protocol mechanisms, the impact can extend to:

  • Cookies: a cookie scoped without the Secure/host-only restriction (for example, set with a Domain attribute covering the parent, or without one and thus scoped to a sibling subdomain via related-domain behavior) can be read or overwritten from the claimed subdomain, enabling session hijacking against the main application.
  • CORS: if the main application’s CORS policy allows the origin pattern that includes the claimed subdomain (a wildcard subdomain match, or a reflected Origin check that trusts *.victim.com), the attacker can make authenticated cross-origin requests against the real application from the claimed subdomain.
  • OAuth: an OAuth client configuration with a redirect URI on the claimed subdomain (or a redirect URI validation that only checks the parent domain suffix) lets the attacker receive authorization codes or tokens intended for the legitimate application.
  • CSP: a Content-Security-Policy on the main application that allowlists the parent domain with a wildcard (*.victim.com) as a script or connect source lets the attacker serve script or exfiltrate data from a trusted-by-policy origin.

When reporting a takeover finding, check whether any of these apply to the specific subdomain claimed, since they change the finding from “content spoofing on an isolated subdomain” to “compromise of the main application’s session/authorization/script trust.”

Gray-Box Testing

The tester has the DNS zone file available, which means DNS enumeration is not necessary. The testing methodology is the same.

Remediation

To mitigate the risk of subdomain takeover, the vulnerable DNS resource record(s) should be removed from the DNS zone. Continuous monitoring and periodic checks are recommended as best practice.

Tools

References

Watch Star