Subdomain Takeover: The Dangling Record That Keeps Handing Out Your Brand

A subdomain takeover is one of the few vulnerabilities that a defender can confirm without touching the target. The DNS record is public. If it points at a third-party service that no longer claims the name, anyone who can register that name at the same provider gets the subdomain, and with it the trust the parent domain extends.
The finding is unglamorous and persistent. It survives domain migrations, marketing campaigns, and reorganisation, because the record lives in a zone file and the service lives in someone else's account, and no single person owns both.

The mechanism, plainly

An organisation points something.example.com at a third-party host, typically by creating a CNAME to a provider-assigned hostname. That is the standard way to serve a marketing site, a help centre, a status page, or a project preview.
The service is later decommissioned. The team deletes the content at the provider, or the account lapses, or the subscription is cancelled. The DNS record remains, because it was created by a different team through a different process.
The provider's hostname is now unclaimed. Many providers assign hostnames that are derived from a project name or a slug, and when the original claim is released, a new account can claim the same name. The new account holder now answers for something.example.com.
The impact depends on what the parent domain trusts. Cookies scoped to the parent domain can be set by the taken-over host, which is why cookie prefixes matter. Email authentication records may align against the parent domain. Content served from the subdomain inherits the brand, which is what makes it useful for phishing or for hosting payloads that security controls treat as first-party.

Finding them without an agent

The discovery method is entirely passive, which is what makes it worth doing on a schedule.
Enumerate the subdomains of the domains you own. Public certificate transparency logs are a rich source, because every certificate issued for a subdomain is logged. Passive DNS sources and your own resolver logs add names that certificates miss.
Resolve each name and record where it points. For each CNAME, compare the target against a maintained list of provider patterns and their released-name fingerprints. The fingerprint is usually the provider's own error page or a specific HTTP response, and the pattern list is worth maintaining as a data file rather than in someone's memory.
Charge the record to a verification step, not to a finding. A CNAME that points at a live, claimed service is not a takeover; it is normal. The distinguishing evidence is that the provider does not recognise the name and the content it serves is not yours.

The problem with one-time scans

A takeover scan answers today's question. The records that matter are the ones that appear between scans.
The durable approach is to own the record lifecycle. Every DNS record that points at a third-party service should have an owner and a purpose attached to it, and the decommissioning process for that service should include the DNS record. The failure is not that the scan did not run. It is that nobody was accountable for the record when the service ended.
Where the zone is large and the ownership is unclear, the practical alternative is continuous discovery with alerting. Certificates are still issued for subdomains you may not know about, and a new CNAME is a leading indicator of a new unmapped dependency.

Controls that reduce the blast radius

Three controls make a takeover less useful even if it happens.
Set session cookies with the __Host- prefix, which restricts the cookie to the exact host and prevents a sibling subdomain from setting a cookie scoped to the parent domain.
Keep email sending domains and the primary domain separated where the mail architecture allows it, so that a subdomain failure does not undermine alignment.
Monitor what is served from your subdomains. A takeover changes content, and the change is visible before anyone reports a phishing page that uses your brand.

What to take away

Subdomain takeover is a lifecycle failure with a technical symptom. The scan is cheap and should run continuously, but the fix is an inventory in which every record that delegates trust to a third party has an owner and a removal step. The finding to act on is not "we have a dangling CNAME." It is "we did not know this dependency existed."

References

• OWASP, Subdomain Takeover
• MITRE ATT&CK, T1584.001: Compromise Infrastructure - Domains
• RFC Editor, RFC 6265bis: Cookies (__Host- prefix)
• Certificate Transparency, CT log search