Subdomain takeover is one of the highest-impact-per-effort attacks — an attacker gains ability to serve content from yoursubdomain.yourbrand.com for the cost of registering a Heroku app or S3 bucket. Microsoft famously had 670 vulnerable subdomains at one point. Monthly audit is the defence.
Prerequisites
- Read-only access to your DNS zone (or the ability to query it externally)
- Familiarity with your organization’s third-party services (S3, Heroku, GitHub Pages, Netlify, etc.)
Step 1 — Enumerate All Your Subdomains
Sources:
- DNS zone export — most authoritative; export from your DNS provider
- Certificate Transparency logs — every SSL cert issued is logged publicly; query
crt.sh?q=%25.yourdomain.com - DomainScan’s subdomain enumeration — aggregates CT logs + passive DNS + brute force
Use the subdomain finder to get a comprehensive list in one pass.
Common finds: forgotten staging environments (staging.old-project.yourdomain.com), decommissioned services, one-off vendor integrations.
Step 2 — Resolve Each Subdomain
For every discovered subdomain, resolve DNS:
for subdomain in $(cat subdomains.txt); do
echo "$subdomain: $(dig +short $subdomain)"
doneCategorize the results:
- Points to your infrastructure (your own IPs, your own CDN edges) — no takeover risk from CNAME dangling, but audit for other issues
- Points to a third-party CNAME (
*.herokuapp.com,*.s3.amazonaws.com,*.azurewebsites.net,*.github.io,*.netlify.app,*.fastly.net) — potential takeover if that third-party resource is abandoned - NXDOMAIN or resolution failure — dangling; potential takeover depending on the CNAME target
Step 3 — Check for Third-Party Danglers
For each CNAME pointing to a third-party service, verify the resource still exists at the target:
- S3 bucket:
curl -I https://yourbucket.s3.amazonaws.com— 404 withNoSuchBucket= takeoverable - Heroku app:
curl -I https://your-app.herokuapp.com— “There’s nothing here” page = takeoverable - Azure Cloud App: 404 = takeoverable
- GitHub Pages:
curl -I https://user.github.io— 404 = potentially takeoverable - Fastly: hostname returns “Fastly error: unknown domain” = takeoverable
Full pattern list: EdOverflow’s can-i-take-over-xyz is the community-maintained reference.
The subdomain enumeration tool flags these automatically for common providers.
Step 4 — Fix Each Danger
For every dangling CNAME:
Option 1 — Delete the DNS record (recommended if the service is truly retired)
Option 2 — Re-register the third-party resource (if the subdomain is still needed)
Option 3 — Change the CNAME target (if migrating to a new provider)
Never leave a dangling CNAME in place. Attackers scan for them constantly.
Step 5 — Automate the Audit
Manual monthly audits are fragile — humans forget. Options:
- DomainScan continuous monitoring — set up watch on your root domain; get alerts when new subdomains appear or CNAMEs become dangling
- Custom cron — script Step 2 + Step 3 as a nightly job; alert on any changes
- CI check — every deploy that touches DNS records passes through a validator that resolves and confirms the target
Step 6 — Prevent New Dangers
Process changes to stop the pattern:
- Rule: DNS records for third-party services get deleted as part of the service teardown, not after
- Change control: any new CNAME to a third-party service requires an owner + expected lifetime in a shared inventory
- Post-mortem: any subdomain takeover discovered gets an incident post-mortem to prevent the pattern from recurring
Common Miss
- Enumerating only via zone export — misses subdomains created by dev teams outside change control
- Skipping cert transparency logs — CT reveals subdomains you don’t own DNS for but issued certs for
- Not re-auditing after service migrations — the old provider’s records get left behind
- Manual monthly cadence — humans miss cycles
Read what a subdomain takeover is, check the dangling CNAME glossary entry, and set up continuous monitoring via DomainScan’s platform.
Related
Read what a subdomain takeover is, check the dangling CNAME glossary entry, and see the CNAME record glossary entry.