BIPI
BIPI

Subdomain Takeover: The Dangling DNS Problem That Won't Die

Cybersecurity

Dangling CNAMEs pointing at deprovisioned S3 buckets and Heroku apps still hand attackers fresh subdomains every week. The fix is boring asset hygiene, not a new tool.

By Arjun Raghavan, Security & Systems Lead, BIPI · September 1, 2024 · 7 min read

#subdomain-takeover#web-security#asset-management

We did an external recon engagement for a fintech in February. 1,847 subdomains discovered via certificate transparency logs. Fourteen had dangling CNAMEs. Three were claimable inside an hour. One pointed at a deleted S3 bucket that had hosted marketing assets four years ago and nobody removed the DNS record.

That subdomain still appeared in old email campaigns and partner integration docs. We registered the bucket with the same name, served a benign page, and the security team confirmed the takeover. Real attackers would have served credential phishing on a domain customers trusted.

How attackers find dangling records

Certificate transparency is the starting point. Every TLS cert your org has issued in the last decade sits in public CT logs. Tools like crt.sh, Subfinder, and Amass pull thousands of subdomains in seconds. Attackers then resolve each one and check for the fingerprint of an unclaimed cloud resource: an S3 NoSuchBucket error, a Heroku 'No such app', an Azure Traffic Manager 404, a GitHub Pages 'There isn't a GitHub Pages site here'.

Automated scanners like nuclei have hundreds of takeover templates. Bug bounty hunters run them across every program in scope, every day. If your subdomain becomes claimable at 2am, someone notices by 4am.

The cloud services that fail open

  • AWS S3, CloudFront (with custom CNAMEs), Elastic Beanstalk
  • Heroku apps, Fastly services, GitHub Pages, GitLab Pages
  • Azure App Service, Traffic Manager, CloudApp
  • Shopify storefronts, Tumblr blogs, Zendesk subdomains
  • Any SaaS that lets you claim a subdomain string with no domain verification

The pattern is identical: customer points DNS at the service, customer cancels the service, DNS record stays. The service provider sees the resource as available and lets the next customer claim the same name. Most providers added domain verification after years of takeovers, but legacy customers and edge cases still slip through.

Detecting your own dangling records

Pull every CNAME and ALIAS record from your authoritative DNS. Resolve each target. If the target returns NXDOMAIN, or returns a known takeover fingerprint, flag it. We run this nightly with a 200-line Python script that hits Route53, Cloudflare, and NS1 APIs and posts to Slack on findings. Total cost: a t3.micro and an analyst's hour to triage false positives.

For organisations that don't know what DNS zones they own, start with CT logs. crt.sh '%.yourcompany.com' returns every subdomain a public CA has ever signed for you. Cross-reference against your DNS export. The diff is the unknown surface.

Prevention beats detection

When a team spins up a marketing landing page on Heroku and points marketing.yourcompany.com at it, two things should happen. The DNS change should require an approver who knows the resource lifecycle. And the cloud account that owns the Heroku app should be tagged with the DNS record, so when the project is decommissioned, the DNS record gets killed in the same change.

We see the same pattern in every breach review: a project shipped, the team disbanded, the budget was cut, the DNS stayed. Treat DNS records as infrastructure with owners, not as set-and-forget config.

The 30-day plan

  1. Export every DNS record from every zone you own
  2. Resolve all CNAMEs and flag NXDOMAIN or takeover fingerprints
  3. Manually claim or remove dangling records (don't wait for ticketing)
  4. Add an owner tag to every CNAME record with a Jira ticket reference
  5. Schedule the resolution check to run nightly with paging on findings

Subdomain takeover is the cheapest external attack path against most organisations. The defence is also cheap. The reason it keeps working is nobody owns DNS hygiene as a product, and the records outlive the people who created them.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.