Subdomain Takeover Detection

Identify subdomains that point to unused third-party services (like GitHub Pages, S3, etc.) which can be claimed by attackers.

Evidence ASSESSED

Checked against: CNAME targets matched against known takeover fingerprints

RED TEAM 0 findings BLUE TEAM control did not hold

Our Subdomain Takeover Checker identifies DNS records pointing at deprovisioned services — dangling CNAMEs that an attacker can claim to serve their own content on your subdomain, with your domain name in the address bar.

What is Subdomain Takeover?

Subdomain takeover happens when a DNS record points at a service that no longer exists, and someone else claims it.

The sequence is routine. A team creates blog.example.com as a CNAME to a hosted platform. Months later the account is closed, the hosted resource disappears, and nobody removes the DNS record. The subdomain now points at an unclaimed name on a platform where anyone can register it.

An attacker who registers that name controls what blog.example.com serves. The browser shows your domain, so visitors see no indication anything is wrong. They can serve phishing pages with your name in the address bar, read cookies scoped to the parent domain, and pass domain validation to obtain a legitimate certificate for your subdomain.

A DNS record pointing at a deprovisioned service
Anyone can claim the unused target on many platforms
The subdomain serves attacker content under your domain name
Cookies scoped to the parent domain may be readable
A valid certificate can be issued for the taken subdomain

Why Subdomain Takeover Matters

The attack requires no exploitation, no vulnerability in your code, and no privileged access. It requires only that a DNS record outlived the service it pointed at, which happens constantly during normal operations.

The impact is disproportionate to the effort. Phishing hosted on your own subdomain defeats the advice users are given about checking the domain. Cookies set on the parent domain are readable from the subdomain, so session tokens can be stolen. Domain-validated certificate issuance succeeds because the attacker genuinely controls what that hostname serves. It remains among the most common findings in bug bounty programmes for exactly these reasons.

Requires no exploitation, only a record that outlived its service
Phishing on your own subdomain defeats domain-checking advice
Parent-domain cookies may be readable from the subdomain
Valid certificates can be issued for the taken hostname
Consistently among the most common bug bounty findings

How This Takeover Checker Works

The tool follows each DNS record and looks for the signatures of an unclaimed service.

Validates the domain input against format and SSRF safety checks
Resolves the subdomain and follows any CNAME chain
Determines whether the final target resolves at all
Requests the target and checks the response for known unclaimed-service signatures
Reports whether the subdomain appears vulnerable to takeover

How to Use the Takeover Checker

Enter a subdomain you own or are authorised to assess
Run the check to follow the record and inspect the target
Review whether the target resolves and what it returns
Treat an NXDOMAIN target or an unclaimed-service page as a finding
Remove the DNS record immediately where a risk is confirmed

Understanding Your Takeover Check Results

Several outcomes indicate different levels of risk:

Field / Value	Meaning
`Target does not exist`	The CNAME points at a name returning NXDOMAIN. High risk on any platform where the name can be re-registered, which covers most hosted services.
`Unclaimed-service page`	The target resolves but returns a provider page indicating no site is configured. A clear takeover signature, since claiming that name is usually self-service.
`Resolves normally`	The target is live and serving the expected content. No takeover risk, though it is still worth confirming the service is one you intend to use.
`No CNAME`	The subdomain uses an A record pointing directly at an address. Lower risk, though a released cloud IP that someone else obtains is a related concern.
`Chained CNAME`	Several aliases in sequence. A break anywhere in the chain creates the same exposure, so the whole chain must be checked rather than only the first hop.
`Third-party platform`	The target belongs to a hosted service. Each such dependency is a potential takeover point if the account is ever closed without removing the record.

Common Problems & How to Fix Them

This is an active vulnerability. On most hosted platforms the unclaimed name can be registered by anyone, immediately giving them control of your subdomain.

Delete the DNS record now. Then audit the entire zone for other records pointing at services you no longer use — where one exists, others usually do.

The provider is reporting that no site is configured for that name, which on most platforms means it is available to claim.

Remove the DNS record. If the subdomain is still needed, re-provision the service properly and confirm it serves your content before leaving the record in place.

Assume the attacker has served content under your name and may have obtained a certificate for the hostname.

Remove the DNS record immediately. Then invalidate all sessions if cookies were scoped to the parent domain, check certificate transparency logs for certificates issued to that hostname, and review whether any content was served that requires customer notification.

The process is wrong rather than any individual record. DNS entries are created by whoever provisions a service and forgotten by whoever decommissions it.

Make removing the DNS record the first step of decommissioning, not the last. Maintain an inventory linking each record to the service and team that own it, and scan the zone on a schedule rather than only after incidents.

Platforms differ. Some prevent re-registration of previously used names, some verify domain ownership before allowing a custom hostname, and some allow anyone to claim anything.

Where the platform behaviour is unclear, treat the record as vulnerable and remove it. The cost of removing an unused record is nothing; the cost of being wrong is significant.

Best Practices

Remove the DNS record before decommissioning the service it points at
Scan your full subdomain inventory for dangling records on a schedule
Maintain a record of which team and service own each DNS entry
Check the entire CNAME chain, not just the first hop
Re-verify after any cloud account closure or platform migration
Treat uncertain cases as vulnerable and remove the record
Include DNS cleanup in your service decommissioning checklist

Security Recommendations

Treat a confirmed dangling record as an active vulnerability requiring same-day removal
Restrict which subdomains carry authentication cookies, so a takeover cannot yield session tokens
Monitor certificate transparency logs for certificates issued to your subdomains by parties you do not recognise
Publish CAA records limiting which certificate authorities may issue for your domain
Assume a taken subdomain has served malicious content and respond accordingly rather than simply removing the record
Only test domains you own or are explicitly authorised to assess

Frequently Asked Questions

It occurs when a DNS record points at a service that no longer exists and someone else claims that target. They then control what your subdomain serves, with your domain name shown in the address bar.

A record is created pointing at a hosted service, the service is later removed or the account closed, and the DNS record is left behind. The target name becomes available for anyone to claim on most platforms.

Serve phishing pages under your domain name, read cookies scoped to the parent domain including session tokens, obtain a valid certificate for the hostname through domain validation, and damage your reputation with content you cannot control.

Delete the DNS record. If the subdomain is still needed, re-provision the service properly and confirm it serves your content before leaving the record in place. Then audit the rest of the zone, since these rarely occur singly.

Less commonly, but the analogous risk exists. A released cloud IP address that someone else obtains gives them whatever that record points at. CNAMEs to hosted platforms are the far more common case.

Make DNS record removal the first step of decommissioning rather than an afterthought, maintain an inventory linking records to owners, and scan your zone on a schedule rather than only after an incident.

Because it requires no exploitation — only a record that outlived its service, which happens constantly during normal operations. Creating DNS records is someone job; removing them usually is not.