Top 10 Subdomain Takeover Attacks and How to Prevent Them

Subdomain takeovers are one of the most overlooked — and most exploited — attack vectors on the web today. They're easy to find, easy to exploit, and small businesses and enterprises alike leave themselves wide open.

Here's the unsettling truth: when you register a domain, you're not just responsible for the main site. Every subdomain you create — api.yoursite.com, staging.yoursite.com, docs.yoursite.com — is your responsibility too. And attackers know it.

A subdomain takeover happens when a DNS record (usually a CNAME) points to a service you've abandoned — like a GitHub Pages site you deleted, a Heroku app you let expire, or an AWS S3 bucket you removed. An attacker notices the dangling DNS record, claims the target service, and now your subdomain points to their content.

The consequences range from phishing campaigns that abuse your brand reputation to full cookie-based session hijacking. Here's what this attack looks like in practice.

Attack #1 — Abandoned GitHub Pages
Severity: HIGH

The Classic

A CNAME record points to yoursite.github.io, but the GitHub Pages site was deleted. Attacker creates a new GitHub Pages site at that same URL and serves malicious content under your subdomain. Your users see secure.yoursite.com — but it's not your server.

Real example: A financial services firm had portal.yoursite.com pointing to a GitHub Pages site that hadn't been maintained in 2 years. Security researchers found it, claimed the GitHub Pages, and demonstrated full credential capture.

Attack #2 — Expired Heroku App
Severity: HIGH

The "It's Just a Staging Site" Trap

Dev teams spin up Heroku apps for testing, then forget to take them down or remove the DNS entry. The CNAME still points to yourapp.herokuapp.com. Attacker deploys a fake login portal there. Your subdomain — which users trust — becomes a credential harvesting tool.

Attack #3 — AWS S3 Bucket That No Longer Exists
Severity: MEDIUM-HIGH

The Accidental Brand Impersonator

DNS points assets.yoursite.comyoursite-assets.s3.amazonaws.com. You deleted the bucket. Attacker creates a new bucket with that exact name and hosts phishing content. Your users get served malicious files from what appears to be your domain.

Attack #4 — Shopify App After Cancellation
Severity: MEDIUM

The Subscription That Bounces

A CNAME like store.yoursite.com points to your Shopify store. You cancel Shopify. The subdomain still resolves — but now points to a default Shopify placeholder. Attackers have claimed abandoned Shopify store subdomains and used them for phishing campaigns.

Attack #5 — Abandoned WordPress.com Site
Severity: MEDIUM

WordPress.com Is Not Free Forever

If you used WordPress.com's custom domain feature and then let the site expire, your CNAME still points there. Claiming the subdomain is as simple as creating a new free WordPress.com account and claiming the URL.

Attack #6 — Discontinued CloudFront Distribution
Severity: MEDIUM

The CDN Ghost

CloudFront distributions get deleted but the DNS record remains. Attacker creates a distribution with the same domain — or uses a different domain that CloudFront accepts — and your subdomain now serves their content through AWS's infrastructure.

Attack #7 — Unclaimed Azure App Service
Severity: MEDIUM-HIGH

Enterprise Attack Surface

Enterprise environments often have dozens of Azure App Service instances that get decommissioned without cleaning DNS. Azure's default domain (yourapp.azurewebsites.net) is claimable after the service is deleted.

Attack #8 — Discontinued Pantheon Site
Severity: LOW-MEDIUM

Pantheon Drupal/WordPress Hosting

Pantheon hosts Drupal and WordPress sites with a predictable domain structure. When sites are migrated or deleted, the subdomain remains pointing to a no-longer-owned Pantheon domain.

Attack #9 — Abandoned Tumblr Blog
Severity: LOW

Social Media Ghosts

Custom domain pointed to a Tumblr blog that's been deleted. Attacker creates a Tumblr account and reassigns that custom domain. Lower risk, but used in targeted phishing campaigns.

Attack #10 — Ghost CNAMEs From Migrations
Severity: VARIABLE

The "We Moved to CloudFlare" Problem

DNS CNAMEs that were set up for A/B testing tools, analytics platforms, or CDN validations that are no longer in use. They linger indefinitely because no one knows who owns them. Each one is a potential takeover.

How Attackers Find These — In Minutes

Here's the scary part: finding vulnerable subdomains takes less than 10 minutes with free tools. The process:

  1. Certificate Transparency logs — Services like crt.sh and CertSpotter log every SSL certificate issued for your domain. These are public. Attackers download all subdomains ever issued for yoursite.com in seconds.
  2. DNS enumeration — Passive CT scans plus active DNS queries find resolved subdomains.
  3. CNAME resolution — Each subdomain is checked for a CNAME pointing to external services (github.io, herokuapp.com, s3.amazonaws.com, etc.)
  4. Service probing — Does the CNAME target resolve? Does the service respond? Does it return a 404, a default page, or a "claim this" prompt?
  5. Takeover — Attacker creates an account at the target service, claims the subdomain URL, and serves malicious content.

How to Prevent Subdomain Takeovers

Audit Your DNS Regularly

Run a Certificate Transparency scan of your domain every month. Any subdomain pointing to an abandoned or decommissioned service is a risk. Tools like EdgeIQ's Subdomain Hunter make this fast — free tier covers most small business needs.

Clean Up DNS Records When You Deprecate Services

This sounds obvious, but it's almost never done. DNS cleanup is a release step — it should happen every time you take down a service. Document your DNS records and assign ownership.

Use CAA Records for Certificate Issuance

A Certificate Authority Authorization (CAA) record limits which CAs can issue certificates for your domain. This reduces the CT log exposure problem somewhat — but doesn't eliminate it entirely.

Monitor for New Subdomains Continuously

Set up alerts for new subdomains appearing in CT logs for your domain. New subdomains = new attack surface. If you didn't create it, investigate immediately.

Enable HSTS and Preloading

HSTS (HTTP Strict Transport Security) with preloading tells browsers to only connect to your domain over HTTPS — and tells them to reject invalid certificates. It doesn't prevent takeover, but it limits what an attacker can do after a successful takeover.

Scan Your Domains for Subdomain Takeovers

EdgeIQ's Subdomain Hunter checks your domains via Certificate Transparency logs and flags potential takeover vulnerabilities — free, no signup required.

Try the free scanner →

The Business Impact

Subdomain takeovers aren't theoretical. They've been used in real breaches at major companies and are actively exploited in the wild. For small businesses, the reputational damage from being associated with a phishing campaign — even one launched from an "abandoned" subdomain you forgot about — can be devastating.

The fix is simple: know your DNS, audit regularly, and close the gaps before someone else finds them.