Subdomain takeover: finding dangling DNS records at scale

In November 2024, a team at watchTowr Labs went shopping for garbage. They looked for Amazon S3 storage buckets that organisations had once used and then deleted, leaving the names free for anyone to re-register. They claimed about 150 of them. The bill, according to watchTowr's own AWS console screenshot, came to $420.85. Over the following two months those empty buckets received more than eight million HTTP requests. The machines making them were asking for software updates, unsigned Windows and Linux and macOS binaries, virtual machine images, JavaScript files, SSL VPN configuration files, and CloudFormation templates that define cloud infrastructure. The requests came from government networks in the United States and the United Kingdom, from military address space, from Fortune 100 companies, payment card networks, banks, universities, and cybersecurity vendors. One trail led to a 2012 CISA advisory that still pointed readers at a patch executable sitting in a bucket nobody owned any more. watchTowr served nothing. Had they wanted to, they controlled what millions of machines would have installed. AWS agreed to sinkhole the buckets before publication.

The pointer that outlives the thing it points to

A DNS record is a pointer. When your browser wants shop.example.com, it asks the Domain Name System, and somewhere in that system sits a record saying: this name is an alias for example-shop-prod.azurewebsites.net. That alias is a CNAME record, short for canonical name. Another record then says that canonical name resolves to an IP address, and your browser connects. The pointer and the thing it points to have separate lifecycles, and that is the whole vulnerability. Delete the cloud resource and the CNAME does not notice. It keeps pointing. In the terminology introduced by Daiping Liu, Shuai Hao and Haining Wang in their 2016 ACM CCS paper, that record is now dangling, borrowed deliberately from the dangling-pointer bugs that plague C programs. Their abbreviation, Dare, has not really caught on, but their framing has: a DNS record is a pointer, and DNS has no mechanism to check that the pointer is still valid. What makes this exploitable rather than merely untidy is that cloud providers hand out globally unique names from a shared pool. example-shop-prod.azurewebsites.net is not yours forever. When you delete the App Service instance, the name usually goes back in the pool, and the next person who asks for it gets it. Microsoft's own documentation, updated in July 2026, walks through exactly this sequence and calls subdomain takeover "a common, high-severity threat." There is a detail here that trips people up. A dangling record does not produce NXDOMAIN, the DNS response meaning "no such name." The name resolves perfectly well. It resolves to a service that returns a 404, or a "no such bucket" error, or a generic provider landing page. To a monitoring system watching for DNS failures, nothing is wrong. To an attacker, that 404 body is a fingerprint.

Four kinds of stale, three ways in

Liu and colleagues catalogued which record types are security-sensitive when they dangle. A records point at an IPv4 address. CNAME records alias to another name. MX records name your mail servers. NS records delegate a whole zone to an authoritative nameserver. All four can be abused, and each fails differently. They also identified three distinct routes to control. The first is IP address reuse in public clouds. They built a tool called IPScouter that repeatedly allocated and released cloud IP addresses to see how fast a specific address could be harvested. On EC2-VPC and Azure the count of distinct addresses obtained grew roughly linearly, around 5,000 and 2,200 new addresses per day respectively. The cost of running this was approximately $0.07 per day on EC2 and half a cent per day on Azure, which is to say, free. Holding a cheap instance to keep an address cost them about $100 a year. The second route is abandoned third-party services: Shopify, WordPress, Heroku, GitHub Pages, Tumblr. You pointed a CNAME at the service, cancelled the account, forgot the record. Anyone can now sign up and claim that hostname. The third is expired domains, where the target of a CNAME, MX or NS record is a registrable domain that nobody renewed. Their measurement covered Alexa top-1M apex domains from 2010 to 2016, plus brute-forced subdomains of the top 10,000 general, 2,700 .edu and 1,700 .gov domains, about 288 million DNS queries yielding roughly 570,000 valid subdomains. They confirmed 791 dangling records and flagged 5,982 more as potential, with 467 exploitable cases spread across 277 top-10,000 domains and 52 .edu zones. The examples are mundane in a way that is the point: support.mediafire.com broke during a website rebuild, books.panerabread.com outlived a discontinued Amazon partnership, bedshed.com.au had NS glue records pointing at a nameserver that no longer existed.

Finding them at scale is the easy part

