Lion Cipher Lab
Find and fix dangling DNS records before a subdomain takeover
- Penetration Testing / Red Team
- Intermediate
- ~55 min
- Free · no account required
Why it matters
Companies spin cloud services up and tear them down constantly: an S3 bucket for a launch, a GitHub Pages site for docs, a Heroku app for a status page, an Azure app for a three-week campaign. The CNAME that pointed promo.company.com at that service usually outlives it, because the person who deleted the service did not own the DNS zone. That leftover record is DANGLING, and on many providers anyone can re-register the released service name and then serve their own content on your real subdomain: a phishing page that passes a glance at the URL, a script that reads cookies scoped to your…
What you'll learn
- explaining how a dangling CNAME (a record that still points at a cloud service the org deprovisioned) becomes a subdomain takeover when the provider lets anyone re-register that service name
- building an offline detection pipeline in stdlib Python: inventory the records, resolve each CNAME target against a stub resolver, fingerprint the target against a table of 'unclaimed service' signatures, and report what is dangling and takeable
- measuring why the naive 'flag CNAMEs whose target returns NXDOMAIN' check is not enough: on the lab surface it finds 2 of 10 dangling names and misses every provider that still resolves
- quantifying the two honest costs of fingerprinting: a false positive (a claimed GitHub Pages repo returns the unclaimed-site body) and a false negative (an Azure CDN target has no stable fingerprint, so it is never examined)
- recognising two more traps: a wildcard CNAME that answers for every name so NXDOMAIN never fires, and a dangling CloudFront record that is real debt but cannot be re-registered
- remediating correctly -- delete or repoint the dangling record, confirm a false positive is actually yours, remove the wildcard -- and re-running to prove 0 takeable records remain
Steps in this lab
- What a dangling CNAME is, and why a stranger can claim it
- Why the outside view needs a different tool from the inventory lab
- Build the surface: records, a stub resolver, and a fingerprint table
- Write the detector: a naive mode and a fingerprint mode
- Measure the BEFORE: the naive NXDOMAIN check finds 2 of 10
- Run the pipeline: 9 of 10 found, and the two it gets wrong
- Two traps: the wildcard that hides everything, and the record you cannot claim
- Remediate, then prove zero remain
- The judgment: when to fingerprint, and how a pro keeps it fixed