Subdomain Takeover: How It Happens and How to Prevent It

A subdomain takeover is an attack where someone gains control of a subdomain because its DNS record points to a third-party service that was removed or never claimed. The attacker registers that service and serves their own content from a subdomain that users trust. 

The flaw behind it, a dangling DNS record, is widespread: security researchers at Certitude identified more than 1,000 organizations with subdomains vulnerable to takeover in a single 2023 study, and described it as the tip of the iceberg.

This guide explains what subdomain takeover is, how it happens, the DNS record types and services at risk, how to detect it, the damage it causes, how to prevent it, and what to do if a subdomain is already taken over.

What is Subdomain Takeover?

A subdomain takeover is the unauthorized control of a subdomain that occurs when its DNS record still points to a deprovisioned or unclaimed third-party service. The subdomain continues to resolve, but because nothing legitimate answers at the destination, an attacker who claims that service controls what the subdomain serves.

The root cause is a dangling DNS record. A dangling DNS record is a DNS entry, most often a CNAME, that points to an external resource that no longer exists or was never set up. The record keeps directing visitors to a service endpoint, yet the endpoint sits empty and claimable. An attacker who registers the same resource name at the provider steps into that empty endpoint.

The danger comes from inherited trust. The hijacked subdomain belongs to the real domain, so it carries the organization's brand, often a valid TLS certificate, and sometimes cookies scoped to the parent domain. Visitors and security tools treat it as legitimate, which makes it a powerful base for fraud. Any organization that uses cloud or third-party hosting through CNAME, A, or NS delegation can be exposed.

How Does a Subdomain Takeover Happen?

A subdomain takeover happens when the lifecycle of a subdomain and its hosting service falls out of sync. A subdomain is created, a DNS record points it to a third-party service, and the service hosts the content. The vulnerability opens when one half of that chain changes without the other. Two scenarios produce it.

The deprovisioning gap is the most common. A team decommissions a service, such as a marketing site on a cloud platform, but leaves the DNS record in place. The record now dangles, pointing to an endpoint anyone can claim. An attacker registers the same resource name at the provider and immediately controls the subdomain.

The provisioning gap runs in the opposite direction. A DNS record is created and pointed at a service before the host is actually claimed. If the provider does not verify ownership, an attacker who is faster claims that resource first and serves content the moment the record goes live.

Common root causes include mergers and acquisitions, where inherited DNS zones are poorly inventoried, weak asset management that loses track of subdomains, and coordination gaps between teams that own DNS and teams that own services. These same blind spots make broader attack surface management difficult, because an organization cannot protect assets it has not tracked.

DNS Record Types Vulnerable to Takeover

Three DNS record types create subdomain takeover risk, each in a different way.

• CNAME records. The most common vector. A CNAME alias points the subdomain to a third-party service, and if that service is deprovisioned but the alias remains, the endpoint becomes claimable.
• A records. Risk appears when a cloud IP address is released back to the provider's pool and later reassigned to an attacker, who then controls whatever the A record points to.
• NS records. The most dangerous case. An NS record delegates a subdomain to a third-party DNS provider, so if that account is closed, anyone who recreates it can claim the delegated zone and control every record beneath the subdomain.

Which Services are Vulnerable to Subdomain Takeover?

Takeover risk concentrates in third-party services where a resource name can be claimed by anyone. The community-maintained can-i-take-over-xyz project catalogs which providers are exploitable and how. The categories below are the most frequently affected.

Whether a service is exploitable depends on one factor: whether the provider verifies domain ownership before letting someone claim a resource name. Providers that skip that check leave their customers' dangling records open to takeover.

How to Detect Subdomain Takeover

Detecting subdomain takeover follows three phases, moving from broad discovery to confirmed validation. The same methodology that defenders use is the one attackers run, so completing it first is what closes the gap.

1. Subdomain enumeration. Discover every subdomain the organization owns, drawing on DNS records, certificate transparency logs, passive DNS sources, and enumeration tools. Coverage matters because an unknown subdomain cannot be checked.
2. Fingerprint-based detection. Compare each subdomain's HTTP response against a database of known unclaimed-service signatures, such as the response strings that AWS S3, GitHub Pages, and Heroku return when a resource is unclaimed.
3. Manual validation. Confirm that the record genuinely dangles and that the service is actually claimable before acting, which filters out false positives from providers that maintain ownership whitelists.

One-time scans only capture a moment in time, so detection works best as a continuous process. Monitoring newly created subdomains and forgotten infrastructure catches records as they become dangling, and watching Certificate Transparency logs for certificates issued to a subdomain can reveal a takeover that has already occurred.

What Are the Risks of a Subdomain Takeover?

A hijacked subdomain inherits the trust of the parent domain, which turns it into a platform for six main forms of harm.

