How do subdomain takeover attacks happen?

Why subdomain takeover happens

Subdomain takeover is not a DNS failure on its own, it is a lifecycle failure. The dangerous condition appears when the DNS record outlives the service it points to, so a hostname remains published after the cloud resource, hosted app, CDN endpoint, or custom-domain binding has been deleted, expired, or abandoned. At that point, control of the name and control of the target drift apart.

That drift is what makes the attack possible. The attacker does not need to change your DNS zone; they only need a provider or platform that still accepts the orphaned hostname and allows a new claimant to bind it to their own resource. The trusted subdomain continues to resolve, but the destination is no longer yours.

The mechanics are usually simple: an organisation decommissions a service, forgets the DNS alias, or removes a cloud resource without cleaning up the record. External observers can often spot the footprint through public DNS, certificate transparency, and service-specific error responses. DNS Security Guide covers the broader DNS failure patterns that make this possible, including dangling records and takeover-prone configurations.

What the attacker gains from an orphaned hostname

The main value is trust transfer. Users, browsers, APIs, and email flows tend to trust the hostname because the domain looks legitimate, even though the underlying service has changed ownership. That means a takeover can be used for phishing, content injection, malicious redirects, and in some cases token or cookie abuse if the subdomain still sits inside an overly broad trust boundary.

The risk is strongest when the subdomain is still referenced in allowlists, OAuth redirect URIs, embedded scripts, or old documentation. A takeover then becomes more than a defacement issue, it becomes a way to inherit a trusted position inside existing business workflows. Subdomain Takeover and Dangling DNS Guide explains the common takeover paths, the services that are typically affected, and the trust relationships that make the impact worse.

Discovery often starts with reconnaissance, not exploitation. Attackers and bug bounty researchers look for CNAMEs or aliases that point to unclaimed cloud resources, expired hosted pages, or deleted application endpoints. That makes this an attack surface problem as much as a DNS problem. Attack Surface Management Guide is the most relevant broader control view because it connects asset discovery, subdomain takeover, and exposed services in one operational picture.

How to prevent and detect it before it is used

Prevention depends on ownership discipline, not just monitoring. DNS change management should be tied to service decommissioning so that deleting a cloud resource, CDN property, or hosting claim also triggers removal or repointing of the DNS record. That same control should include regular sweeps for stale aliases, especially after migrations, vendor exits, and application retirements.

Detection should focus on both inventory and signals. Compare zone files against live ownership of the target service, and check for takeover indicators such as provider-specific “not found” pages, expired custom-domain bindings, or certificate issuance patterns that should not exist for an abandoned host. OSINT and Reconnaissance Guide is useful here because it frames the public sources that reveal exposed DNS and domain footprint before an attacker claims it.

When teams want a practical clean-up process, the priority is to remove the orphaned record or reclaim the service binding first, then verify whether the hostname appears anywhere else in configuration, certificates, redirect rules, or access policies. If the subdomain has been used for authentication, messaging, or customer-facing flows, treat it as a trust-boundary event rather than a housekeeping task. Subdomain Takeover Response Playbook gives the operational sequence for evidence capture, cleanup, and trust-list review.

Risk and Threat Considerations

Subdomain takeover is high-risk because it combines a stale control plane entry with a live trust relationship. The failure is often invisible until someone claims the abandoned target, and at that point the hostname may already be embedded in user journeys, application code, or security allowlists.

Failure mechanism: A DNS record remains active after the owned service is gone, and the external provider accepts a new claim on the abandoned hostname. The organisation still controls DNS, but no longer controls what answers that hostname returns.

Impact: Attackers can reuse a trusted subdomain for impersonation, phishing, malicious hosting, or abuse of embedded trust relationships. If cookies, redirect URIs, or allowlists still reference the host, the blast radius can extend beyond simple web defacement.

Practitioner Guidance

What to verify: Check every external DNS alias against current service ownership, not just against current resolution. A record is safe only when the destination service is still under your control and the provider binding cannot be independently claimed.

What good looks like: Decommissioning includes DNS cleanup, certificate and redirect review, and a final sweep for the hostname in code, allowlists, and identity flows. The operational test is simple: if the service disappears, the hostname should stop being claimable.

Practitioner takeaway: Treat subdomain takeover as a lifecycle control failure, not a niche DNS bug, because the real fix is continuous ownership reconciliation across DNS, hosting, and every place the hostname is trusted.

Related resources from NHI Mgmt Group

• How should security teams prevent API keys from being exposed through subdomain takeover attacks?
• Why do endpoint tools miss so many browser-based account takeover attacks?
• How should security teams handle browser-based attacks that happen inside the session?
• How should security teams reduce account takeover from bot-driven attacks?