Subdomain takeover

What it is#

A subdomain takeover occurs when a DNS record, typically a CNAME, points to an external service that has been deprovisioned or unclaimed, and an attacker registers an account on that service to claim the target endpoint. The result is that the attacker controls the content served on the victim's subdomain without ever compromising the victim's DNS or hosting infrastructure directly.

For example, if blog.example.com has a CNAME pointing to example.ghost.io and the organization cancels its Ghost account, the CNAME still exists in DNS. An attacker can create a new Ghost account claiming example.ghost.io and now controls what blog.example.com serves.

The dangling CNAME mechanism#

The vulnerability follows a predictable pattern:

1. An organization creates a subdomain and points it (via CNAME or A record) to a third-party service, a cloud provider, CDN, SaaS platform, or hosting service.
2. The organization later decommissions the service but forgets to remove the DNS record.
3. The third-party service returns an error page or NXDOMAIN for the now-unclaimed endpoint.
4. An attacker discovers the dangling record, provisions a new resource on the same service, and claims the target hostname.

The attacker doesn't need access to the victim's DNS, they only need to create an account on the third-party platform and configure it to respond to the orphaned hostname.

Commonly vulnerable services#

Subdomain takeovers are most common with services that allow users to claim custom hostnames on shared infrastructure:

• Cloud platforms. AWS S3 buckets, Azure blob storage, Azure Traffic Manager, CloudFront distributions, and Heroku apps all allow custom domain mapping and have been frequent takeover targets
• SaaS platforms. GitHub Pages, Shopify, Tumblr, Zendesk, and Fastly are well-documented vectors
• CDN and hosting. Any service where deprovisioning the account doesn't invalidate the hostname binding

Not all services are vulnerable. Some platforms verify domain ownership before allowing hostname claims, which prevents takeover. Vulnerability depends on the service's specific provisioning model.

Impact#

The consequences of subdomain takeover are more severe than they initially appear:

• Phishing credibility. Content served from blog.example.com inherits the trust associated with example.com, making phishing pages far more convincing
• Cookie theft. Cookies set on the parent domain (.example.com) are sent to all subdomains, potentially allowing the attacker to steal session tokens
• Content injection. The attacker can serve arbitrary content, including malware, under a trusted subdomain
• Email implications. In some configurations, SPF records may authorize the subdomain's infrastructure to send email on behalf of the parent domain

Organizations typically fold dangling-subdomain checks into a broader domain monitoring program that also covers external lookalike registrations.

Detection and prevention#

Detection involves scanning DNS records for indicators of dangling references:

• Resolving all CNAME targets and checking for NXDOMAIN responses, default service error pages, or unclaimed-resource indicators
• Periodically auditing DNS zone files for records pointing to services the organization no longer uses
• Monitoring Certificate Transparency logs for certificates issued to subdomains, a takeover attacker will often request a TLS certificate
• Running continuous domain monitoring that covers owned subdomains in addition to external lookalike domains

Prevention is primarily operational hygiene. Remove DNS records when decommissioning services, maintain an inventory of subdomain-to-service mappings, and enforce a change management process that ties service cancellation to DNS cleanup. Some organizations use automation to scan for dangling records on a regular schedule. Maintaining an accurate inventory of all name server delegations and CNAME targets is the foundation of an effective prevention program.