Subdomain takeover is one of the most elegant attacks in a hacker's toolkit. It requires no exploitation of your servers, no vulnerability in your code, and no social engineering. All it needs is a DNS record pointing to a service you no longer use — and there are thousands of them across the internet right now.
The Anatomy of a Takeover
Here's the typical lifecycle. Your team sets up blog.yourcompany.com with a CNAME pointing to a Heroku app, a GitHub Pages site, or an AWS S3 bucket. Months later, the project is discontinued and the hosting resource is deleted. But nobody removes the DNS record.
Now blog.yourcompany.com has a CNAME pointing to a resource that doesn't exist. An attacker registers that same resource name on the hosting platform, and suddenly they control what's served at your subdomain. No hacking required — just a signup form.
Vulnerable Services
The list of services susceptible to subdomain takeover is extensive and includes many of the most popular platforms:
- GitHub Pages: Dangling CNAME to a deleted repository
- Heroku: CNAME to an unclaimed app name
- AWS S3: CNAME to a deleted bucket (bucket names are globally unique, so an attacker can recreate it)
- Azure: Custom domain pointing to a deprovisioned resource
- Shopify, Tumblr, Unbounce, and dozens more: Each with their own takeover pattern
The telltale sign is usually an error page from the hosting provider: "There isn't a GitHub Pages site here," or "NoSuchBucket." These error messages are breadcrumbs that attackers actively scan for at scale.
What Attackers Do After Takeover
Controlling a subdomain under a legitimate company's domain is extraordinarily powerful:
- Cookie theft: If the parent domain sets cookies with
Domain=.yourcompany.com, the attacker's subdomain can read them. This includes session tokens. - Phishing: A login page at
blog.yourcompany.comis virtually indistinguishable from a legitimate company page. It has the right domain, a valid TLS certificate (via the hosting platform), and bypasses most phishing filters. - OAuth token theft: If your OAuth configuration includes wildcard redirect URIs for subdomains, the attacker can intercept authorization codes.
- Email receiving: With control of the subdomain, MX records can be configured to receive email sent to addresses at that subdomain.
Why It Keeps Happening
The root cause is organisational, not technical. DNS records are created by developers, marketing teams, and agencies. They're rarely inventoried, almost never audited, and deletion of the hosting resource is disconnected from deletion of the DNS entry. In large organisations with hundreds of subdomains, dangling records are inevitable without automated monitoring.
The Scale of the Problem
Security researchers routinely find thousands of vulnerable subdomains in bug bounty programs. In 2024, a single researcher reported over 400 subdomain takeover vulnerabilities across Fortune 500 companies in a six-month period. Automated tools scan the entire internet's DNS records continuously, making this a race between defenders and attackers.
ShieldReport scans your domain's DNS infrastructure to identify dangling records and subdomain takeover risks, catching forgotten entries before they become someone else's attack platform.