Why Subdomain Takeovers Are the Forgotten Attack Vector (And How to Check for Them)

What a subdomain takeover actually is

When you create a CNAME record pointing to a third-party service — say, docs.yourcompany.com → ghithub.io — you are delegating control of that subdomain to that service. If you later stop using the service but forget to remove the CNAME record, the domain record still points to an address you no longer own or control.

An attacker notices the dangling record, spins up an account on that platform, provisions a matching endpoint, and your subdomain now points to their server. Every cookie, token, or credential your users send to that subdomain goes straight to the attacker.

You wouldn't leave your front door open just because you moved out of a house. But this is effectively what a dangling DNS record does — and it's far more common than it should be.

The real-world damage

Subdomain takeovers are not theoretical. They have been used in real campaigns against real organizations:

• Uber (2016–2017) — A forgotten sc.io subdomain was taken over, allowing attackers to serve phishing pages under Uber's trusted domain. Cookies harvested from the fake page gave full account access to Uber's internal tools.
• Coinbase (2019) — Attackers leveraged a dangling subdomain to host credential-harvesting pages during a spear-phishing campaign, impersonating Coinbase login portals with an apparently legitimate domain.
• Pickman (2024, OAuth bypass) — Researchers found that abandoned SaaS tool subdomains were used to host malicious OAuth callbacks, bypassing token validation in a series of supply-chain attacks against developers.

The common thread: in every case, the victim organization had no idea a subdomain was pointing to infrastructure they no longer owned. The attacker used trust — the trust your users place in anything under your domain — as the entry point.

Common vulnerable patterns

Most takeovers follow a handful of recurring patterns. If your DNS has any of these, you have a gap:

Expired cloud services

AWS, Azure, and GCP all assign predictable S3/Blob storage endpoints. When a bucket is deleted but the DNS record remains, the subdomain starts returning a "bucket not found" error — a clear signal to any attacker running automated scanners. The attacker provisions a bucket with the same name and the subdomain is theirs.

# Dangling CNAME pointing to a deleted AWS S3 bucket
docs.yourcompany.com  CNAME  docs.yourcompany.com.s3.amazonaws.com
# Attacker creates a bucket named "docs.yourcompany.com" — it's game over

Forgotten GitHub Pages

GitHub Pages uses a predictable domain structure: [username].github.io. If you set up a project site or organization page, then deleted the repo or let the plan lapse, the CNAME record stays live. An attacker forks the repo, pushes to their own account under the same name, and controls your subdomain.

# Dangling CNAME from a decommissioned GitHub Pages site
blog.yourcompany.com  CNAME  yourcompany.github.io
# Attacker creates repo "yourcompany" under their GitHub account

Abandoned SaaS tools

Marketing automation platforms, changelog tools, feedback widgets, support portals — these all require DNS delegation when you set them up. When the contract ends or the startup dies, those CNAME records often outlive the service. Inbox tools, SurveyMonkey alternative portals, and customer analytics platforms have all been weaponized this way.

# Common dangling patterns after SaaS tool deprovisioning
feedback.yourcompany.com  CNAME  yourcompany.feedbacksaas.com  # SaaS shutdown
support.yourcompany.com  CNAME  yourcompany.zendesk-support.com  # plan cancelled
status.yourcompany.com  CNAME  yourcompany.statuspage.io  # service shut down

Test and dev environments

Staging and QA subdomains are prime targets — they're often pointed at ephemeral infrastructure that gets decommissioned frequently, and nobody's watching them as closely as production. A staging.yourcompany.com pointing to a deleted Elastic Beanstalk environment is as good as unclaimed territory for an attacker running passive reconnaissance at scale.

How to check if your subdomains are vulnerable

The core of a takeover check is straightforward: for every CNAME record in your zone, verify that the target still resolves to infrastructure you control. If it doesn't, you have a dangling record.

Step 1: Enumerate your CNAME records

Start with a zone transfer or dig output for your domain:

