Lion Cipher Lab
Find dangling DNS records before someone takes them over
- Threat Intel Analyst
- Intermediate
- ~50 min
- Free · no account required
Why it matters
Every company creates and deletes cloud resources constantly: a marketing site on Azure App Service for a three-week campaign, an S3 bucket for a product launch, a Heroku app for a status page. The DNS record that pointed promo.yourcompany.com at that resource usually outlives it, because the person who deleted the app did not own the DNS zone. That leftover record is called DANGLING, and on many providers the abandoned name can be registered by anyone. Once an attacker claims it, your subdomain serves their content: a convincing phishing page on your real domain, a script that reads cookies…
What you'll learn
- defining a dangling DNS record -- a record in your zone that points at a cloud resource, IP, or delegated zone you no longer hold -- and why it becomes a subdomain takeover when the provider lets anyone claim that name
- measuring why the naive 'resolve everything and flag NXDOMAIN' check is not enough: on the lab zone it finds 2 of 9 real dangling names and raises 2 false positives
- building an inventory-join auditor in stdlib Python (csv + ipaddress) that compares CNAME targets, A-record IPs, and NS delegations against what you actually hold, finding 8 of 9 on the first run
- recognising the three shapes NXDOMAIN cannot see: A records to released cloud IPs (they resolve fine), CNAMEs to providers that answer every name with a generic 404 page, and NS delegations that fail with SERVFAIL instead of NXDOMAIN
- treating the inventory export as data that goes stale: one false positive (a resource created after the export) and one miss (a bucket deleted after it), both fixed by re-exporting
- remediating the right way -- delete the record or re-claim the resource -- and fixing the process: delete DNS before deprovisioning, and add Azure asuid TXT domain-verification records
- triaging by exploitability using the can-i-take-over-xyz provider list, while still treating every dangling record as a hygiene finding to delete
Steps in this lab
- What a dangling record is, and why someone else can claim it
- How this differs from the neighbouring DNS and attack-surface labs
- Generate the zone, the inventory, and the lookup results
- Write the auditor: one naive mode, one inventory-join mode
- Measure the BEFORE: the NXDOMAIN check finds 2 of 9
- Run the join: 8 of 9 found, and the inventory's own errors
- Refresh the inventory, then remediate the zone and the process
- Triage by exploitability, without skipping any
- Honest negatives: where this auditor is still blind
- When to use this, and how a pro runs it