Subdomain takeover
In external testing, a subdomain takeover is what happens when a DNS record still points at a cloud or hosting resource that no longer exists, so anyone may register that resource and serve content from your domain name. The domain still resolves; the thing it resolves to now belongs to somebody else.
How it works
A team creates a hostname that points, usually by CNAME, at a provider-controlled name: a static site host, a documentation platform, a support desk, a marketing tool, a cloud storage bucket, a load balancer. Later the service is cancelled, the bucket is deleted or the account is closed, but nobody removes the DNS record. The name is now dangling: it resolves, the provider answers, and the provider has no tenant for it.
Claiming it costs nothing. The attacker signs up with the same provider and asks for the same identifier the record points at. The provider hands it over because it is unassigned. From that moment the attacker serves whatever they like on a hostname inside your registered domain, with a valid certificate they can obtain themselves.
What goes wrong
The damage is not the defacement. It is everything else that trusts the name. Cookies scoped to the parent domain are sent to the subdomain, so a session can be collected without touching the main application. Redirect allowlists, single sign-on reply URLs and Content Security Policy allowlists are frequently written with a wildcard over the domain, so a hostile subdomain becomes a trusted script source or a valid place to send an authorisation code. Password reset emails and phishing from a real corporate hostname pass every check a recipient can make.
The reason this persists is that nobody owns retired DNS records. Marketing creates hostnames, projects end, and the record outlives the project by years. It is the clearest evidence that a domain has no asset inventory and that shadow IT has been provisioning under the corporate name.
Where this shows up in an audit
We enumerate names from certificate transparency, zone data and passive sources, resolve them, and identify the ones whose target answers with a provider error indicating an unclaimed resource. Where the rules of engagement allow, we claim it, serve a single marker file and hand it straight back, because an unclaimed proof is a hostname somebody else can take between our report and the fix. The finding lists the record, the provider, the evidence and every trust relationship that named the domain. This is part of how we map and verify an external estate.