Subdomain Takeover and Dangling DNS: A Field Guide to the Forgotten-Asset Problem

Somewhere in your DNS zone there is almost certainly a record pointing at a resource that no longer exists. A marketing landing page hosted on a SaaS that was cancelled two quarters ago. A staging app on a cloud platform that was torn down in a sprint cleanup. A vanity domain delegated to a CDN endpoint that was never reclaimed. Each of these is a small administrative loose end. Each is also, quietly, a working entry point into your brand that an attacker can claim for the cost of a free trial account.

This is the forgotten-asset problem, and subdomain takeover is its sharpest expression. The record still resolves. Browsers still trust it. Your own login pages may still ship cookies scoped to it. The only thing that changed is who owns the thing on the other end of the pointer. This field guide walks through how dangling DNS records form, why CNAME records are the prime risk, how to fingerprint and validate a real takeover instead of chasing noise, what the impact looks like in documented incidents, and how to remediate so the same gap does not reopen next quarter.

What a subdomain takeover actually is

A subdomain takeover happens when a DNS record for one of your subdomains points to an external service or resource that has been deprovisioned, expired, or otherwise released, and an attacker re-registers that target so traffic to your subdomain now lands on infrastructure they control. Microsoft's own security documentation calls the underlying record a "dangling DNS" entry and notes plainly that CNAME records are especially vulnerable to this threat.

The mechanism is best understood as a lifecycle that broke in the middle. You provision a cloud resource with a vendor-assigned hostname, point a friendly subdomain at it with a CNAME, and ship. Later the resource is deleted, but the CNAME survives the cleanup. The subdomain is now advertised as live but routes to nothing the vendor still associates with you. As the Azure documentation describes the takeover step, an attacker provisions a resource with the same vendor hostname you previously controlled, and traffic to your subdomain is now routed to their content. The deeper write-up of this exact pattern on storage backends lives in our public cloud storage bucket exposure, and the DNS-record angle is cataloged as a dangling DNS record.

The record types that go dangling

Not every record carries the same risk. Understanding which ones dangle, and how, is the first step in a useful detection program.

• CNAME to a vendor hostname. The classic and most common case. Your subdomain aliases to something like a SaaS app, a static-site host, a CDN edge, or an object-storage endpoint. When the backing resource is deleted but the vendor namespace stays open to new registrations, the alias becomes claimable. This is the core of the subdomain-takeover exposure.
• CNAME or A record to an expired apex domain. If your subdomain points at a second domain you let lapse, anyone who re-registers that domain inherits control of your subdomain until the record is pulled.
• NS delegation to an abandoned zone. Delegating a subdomain to a nameserver or hosted zone you later delete can let an attacker recreate the zone on the same provider and serve arbitrary records, sometimes a more powerful primitive than a single CNAME.
• MX records pointing at decommissioned mail infrastructure. Less discussed, but a dangling MX can let an attacker receive email addressed to a trusted subdomain, which feeds password resets and verification flows.
• Dangling A records to released cloud IPs. Elastic and ephemeral public IPs get recycled. A record left pointing at an IP that returns to a provider pool can land on someone else's instance.

The connective tissue across all of these is shared infrastructure with weak ownership binding. The vendor namespace is global, the resource lifecycle is yours, and nothing forces the two to stay in sync. That is also why this problem grows with cloud adoption rather than shrinking: the more resources a team creates and destroys, the more chances a record outlives its target. It is, in a real sense, a shadow IT problem expressed in DNS.

Why this is worse than it sounds

It is tempting to file subdomain takeover under defacement, a cosmetic nuisance on an unimportant hostname. The documented impact is considerably broader, and most of it flows from one fact: browsers and applications grant trust based on the name, not the owner.

• Cookie harvesting across the parent domain. Web apps frequently scope session cookies to `*.example.com`. As Microsoft warns, a hijacked subdomain can read those cookies, and a valid TLS certificate does not help because the attacker can simply request their own certificate for the name they now control.
• Credible phishing on a real, trusted hostname. A login clone served from your own subdomain bypasses the user instinct to check the domain. It can also bypass naive allowlists and email filters that trust your brand's namespace.
• OAuth and SSO abuse. Many SSO and OAuth flows whitelist redirect URIs or trust an entire wildcard subdomain space. A takeover inside that trust boundary can become a path to session or account compromise, which is exactly the kind of broken object level authorization and trust-boundary failure that turns a minor record into a major incident.
• Content and supply-chain injection. If your application or build process fetches scripts, configs, or updates from a subdomain that gets taken over, the attacker can serve malicious payloads to your users or your pipeline.
• Escalation primitives. A controlled same-origin subdomain weakens CORS, CSRF, and XSS defenses that assumed the whole namespace was trustworthy.

A common misconception is that using SSL certificates protects your site, and your users' cookies, from a takeover. However, a threat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate.— Microsoft Azure security documentation, Prevent dangling DNS entries and avoid subdomain takeover

What the incident record shows

This is not a theoretical class of bug. It is a recurring, large-scale one, and the public record is unusually clear because so much of it comes from researchers reporting at scale.

In 2020, researchers documented in reporting from Sophos that more than 670 Microsoft subdomains were vulnerable to takeover because DNS records still pointed at unclaimed cloud resources. The same coverage quotes the practical impact bluntly: an attacker could use a hijacked subdomain for "phishing enterprise credentials with a fake login page" or persuading visitors to install a malicious browser extension. The notable detail is the scale. This was not one forgotten record; it was hundreds, on one of the most security-mature organizations on earth.

