Subdomain Takeover: How Attackers Hijack Your Forgotten Subdomains

Your company has hundreds of subdomains. Some were created for a marketing campaign three years ago. Some pointed to a Heroku app that was deleted. Some were test environments that never got cleaned up. Every one of those forgotten subdomains with a dangling DNS record is a subdomain takeover waiting to happen — and attackers are actively scanning for them.

What Is Subdomain Takeover?

A subdomain takeover occurs when a DNS record (usually a CNAME) points to an external service that no longer exists, and an attacker claims that service to gain control of the subdomain. The DNS record still exists, so browsers trust the subdomain. But the content is now served by the attacker.

Here is a concrete example:

1. Your company creates blog.example.com and points it to a GitHub Pages site: blog.example.com CNAME yourcompany.github.io
2. The project is abandoned. Someone deletes the GitHub repository but does not remove the DNS record.
3. An attacker creates a new GitHub repository called yourcompany.github.io and adds a CNAME file with blog.example.com.
4. blog.example.com now serves the attacker's content, under your domain name.

This is not hypothetical. Subdomain takeover is one of the most commonly reported vulnerabilities in bug bounty programs. Major companies including Microsoft, Starbucks, and Uber have had subdomains taken over.

Why Subdomain Takeover Is Dangerous

An attacker who controls a subdomain can:

• Host phishing pages under your legitimate domain. A login page at portal.yourcompany.com looks completely authentic to users and even to email security filters.
• Steal cookies. If your main domain sets cookies with Domain=.yourcompany.com, the attacker's subdomain can read those cookies, including session tokens. This can lead to account hijacking across your entire application.
• Bypass Content Security Policy. If your CSP allows *.yourcompany.com, the attacker can inject scripts from their controlled subdomain.
• Send authenticated emails. If your SPF record includes the subdomain or uses a broad mechanism, the attacker can send emails that pass SPF checks from your domain.
• Damage brand reputation. An attacker can host malware, adult content, or scam pages on your subdomain, causing blocklisting and reputational harm.
• Issue SSL certificates. The attacker can obtain a valid SSL certificate for the subdomain from Let's Encrypt (HTTP-01 challenge), making the takeover look completely legitimate.

How Dangling DNS Records Happen

The root cause is always the same: a DNS record outlives the service it points to. Here are the most common scenarios:

Scenario 1: Decommissioned Cloud Services

A team provisions an S3 bucket, Azure Blob Storage, or Heroku app for a project. They create a CNAME record. The project ends, the cloud resource is deleted, but the DNS record remains. The gap between "resource deleted" and "DNS record removed" is the vulnerability window.

Scenario 2: Expired SaaS Subscriptions

Your marketing team uses a landing page builder (Unbounce, Instapage, etc.) and points promo.example.com to it. The subscription lapses. The CNAME still resolves, but the service returns a "page not found" error. An attacker creates an account on the same service and claims the domain.

Scenario 3: CDN Deprovisioning

You set up a CDN distribution (CloudFront, Fastly, Akamai) for a subdomain. When you delete the CDN distribution but keep the CNAME, the subdomain becomes claimable by anyone who creates a new distribution on the same CDN.

Scenario 4: Development and Staging Environments

Developers create staging.example.com pointing to a cloud instance. The instance is terminated but the DNS record persists. If the IP address is reassigned to another cloud customer, that customer now controls your subdomain.

Vulnerable Services

Not all services are equally vulnerable to subdomain takeover. The key factor is whether an attacker can register and claim a hostname on the service after you have released it.

High-risk services (takeover is straightforward)

• GitHub Pages: Attacker creates a repo with a CNAME file matching your subdomain. One of the most commonly exploited.
• Heroku: Attacker creates a Heroku app and adds your subdomain as a custom domain. Heroku does not verify domain ownership.
• AWS S3 (website hosting): If your CNAME points to yourbucket.s3-website-us-east-1.amazonaws.com and the bucket is deleted, an attacker creates a bucket with the same name in the same region.
• AWS Elastic Beanstalk: Similar to S3. CNAME points to yourapp.us-east-1.elasticbeanstalk.com. Attacker creates a new EB environment with the same name.
• Surge.sh: Simple claim process via CLI.
• Pantheon: Custom domain registration without verification.
• Shopify: Attacker creates a Shopify store and adds your subdomain.

