Subdomain Discovery and Takeover Risk Detection
How subdomain discovery works, what subdomain takeover means, and how to detect and fix dangling DNS records before attackers exploit them.
Subdomain Discovery and Takeover Risk Detection
Subdomains are often added quickly and forgotten. A subdomain pointing to a decommissioned service creates a subdomain takeover vulnerability - an attacker can claim the unclaimed service and serve content from your domain name.
How Subdomain Discovery Works
ElasticDomain's subdomain discovery uses DNS enumeration: it tries to resolve a list of 42 common subdomain prefixes against your domain using DNS resolvers at 8.8.8.8 and 1.1.1.1.
The 42 prefixes checked include:
www, mail, webmail, smtp, ftp, api, app, dev, staging, test, admin, portal, cpanel, ns1, ns2, mx, cdn, static, assets, media, blog, shop, store, support, help, docs, status, git, vpn, remote, db, sso, auth, login, m, mobile, secure, my, account, autodiscover, exchange, cloud
Subdomains that resolve to an IP address are added to your domain's subdomain list. The discovery scan runs 15 parallel DNS lookups at a time with a 2-second timeout per prefix.
Cost: 3 credits per subdomain scan.
What the Results Show
For each discovered subdomain:
| Field | Description |
|---|---|
| Subdomain | Full hostname (e.g. api.example.com) |
| IP address | Resolved IP |
| Status | Up / Down / CNAME only |
| Is live | Whether HTTP/S returned a valid response |
| CDN | Whether it's behind a CDN |
| Takeover risk | Whether a dangling CNAME was detected |
What Is Subdomain Takeover?
Subdomain takeover happens when:
- You create a DNS record like
CNAME staging.example.com → myapp.github.io - You later delete the GitHub Pages project
- The CNAME record remains in DNS - now pointing nowhere
- An attacker creates a GitHub Pages project at
myapp.github.io - They now control what's served at
staging.example.com
This is a real, common vulnerability. The attacker can serve phishing content, set cookies on your domain, or conduct social engineering - all appearing to come from your domain name.
Services Vulnerable to Subdomain Takeover
The most commonly exploited:
- GitHub Pages -
*.github.io(claimed by creating a new Pages project) - Heroku -
*.herokuapp.com(claimed by creating a new Heroku app) - AWS S3 -
*.s3.amazonaws.comand region-specific buckets - Azure -
*.azurewebsites.net,*.blob.core.windows.net - Netlify -
*.netlify.app - Fastly, Shopify, Squarespace — various wildcard subdomain patterns
How ElasticDomain Detects Takeover Risk
For each discovered subdomain, if it resolves via CNAME, the system checks whether the CNAME target returns a "site not found" or "unclaimed" response from the target service.
These specific fingerprints are checked:
- GitHub Pages:
There isn't a GitHub Pages site here - Heroku:
No such app - AWS S3:
NoSuchBucket - Azure:
404 Web Site not found - And others
If found, the subdomain is flagged as Takeover Risk: High and the domain's risk score increases.
How to Fix a Dangling CNAME
- Identify the dangling CNAME from the Subdomains tab.
- Either:
- Remove the CNAME record from your DNS if the service is decommissioned
- Reclaim the service account (re-create the GitHub Pages project, S3 bucket, etc.) if the service should still be active
- Run a new subdomain scan to verify the takeover risk is resolved.
Always remove unused DNS records when you decommission a service. This is the only reliable prevention.
Setting Up Subdomain Monitoring
To get alerted when new subdomains appear or disappear:
- Domain detail → Alerts → Create Alert Rule
- Trigger: New Subdomain Discovered (or Subdomain Removed)
- Save
New subdomain alerts catch: unauthorized subdomain creation (someone with DNS access adding records), subdomain discovery by attackers (if the same subdomain appears elsewhere), and configuration drift.