table of contents
Attackers love forgotten DNS records. You point a subdomain to a cloud service like AWS S3 or Heroku. Then you delete the resource but leave the DNS entry. Now anyone can claim that subdomain and serve phishing pages under your brand.
This gap happens often. Recent scans show dangling records across SaaS, CDNs, and storage platforms. Hackers exploit them for credential theft or malware. A solid subdomain takeover audit spots these risks before they bite.
You can fix this with basic tools and checks. Let’s walk through the process.
Spot the Threat: Understand Subdomain Takeover Basics
Subdomain takeover starts with a dangling DNS record. Your team creates staging.example.com as a CNAME to a Heroku app. The app goes away. The CNAME stays.
An attacker sees the record. They register the same Heroku app name. Traffic now hits their server. In 2026 reports, Fly.io and JetBrains apps topped vulnerable lists.
False positives trip up audits. A CNAME might resolve to a live IP you control. Or the provider blocks new registrations. Always verify.
Check provider docs first. Services change rules. For example, Azure now requires TXT verification IDs for custom domains.
Build Your Audit Workflow
Start with inventory. List all subdomains. Use tools like Subfinder or certificate transparency logs at crt.sh.
Next, query DNS for each. Focus on CNAMEs and A records pointing to third parties. Tools like dnsReaper scan fast with 50+ signatures.
Distinguish real risks. A true dangling condition shows NXDOMAIN on the CNAME target. Curl the URL for provider error pages like “no such bucket” on S3.
Conducting the Audit
Gather your list. Export from your DNS provider or run passive recon.
Query records in bulk. Use dig or MassDNS for speed.

Prioritize by type. CNAMEs to SaaS lead the pack. Run this bash loop on your subdomain list:
for sub in $(cat subdomains.txt); do
dig +short $sub CNAME | while read cname; do
dig +short $cname A || echo "$sub -> $cname (dangling)";
done;
done
Follow up manually. Visit the target. Look for takeover fingerprints like empty repos on GitHub Pages.
Tools automate this. Try Subjack for Go-based scans. It flags stale A records too. Double-check results. Providers update fingerprints often.
Track changes. Version your DNS with Terraform. This logs who added what.
Common Misconfiguration Patterns
SaaS platforms dominate risks. Helpdesks like Intercom leave chat widgets dangling. CDNs such as CloudFront buckets sit unused.
Here’s a quick reference:
| Platform Type | Example Services | Telltale Sign |
|---|---|---|
| Cloud Storage | AWS S3, Azure Blob | “NoSuchBucket” error |
| App Hosting | Heroku, Fly.io | “No such app” page |
| CDN | CloudFront, Fastly | 403 with service name |
| Docs/Static | GitHub Pages, Netlify | Repo not found |

Uptimerobot and Cargo Collective appear in fresh 2026 incidents. Discourse forums also pop up. Always test live; lists evolve.
A records fool scanners less. Dead IPs might just mean deprovisioned servers you own. Ping them or check ARIN whois.
Remediation Best Practices
Delete the record first. Confirm via dig it vanished.
Validate ownership. Log into the provider. Search for the resource name. If gone, good.

Enforce change management. Require pull requests for DNS updates. Pair with service catalogs mapping subdomains to owners.
Monitor ongoing. Set alerts on CT logs for your domains. Schedule weekly scans with TakeOver or Nuclei templates.
Follow OWASP’s prevention cheat sheet. It covers alias records and verification IDs.
For complex setups, book a discovery call with Bud Consulting. They handle attack surface mapping.
Conclusion
Regular audits keep dangling records at bay. Focus on enumeration, validation, and quick fixes. Tools like dnsReaper speed the work.
You now spot true risks from noise. Providers shift, so recheck often. Clean DNS shrinks your attack surface fast.
Stay vigilant. One overlooked CNAME can cost big.


