Subdomain takeover has gone from a party trick security researchers demoed at conferences to a routine finding in bug bounty reports, and the mechanics behind it have shifted substantially since the technique first got attention around 2014-2016. Understanding how these attacks evolved matters because the defenses that worked a decade ago – manually checking a spreadsheet of DNS records once a year – simply don’t hold up against how fast cloud infrastructure now turns over.
Where Subdomain Takeover Started
The earliest documented cases centered on GitHub Pages. A company would set up a CNAME like blog.example.com pointing to a GitHub Pages project, then delete the repository without removing the DNS record. Anyone who noticed the dangling CNAME could register the same project name on GitHub and serve content from the victim’s subdomain.
Frans Rosén’s research around 2014-2015 helped formalize the pattern and gave the security community a name for it. At that point the attack surface was narrow – a handful of services (GitHub Pages, Heroku, a few early PaaS providers) had predictable claiming mechanisms, and most companies had maybe a dozen subdomains total. Finding a vulnerable one meant manually walking through zone files.
The Cloud Shift Multiplied the Attack Surface
Between roughly 2017 and 2020, AWS S3 buckets, Azure endpoints, and Heroku apps became the dominant takeover vectors. An S3 bucket named to match a subdomain, then deleted or renamed, left behind a CNAME pointing at an S3 endpoint that returned a “NoSuchBucket” error – and that error was an open invitation. Anyone could create a bucket with the exact same name (bucket names are globally unique in S3) and immediately serve traffic on the victim’s subdomain.
This period also saw the attack surface explode in volume rather than just in service variety. Marketing teams spun up campaign microsites on Unbounce or Squarespace. Engineering teams provisioned throwaway Heroku dynos for demos. DevOps automated CNAME creation through Terraform and CloudFormation templates, which meant subdomains got created faster than anyone was tracking their teardown. A mid-size SaaS company that had 15 subdomains in 2014 might have had 200+ by 2019, spread across a dozen cloud providers, with no single owner responsible for cleanup.
Can Yıldızlı and other researchers published extensive service-by-service fingerprinting guides during this window – documenting the exact HTTP response signatures (404 messages, error pages) that indicated a claimable resource for each of dozens of providers. That fingerprint database is essentially what automated scanners still rely on today.
Automation and Scale, 2020 Onward
Tools like Subjack, tko-subs, and later Nuclei templates turned what used to be manual reconnaissance into scriptable, repeatable scans. An attacker no longer needed to understand the nuances of each cloud provider – they could point a scanner at a target’s subdomain list, pulled from certificate transparency logs via crt.sh, and get a report of likely-vulnerable entries in minutes.
This is also when subdomain takeover started showing up as a recurring category in HackerOne and Bugcrowd disclosure statistics, often ranking among the more commonly reported issue types on programs with large attack surfaces. It’s not usually the highest-severity finding on a program, but it’s one of the most frequently *found*, because certificate transparency logs make subdomain enumeration essentially free for anyone looking.
The past three or four years added a wrinkle: dangling DNS isn’t limited to CNAMEs anymore. Researchers have documented takeover paths through orphaned NS delegations, stale MX records pointing at abandoned mail services, and even IP-based A records for decommissioned cloud instances that get reassigned to a new tenant on providers like AWS EC2 or DigitalOcean. The core mechanic – a DNS record pointing at a resource you no longer control – hasn’t changed, but the number of record types and services it applies to keeps expanding.
A Persistent Myth Worth Correcting
A lot of teams still believe subdomain takeover only affects CNAME records pointing at third-party SaaS platforms. That was true in 2015. It is not true now. Dangling CNAME records remain the most common vector because they’re the easiest to fingerprint, but A records pointing at released cloud IPs, NS records delegating to unclaimed name servers, and even some misconfigured TXT-based domain verification setups have all produced confirmed takeovers in the wild. Scoping a review to “just check the CNAMEs” leaves real gaps.
How the Defensive Playbook Has Changed
A decade ago, the standard advice was an annual DNS audit – export the zone file, eyeball it, move on. That cadence made sense when subdomain counts were low and change velocity was slow. It does not make sense when a growth team can spin up a new campaign subdomain on a Tuesday and abandon it by Friday.
An experienced security engineer today treats subdomain inventory as a continuously changing dataset, not a static list reviewed once a quarter. The practical shift has been toward continuous, automated discovery paired with DNS health checks – catching a dangling pointer within hours of the underlying resource being deprovisioned, rather than months later during the next scheduled audit. Preventing takeover now depends less on any single person remembering to delete a record and more on having a system that flags the orphaned pointer automatically.
The other change is organizational. Ten years ago, DNS was owned by a single network admin. Now, with self-service cloud provisioning, marketing platforms, and dozens of engineers with DNS write access, no one person has full visibility into what’s live. That’s less a technology problem than a process one, and it’s why keeping a subdomain inventory current has become its own discipline rather than a side task bolted onto a broader security audit.
Common Mistakes Teams Still Make
Three patterns show up repeatedly in postmortems. First, treating a deprovisioned cloud resource as “done” without checking whether the DNS record pointing at it was also removed – the two cleanup steps live in different systems and different teams, so they drift apart. Second, relying on certificate transparency monitoring alone and assuming that catches everything; it only surfaces subdomains that ever had a TLS certificate issued, missing plenty of internal or HTTP-only entries. Third, running a one-time subdomain scan after a security incident and calling it solved, instead of recognizing that the subdomain list will look completely different again in six months.
Frequently Asked Questions
Is subdomain takeover still a common finding in 2026?
Yes. It remains a regularly reported issue class in bug bounty programs, largely because cloud provisioning keeps outpacing DNS cleanup, and certificate transparency logs make the initial discovery step trivial for anyone scanning.
Which record types are most at risk today?
CNAME records pointing at deprovisioned cloud services (S3, Azure, Heroku-style PaaS) are still the largest category, but A records pointing at released cloud IPs and orphaned NS delegations have both produced confirmed takeovers and are frequently overlooked.
How often should subdomains be reviewed to catch this early?
Given how quickly cloud resources get spun up and torn down, a quarterly or annual review cadence is too slow. Continuous monitoring that flags a dangling pointer within hours or days of a resource being decommissioned is what closes the actual window of exposure.
The pattern across ten years of subdomain takeover history is consistent: attackers follow wherever provisioning outpaces cleanup. As long as new services and new record types keep appearing, the specific vector will keep shifting – but the underlying fix, knowing exactly what’s pointing where and reacting fast when something goes stale, hasn’t changed at all.