Subdomain Takeover: What It Is and How to Prevent It

The Mechanics of Subdomain Takeover

The vulnerability requires three conditions:

1. 1You have a DNS record (typically a CNAME) pointing subdomain.yourdomain.com to an external service endpoint.
2. 2The external service resource (a GitHub Pages repo, Heroku app, S3 bucket, etc.) no longer exists or is unclaimed.
3. 3The external platform allows anyone to register that same endpoint name.

The attack flow:

The attacker does not need access to your DNS — they only need access to the external platform, which is often free and open to registration.

Real-World Examples by Platform

GitHub Pages

GitHub Pages is the most commonly exploited vector. When a company shuts down a project or renames a GitHub organization, CNAME records pointing to orgname.github.io become vulnerable.

Indicators:

If you see this 404 from GitHub, the subdomain is likely claimable.

Heroku

Heroku apps have URLs like appname.herokuapp.com. When an app is deleted but the DNS CNAME pointing to it remains, anyone can create a new Heroku app with the same name:

Amazon S3

S3 static website hosting uses bucket names that must match the subdomain. If assets.example.com points to assets.example.com.s3-website-us-east-1.amazonaws.com and the bucket is deleted, any AWS user can create a bucket named assets.example.com:

This is particularly dangerous for subdomains serving JavaScript files — the attacker can inject malicious scripts into every page that loads assets from that URL.

Other Vulnerable Platforms

A comprehensive list of vulnerable services and their fingerprints is maintained at can-i-take-over-xyz.

How Attackers Exploit a Taken-Over Subdomain

Once an attacker controls a subdomain, several attack vectors open:

Phishing — The attacker creates a convincing login page at accounts.yourcompany.com or login.yourcompany.com. Users trust the domain. Password reuse and credential harvesting follow.

Cookie theft — Cookies set with Domain=.yourcompany.com (note the leading dot) are sent by the browser to all subdomains including the taken-over one. If your application sets session cookies this way, the attacker can harvest them.

XSS via asset injection — An attacker who controls static.yourcompany.com can serve malicious JavaScript that any page loading resources from that subdomain will execute.

CORS abuse — If your API allowlists *.yourcompany.com in its CORS policy, the attacker''s origin becomes a trusted CORS origin, enabling cross-origin requests to your API with victim credentials.

Email spoofing — Subdomain control can sometimes be used to pass SPF/DKIM checks if mail infrastructure uses that subdomain, enabling email spoofing from a trusted-looking address.

Tools to Scan for Vulnerable Subdomains

Subzy

Nuclei with Subdomain Takeover Templates

Subjack

Enumerating Your Subdomains First

Before you can scan for takeovers, you need a comprehensive list of your subdomains:

How to Fix Vulnerable Subdomains

The fix depends on whether you still need the subdomain:

If You No Longer Need the Subdomain

Delete the DNS record. This is the correct fix and the only permanent one:

If You Still Need the Subdomain

Re-create the resource at the cloud provider before deleting and recreating the DNS record:

1. 1Create a new Heroku app / GitHub Pages repo / S3 bucket with the same endpoint name
2. 2Verify it returns a valid 200 response
3. 3Update or confirm the DNS record is pointing to it correctly

GitHub Pages — Verify Your Custom Domain

GitHub provides domain verification that prevents others from claiming your organization''s domain:

1. 1Go to your GitHub organization Settings → Pages
2. 2Add and verify your apex domain (e.g., yourcompany.com)
3. 3GitHub will refuse to serve GitHub Pages content for your verified domain from any repository you do not own

Preventing Future Subdomain Takeovers

Maintain a DNS inventory — keep a record of every DNS record and the resource it points to. When you decommission a cloud resource, the DNS record deletion should be part of the offboarding checklist.

Automate DNS record cleanup — use infrastructure-as-code (Terraform, Pulumi) where DNS records are created and destroyed together with their associated cloud resources. If the resource is deleted, the DNS record is deleted in the same terraform destroy.

Use short TTLs on CNAME records — a TTL of 300 seconds (5 minutes) means if a DNS record is compromised, propagation of the fix is fast.

Monitor for DNS changes — set up alerts when DNS records change unexpectedly. ZeriFlow monitors your DNS configuration continuously and alerts you via Slack, Discord, or email when records change or when new vulnerability indicators appear.

Quarterly subdomain audits — run your subdomain enumeration and takeover scan every quarter. Cloud infrastructure changes frequently, and a record that was safe six months ago may now point to a deleted resource.

What to Do If You''ve Already Been Taken Over

1. 1Immediately delete the CNAME DNS record to break the takeover
2. 2Rotate any cookies that may have been harvested — force logout all active sessions
3. 3If the subdomain was serving JavaScript or other assets, audit your CSP to determine which pages loaded content from it
4. 4Notify affected users if session theft is possible
5. 5File an abuse report with the platform (GitHub, Heroku, etc.) to have the attacker''s account removed
6. 6Conduct a full DNS audit to identify any other at-risk records

ZeriFlow scans your DNS records as part of its 80+ security checks, identifying dangling CNAMEs and subdomain configurations that suggest takeover risk. Run a free scan at zeriflow.com and see your full DNS security picture in under 60 seconds.