Subdomain Takeover: The Silent Risk Lurking in Your DNS

A subdomain takeover is one of those vulnerabilities that sits quietly for months until someone stumbles across it — usually a bug bounty hunter, occasionally an attacker. It doesn't require a zero-day, a leaked password, or any sophisticated exploit. It just requires a forgotten DNS record and a few minutes of someone else's time.

If your company has ever spun up a marketing landing page on Webflow, a docs site on GitHub Pages, or a temporary demo on Heroku and pointed a subdomain at it, you already have the ingredients for a potential takeover. The question is whether anyone cleaned up after themselves.

What Subdomain Takeover Actually Is

It happens when a subdomain (like promo.yourcompany.com) has a DNS record — usually a CNAME — pointing to an external service that no longer has a matching resource claimed. The DNS entry is still live, but the destination is "unclaimed," meaning anyone can register that same resource on the third-party service and effectively take control of your subdomain.

Once claimed, an attacker can:

• Host phishing pages under your legitimate domain (huge trust boost for scams)
• Steal cookies or session tokens if your cookies aren't scoped tightly
• Intercept OAuth redirects if the subdomain was ever used in an auth flow
• Serve malware while your domain's reputation absorbs the damage
• Bypass CSP or CORS rules that trust your parent domain by wildcard

A Realistic Example

Say your team created launch.yourcompany.com pointing to a CNAME on a Heroku app for a product launch two years ago. The campaign ended, someone deleted the Heroku app, but nobody removed the DNS record. Today, an attacker can create a new Heroku app, claim the same subdomain string, and Heroku will happily serve their content under launch.yourcompany.com — with a valid SSL certificate they can even provision themselves through Let's Encrypt.

Which Services Are Commonly Vulnerable

Almost any platform where resources are claimed by name is a candidate. The usual suspects include:

• GitHub Pages — unclaimed username.github.io repos
• Heroku — deleted apps with dangling CNAMEs
• AWS S3 — buckets pointed to by CNAME that were deleted or renamed
• Shopify — stores that were closed but DNS wasn't updated
• Fastly / Cloudfront — distributions removed without DNS cleanup
• Zendesk, Statuspage, Unbounce, Tumblr — anything with a "custom domain" feature
• Azure and Cloud services — cloudapp.net, trafficmanager.net endpoints

The common thread: a third-party service where account/resource names are user-chosen and reusable.

How to Detect Subdomain Takeover Risk

1. Enumerate Every Subdomain You Own

You can't audit what you don't know exists. Pull subdomains from multiple sources:

• Your DNS provider's zone file (the authoritative source)
• Certificate Transparency logs (crt.sh is free and searchable)
• Passive DNS tools like SecurityTrails or DNSDumpster
• Internal records — old project docs, marketing team spreadsheets, Slack history

Agencies managing multiple client domains should treat this as a recurring quarterly task, not a one-off audit — new subdomains get created constantly by marketing, DevOps, and third-party integrations.

2. Check Each CNAME's Resolution Status

For every subdomain with a CNAME record, resolve it and check whether the destination service returns a "not found," "no such app," or "domain not claimed" style response. Signature examples:

• GitHub Pages: "There isn't a GitHub Pages site here"
• Heroku: "No such app"
• S3: "NoSuchBucket"
• Shopify: "Sorry, this shop is currently unavailable"

Any of these responses on a live CNAME is a strong signal the subdomain is takeover-ready.

3. Use Automated Scanning Instead of Manual Checks

Manually resolving DNS and reading error fingerprints for hundreds of subdomains doesn't scale, especially across an agency's full client portfolio. This is exactly the kind of check that belongs in a recurring automated scan rather than a one-time spreadsheet exercise.

WebSentry checks DNS configuration as part of its overall security grading, flagging dangling records and misconfigured CNAMEs alongside SSL, headers, CSP, and cookie issues — so subdomain risk doesn't get missed simply because it's not the thing anyone remembers to check manually.

How to Prevent It Going Forward

Fix the Immediate Problem

1. Remove the DNS record if the subdomain is genuinely no longer needed — this is the cleanest fix.
2. Re-claim the resource on the third-party service if the subdomain is still needed, before an attacker does.
3. Verify ownership using the provider's domain verification (TXT records, etc.) so the resource can't be silently re-pointed later.

Build Process Around It

• Maintain a DNS inventory — a living document (or better, code-managed DNS via Terraform) listing every subdomain, its purpose, owner, and expiry date.
• Add decommission steps to project checklists — when a campaign, staging environment, or integration ends, DNS cleanup should be a mandatory step, not an afterthought.
• Restrict who can create DNS records — sprawl usually comes from marketing tools or individual engineers self-serving subdomains without central visibility.
• Avoid wildcard CNAMEs pointing to shared third-party infrastructure unless absolutely necessary.
• Set calendar reminders for time-limited campaigns and demo environments so DNS records don't outlive their purpose by years.

Monitor Continuously

Subdomain takeover isn't a "fix once" problem — new dangling records get created every time a team spins up a new tool integration. Continuous monitoring catches the drift that inevitably happens as teams grow and tooling changes.

Running periodic scans through WebSentry gives you an ongoing DNS health check alongside the rest of your security posture (SSL expiry, missing security headers, loose CORS policies, cookie flags), so a dangling CNAME gets caught in weeks rather than surviving for years.

Why This Matters More for Agencies

If you manage security for multiple client domains, subdomain takeover risk multiplies fast. Each client likely has their own history of marketing tools, staging environments, and abandoned integrations — and client teams rarely tell you when they spin something down. A scanning workflow that runs across your entire client portfolio, rather than relying on someone remembering to check DNS manually, is the only way this scales without becoming a liability.

Run a free scan at websentry.dev to check your domains — including DNS configuration, dangling CNAMEs, SSL, headers, and cookie security — and get an A–F grade showing exactly where the risk sits.