How Subdomain Takeover Works

The attack requires two conditions: a DNS record pointing to an external service, and that service being unclaimed or deleted. The typical sequence:

  1. Your team creates blog.example.com as a CNAME pointing to example.github.io
  2. Your team deletes the GitHub Pages site but forgets to remove the DNS record
  3. The CNAME still points to example.github.io, but that resource is unclaimed
  4. An attacker creates a GitHub Pages site at the same URL, claiming the resource
  5. Now blog.example.com serves the attacker's content

Cookie scope: Because the attacker's page loads under your domain, JavaScript on that page can read cookies scoped to .example.com β€” including session cookies from your main application, if they're not HttpOnly.

Commonly Vulnerable Services

Any service that maps a domain to an account-level resource is potentially vulnerable when the resource is deleted but the DNS record remains:

  • GitHub Pages β€” *.github.io CNAMEs to deleted repos
  • AWS S3 β€” *.s3.amazonaws.com CNAMEs to deleted buckets
  • Azure β€” various *.azurewebsites.net, *.cloudapp.net services
  • Heroku β€” *.herokuapp.com CNAMEs to deleted apps
  • Fastly, Shopify, Zendesk, Intercom β€” all have CNAME-based custom domain setup

subdomain.center and can-i-take-over-xyz: The GitHub repository EdOverflow/can-i-take-over-xyz maintains a list of services and their takeover vulnerability status, including fingerprint strings to identify vulnerable endpoints.

What an Attacker Can Do

  • Phishing: Serve a login page that looks legitimate β€” it's on your domain, browsers show no warning, and it may have a valid TLS certificate (Let's Encrypt doesn't verify DNS ownership)
  • Cookie theft: JavaScript running on the takeover page can read non-HttpOnly cookies scoped to the parent domain
  • CSP bypass: If your CSP trusts *.example.com, attacker-controlled content on a takeover subdomain passes your CSP
  • CORS abuse: If your API trusts *.example.com origins, requests from the takeover subdomain receive valid CORS responses
  • OAuth redirect abuse: OAuth apps registered with redirect URIs matching *.example.com wildcards can be exploited via a takeover subdomain

Finding Vulnerable Subdomains

terminal bash 
# Step 1: Enumerate subdomains
subfinder -d example.com -o subdomains.txt
amass enum -d example.com -o subdomains.txt

# Step 2: Check for dangling CNAMEs
subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -ssl

# Step 3: Manual CNAME check
dig CNAME blog.example.com
# If CNAME target returns NXDOMAIN β€” potentially takeable
host -t CNAME staging.example.com

Prevention

  • Delete DNS records before decommissioning resources β€” this is the root cause. Make DNS record cleanup part of your decommission checklist.
  • Avoid wildcard CORS and OAuth redirect URIs β€” https://*.example.com in trusted origins dramatically increases the impact of any takeover.
  • Use HttpOnly on session cookies β€” prevents JavaScript on a takeover page from stealing them.
  • Inventory all DNS records and their associated resources β€” many organizations have hundreds of forgotten subdomain records.

Ongoing Monitoring

Subdomain takeover is a continuous risk β€” new services are onboarded and decommissioned regularly. Automated monitoring tools can alert when a subdomain resolves to an unclaimed resource:

  • nuclei β€” has templates specifically for subdomain takeover fingerprinting
  • dnsReaper β€” monitors DNS records for dangling CNAMEs continuously
  • Cloud asset inventory tools (AWS Config, GCP Asset Inventory) β€” alert when DNS records reference non-existent cloud resources

Harden Your Application Against Takeover Impact

AquilaX DAST scans your application for CORS misconfigurations, cookie security settings, and other vulnerabilities that amplify subdomain takeover impact.

Start Free Scan