The attacker's pipeline has four stages, and all four are commodity. Enumerate. Get a list of an organisation's subdomains. Certificate Transparency logs are the single richest source: since browsers require publicly logged certificates, every TLS certificate ever issued for anything.example.com is in a searchable append-only log, queryable through services like crt.sh. Add passive DNS datasets and dictionary brute-forcing and you have tens of thousands of names for a large organisation. Resolve. Check which names still answer, and what they point to. Fingerprint. Match the response against a known list of "this service returns this error when the resource is unclaimed." The community reference for this is can-i-take-over-xyz, which documents roughly 97 services with per-service claiming instructions, of which about 39 are currently marked vulnerable. The project ships a machine-readable fingerprints.json that dozens of scanning tools consume directly. Claim. Sign up, create the resource with the matching name, serve content. The asymmetry is brutal. Keytos automated stage three against Azure specifically by inverting Certificate Transparency: find which certificate authorities Azure uses, scan CT logs for certificates those CAs issued, check whether the site still works, and if not, check whether the Azure resource is claimable. Their May 2023 write-up reports over 30,000 vulnerable domains in the first month of running this and roughly 15,000 new vulnerable Azure subdomains per month since, from scanning under 1% of Azure certificates. These are vendor figures from a company selling a monitoring product, so treat the precision with some caution; the order of magnitude is consistent with what independent researchers find. The more uncomfortable number in that write-up is the response rate. Of more than 1,000 organisations notified, roughly 2% fixed anything.

The most rigorous public measurement remains Squarcina, Tempesta, Veronese, Calzavara and Maffei's USENIX Security 2021 paper. They enumerated 26 million subdomains under the top 50,000 registrable domains in the Tranco list and found 1,520 subdomains exposed to takeover, distributed across 887 distinct domains. Named victims included cnn.com, time.com, harvard.edu, mit.edu, nih.gov, europa.eu, lenovo.com and cisco.com. Their breakdown is instructive. Discontinued third-party services accounted for 83% of confirmed cases, expired domains for the remaining 17%, and 93% of vulnerable subdomains sat on just four platforms: WordPress, Shopify, Tumblr and GitHub Pages. They also flagged 187,498 subdomains across 13,532 sites as potentially vulnerable through deprovisioned cloud instances, a heuristic result they were careful not to overclaim. Exposure tracks attack surface: among .edu domains, which averaged 6,033 subdomains each, 7.32% had at least one vulnerable subdomain, against 1.81% for .com. And in July 2026, Silent Push published DangleGeddon, a simulation across government, banking, automotive and pharmaceutical targets. From 12,500 apex domains they isolated roughly 16,000 dangling subdomains, of which about 4,000 could be taken over by fully automated script; they classed around 7,000 as needing manual review and 5,000 as protected by provider safeguards. They used Claude Opus 5 to generate the takeover tooling and report having a working mass-exploitation script "within hours." Confirmed takeovers touched a US federal agency, a large French bank, a Fortune 500 automaker and a pharmaceutical company, all through disclosure programmes. Silent Push sells DNS threat intelligence, so read it as a vendor demonstration; the specific claim worth taking seriously is that the expensive part of the pipeline, deciding which of thousands of candidates is actually claimable, is now cheap.

The misconception that keeps this alive: "it's only a marketing page"

