Subdomain Takeover: How Attackers Hijack Your Subdomains

What is subdomain takeover?

Subdomain takeover occurs when a DNS record (usually a CNAME) points to an external service that has been deprovisioned or deleted, but the DNS record itself was never removed. An attacker can then claim that resource on the external service and serve their own content on your subdomain.

For example, imagine you set up blog.yourcompany.com as a CNAME pointing to yourcompany.github.io. Later, you delete the GitHub Pages repository but forget to remove the DNS record. An attacker can now create a GitHub Pages site called yourcompany.github.io and serve whatever content they want -- all under your legitimate domain.

Why is this dangerous?

Subdomain takeover is not just a theoretical risk. Attackers exploit it for:

Phishing and credential theft

An attacker controlling portal.yourcompany.com can host a convincing login page. Because the domain is legitimately yours, browsers show no warning and users have no reason to be suspicious.

Cookie theft and session hijacking

If your main domain sets cookies with Domain=.yourcompany.com, those cookies are sent to every subdomain -- including the taken-over one. This can give attackers access to session tokens.

SEO hijacking

Attackers can host spam or malware on your subdomain, damaging your domain's reputation and search rankings.

Bypassing email authentication

If the attacker controls the subdomain, they may be able to send emails from it, especially if your SPF record or DMARC policy does not explicitly cover all subdomains.

Commonly vulnerable services

These services are frequently involved in subdomain takeover because they allow users to claim resources by name:

Service	Fingerprint (error when unclaimed)
AWS S3	"NoSuchBucket"
GitHub Pages	"There isn't a GitHub Pages site here"
Heroku	"No such app"
Azure (various)	"NXDOMAIN" or default Azure page
Shopify	"Sorry, this shop is currently unavailable"
Surge.sh	"project not found"
Fastly	"Fastly error: unknown domain"
Pantheon	"404 error unknown site"
Tumblr	"There's nothing here"
Zendesk	"Help Center Closed"

How to detect dangling DNS records

Manual check with dig

# Check what the CNAME points to
dig CNAME blog.yourcompany.com +short

# If it returns something like yourcompany.github.io, verify the target exists
dig yourcompany.github.io +short

# If the target returns NXDOMAIN or no A record, you have a dangling CNAME

Check all subdomains at once

First, enumerate your subdomains:

# Using subfinder (open source subdomain enumeration)
subfinder -d yourcompany.com -o subdomains.txt

# Then check each one for dangling records
while read sub; do
  result=$(dig CNAME "$sub" +short)
  if [ -n "$result" ]; then
    echo "$sub -> $result"
    dig "$result" +short > /dev/null 2>&1 || echo "  WARNING: target may not exist"
  fi
done < subdomains.txt

Using subjack

subjack is a purpose-built tool for detecting subdomain takeover:

go install github.com/haccer/subjack@latest
subjack -w subdomains.txt -t 100 -timeout 30 -ssl -v

How to fix

Option 1: Remove the stale DNS record

The simplest fix -- if you no longer need the subdomain, delete the CNAME (or A record) from your DNS provider.

# Verify it is removed
dig CNAME old-service.yourcompany.com +short
# Should return nothing

Option 2: Reclaim the service

If you still need the subdomain, re-create the resource on the external service before an attacker does. Then either keep it active or migrate to a new setup.

Option 3: Point to a controlled resource

If you want to keep the DNS record for future use, point it to something you control -- even a simple static page saying "Coming soon" hosted on your own infrastructure.

Prevention checklist

1. Maintain a DNS inventory. Keep a living document of every DNS record, what it points to, and who owns it. Review it quarterly.
2. Delete DNS records before deprovisioning services. Make this a mandatory step in your offboarding process for any cloud service.
3. Monitor for dangling records. Use automated scanning to catch records that no longer resolve. See our guide on orphan DNS records.
4. Use CNAME validation where possible. Some services (like AWS CloudFront) require you to prove domain ownership before serving content -- prefer these over services that do not.
5. Audit third-party services regularly. Know which services have access to serve content on your domains.
6. Implement a strong DMARC policy. A DMARC policy at p=reject prevents attackers from sending email as your taken-over subdomain.

How SurfaceScan helps

SurfaceScan automatically discovers all subdomains across your attack surface and checks each one for signs of subdomain takeover. It detects dangling CNAME records pointing to deprovisioned services, flags the specific service involved, and alerts you before an attacker can claim it. Every scan re-checks your DNS records, so you will be notified if a new dangling record appears after a service is decommissioned. Results appear in the DNS section with clear remediation steps.