Subdomain Takeover: How It Works and How to Prevent It

How does subdomain takeover work?

The attack exploits a gap between DNS configuration and cloud resource lifecycle:

Step 1: Organisation creates a service. A team sets up a marketing site on GitHub Pages and creates a CNAME record: promo.example.com → your-org.github.io.

Step 2: Service is decommissioned. The GitHub Pages repository is deleted, but the DNS CNAME record remains. This is the “dangling” record.

Step 3: DNS resolves to an unclaimed resource. When a browser requests promo.example.com, DNS resolves the CNAME to your-org.github.io, which no longer exists. The cloud platform returns an error page.

Step 4: Attacker claims the resource. The attacker creates a GitHub Pages site at your-org.github.io (or whatever endpoint the CNAME references). The cloud platform accepts this because the resource name is available.

Step 5: Attacker controls your subdomain. Now when anyone visits promo.example.com, they see the attacker’s content - served from your domain with your domain’s trust and reputation.

Which services are vulnerable to subdomain takeover?

Not every external service is vulnerable to takeover. The attack only works when:

1. The DNS record uses a CNAME pointing to a specific resource on the platform
2. The platform allows anyone to claim that resource name after it’s released

Services commonly vulnerable to takeover:

Service	Indicator of vulnerability
AWS S3	NoSuchBucket error
GitHub Pages	”There isn’t a GitHub Pages site here”
Heroku	”No such app”
Azure (various)	NXDOMAIN or platform-specific 404
Shopify	”Sorry, this shop is currently unavailable”
Fastly	”Fastly error: unknown domain”
Pantheon	”404 error unknown site”
Tumblr	”There’s nothing here”
Zendesk	”Help Center Closed”

Each platform has a distinct error message or response pattern that indicates the resource is unclaimed and potentially takeable.

What is the impact of a successful subdomain takeover?

A successful takeover gives the attacker significant capabilities:

Phishing. The attacker serves a convincing login page on auth.example.com or login.example.com. Victims see a legitimate domain in the address bar and trust the page. This is phishing with your domain’s reputation.

Cookie theft. An attacker controlling any subdomain of example.com can set cookies scoped to .example.com. This enables session hijacking, CSRF attacks, and authentication bypass against your main application.

SEO hijacking. The attacker hosts spam or malware on your subdomain. Search engines attribute this content to your domain, damaging your reputation and potentially triggering malware warnings.

Brand damage. Content served on your subdomain reflects on your organisation. Defacement, political messaging, or offensive content on your-subdomain.example.com is visible to anyone and associated with your brand.

How do you detect subdomain takeover vulnerabilities?

Manual detection

For each of your subdomains with CNAME records pointing to external services, check whether the external resource still exists:

# Check what a CNAME points to
dig promo.example.com CNAME

# Check if the target resource responds normally
curl -sI https://promo.example.com

If the CNAME target returns a platform-specific error page (see the table above), the subdomain is likely vulnerable to takeover.

Automated detection

Tools built for takeover detection:

• Subzy - fast subdomain takeover checker, supports 40+ services
• Subjack - CNAME takeover detection with fingerprint matching
• Nuclei - ProjectDiscovery’s scanner includes takeover detection templates

These tools take a list of subdomains and check each CNAME against known vulnerable platform fingerprints.

How do you prevent subdomain takeover?

Preventing subdomain takeover is straightforward in principle - the challenge is operational discipline:

1. Remove DNS records when decommissioning services. This is the root cause fix. When you delete a GitHub Pages site, Heroku app, or S3 bucket, delete the corresponding DNS record at the same time. Make DNS cleanup part of your decommissioning checklist.

2. Provision DNS records after creating resources. Reverse the typical order: create the cloud resource first, verify it works, then add the DNS record. This ensures the record never points to a non-existent resource.

3. Audit CNAME records regularly. Periodically review all CNAME records for your domains. For each CNAME pointing to an external platform, verify the target resource still exists and is under your control.

4. Use monitoring. Continuous subdomain monitoring catches dangling records as they appear - when a team decommissions a service without cleaning up DNS, the monitoring flags the vulnerability.

5. Consider alternatives to CNAME for external services. Some platforms support verification mechanisms (TXT records, meta tags) that reduce takeover risk. Where available, use these instead of or in addition to CNAME records.

What did the SubdoMailing campaign reveal about subdomain takeover risk?

In early 2024, researchers uncovered “SubdoMailing” - a massive campaign that exploited over 8,000 legitimate domains through dangling DNS records. Attackers used orphaned SPF includes and CNAME records to send fraudulent emails that passed authentication checks, bypassing email security filters at scale.

This campaign demonstrated that subdomain takeover isn’t just a web content risk - DNS misconfigurations can be exploited for email fraud, ad fraud, and other abuses that leverage a domain’s established reputation.