Ask a security team why a subdomain takeover ticket has been open for six months and the answer is usually some version of: that subdomain hosted an old campaign site, there is nothing on it, worst case someone defaces a page nobody visits. This misreads where the value sits. The value is not the content. It is the name. Cookies are the clearest case. Web applications routinely set cookies scoped to .example.com so they work across www, app and account. Any subdomain can read them. Squarcina's team measured this directly: of 24,924 session cookies collected, 3,390 (14%) from 687 sites (81% of those analysed) could have their confidentiality violated by an attacker controlling a sibling subdomain. For integrity the numbers are worse, because cookie shadowing lets a related-domain attacker overwrite cookies regardless of the Secure flag: 24,689 cookies, 99%, across 834 sites. The __Host- cookie prefix exists to fix this and they found exactly one cookie using it. Microsoft's documentation names the specific misconception: "A common misconception is that SSL certificates protect your site and your users' cookies from a takeover." They do not. Whoever controls the subdomain can pass a certificate authority's domain validation check and obtain a genuine, browser-trusted certificate for it, free, in minutes. The padlock then works in the attacker's favour. Beyond cookies, a controlled subdomain sits inside trust boundaries that were drawn assuming the whole domain is one organisation. Content Security Policy allowlists that permit *.example.com become script injection paths; Squarcina found 45 sites where frame injection became actually exploitable this way. CORS policies that reflect related origins leaked credentials in 63 additional cases. document.domain relaxation, OAuth redirect allowlists and postMessage handlers all commonly trust siblings. A dangling MX record is worse still: it lets the attacker receive mail for the subdomain, which means password resets and certificate validation emails. The economics have their own misconception attached, which is that this is a solved, dead bug class. It is not. Shopify paid the USENIX team $1,000 for a flaw in how their platform handled www-prefixed custom domains, and GitHub told the researchers they were "exploring various changes to the custom domain flow" to require formal ownership verification. Typical bug bounty payouts for subdomain takeover cluster around $1,000, reaching five figures where real impact is demonstrated, and researchers were still collecting them in 2026.

The verification gap, and whose problem it is

Every one of these attacks succeeds because a service accepts a claim without checking it. You tell Shopify or Azure or a CDN "I control shop.example.com," and it takes your word. The most systematic look at this is a September 2024 arXiv preprint introducing DVAHunter, which tested domain verification across 45 major CDN providers. The finding: 39 of the 45 performed no verification at all, and the six that did remained exploitable. Measuring 89 million subdomains from Tranco's top 1M across those CDNs, the authors identified over 332,000 subdomains vulnerable to domain abuse. Twelve providers confirmed the reports and six, including Edgio, shipped fixes. This is a preprint rather than a peer-reviewed conference paper, and the 332,000 figure depends on heuristics, but the headline structural point, that ownership verification is the exception rather than the rule, is not seriously contested. Where verification exists it works. Azure App Service lets you publish an asuid.{subdomain} TXT record containing your domain verification ID; with that record present, no other Azure subscription can claim the custom domain. GitHub Pages and ngrok place their user-content domains in the Public Suffix List, which tells browsers to treat them as registry boundaries and blocks cookie sharing between tenants. Squarcina's team found 20 of 31 services they examined did not do this, meaning any registered user of those platforms was in a related-domain position relative to every other customer.

Sitting Ducks: the same disease, one level up

In July 2024, Eclypsium and Infoblox published research on a variant that targets NS records rather than CNAMEs. The technique, which they named Sitting Ducks, exploits lame delegation: a domain is registered at one company and delegated to a different DNS provider, but the provider has no zone configured for it. If that provider lets a new account claim the domain without proving ownership, the attacker gets full authoritative control, all records, no registrar access required.

Eclypsium estimated roughly one million exploitable domains with at least 30,000 hijacked since 2019. Infoblox's follow-on monitoring put the identifiable vulnerable population at around 800,000, of which roughly 70,000 were later confirmed hijacked. Those two figures come from different methodologies and are not directly comparable; treat the scale as "hundreds of thousands to a million" rather than a precise count. What makes Sitting Ducks different from a classic takeover is who benefits. These are not bug bounty findings. Infoblox attributes sustained use to named actors: Vacant Viper, active since 2019, hijacking about 2,500 domains a year to feed a traffic distribution system called 404TDS for spam and remote access trojans, and Horrid Hawk, active since February 2023, with close to 5,000 hijacked domains pushing fake government investment schemes on social media. Brian Krebs reported affected domains once belonging to CBS Interactive and, pointedly, the Anti-Phishing Working Group, and named DNSMadeEasy, DigitalOcean and Hostinger among providers whose claiming flows were implicated. Infoblox's Dave Mitchell summarised it: "It's easy to exploit, very hard to detect, and it's entirely preventable." Krebs's diagnosis of why an eight-year-old weakness persisted is worth sitting with. Registrars point at DNS providers, DNS providers point at registrars, neither bears the cost of the fraud, and no standard forces the question.

What actually closes the window