Medium-risk services (takeover requires specific conditions)

• AWS CloudFront: If a CNAME points to a deleted CloudFront distribution, an attacker can create a new distribution and add your subdomain as an alternate domain name. AWS added mitigations but edge cases remain.
• Azure: Various Azure services (App Service, Traffic Manager, CDN) have been vulnerable. Microsoft has added ownership verification for many services.
• Fastly: An attacker can create a Fastly service and configure it for your subdomain.

Lower-risk services (mitigations in place)

• Cloudflare: Cloudflare verifies domain ownership via TXT records before allowing custom domains.
• Netlify: Added domain verification in 2023.
• Vercel: Requires DNS verification.

How to Detect Subdomain Takeover Risks

Step 1: Enumerate All Subdomains

You cannot protect subdomains you do not know about. Use multiple enumeration techniques to build a complete inventory:

# Method 1: Certificate Transparency logs (most reliable)
# CT logs record every SSL certificate ever issued for your domain
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[].name_value' | sort -u

# Method 2: DNS brute forcing with common subdomain wordlist
# Using a tool like subfinder, amass, or dnsx
subfinder -d example.com -silent

# Method 3: Check your DNS zone file directly
# Export from your DNS provider (Route 53, Cloudflare, etc.)
aws route53 list-resource-record-sets --hosted-zone-id ZXXXXX | \
  jq -r '.ResourceRecordSets[] | select(.Type=="CNAME") | .Name'

Our Exposure Checker uses Certificate Transparency logs to automatically enumerate all known subdomains for your domain. Use our DNS Lookup tool to investigate individual subdomain records.

Step 2: Identify Dangling CNAMEs

For each CNAME record, check whether the target still exists:

# Check if a CNAME target resolves
dig +short blog.example.com
# Returns: yourcompany.github.io.

dig +short yourcompany.github.io
# If this returns NXDOMAIN or SERVFAIL, the CNAME is dangling

# Batch check all CNAMEs
for sub in $(cat subdomains.txt); do
  cname=$(dig +short CNAME "$sub" | head -1)
  if [ -n "$cname" ]; then
    target_ip=$(dig +short "$cname" | head -1)
    if [ -z "$target_ip" ]; then
      echo "DANGLING: $sub -> $cname"
    fi
  fi
done

Step 3: Check for Takeover Indicators

HTTP response patterns that indicate a subdomain is takeover-ready:

# Check HTTP response for service-specific error pages
curl -sI https://blog.example.com | head -5

# Common takeover indicators in response body:
# GitHub Pages: "There isn't a GitHub Pages site here."
# Heroku: "No such app"
# S3: "NoSuchBucket"
# Shopify: "Sorry, this shop is currently unavailable"
# Tumblr: "There's nothing here."
# Fastly: "Fastly error: unknown domain"
# Pantheon: "404 error unknown site!"
# Ghost: "The thing you were looking for is no longer here"

How to Prevent Subdomain Takeover

1. Remove DNS Records When Deprovisioning Services

This is the most important prevention measure. Make it part of your decommissioning checklist: always remove DNS records before or at the same time as deleting the service. Never delete the service first and "clean up DNS later" — "later" often means "never."

2. Maintain a Subdomain Inventory

You cannot manage what you do not track. Maintain a registry of all subdomains, what service they point to, who owns them, and when they were last verified. Review this inventory quarterly.

# Export all DNS records monthly and diff against previous export
# Route 53 example:
aws route53 list-resource-record-sets \
  --hosted-zone-id ZXXXXX \
  --output json > dns-records-$(date +%Y%m).json

# Compare with last month
diff dns-records-202603.json dns-records-202602.json

3. Use DNS TXT Verification Where Possible

Some services support domain verification via TXT records before accepting custom domains. Always enable this when available. It prevents attackers from claiming your subdomain even if you have a dangling CNAME.

4. Monitor Certificate Transparency Logs

If someone issues an SSL certificate for your subdomain, it will appear in CT logs. Monitor CT logs for unexpected certificates — this can be an early warning of a takeover attempt.

# Set up CT monitoring
# Use a service like Cert Spotter (sslmate.com/certspotter)
# or monitor crt.sh directly

# Check for recently issued certificates
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[] | select(.not_before > "2026-03-01") | "\(.not_before) \(.name_value)"'

5. Set Restrictive Cookie Scopes

