DedSec Security Research ·
The report usually arrives with a screenshot: promo.example.com, a campaign site from a couple of years ago, now shows a page that is not yours, perhaps a researcher's proof-of-concept or a copy of your login page. Nobody changed the DNS. Nobody changed anything, and that is how it happened.
This post covers how subdomain takeover works, what an attacker gains beyond embarrassing you, why detection is wrong in both directions, and what to fix in which order.
A dangling DNS record still points at something that no longer belongs to you. The record lives in your zone; its target lives with a cloud provider, a SaaS vendor or a registrar. The two have separate lifecycles, and nothing forces them to end together.
The usual cause is order of operations. A project ends and someone deletes the storage bucket, app service or CDN distribution. The DNS record lives in a different system, often owned by a different team, and it stays. From then on it tells every resolver on the internet: for this name, ask that provider. Whether that matters depends on whether someone else can now become what the provider answers with.
The safe order is the reverse: remove or repoint the DNS record first, then deprovision the resource. The typical takeover is that order inverted.
Dangling is necessary but not sufficient. A record is a takeover risk only if its target can be obtained by someone else, and the variants differ in exactly that.
The classic case. shop.example.com is a CNAME to a hostname at a provider: a storage bucket's website endpoint, a platform-as-a-service app hostname, a CDN distribution, or a SaaS product's custom-domain endpoint. The provider reads the Host header and works out which customer should answer, from a resource name embedded in the target or from a custom domain some account registered.
It becomes claimable when two things are true. First, the resource name is global and released on deletion, so any other account can create a bucket or app with the same name. Second, the provider lets an account attach your hostname without proving it controls your domain. If both hold, the attacker creates the resource or adds shop.example.com as a custom domain on their own account, and the provider serves their content to everyone who visits your name.
If either fails, the record is dangling but not claimable. Some providers put a random component the customer never chose into target hostnames, so a deleted hostname is never reissued. Others require a TXT ownership token in your zone before a custom domain can be attached. Providers have adopted these at different times, which is why the list of claimable services keeps changing.
Here example.com delegates dev.example.com to a managed DNS provider's nameservers, and the hosted zone was later deleted. Resolvers following the delegation typically get a refusal or a server failure.
Whether this is claimable is host-specific. At some providers another account can create a hosted zone for the same name, and if the new zone is served by the nameservers your delegation lists, that account now answers authoritatively for the whole subzone: every name under it and every record type, including MX, TXT and anything a certificate authority checks. Providers that spread zones across many nameserver sets turn that into repeated attempts, and some have added controls against it, so check the provider's current behaviour rather than assuming. When it works, the attacker holds a zone, not a name.
An address record has a different risk shape. You release a static IP, the provider returns it to the pool, and later it is allocated to another tenant. Your record now sends visitors to them.
Nobody claims this by name. An attacker can cycle allocations hoping to land on a particular address, which is slow and probabilistic, or hold many addresses and watch for traffic meant for someone else's hostname, which is opportunistic rather than targeted. More often an unrelated tenant simply answers on your name. That is still your name serving someone else's content, and it is enough to pass HTTP-based certificate validation.
From outside, a reassigned address looks like a working host. The signals are indirect: a certificate or content that stopped matching yours, or an address missing from your own cloud inventory.
An MX record pointing at a hostname under a domain that has since lapsed is a takeover of inbound mail. Whoever registers it receives the mail, password resets included.
An SPF include of a lapsed domain is quieter. Your SPF record says, in effect, also accept mail from senders authorised by vendor-mail.example. If that domain expires and someone registers it, they publish their own SPF record authorising their own servers, and mail they send with your domain as the envelope sender passes your SPF check. Because the envelope domain is yours, SPF-based DMARC alignment can pass as well. Includes accumulate over years of vendor changes and are rarely pruned.
Any registered domain anywhere in your resolution chain, whether a CNAME target under a vendor's former domain or a nameserver hostname, is a dependency with a renewal date. If it lapses, the next registrant controls everything that resolves through it. One tell from outside is an NXDOMAIN at a point in the chain where the registered domain itself, not just one host under it, no longer exists.
A takeover is often triaged as a content problem. The serious consequences come from what browsers and other systems grant a name because it sits under your domain. Each depends on configuration, which is why each needs checking.
Cookies. A cookie set with a Domain attribute of example.com is sent to every subdomain, including the one the attacker now serves, so if session cookies are scoped that way the attacker's page receives them on every visit. In the other direction, any subdomain can set cookies for the parent domain, planting or overwriting cookies the main application reads, which enables session fixation and CSRF-token tampering. Cookies without a Domain attribute are host-only. Cookies named with the __Host- prefix go further: the browser rejects that prefix on any cookie with a Domain attribute, so a sibling cannot plant one.
SameSite. SameSite does not separate sibling subdomains, because a site means the registrable domain, not the host. A request from the lost subdomain to app.example.com is same-site, so cookies marked SameSite Lax or Strict are attached. A CSRF defence resting on SameSite alone does not apply.
CORS and CSP allowlists. An API that accepts any origin matching *.example.com, with credentials allowed, will let the attacker's page make authenticated requests and read the responses. A Content-Security-Policy whose script sources include *.example.com allows scripts from the lost host; on its own that is not an injection, but it turns an HTML injection that the policy would otherwise have neutralised into script execution.
OAuth redirects. If an OAuth client's allowed redirect URIs include the lost name, or a pattern that matches it, authorization codes or tokens can be delivered to the attacker. Many identity providers require an exact match, which helps only if the exact match is not the dangling name itself.
HTTPS does not help. A certificate authority issuing a domain-validated certificate checks control, not ownership. HTTP-01 validation asks for a token served at a well-known path on the name over plain HTTP, and whoever serves content there passes it. DNS-01 validation asks for a TXT record under the name, and whoever runs a delegated zone passes it. Many hosting and CDN providers also provision a certificate automatically once a custom domain is attached to an account. So the attacker's page arrives with a valid padlock. CAA records narrow which certificate authorities may issue for your names, and with the accounturi parameter, which ACME account may request issuance. But a CA reads CAA from the closest zone that publishes it, so an attacker holding a delegated subzone can publish their own.
From outside, a takeover check is a chain of observations: resolve the name, follow every hop, see where the chain ends, and decide whether what is at the end can be claimed.
NXDOMAIN versus resolves-but-unclaimed. These are two different end states. Sometimes the CNAME target no longer resolves, because the provider removed the hostname or a registered domain in the chain lapsed. Sometimes it still resolves, because many providers answer for every hostname under their domain, and the front end returns an error meaning no such resource or no such custom domain. An NXDOMAIN target says something is gone, but not whether the name can be reissued: a lapsed domain is a question for the registry, a provider hostname a question about that provider's naming rules.
Fingerprints. The resolves-but-unclaimed case is usually detected by matching the response against known provider error pages: a body that says the bucket does not exist, a page saying no app is configured for this hostname, a specific combination of status and headers. Fingerprint matching fails in both directions.
The community-maintained can-i-take-over-xyz repository on GitHub, under EdOverflow, is a useful public reference for which services are considered vulnerable and which have changed, with the discussion behind each entry. It is a starting point for judgement, not a substitute for checking the provider.
Wildcards. A wildcard record in your own zone, *.example.com pointing at a provider, means every name resolves, including names nobody ever created. Enumeration has to detect this, usually by resolving a random label, or it reports endless identical findings. If the provider routes by Host header and lets accounts attach arbitrary hostnames, a wildcard to a claimable target exposes names you never used, so a wildcard to a third party is a finding in its own right.
Attribution. A dangling record belongs on your list only if the name is yours. The resource at the end of the chain usually is not.
The only conclusive proof that a record can be taken over is to take it over: create the resource with the released name, or attach the custom domain, and serve a harmless marker. That has consequences. You now hold a resource serving content on the name, which someone has to own and eventually delete. And if the name is not actually yours, because the asset was misattributed, you have claimed someone else's name at a third-party provider.
So most programmes work to strong evidence rather than proof, retained with the finding:
That lets the record's owner act without repeating the investigation, and lets a reviewer spot a fingerprint that matched the wrong thing.
Active checks here need a scope boundary, and it is easy to get wrong, because the CNAME target is a third-party host by definition. Probing your own name is one thing; probing or creating resources on the provider is another. The boundary should be explicit and enforced, not inferred from a host appearing in your DNS. The general case is in what autonomous EASM actually means, and the case for retaining the raw exchange is in why an EASM finding needs evidence attached.
A claimable dangling record is exploitable from the moment the resource is deleted. Detection is a race against whoever notices next.
Certificate Transparency helps with inventory: names that once had publicly trusted certificates appear in public logs, so a campaign site missing from your asset register is still discoverable, by you and by anyone else.
The other half is change. Re-enumerating on a schedule and diffing against the previous run shows a target that stopped resolving, a response that switched from your content to a provider's error page, a certificate whose issuer changed. The record whose target quietly disappeared only shows up as a difference between runs. A quarterly scan sees it too, up to a quarter after the window opened.
If the record is dangling but nobody has claimed it:
If it has already been taken over:
To stop it recurring:
Maphra starts from a domain name and works outward: it enumerates subdomains, resolves infrastructure and attributes each discovered asset back to the organisation that owns it. Certificate transparency monitoring and change detection between runs are part of its discovery: it re-runs discovery on a schedule, diffs the result against the last known surface, and reports what appeared, what changed and what quietly disappeared. Every discovered asset is checked for exposure, including DNS hygiene and takeover-prone records, and each finding carries the raw response that produced it. Active validation runs only inside an explicit scope boundary you define, and the scope gate prevents active checks from reaching third-party hosts that merely appear in your surface. Findings are deduplicated across scans and tracked through new, reopened and fixed states.
Everything else in this post, including claiming a resource as proof, the remediation order and the certificate, cookie and session clean-up, is general practice and work for your own team, and the questions below apply to any tool, ours included.
A dangling record is not a vulnerability in anything you run. It is an instruction you forgot you gave, and it stays valid until someone deletes it.