The single highest-leverage change is order of operations. OWASP's prevention cheat sheet spells it out: remove or repoint the DNS record first, wait for the TTL to expire, and only then delete the cloud resource. Most organisations do the reverse, because deleting the resource is the thing that stops the bill. Structurally, the better fix is to stop letting the two lifecycles diverge. Azure DNS alias records bind a record to a specific Azure resource so that deleting the resource empties the record set rather than leaving it pointing into space, though today that only covers Front Door, Traffic Manager, CDN endpoints and public IPs. AWS took a different angle: its June 2026 CIRT write-up, which states plainly that AWS has observed threat actors scanning for dangling CNAMEs, points at account-scoped regional S3 bucket namespaces, introduced in March 2026, which remove the global-uniqueness property that made bucket names claimable in the first place. That is the right shape of fix: not detection, but making the resource name un-stealable. Everything else is hygiene that has to be automated to matter. Run Microsoft's Get-DanglingDnsRecords or an equivalent across your zones. Enable Defender for App Service, which alerts when a site is decommissioned with its custom domain still mapped. Put "remove DNS record" on the decommissioning checklist and use resource delete locks as a tripwire. Monitor Certificate Transparency for your own domains so you learn about certificates issued for your names before an attacker does. Add CAA records restricting which certificate authorities may issue for your domain, which Keytos found almost nobody had configured. And narrow the blast radius: scope cookies to exact hosts rather than .example.com, avoid wildcard CSP allowlists, and keep OAuth redirect URIs explicit.

What to watch

The defender needs a complete and continuously accurate inventory of every DNS record their organisation has ever created, mapped to a cloud resource that still exists and that they still own. The attacker needs one record. That asymmetry has always favoured the attacker, but until recently the attacker's advantage was bounded by the cost of triage: you could enumerate a million candidate hostnames, but deciding which handful were genuinely claimable, on which of 97 services, with which signup flow, was slow manual work. That bound is what is dissolving. Whether Silent Push's specific numbers hold up or not, the direction is clear, and it points somewhere uncomfortable: the population of dangling records that are theoretically vulnerable and the population that is practically exploitable are converging. The genuinely open question is whether the fix arrives at the layer that can actually deliver it. Fifteen thousand new vulnerable Azure subdomains a month and a 2% remediation rate among notified organisations is not a story about careless administrators; it is a story about a workflow that guarantees failures at a rate no checklist absorbs. Account-scoped namespaces and lifecycle-bound alias records are the only mitigations on this list that make the mistake impossible rather than merely detectable. Watch how fast providers other than AWS and Azure follow, and whether mandatory domain ownership verification becomes a baseline expectation of any service that accepts a custom hostname. Until it does, every organisation is one forgotten CNAME away from hosting someone else's phishing page under its own certificate.

Sources

1. watchTowr Labs, 8 Million Requests Later, We Made The SolarWinds Supply Chain Attack Look Amateur, 2025.
2. Daiping Liu, Shuai Hao and Haining Wang, All Your DNS Records Point to Us: Understanding the Security Threats of Dangling DNS Records, ACM CCS, 2016.
3. Marco Squarcina, Mauro Tempesta, Lorenzo Veronese, Stefano Calzavara and Matteo Maffei, Can I Take Your Subdomain? Exploring Related-Domain Attacks in the Modern Web, USENIX Security, 2021.
4. Microsoft, Prevent dangling DNS entries and avoid subdomain takeover, Microsoft Learn, updated 2026.
5. Amazon Web Services, Threat tactic spotlight: Subdomain takeover, AWS Security Blog, 2026.
6. Eclypsium, Ducks Now Sitting (DNS): Internet Infrastructure Insecurity, 2024.
7. Brian Krebs, Don't Let Your Domain Name Become a "Sitting Duck", KrebsOnSecurity, 2024.
8. Infoblox, Horrid Hawk: New Domain Hijacking Threat Actor, 2024.
9. Keytos, Microsoft Azure Vulnerability Still Affecting Thousands of New Subdomains Each Month, 2023.
10. Silent Push, Welcome to Danglegeddon, 2026.
11. Ziyu Lin et al., Detecting and Measuring Security Implications of Entangled Domain Verification in CDN, arXiv preprint, 2024.
12. EdOverflow and contributors, Can I take over XYZ?, GitHub, ongoing.
13. OWASP, Subdomain Takeover Prevention Cheat Sheet, OWASP Cheat Sheet Series.
14. Sylvain Leroux, DNS Tree, Wikimedia Commons, CC BY-SA 3.0.