What Is Subdomain Takeover?

Subdomain takeover is a condition where an attacker gains control of a company-owned subdomain because its DNS record still points to an external service the company no longer controls. In most cases, subdomain takeover happens because of dangling DNS records tied to deleted cloud apps, expired hosting endpoints, or abandoned SaaS services. The attacker does not break DNS itself. Instead, they claim the underlying resource that the DNS record still references.

How subdomain takeover works

At a high level, subdomain takeover is not about breaking DNS itself. It is about taking advantage of a mismatch between what DNS points to and what the organization actually still owns.

The basic sequence

A typical scenario looks like this:

An organization creates a subdomain for a cloud or SaaS service.
DNS is configured, often with a CNAME or similar alias, to point that subdomain to the provider.
Later, the underlying service is deleted, expires, or is abandoned.
The DNS record remains in place.
An attacker notices the dangling reference and claims the now-available resource on the provider side.
The attacker can now serve content from the organization’s subdomain.

The DNS record is still legitimate from the outside. The problem is that the destination is no longer under the organization’s control.

Why this happens

Subdomain takeover usually comes from asset lifecycle gaps, not from one dramatic security failure. Common causes include:

Test environments that were never cleaned up
Retired marketing sites
Expired cloud storage or hosting instances
SaaS applications removed without DNS cleanup
Mergers, migrations, or replatforming projects
Poor coordination between infrastructure, app, and DNS teams

This is why security teams often treat it as an attack surface management problem as much as a DNS problem.

What an attacker can do

If takeover is possible, the attacker may be able to:

Host a phishing page on the trusted subdomain
Serve malware or malicious downloads
Impersonate a legitimate business service
Abuse brand trust and reputation
Capture user traffic intended for the real application
Bypass simple allowlists that trust the parent domain

The impact depends on what users, partners, and internal systems expect that subdomain to be. A forgotten demo site may be low risk. A retired login portal or support subdomain can be much more serious.

What subdomain takeover does not mean

Subdomain takeover does not mean an attacker has taken over the root domain or your DNS registrar account. It is usually narrower than that. The attacker controls content for one specific subdomain because of an exposed external dependency.

That said, the business risk can still be high because users tend to trust anything under the company domain.

For a closely related naming and trust issue, see what is dns spoofing.

Why subdomain takeover matters

The main reason subdomain takeover matters is trust. A company-owned subdomain looks legitimate to users, partners, security tools, and sometimes internal allowlists.

That trust can create several problems:

Users are more likely to click and believe the content
Email, chat, or documents linking to the subdomain may seem credible
Security teams may initially treat the activity as internal or low-risk
Brand damage can be significant even if only one subdomain is affected

In other words, the technical flaw may be narrow, but the reputational and phishing risk can be much broader.

When you’ll encounter it

You will most often hear about subdomain takeover in cloud-heavy environments, bug bounty programs, external attack surface reviews, and DNS hygiene work.

During attack surface assessments

Security teams or external testers often look for dangling DNS records as part of routine reconnaissance. If a subdomain points to a service with a “not found,” “no such app,” or “resource unavailable” response, it may warrant investigation.

In bug bounty and vulnerability disclosure reports

Subdomain takeover is a common finding in public vulnerability reporting because it is externally visible and often reproducible when the conditions are right. Not every dangling record is exploitable, but many get flagged for review.

After cloud migrations or decommissioning

This issue often appears after teams move away from a provider or retire an application but forget to remove old DNS entries. The more distributed the environment, the easier it is for stale records to survive.

In mergers, acquisitions, and brand management

Large organizations with many business units, inherited domains, and third-party platforms are especially exposed. Old campaign sites, regional portals, and temporary services tend to accumulate over time.

For a broader view of exposed internet-facing assets, read what is attack surface management.

How defenders reduce the risk

The fix is usually operational, not exotic.

Clean up DNS during deprovisioning

When an app, storage bucket, hosted site, or SaaS endpoint is retired, the DNS record should be reviewed and removed if no longer needed. Decommissioning should include DNS as a standard checklist item.

Inventory external service dependencies

Teams should know which subdomains point to which providers. This includes marketing platforms, help desk portals, object storage, landing page services, CI/CD previews, and other externally hosted resources.

Monitor for dangling records

Security teams often scan for subdomains that resolve to error states associated with unclaimed resources. This can be part of attack surface management or continuous exposure monitoring.

Restrict stale domain sprawl

Temporary subdomains and one-off projects create long-term risk if there is no owner. Governance matters here: every exposed subdomain should have a business owner and a retirement process.

Protect the endpoints used for DNS and cloud admin work

Many subdomain takeover issues start as hygiene problems, but cleanup and prevention still depend on secure admin workflows. On teams managing registrar access, cloud dashboards, and shared credentials, a password manager like 1Password can help reduce risky credential sharing. If administrators frequently work from laptops outside tightly managed environments, endpoint protection such as Malwarebytes may also be useful as a supporting control.

Bottom line

Subdomain takeover is what happens when DNS outlives ownership. If a live subdomain still points to an external service that has been deleted or abandoned, an attacker may be able to claim that service and operate under your domain name. It is a preventable problem, but only if DNS hygiene, cloud deprovisioning, and attack surface review are treated as one continuous process.