Do not set cookies with Domain=.example.com unless absolutely necessary. This makes cookies accessible to all subdomains, including any that might be taken over. Use the most specific domain possible for session cookies.

# DANGEROUS: Cookie accessible to ALL subdomains
Set-Cookie: session=abc123; Domain=.example.com; Secure; HttpOnly

# SAFER: Cookie only accessible to the specific subdomain
Set-Cookie: session=abc123; Domain=app.example.com; Secure; HttpOnly

# SAFEST: No Domain attribute (defaults to the exact host)
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict

6. Restrict Your CSP

Avoid using wildcard subdomains in your Content Security Policy. Instead of script-src *.example.com, list specific subdomains. This way, even if a subdomain is taken over, it cannot inject scripts into your main site. Build a precise CSP with our CSP Builder.

7. Automate Detection

Manual checks do not scale. Use automated tools to continuously monitor for dangling records:

• subjack: Open-source tool that checks CNAME records against a fingerprint database of vulnerable services.
• nuclei: Versatile scanner with subdomain takeover detection templates.
• can-i-take-over-xyz: Community-maintained list of services vulnerable to subdomain takeover, with fingerprints and proof of concepts.

Real-World Subdomain Takeover Examples

• Microsoft (2020): Security researcher found over 670 Microsoft subdomains vulnerable to takeover via dangling CNAMEs pointing to Azure services. Some pointed to deprovisioned Azure TrafficManager endpoints.
• Starbucks (2019): A subdomain CNAME pointed to a deprovisioned Azure resource. Reported via HackerOne bug bounty.
• Uber (2016): saostatic.uber.com pointed to an unclaimed Amazon CloudFront distribution.
• Numerous S3 takeovers: Thousands of websites have had subdomains taken over because a CNAME pointed to a deleted S3 bucket. The attacker creates a bucket with the same name and serves arbitrary content.

According to HackerOne's annual report, subdomain takeover consistently ranks among the top 10 most reported vulnerability types in bug bounty programs.

Frequently Asked Questions

How do I find all my subdomains?

Use Certificate Transparency logs (crt.sh), which record every SSL certificate ever issued. This reveals subdomains you may have forgotten. Complement with your DNS provider's zone export and subdomain enumeration tools like subfinder or amass. Our Exposure Checker automates CT-based subdomain discovery and checks each one for takeover risk.

Can an attacker get an SSL certificate for my taken-over subdomain?

Yes. Once an attacker controls the content served on the subdomain, they can complete an HTTP-01 challenge from Let's Encrypt and obtain a valid, trusted SSL certificate. This makes the takeover completely transparent to users — the browser shows a green padlock and a legitimate-looking URL. This is why prevention (removing dangling DNS records) is far more important than detection.

Is subdomain takeover possible with A records (not just CNAMEs)?

Yes, in cloud environments. If an A record points to an elastic IP or cloud instance that you release, the IP may be reassigned to another customer. That customer then controls traffic to your subdomain. This is less common than CNAME takeover because cloud IPs are randomly assigned, but it does happen. AWS has introduced protections like "Bring Your Own IP" and IP address retention, but the risk exists on all cloud platforms.

Does Cloudflare protect against subdomain takeover?

Partially. If your DNS is on Cloudflare and the subdomain is proxied (orange cloud), Cloudflare serves its own error page instead of allowing the dangling CNAME to resolve. However, DNS-only (gray cloud) subdomains are still vulnerable. Also, Cloudflare cannot protect against takeovers if the dangling record points to a service outside Cloudflare's proxy. The best protection is still removing unused DNS records. Read our DNS Explained for Developers guide for more context.

The Bottom Line

Subdomain takeover is one of the easiest attacks to prevent and one of the most commonly neglected. The fix is simple: remove DNS records when you decommission services. The hard part is maintaining discipline across teams and years of infrastructure changes. Build a subdomain inventory, automate monitoring with CT logs, remove dangling records immediately, and make DNS cleanup part of every service decommissioning checklist. One forgotten CNAME record is all it takes for an attacker to operate under your domain name.

Related tools and articles: Exposure Checker, DNS Lookup, Whois Lookup, SSL Checker, DNS Record Types Explained, DNS Explained for Developers, SPF/DKIM/DMARC Guide, SSL Security Checklist, and 70+ more free tools.