Anatomy of a Subdomain Takeover: When Forgotten DNS Gets Hijacked
A subdomain takeover doesn’t require breaching anything. No password to guess, no server to compromise. It just needs a DNS record nobody remembered to delete, pointing at a service nobody’s paying for anymore.
The example below is a composite walkthrough, not a specific real domain we found and are naming. The pattern itself is extremely common and well documented in public security research, common enough that we can show you exactly how it works without pointing at anyone’s actual infrastructure.
How a subdomain takeover actually works
Most companies point subdomains at third-party services using a CNAME record. app.example.com might point to a Heroku app, docs.example.com to a GitHub Pages site, assets.example.com to an S3 bucket. That’s normal and fine, right up until the team stops using that service and deletes the app, the repo, or the bucket, but leaves the DNS record pointing at it.
The DNS record still resolves. It’s still app.example.com in a browser’s address bar. But the resource it points to no longer exists on the provider’s side, and on most cloud platforms, that means anyone can claim it. Register a new Heroku app with the right name, or a GitHub Pages site under the right account, and the dangling subdomain starts serving whatever the new owner puts there, still under the original company’s domain.
This is not a secret technique. Cloud providers publish their own guidance on avoiding it, and security researchers maintain public, crowdsourced lists of exactly which services are vulnerable and what their “unclaimed” error pages look like, because the fingerprints are consistent enough to automate detection at scale.
Walking through the method
Here’s how it actually gets found, step by step, using only public information.
Enumerate subdomains. Certificate Transparency logs are the starting point. Every publicly trusted SSL certificate gets logged publicly, per RFC 6962, which means every subdomain that’s had its own certificate issued is discoverable by searching those logs. This surfaces subdomains that were never linked from the website itself, old staging environments, one-off marketing pages, integrations set up for a project that wrapped up two years ago. The exception is a company relying entirely on a wildcard certificate (*.example.com), which covers every subdomain without naming any of them in the logs. Those get found the older way, by checking a dictionary of common subdomain names against DNS directly.
Check where each one points. For each subdomain, a DNS lookup shows the CNAME record it resolves to. Most point somewhere legitimate and current. A smaller number point at a third-party service.
Look for the error signature. Visiting a subdomain whose target no longer exists usually returns a very specific “not found” page, and the exact wording is a fingerprint. “There isn’t a GitHub Pages site here,” “No such app,” “NoSuchBucket.” Different providers, different wording, same underlying condition: DNS still resolves, nothing legitimate answers.
Confirm before doing anything else. A matching error page is a strong signal, not proof. From here, the responsible next step is reporting it to the domain owner, not attempting to actually claim the resource. Registering the dangling name yourself, even to demonstrate the risk, is taking control of infrastructure that isn’t yours, and that’s a legal and ethical line worth not crossing for a blog post or anything else.
Why this matters even without a hack
A taken-over subdomain isn’t just an embarrassing 404. Whoever claims it can serve real content under the original company’s domain, which means phishing pages that pass every visual trust check a user might run, because the address bar shows the real domain. If the main site sets cookies with an explicit Domain= attribute rather than leaving them scoped to the exact host, the browser sends those same cookies to the hijacked subdomain, which can expose session or authentication tokens too. Search engines and email filters that trust the parent domain extend some of that trust to the subdomain by default.
None of this requires the attacker to touch the company’s actual servers. The vulnerability lives entirely in a DNS record that was never cleaned up.
Would I even know if this happened to me?
Probably not, not on your own. A takeover doesn’t touch your servers, doesn’t trigger a firewall alert, and doesn’t show up in server logs, because your infrastructure was never involved. The only place it’s visible is the DNS record itself and whatever the hijacked subdomain is now serving, and nobody checks either of those unless they’re specifically looking. Most companies find out from a customer, a security researcher, or a journalist, not from their own monitoring.
A quick self-audit
- Pull a full list of subdomains from certificate transparency logs, not just the ones linked from your site or listed in your DNS admin panel from memory.
- Check the CNAME target of each one still resolves to something you actually control or still pay for.
- When decommissioning any service tied to a subdomain, delete the DNS record in the same step, not “eventually.”
- Treat this as a recurring check, not a one-time cleanup. New subdomains and new integrations get added constantly, and each one is a new record that can eventually go stale.
kant.au runs this exact process continuously for every domain you monitor: enumerating subdomains from certificate transparency logs, checking CNAME targets against known vulnerable-service fingerprints, and flagging anything dangling before someone else finds it first. Want to see what’s actually pointing where on your own domain? Start a free 14-day trial and find out.