Subdomain takeover: how a forgotten DNS record gets hijacked

A subdomain takeover happens when a name you control in DNS still points at a third-party service you no longer control. The DNS record is a promise — "this hostname is served by that provider" — and when the provider side of the promise disappears but the record stays, anyone who can re-register that provider resource inherits your hostname. The result is an attacker serving their content from a subdomain that still carries your name and, often, your users' trust.

The mechanism: a record that outlives its target

Most takeovers hinge on a CNAME, but ALIAS and delegated NS records have the same failure mode. Suppose you once ran a marketing microsite on a hosting platform and pointed a subdomain at it:

docs.example.com.   CNAME   example-docs.somehost.example.

While the platform account is live, that CNAME resolves to the provider's infrastructure and your site loads. Later, someone deletes the account, cancels the plan, or tears down the app — but nobody removes the DNS record. Now docs.example.com still delegates to a target the provider has de-provisioned. On many platforms the vanity hostname (example-docs.somehost.example) becomes unclaimed and available for anyone to register again. An attacker who creates a fresh account and claims that exact target name now controls what docs.example.com serves — without ever touching your DNS, your servers, or your accounts.

The same class of bug appears with cloud storage buckets, static-site hosts, platform-as-a-service apps, and SaaS products that let you attach a custom hostname. In every case the ingredients are identical: a DNS record that survives, a third-party resource that does not, and a provider that lets the freed resource be re-registered by a stranger.

How dangling records are discovered

Discovery is passive reconnaissance — it does not require touching your servers at all, which is exactly why attackers like it. The steps are conceptual and equally useful to a defender auditing their own estate:

• Enumerate subdomains. Certificate Transparency logs, public DNS datasets, and simple wordlists surface hostnames like staging, docs, cdn, email, and long-forgotten campaign names.
• Resolve each name. Follow the CNAME chain and see where it terminates. A tell-tale pattern is a hostname that still has a CNAME pointing at a third party, but where the final lookup returns NXDOMAIN or an error — the delegation exists, the target does not.
• Fingerprint the response. When the target still resolves to a provider's shared infrastructure, the platform typically answers unclaimed hostnames with a distinctive "no such site / not found" page. That signature, combined with a live CNAME to that provider, marks the record as a takeover candidate.

A responsible detector stops at candidate identification. Confirming a takeover would mean actually claiming the resource, which is the attack itself — so good tooling flags the exposure and leaves the claiming to you (by removing the record) rather than proving it destructively.

Why it matters more than "a page nobody visits"

The instinct is to shrug at an abandoned subdomain. That underestimates how much trust a hostname inherits from its parent domain:

• Credible phishing. Content served from login.example.com looks legitimate to your users, your staff, and email filters. An attacker can stand up a convincing sign-in page on infrastructure that genuinely answers to your brand — no look-alike domain required.
• Cookie theft and session abuse. If cookies are scoped to the parent domain (Domain=.example.com), the browser will send them to every subdomain, including the hijacked one. Content the attacker controls on a sibling subdomain can then read cookies that were never meant to leave your real application. This is why over-broad cookie scope and takeover risk compound each other.
• Allowlist bypass. Policies that trust a wildcard are only as trustworthy as every host under it. A Content-Security-Policy that permits *.example.com as a script source, or a CORS policy that reflects any *.example.com origin, will happily trust an attacker who owns one takeoverable subdomain. See CORS misconfiguration for how a trusted origin turns into cross-origin data access.

Prevention: treat DNS as part of decommissioning

Every prevention measure comes down to keeping DNS records and the resources they point at in sync, especially at the two moments things drift — setup and teardown.

• Remove the DNS record when you retire a service. Decommissioning a hosted app, a bucket, or a SaaS integration is not finished until its CNAME/ALIAS/ NS record is gone too. Make "delete DNS record" an explicit step in the teardown runbook, not an afterthought.
• Order operations to avoid a dangling window. When standing a service up, provision first, then point — claim the provider resource before you create the DNS record so the name is never live-but-unbacked. When tearing down, de-point first, then de-provision — remove or repoint the DNS record before you delete the underlying resource, so there is never an interval where your record points at something claimable.
• Audit for dangling records periodically. Estates accumulate subdomains faster than anyone documents them. Schedule a recurring pass that enumerates your subdomains, resolves each one, and flags any CNAME whose target no longer resolves or returns an unclaimed-service signature.
• Tighten what your subdomains are trusted for. Prefer explicit host allowlists over wildcards in CSP and CORS, and scope cookies to the exact host that needs them rather than the whole parent domain. That way a single stale record cannot become a foothold into everything.

How Cyber Report checks this

Cyber Report runs an external, non-destructive DNS check: it enumerates subdomains, resolves each record, and looks for the dangling pattern — a live CNAME/ALIAS pointing at a third-party target that no longer resolves or answers with an unclaimed-service signature. Because it is passive DNS analysis, it can run without touching your servers, and any match is reported as a high-severity subdomain takeover candidate for you to remediate by removing the record. It runs alongside our wider DNS and email hygiene checks and our origin IP exposure analysis, which cover the rest of the DNS attack surface.

See what we scan, or run a scan on your own domain to see where you stand.