• Phishing on a trusted domain. Credential-harvesting pages hosted on a real brand subdomain bypass the suspicion that a lookalike domain would raise.
• Cookie theft and session hijacking. Cookies scoped to the parent domain can be read from the subdomain, exposing active user sessions.
• Cross-site scripting and CSP bypass. Same-origin trust between the subdomain and parent lets an attacker run scripts or circumvent content security policies.
• Malware distribution. Payloads served from a trusted subdomain reach users and security tools that would block an unknown source.
• Email spoofing. A controlled subdomain can be abused in email authentication contexts to send mail that appears legitimate.
• Brand and reputation damage. Defacement or scam content published under the official domain erodes customer trust directly.

How to Prevent Subdomain Takeover

Preventing subdomain takeover is a matter of disciplined DNS and service lifecycle management. The following six measures close the gaps that attackers rely on.

• Fix the order of operations. When provisioning, claim the host first and create the DNS record last. When deprovisioning, remove the DNS record first and the service afterward.
• Maintain a DNS and subdomain inventory. Keep a current record of every subdomain, every DNS entry, and the service each one points to, updated as infrastructure changes.
• Remove dangling records promptly. Delete CNAME, A, and NS entries the moment the service they reference is decommissioned, leaving nothing pointed at an empty endpoint.
• Monitor DNS continuously. Use automated detection that flags records whose target has become unclaimable, rather than relying on periodic manual review.
• Validate third-party services. Confirm that external services referenced by DNS are still active and owned by the organization.
• Choose providers that verify ownership. Prefer hosting vendors that confirm domain ownership before allowing a resource claim, and make this part of vendor qualification.

My Subdomain Has Been Taken Over: What to Do

If a subdomain has already been taken over, a structured response contains the damage and prevents recurrence. Work through the five steps in order.

1. Remove the dangling DNS record. Cut the connection at the DNS layer first by deleting the CNAME, A, or NS record that points to the attacker-controlled service, which immediately stops the subdomain from resolving to their content.
2. Check Certificate Transparency logs. Search logs such as crt.sh for certificates issued to the affected subdomain, and report certificates that the attacker obtained to the issuing certificate authority for revocation.
3. Rotate sessions and secrets. If the application sets cookies on the parent domain, rotate session secrets and force re-authentication so any stolen sessions become useless.
4. Review email authentication. Confirm the compromised subdomain could not send authenticated mail by checking SPF records and the DMARC policy.
5. Audit every DNS zone. If one record was dangling, others may be too, so scan all zones for additional dangling records and fix the process gap that allowed it.

Detecting Subdomain Takeover Risk with CloudSEK BeVigil

Subdomain takeover is fundamentally an external attack surface problem, which is the category CloudSEK BeVigil is built for. The platform fingerprints an organization's internet-facing assets, automatically discovering domains, subdomains, SSL certificates, and DNS records, then scans them for misconfigurations. Its DNS scanner specifically flags subdomain takeovers, alongside related exposures such as SPF and DMARC issues and private IP disclosures, surfacing the exact dangling records an attacker would find through enumeration.

The value lies in running that discovery continuously rather than once. External assets change constantly as teams spin up and retire services, so a subdomain that becomes dangling after a service is decommissioned is flagged as the exposure emerges, not months later in an audit. Treating dangling records as part of ongoing misconfiguration monitoring closes the window that the attack depends on.

Frequently Asked Questions

What is a dangling DNS record?

A dangling DNS record is a DNS entry, usually a CNAME, that points to a third-party resource that no longer exists or was never claimed. The record still resolves, but the destination is empty, which makes it claimable by an attacker.

How common is subdomain takeover?

It is widespread. A 2023 study found more than 1,000 organizations with vulnerable subdomains, and in 2020, researchers identified over 670 Microsoft subdomains at risk. Any organization using cloud hosting with unmanaged DNS records can be affected.

Can subdomain takeover be done on any subdomain?

No. Only subdomains with a dangling DNS record pointing to a claimable third-party service are exploitable. A subdomain pointing to an active, owned service or a verified provider is not vulnerable to takeover.

What is the difference between subdomain takeover and domain hijacking?

Subdomain takeover claims a single subdomain through a dangling DNS record at a hosting provider. Domain hijacking seizes an entire domain, usually by compromising the registrar account or transferring ownership, affecting every subdomain at once.

How do I check if my subdomain is vulnerable to takeover?

Enumerate every subdomain, check whether each points to a deprovisioned or unclaimed service, and validate the finding manually. Continuous external attack surface monitoring automates this and flags dangling records as they appear.

Is subdomain takeover illegal?

Yes. Claiming and controlling a subdomain you do not own is unauthorized access under computer-misuse laws in most jurisdictions, even when done to demonstrate the flaw. Security researchers operate only under bug-bounty or disclosure agreements.