The cloud-storage variant produced an even starker demonstration. In research published in early 2025, the team at watchTowr re-registered around 150 abandoned Amazon S3 buckets that had once belonged to governments, Fortune 500 companies, security vendors, and open-source projects. They spent 420.85 dollars to claim the names, enabled logging, and watched. Over roughly two months the reclaimed buckets received more than 8 million HTTP requests for software updates, precompiled Windows, Linux, and macOS binaries, virtual-machine images, CloudFormation templates, and even SSL VPN configurations. The researchers argued an attacker in their position could have hijacked the global software supply chain in a way that would make the SolarWinds compromise look small, and AWS subsequently sinkholed the identified buckets.

Government defenders have institutionalized the concern. CISA's Emergency Directive 19-01 on DNS infrastructure tampering directed federal agencies to audit their public DNS records and to monitor Certificate Transparency logs for certificates issued against their domains that they did not request, a signal that frequently accompanies an attacker establishing a foothold on a hijacked name.

Detection: from enumeration to a validated finding

Detection is where most programs either succeed or drown in noise. A scanner that flags every CNAME pointing at a third party will generate a queue nobody can triage. The goal is a validated finding, not an alert. The OWASP testing methodology breaks this into three disciplined phases, and they map cleanly onto how a serious recon pipeline should run.

1. Enumerate every subdomain you actually have

You cannot check records you do not know about. Comprehensive subdomain enumeration combines passive sources, Certificate Transparency logs, DNS aggregators, and where authorized, active resolution, so that forgotten and rarely-used hostnames surface alongside the obvious ones. This is the asset discovery foundation of any takeover hunt: the records most likely to dangle are precisely the ones least likely to appear in your CMDB.

2. Resolve and fingerprint the targets

For each subdomain, resolve the chain and inspect what answers. The strongest takeover signal is a CNAME that points at a known service whose response is the provider's unclaimed-resource page rather than your content. Mature tooling matches HTTP responses, error bodies, and status codes against a library of provider fingerprints, for example the specific 404 page a static-site host serves when no site is bound to a requested name. A bare NXDOMAIN on the CNAME target, or a provider error explicitly stating the resource does not exist, is a high-confidence lead.

3. Validate ownership before you escalate

Fingerprints narrow the field; they do not close the case. The final step is confirming that the target is genuinely unclaimed and would actually be claimable by an outside party. This is the difference between scanner noise and a finding worth a ticket, and it is exactly the discipline we wrote about in validated findings versus scanner noise. A defender practicing safe exposure validation confirms the dangling state without registering the resource themselves on production infrastructure, and documents the proof so the owning team can act with confidence rather than debate the alert. Skipping this step is how programs accumulate false positives in security scanning until the queue loses all credibility.

Remediation that actually closes the gap

Fixing a single dangling record is trivial. Making sure the next one never reaches production is the real work. Treat remediation as two layers: immediate cleanup and structural prevention.

Immediate cleanup

1. Remove every CNAME, A, NS, or MX record that points at a resource you no longer provision. Per Microsoft's guidance, the record should be deleted from the zone the moment its target is decommissioned.
2. If the subdomain still needs to exist, repoint it at a resource you currently own and control rather than leaving the old pointer in place.
3. If a takeover has already occurred, treat it as an incident: investigate what data, cookies, OAuth credentials, or supply-chain artifacts may have reached the attacker-controlled resource, and follow your response process accordingly.
4. Search application code and configuration for hardcoded references to the affected subdomain so nothing silently re-creates the dependency.

Structural prevention

• Bind DNS lifecycle to resource lifecycle. Where the platform supports it, use alias-style records that empty automatically when the backing resource is deleted, instead of static CNAMEs that outlive their targets.
• Use domain-ownership verification. Several providers let you assert ownership of a custom domain with a verification token, for example a TXT record, so no other tenant can claim the name even if they recreate a resource with the same vendor hostname.
• Add 'remove DNS record' to every decommissioning checklist, and consider delete-locks on resources that carry a custom domain so the mapping must be cleaned up before the resource can be torn down.
• Monitor Certificate Transparency logs for certificates issued against your domains that you did not request, in line with CISA guidance; an unexpected certificate on a subdomain is a strong takeover indicator.
• Run continuous, not annual, checks. New dangling records appear every time a team ships, so detection must be ongoing.

That last point is the one programs get wrong most often. A point-in-time audit finds today's dangling records and says nothing about the ones created next Tuesday. The watchTowr buckets were not exotic; they were ordinary resources that nobody re-checked after deletion. This is the entire argument for continuous attack surface monitoring over the periodic scan, and it is why takeover detection belongs inside a broader external attack surface management practice rather than as a one-off hunt. For the full picture of how dangling DNS fits alongside other exposures, our external attack surface management guide for 2026 maps the territory.

Where this fits in your attack surface program

Subdomain takeover is the cleanest possible illustration of why discovery has to come before assessment. You cannot patch, monitor, or decommission an asset you have forgotten exists, and the forgotten ones are exactly where this risk concentrates. The job to be done is not "scan our known hostnames." It is "continuously know every name that resolves to us, prove which ones are exploitable, and route validated findings to the team that can fix them."

That is the workflow Legba Adversary is built around: enumerate the full external footprint, fingerprint dangling records and other exposures, validate before alerting so engineering trusts the queue, and watch continuously so the next forgotten asset surfaces in days rather than after an attacker finds it first. Dangling DNS rarely arrives alone; the same neglected corners hide an exposed env file, leaked API keys in frontend code, or a forgotten exposed admin panel. Find the forgotten assets first, and the rest of the program has something solid to stand on.