A marketing team spins up a landing page on a cloud platform, points shop.example.com at it with a CNAME record, and moves on. Two years later someone deletes the cloud resource but nobody touches the DNS. That leftover record now points at an address anyone can claim, and whoever claims it gets to serve content as shop.example.com, with a valid TLS certificate to match.
This is subdomain takeover, and it is one of the most common findings in bug bounty programs for a simple reason: it is created by ordinary operational drift, not by a mistake anyone notices at the time. The vulnerability lives in the gap between two teams, the one that manages DNS and the one that manages cloud resources, and it appears the moment those two stop agreeing about what exists.
How the takeover works
Most cloud hosting platforms let you attach a custom domain to a resource you control. GitHub Pages sites, object storage buckets, managed app platforms, and CDN distributions all follow the same pattern: you create the resource, the platform gives you a target hostname, and you point your subdomain at that target with a CNAME record.
The trouble starts when the resource is deleted but the CNAME survives. The record is now "dangling": it points at a hostname on the platform's infrastructure that no longer belongs to anyone. On platforms where resource identifiers are claimable, an attacker registers a new resource that answers at that same target, and the platform starts serving the attacker's content to anyone who visits your subdomain.
The attacker never touched your DNS, your registrar account, or your servers. That separates this from domain hijacking, where the registrar account itself is compromised. Here the DNS is doing exactly what you told it to do. The instruction is simply stale.
Why it is worse than a defaced page
Serving phishing pages from a trusted domain is the obvious payoff, and it is bad enough: a login form at accounts-help.example.com convinces people that a form at totally-unrelated-domain.com never would. But the browser security model makes a controlled subdomain considerably more dangerous than a convincing fake.
-
Cookies scoped to the parent domain leak. A cookie set with
Domain=example.comis sent to every subdomain, including the one the attacker now controls. Depending on what the main site stores in domain-wide cookies, that can mean session material arriving in the attacker's logs. Cookie attributes like SameSite restrict cross-site sending, but a sibling subdomain is same-site. - Valid TLS comes free. The attacker controls the content served at the subdomain, which is exactly what a certificate authority checks during HTTP-01 domain validation. They can obtain a browser-trusted certificate for your subdomain in minutes. CAA records can narrow which authorities will issue, but they do not stop issuance for a subdomain whose content the attacker controls unless the policy is unusually strict.
- Trust relationships in code fire. Sites frequently allowlist their own subdomains in CORS policies, Content Security Policy directives, OAuth redirect URIs, and postMessage origin checks. Every one of those becomes a bridge from the attacker's page into the application proper.
A subdomain is not a separate identity. Browsers, certificate authorities, and your own application code all extend measures of trust from example.com to its children. Taking over one subdomain means inheriting slices of that trust, not just borrowing the name.
The variants: CNAME, NS, and forgotten A records
The CNAME-to-dead-resource case is the most common, but it has siblings. A dangling NS record, left over from a delegated zone whose nameservers were decommissioned, hands an attacker control of an entire subtree of your namespace rather than one hostname: they re-register the nameserver domain or claim the hosted zone and answer authoritatively for everything under the delegation. A stale A record pointing at a released cloud IP address is a slower, luckier version of the same thing, since the attacker has to be assigned that specific IP by the provider, but with enough churn in a provider's address pool it happens.
Researchers have demonstrated takeovers against subdomains of some of the largest companies on the internet, and continue to. The platforms have responded unevenly. GitHub Pages added domain verification so an organization can prove ownership of a domain and block others from claiming its subdomains. Several cloud providers now require a TXT record proving domain control before a custom hostname binds to a new resource. Many services still perform no such check, which is why the class persists.
Finding your own dangling records
The defensive work is an inventory problem. You need to know every DNS record your organization publishes and whether the thing each record points at still exists and still belongs to you.
| Step | What it catches |
|---|---|
| Export the full zone | Shadow records nobody remembers creating. Zone files from the provider's API beat memory every time. |
| Resolve every CNAME target | Targets that return NXDOMAIN or a platform's "no such app" page are candidates for takeover right now. |
| Match records to live resources | Records that resolve but point at resources in accounts your organization no longer controls, such as a departed contractor's platform account. |
| Audit NS delegations | Whole-subtree exposure from decommissioned nameservers, the highest-impact variant. |
| Watch certificate transparency | A certificate you did not request for one of your subdomains is a loud signal someone else validated control of it. CT logs are public and monitorable. |
The deeper fix is procedural: make DNS cleanup part of resource decommissioning, in that order. Delete the record first, then the resource. A resource that briefly outlives its DNS record is harmless. A DNS record that outlives its resource is the entire vulnerability.
What this means if you just use the web
You cannot audit other people's DNS, and a takeover on a site you use is invisible by design: the URL is right, the padlock is present, the certificate validates. The practical defenses are indirect. Password managers help here in a way people rarely credit, since autofill keyed to an exact origin will happily fill a hijacked subdomain, but unique per-site passwords cap the damage at one account. Phishing-resistant authentication helps more: a passkey or hardware key bound to the real login origin will not authenticate to a page an attacker stood up on a different subdomain than the one the credential was registered on.
Mostly, though, subdomain takeover is a reminder of how much of web trust is infrastructural. The security of a name depends on an unglamorous chain of records, resources, and the people who remember to delete both together.
Originally published at havenmessenger.com
Top comments (0)