What Is Subdomain Takeover and How to Check If You Are Vulnerable
How to Prevent Subdomain Takeover: 7 Practical Steps for DevOps Teams
What Is Subdomain Takeover and How to Check If You Are Vulnerable
Most founders and engineering teams treat DNS as something you set up once and forget. That is exactly what attackers are counting on.
Subdomain takeover is one of the most underrated vulnerabilities in startup and SMB security. It does not require sophisticated exploits or zero-days. It requires finding a DNS record pointing to a service that no longer exists and claiming that service before you do. The result is an attacker-controlled page living under your own domain, inheriting your brand trust, your cookies, and sometimes your users' sessions.
This article explains what subdomain takeover is, why it happens, how attackers find and exploit it, and the exact steps you should take to find and fix vulnerable subdomains before they become a problem.
What Is Subdomain Takeover?
Subdomain takeover happens when a DNS record for a subdomain points to an external service that has been deprovisioned, deleted, or never fully set up, and an attacker claims that external service to take control of the subdomain.
The classic scenario looks like this:
Your team spins up
staging.yourcompany.comand points it to a Heroku app.The Heroku app is eventually deleted, but nobody removes the DNS record.
The CNAME for
staging.yourcompany.comstill points toyour-app.herokuapp.com.An attacker creates a new Heroku app at that exact subdomain.
That attacker now controls everything served at
staging.yourcompany.com.
From a browser's perspective, the page at staging.yourcompany.com is legitimately yours. There is no warning. The attacker can serve phishing pages, steal cookies scoped to *.yourcompany.com, send authenticated requests on behalf of your users, or use it as a trusted platform for malware distribution.
Why It Happens So Often
The root cause is almost always poor DNS hygiene combined with fast-moving teams. Subdomains get created for staging environments, product launches, marketing campaigns, third-party integrations, and trial SaaS tools. When those things get removed or replaced, the DNS records stay. Nobody owns the cleanup process.
Common services that are frequently involved in subdomain takeovers include:
Heroku (deprovisioned apps)
GitHub Pages (deleted repositories or pages configurations)
Netlify and Vercel (removed deployments)
AWS S3 and CloudFront (deleted buckets or distributions)
Fastly, Pantheon, Shopify, HubSpot, Zendesk, and dozens more
Any SaaS tool your team connected to a custom subdomain
The problem scales with team size and time. The more people who have DNS access, the more subdomains accumulate. The older the company, the more forgotten records exist.
What Attackers Can Do With a Taken Subdomain
The impact varies based on what the subdomain is and what trust it inherits from the parent domain.
Cookie theft and session hijacking. Cookies set with the Domain=.yourcompany.com attribute are accessible from any subdomain, including a taken one. An attacker serving content at a taken subdomain can read those cookies via JavaScript.
Phishing with built-in legitimacy. A page at login.yourcompany.com or support.yourcompany.com is far more convincing than any lookalike domain. Users and email clients see a valid certificate for your domain.
Bypassing Content Security Policy (CSP). If your CSP allowlists *.yourcompany.com, a taken subdomain is a trusted origin. An attacker can use it to load malicious scripts on your main site.
Email spoofing assistance. In some configurations, a taken subdomain can be used to assist in phishing email campaigns that appear to originate from your organization.
Reputation and SEO damage. Search engines may index malicious or low-quality content served under your domain, affecting your domain authority and brand trust.
How to Check If You Are Vulnerable
Step 1: Enumerate All Your Subdomains
Before you can audit for dangling records, you need a complete list of your subdomains. Most teams are surprised how many they find.
Sources to check:
Your DNS registrar and DNS management panel (Route 53, Cloudflare, Namecheap, etc.)
Certificate transparency logs (crt.sh is a free public resource)
Your version control history and CI/CD configuration files
Your team's internal documentation and runbooks
Old infrastructure notes, Notion pages, or Confluence docs
Free tools for enumeration: subfinder, amass, dnsx, and passive CT log searches via crt.sh.
Step 2: Identify Dangling CNAME Records
A dangling CNAME is a DNS record that points to an external hostname that no longer resolves to an active resource. These are the primary vehicle for subdomain takeover.
For each subdomain in your list:
Check if it has a CNAME record:
dig CNAMEstaging.yourcompany.comResolve the CNAME target and check if it returns a valid response
Look for error responses from the target platform that indicate the resource no longer exists
Indicator responses to watch for:
Heroku:
No such appGitHub Pages:
There isn't a GitHub Pages site hereNetlify:
Not Found - Request IDAWS S3:
NoSuchBucketFastly:
Fastly error: unknown domain
Any of these responses from a CNAME target means the subdomain is potentially claimable by an attacker.
Step 3: Check for A Records Pointing to Released IPs
Less common but still relevant. If a subdomain points via A record to a cloud IP address that has since been released and reassigned to another customer, the same takeover risk exists. This is harder to enumerate manually but worth including in automated scanning.
Step 4: Validate Against Known-Vulnerable Services
The can-i-take-over-xyz repository on GitHub maintains a community-sourced list of services and their takeover fingerprints. It is a useful reference when auditing your subdomains against specific platforms.
Cross-reference each dangling CNAME target against the list to confirm whether that service is exploitable.
Step 5: Prioritize by Risk
Not all dangling subdomains carry the same risk. Prioritize based on:
Subdomains with names suggesting user-facing use:
login,app,account,portal,support,apiSubdomains that inherit sensitive cookies from the parent domain
Subdomains mentioned in your CSP allowlist
Subdomains that appear in publicly visible links or indexed by search engines
A forgotten dev-test-2021.yourcompany.com pointing to a deleted Heroku app is still a risk, but a dangling auth.yourcompany.com is a critical one.
How to Fix Subdomain Takeover Vulnerabilities
Remove dangling DNS records immediately
If the service is gone and the subdomain is no longer needed, delete the DNS record. This is the cleanest fix and removes the risk entirely.
Reclaim the external resource
If the subdomain is still in use or you are not ready to remove it, recreate the resource on the target platform under the same identifier. For example, recreate the deleted Heroku app at the same app name. This removes the attacker's ability to claim it.
Implement DNS hygiene processes
Before decommissioning any external service, remove the DNS record first
Audit DNS records as part of offboarding any third-party tool
Assign ownership of DNS records to specific team members or a shared infrastructure registry
Run subdomain enumeration on a recurring schedule (monthly at minimum)
Monitor certificate transparency logs
New TLS certificates issued for your subdomains will appear in CT logs within minutes of issuance. Monitoring these logs gives you real-time visibility into new subdomains being created and can alert you to unexpected certificate issuance on subdomains you did not set up.
Tools like certspotter, crt.sh RSS feeds, or purpose-built ASM platforms can automate this.
Subdomain Takeover Audit Checklist
Enumerate all subdomains from DNS, CT logs, and internal records
Identify CNAME records for each subdomain
Resolve CNAME targets and check for platform-specific error responses
Cross-reference dangling CNAMEs against known-vulnerable service fingerprints
Prioritize subdomains by risk (user-facing, cookie scope, CSP allowlist)
Remove DNS records for deprovisioned services
Reclaim any external resources that cannot be immediately removed
Establish a pre-decommissioning DNS cleanup process
Set up CT log monitoring for unexpected certificate issuance
Schedule recurring subdomain audits
Conclusion
Subdomain takeover does not require an attacker to break anything. It requires finding something your team left unlocked. The fix is simple: keep your DNS records in sync with your actual infrastructure and build the habit of cleaning up before you turn something off. A full subdomain audit takes a few hours the first time. Maintaining it takes minutes per quarter. That is a small investment compared to the cost of an attacker hosting a phishing page under your own domain name.
