What Is Subdomain Takeover?
Subdomain takeover is the hijacking of a legitimate subdomain by claiming the deprovisioned cloud or third-party resource that its DNS record still points to. The victim keeps its domain registration and its DNS account while the attacker claims the resource behind a dangling record (opens in new tab), most often a CNAME, and controls what is served at the subdomain.
How subdomain takeover works
Two conditions must hold at the same time: the subdomain's DNS record points to a resource that no longer exists or is inactive, and the provider allows someone else to claim it. Providers with globally shared namespaces that do not verify DNS ownership at claim time meet the second condition.
A team creates blog.example.com CNAME example-blog.herokuapp.com, and the Heroku app serves the blog. The team later decommissions the app but leaves the CNAME in place, so the record now points to a hostname that returns nothing.
An attacker creates a new Heroku app named example-blog, claims the hostname, and controls what loads at blog.example.com, the canonical case (opens in new tab) of the attack.
The root cause is a process failure. Teams create DNS records when they spin up a service and rarely run a step that deletes them during teardown.
Why subdomain takeover matters
A hijacked subdomain inherits parent-domain trust (opens in new tab), defeating the checks defenders tell users and tools to rely on: the URL itself is genuine. The attacker can request a valid TLS certificate through domain validation, so the browser shows a padlock. A valid certificate also lets browsers send secure cookies (opens in new tab) over the connection and adds to the page's perceived legitimacy.
Cookies that the application scopes to .example.com travel to attacker-controlled subdomains. Wildcard Content Security Policy and CORS rules that trust wildcard subdomains admit the attacker's scripts. OAuth flows that allowlist the subdomain as a redirect URI can leak tokens.
Email authentication fails the same way: when an SPF record includes a mechanism that matches the hijacked subdomain's IP, the attacker sends SPF-authenticated mail that appears to originate from the brand's domain.
The technique, once associated mainly with bug bounty findings, now appears in organized operations. The Hazy Hawk threat actor (opens in new tab), first documented in April 2025, systematically hijacks dangling CNAMEs in abandoned cloud resources at government agencies, universities, and Fortune 500 companies, then routes victims through traffic distribution systems to scams and malware.
The attacker inherits the trust attached to that infrastructure while the victim's registrar, DNS, and authentication controls stay untouched. Because dangling records can appear between scheduled audits, continuous automated scanning catches them sooner.
Types of subdomain takeover
The variants differ by which record type dangles and what the attacker can claim through it:
- CNAME takeover of deprovisioned cloud or SaaS resources. In the most common variant, a CNAME points to a provider-named endpoint, such as an S3 bucket or an Azure web app. A GitHub Pages site can create the same condition. The owner deletes the resource, and another account registers the same name at the same provider and gains control of the subdomain. It is scoped to the individual subdomain; provider error fingerprints (opens in new tab) include messages such as The specified bucket does not exist.
- NS delegation takeover. A parent zone delegates a subdomain to nameservers whose hostnames sit on an expired domain or a closed DNS hosting account, and re-registering that domain, or claiming the zone at the same provider, makes the attacker authoritative for every record beneath the delegation. This is the highest-impact variant because a successful attack can yield control of the entire DNS zone, and the same pattern runs at internet scale under the name "Sitting Ducks" (opens in new tab).
- MX record takeover. An MX record points to a mail host on a deprovisioned domain or service, and the attacker intercepts inbound email addressed to the subdomain, which turns password-reset flows into account takeover and lets the attacker complete email-based certificate validation. PyPI added daily scans in June 2025 after domain resurrection attacks (opens in new tab) used this path against package maintainer accounts.
- Second-order (broken link) takeover. The victim's page loads a script, font, or CDN asset from an external hostname whose domain has expired.
Claiming that hostname lets the attacker inject client-side code (opens in new tab) into the victim's site, a stored cross-site scripting outcome.
How to defend against subdomain takeover
Without provider-side domain verification, the owner still controls the DNS record. The prescribed teardown order (opens in new tab): delete the DNS record first, wait for the TTL to expire, then delete the resource, and add the DNS record last on creation. Organizations with S3 buckets created before AWS introduced regional bucket namespaces (opens in new tab) in March 2026 still face globally claimable names after deletion; existing buckets can't migrate into the new namespace.
Sequencing alone will not cover SaaS offboarding or delegated zones.
- Prefer alias records and provider verification. Azure DNS alias records (opens in new tab) couple a record's lifecycle to the resource, so deleting the resource empties the record set. Azure App Service's asuid.{subdomain} TXT record and GitHub Pages domain verification block other accounts from claiming a custom domain, though wildcard records put you at immediate risk (opens in new tab) even after verification.
- Treat DNS as governed code. Keep DNS configuration in a repository under pull-request approval (opens in new tab) and deploy it through a dedicated service account. Pair that with central control (opens in new tab) over who can register domains and an accurate inventory of all known domains your organization owns or operates.
- Audit the inventory continuously. Enumerate subdomains from DNS and Certificate Transparency logs, then supplement the results with open-source intelligence sources before resolving each record chain. NXDOMAIN, SERVFAIL, and REFUSED responses warrant investigation.
- Offboard SaaS vendors with a DNS checklist. Helpdesk, careers, community, and ecommerce subdomains become claimable the day a SaaS contract ends without cleanup.
Provider-side ownership verification is a fail-safe; the offboarding checklist is the control.
How Doppel helps
Point-in-time audits leave windows between scans while cloud resources change daily. Doppel, the Frontier AI Social Engineering Defense (SED) platform that unifies Digital Risk Protection (DRP) and Human Risk Management (HRM), connects a hijacked subdomain to the impersonation campaign and attacker infrastructure around it.
We scan for DNS anomalies and identify dangling CNAME records before attackers claim them. The Doppel Threat Graph tracks domain state continuously and detects DNS and MX record changes as well as fresh TLS certificates. Its agentic AI correlates the infrastructure, prioritizes it, and executes automated takedowns across registrars, hosts, and social platforms, while analysts handle escalations.
Request a demo to see how attackers build multi-channel campaigns around your brand and how those campaigns appear in the Threat Graph.
Frequently asked questions about subdomain takeover
What is subdomain takeover?
Subdomain takeover is an attack in which someone claims a cloud or third-party resource that a company's DNS record still points to after the company deleted the resource. The leftover record is called dangling DNS, most often a CNAME pointing to a decommissioned app or bucket; a SaaS endpoint can create the same condition. Because the provider makes the resource name available for registration, the attacker creates a resource with that name and controls what loads at the real subdomain. The company keeps ownership of its domain and DNS account the entire time.
What is subdomain takeover in cybersecurity?
In cybersecurity, subdomain takeover is classified as a DNS misconfiguration that an attacker exploits to gain hosting control over a trusted hostname. In security frameworks, it appears under OWASP WSTG-CONF-10 and MITRE ATT&CK Compromise Infrastructure: Domains (T1584.001) in the Resource Development tactic. A hijacked subdomain can carry a valid TLS (Transport Layer Security) certificate, receive cookies that applications scope to the parent domain, and send email that passes Sender Policy Framework (SPF) checks. Scoring frameworks (opens in new tab) generally rate it medium to high severity, and organizations that frequently create and delete cloud resources face it as a common, high-severity threat.
Subdomain takeover vs. domain hijacking: what is the difference?
Subdomain takeover exploits a misconfiguration with no account compromise; the legitimate owner still controls the registrar and the DNS zone, and the attacker only claims the orphaned resource one record points to. Domain hijacking is an unauthorized registration change (opens in new tab), usually via a compromised registrar account or a social-engineered helpdesk, and the owner loses control outright. DNS hijacking sits between them: the registration stays intact, but the attacker alters DNS records (opens in new tab) on the DNS server or redirects resolution to a rogue nameserver. Each needs different remediation: deleting a stale record versus recovering a compromised account.
What is an example of subdomain takeover?
The classic example is a marketing team that points blog.example.com at a Heroku app, later cancels the app, and leaves the CNAME in place; an attacker then registers the same app name and serves credential-harvesting pages at the real address. In the wild, Hazy Hawk (opens in new tab) hijacked dangling CNAMEs pointing to abandoned Amazon S3 buckets and Microsoft Azure endpoints at government agencies, universities, and Fortune 500 companies. In each case the fix was the same: delete the dangling DNS record and audit every other zone for the same gap.