# Find all CNAME records for your domain
dig +short yourcompany.com CNAME
dig +short _dcim._tcp.yourcompany.com CNAME   # SRV records too

# Or use DNSRecon for a full zone dump
dnsrecon -d yourcompany.com -t axfr

Look for anything pointing to third-party domains: AWS, GitHub, Cloudflare, Zendesk, Intercom, HubSpot, generic SaaS platforms. These are your takeover candidates.

Step 2: Check which targets are dangling

For each CNAME target, run a dig query against it and inspect the response. The telltale signs of a dangling record:

• The domain resolves to a cloud provider's IP range but returns an error or NXDOMAIN when visited in a browser
• The DNS query returns a 404 or ownership-error page from the cloud provider (AWS "No such bucket", Azure "Resource not found", GitHub "404 — not found")
• The CNAME resolves but the HTTP host header check rejects the request

# Check if the CNAME target resolves and responds
dig +short some-old-service.yourcompany.com CNAME
# Result: old-service.herokudns.com

# Try an HTTP request against the target
curl -I -H "Host: some-old-service.yourcompany.com" https://12.34.56.78
# 404 or 403 means it's likely dangling

Step 3: Know which providers are highest risk

Not all dangling records are equally exploitable. Some providers will let anyone claim a matching endpoint, while others require account ownership or specific verification steps. Here's the risk breakdown:

• AWS S3, Azure Blob, GCP Cloud Storage — Anyone can claim a deleted bucket name. Highest risk.
• GitHub Pages — CNAME must match a repo you own, but typosquatting on org names can work.
• Heroku — App names are first-come, first-served after deletion.
• ReadMe.io, Intercom, Zendesk — Require account ownership, but can still be exploited via phishing pages under your domain.
• Cloudflare Pages — Requires Cloudflare account verification for custom domains, lower risk but not zero.

Step 4: Automate it at scale

Manual checks work for a handful of subdomains. For a real attack surface assessment, you need automation. EdgeIQ Labs maps your entire DNS footprint, identifies dangling CNAME patterns pointing to decommissioned infrastructure, and flags takeover candidates by risk level — so you can close the gaps before someone finds them.

What to do if you find a dangling record

1. Immediately remove or update the CNAME record — if you no longer use the service, delete the record entirely. A null MX or A pointing to 127.0.0.1 is safer than a dangling CNAME.
2. Audit your other DNS records at the same time — finding one dangling record usually means there are more. Run a full zone review.
3. Check if the subdomain has already been taken over — visit it in a browser and check for unexpected content, OAuth screens, or login pages. If it has, treat it as an active incident.
4. Add subdomain monitoring to your asset inventory — DNS records should be reviewed on a schedule, not just at provisioning time.
5. Document the deprecation process for services — whenever a service is sunsetted or a contract ends, DNS cleanup should be part of the offboarding checklist.

Why this attack vector keeps working

Subdomain takeovers persist because DNS ownership and service ownership are managed in separate systems by separate teams. The developer who spins up a Heroku app and creates the CNAME moves on. The DNS admin doesn't know the app was deleted. Nobody's watching the subdomain to begin with.

Automated reconnaissance tools have made this worse. Attackers run passive scans against entire domain lists, flagging any CNAME pointing to a known-vulnerable provider in minutes. The window between a service being decommissioned and an attacker claiming the subdomain can be very short — and there's no automated alert telling you it's happened.

The fix is simple in concept: treat your DNS zone as an active inventory, not a static configuration. Every record should have a purpose and an owner. Every decommissioned service should trigger a DNS cleanup. And you should be scanning your own subdomains before someone else does it for you.

Quick checklist

• ☐ Enumerate all CNAME records across your domain
• ☐ Verify each target resolves to infrastructure you still control
• ☐ Flag anything pointing to deleted S3 buckets, Heroku apps, GitHub repos, or dead SaaS tools
• ☐ Remove or update dangling records immediately
• ☐ Add DNS review to your service offboarding checklist
• ☐ Set up automated monitoring to catch future gaps