Three years ago someone set up status.yourcompany.com pointing at a hosted status page. The vendor was replaced, the account was cancelled, and the DNS record stayed.
That record still resolves. It points at a hostname on the vendor's platform that is now unclaimed, and anyone can go and claim it. When they do, they control content served from your domain, with your name on it and a valid certificate.
This post is how the situation arises, why it is worse than it sounds, and how to find yours. For whoever owns DNS, which at most companies is nobody in particular.
The mechanism
A subdomain takeover needs two things: a DNS record pointing at a third-party service, and that service no longer recognising the name.
status.yourcompany.com. CNAME yourcompany.statuspage-vendor.io.
If the account behind yourcompany.statuspage-vendor.io is cancelled, the vendor frees that hostname. An attacker registers an account, claims that same hostname, and now your CNAME resolves to their content.
The vulnerable shape is any platform that assigns you a hostname on a shared domain and lets anyone claim an unused one. That is most of them: static site hosts, status pages, help desks, documentation platforms, marketing and landing page tools, form builders, CDN endpoints, and cloud storage buckets referenced by name.
It also happens with dangling A records pointing at a cloud IP you released, where an attacker cycling instances in the same region can eventually acquire it. Harder, and it happens.
Why it is worse than a defaced page
The instinct is that a marketing subdomain does not matter much. The damage is mostly not about the content.
Cookies scoped to the parent domain. If anything on your main domain sets cookies with Domain=.yourcompany.com, they are sent to every subdomain, including the one an attacker now controls. That can include session tokens.
OAuth redirect allowlists. Many are configured with a wildcard or with a list that includes subdomains. An attacker controlling one can receive an authorization code intended for you.
Content Security Policy. If your CSP allows scripts from *.yourcompany.com, the attacker can now serve scripts your main application will execute.
Phishing with real credibility. A login page on your actual domain, with a valid certificate issued automatically by the hosting platform. Every signal a user is taught to check passes.
Email and reputation. Depending on your SPF and DMARC configuration, a controlled subdomain can be leveraged toward sending mail that looks legitimate.
So the finding is rarely "somebody can put a page on a subdomain". It is usually a path to session data or credentials.
Finding yours
Enumerate your DNS records, then check which ones point somewhere nobody owns.
# every CNAME in a zone, from the authoritative export
# then for each target, check whether it resolves and what it says
for name in $(cat subdomains.txt); do
target=$(dig +short CNAME "$name" | head -1)
[ -z "$target" ] && continue
code=$(curl -s -o /tmp/body -m 10 -w "%{http_code}" "https://$name/")
echo "$name -> $target [$code]"
grep -qiE "no such app|there isn't a github pages site|domain not found|NoSuchBucket" /tmp/body \
&& echo " ^^ CANDIDATE TAKEOVER"
done
The tell is a vendor error page rather than a DNS failure. If the name does not resolve at all, it is dead and harmless. If it resolves and the platform says it does not recognise the hostname, that is a claimable name. Each provider has its own fingerprint, and the public fingerprint lists used by tooling such as subjack and nuclei are a reasonable starting point.
Do this across every zone you own, including the domains acquired with a company three years ago that nobody has looked at since. Those are where the findings are.
Preventing it
Delete the DNS record first, before cancelling the service. This is the whole prevention, and it is an ordering rule rather than a technology. Cancel first and there is a window where the name is claimable; delete the record first and there is no window at all.
Put it in your vendor offboarding checklist, because that is the process where this is lost.
Give every DNS record an owner and an expiry. A record with no owner is one nobody will remove. Managing DNS as code, in a repository with a review process, gets you this for free: the commit says who added it and why, and a stale record shows up in review.
Scan continuously, not once. New records are created constantly, often by people outside the team that owns DNS. A weekly automated check against your zones costs little and catches the record added last Tuesday.
Reduce the blast radius. Scope cookies to the exact host rather than the parent domain where you can. Avoid wildcard subdomains in OAuth redirect allowlists and in CSP. Then a takeover is embarrassing rather than dangerous.
Wildcard records deserve their own review. A *.yourcompany.com CNAME to a platform means every unclaimed name under your domain is potentially claimable. It is convenient and it is a standing exposure.
The concession
Most takeover findings are low impact, and a programme that treats every dangling CNAME as critical will exhaust the people who have to fix them. A record pointing at a decommissioned marketing microsite, with host-scoped cookies, a strict CSP and no wildcard in your OAuth configuration, is genuinely minor.
So triage on the amplifiers rather than on the takeover: are cookies scoped to the parent domain, does CSP trust subdomains, do OAuth redirects. Those three answers turn the same finding into either a cleanup task or an urgent one, and knowing which is the difference between a useful report and noise.
The implication
DNS records are created by whoever needs one and removed by nobody, because removal is not part of any process that has an owner.
That asymmetry is the root of this, and it is why the fix is a checklist item rather than a tool: delete the record before you cancel the service. Everything else here is detection for the ones where that did not happen, which is all of the ones you have right now.
