Subdomain takeovers, explained — and how to detect them | Scanthra

Scanthra · 7 min read · Updated May 2026

The mechanism, in one paragraph

Three years ago someone in your team created events.yourcompany.com as a CNAME pointing at your-event-page.herokuapp.com. The marketing campaign ended, the Heroku app was deleted, the CNAME in DNS was forgotten. Today, anyone can sign up for Heroku, claim the name your-event-page.herokuapp.com, and serve any HTML they want. Browsers visiting events.yourcompany.com get their page, with your domain in the address bar, with your brand's trust. TLS works because services like Heroku issue certs automatically. From the browser's point of view, it's a perfectly legitimate visit to your real site.

Why this matters

Real attacks observed in the wild:

• Phishing. "Login to your-bank.example.com" lands on the attacker's page with a perfect TLS lock icon.
• Cookie theft. If your parent domain sets cookies on .example.com, the takeover subdomain can read them by simply living under the same parent.
• SEO poisoning. Attackers redirect from your subdomain to ad-fraud or malware hosts. Google occasionally blacklists the entire example.com as a result.
• Brand damage. A leaked story like "Acme Corp's own subdomain serves crypto-scam pages" is hard to clean up.

The vulnerable services

Subdomain takeover is a class of vulnerability against any SaaS that: (1) lets users claim an arbitrary subdomain on the platform, and (2) doesn't verify that the claimer also owns the original domain. Historically vulnerable platforms have included:

• Heroku, AWS S3 buckets (static-website hosting), Azure Cloud Apps / Traffic Manager / CDN, GitHub Pages, GitLab Pages, Shopify, Squarespace, Tumblr, Webflow, Netlify, Vercel, Fastly, Pantheon, Zendesk, Statuspage, SendGrid, Mailgun, Tilda, Strikingly, Surge.sh, Ghost.io, Cargo, Read the Docs.

Each platform's takeover indicator is slightly different — most show a characteristic "no such app" / "bucket does not exist" / "404 Not Found" fingerprint when the name is unclaimed. The community-maintained EdOverflow/can-i-take-over-xyz repository on GitHub keeps the current list.

How to detect dangling records yourself

Step 1 — Enumerate your subdomains

You can't fix what you don't know about. Sources for a full inventory:

• Your DNS provider's zone file — export every A, AAAA and CNAME record.
• Certificate Transparency logs via crt.sh — every TLS certificate ever issued for your domain is public.
• Past scans, password manager entries, internal wikis — anywhere someone might have added a subdomain that nobody removed.

Step 2 — Resolve each one

For every record:

• If it's an A/AAAA pointing at an IP you no longer own — delete.
• If it's a CNAME pointing at a third-party service, fetch the URL and look at the response. "No such app", "There isn't a GitHub Pages site here", "NoSuchBucket" or "Repository not found" are takeover smells.
• If dig +short cname.subdomain returns an NXDOMAIN for the target — that's a strong takeover signal.

Step 3 — Remove or reclaim

If you don't need the subdomain, delete the DNS record. If you still need it, point it at a current asset. Avoid pointing at "placeholder" cloud apps — they tend to drift into vulnerable state.

How to prevent the next one

• DNS owner per record. Each subdomain record in your zone should have a documented owner in your DNS provider's notes or in an internal spreadsheet.
• Deprovisioning checklist. "Sunset the campaign site" must include "remove the DNS CNAME pointing at the campaign host."
• Quarterly DNS review. 30 minutes per quarter saves a brand-damaging incident.
• Wildcards with care. A wildcard *.example.com CNAME to a third-party service is a permanent takeover invitation for any unclaimed name.

How Scanthra detects this

Our DNS Recon module queries the public Certificate Transparency logs (passively, no DNS brute-force) and flags every subdomain that has ever held a real certificate. We surface development, staging and admin-looking subdomains as findings — the classic candidates for forgotten and dangling records. Subdomain takeover detection itself (checking whether each CNAME target is unclaimed on a known vulnerable provider) is on our roadmap and benefits paying users first.