Subdomain Takeover
detect, understand, remediate
Subdomain takeover occurs when a DNS record points to a deprovisioned cloud resource, allowing attackers to claim the resource and serve malicious content on a trusted subdomain.
No credit card required. Free plan available forever.
What is subdomain takeover?
Subdomain takeover occurs when a DNS record (typically a CNAME) points to an external service that has been deprovisioned or deleted, but the DNS record remains in place. An attacker can claim the orphaned resource on the external provider and serve arbitrary content on the victim's subdomain, inheriting the trust of the parent domain.
Common targets include cloud services like AWS S3 buckets, Heroku apps, Azure web apps, GitHub Pages, Shopify stores, and Netlify sites. When an organisation deletes the cloud resource but forgets to remove the CNAME record, the subdomain becomes "dangling," pointing to an unclaimed resource that anyone can register.
The impact of subdomain takeover is severe: attackers can serve phishing pages on a trusted subdomain, steal cookies scoped to the parent domain, intercept OAuth callbacks, send emails that pass SPF/DKIM checks, and bypass Content-Security-Policy rules that trust the organisation's domain. Because the subdomain is legitimate, users and security tools are unlikely to flag the malicious content.
How it works
Enumerate subdomains
Attacker discovers subdomains through DNS brute-forcing, certificate transparency logs, or passive DNS databases to build a comprehensive subdomain inventory.
Identify dangling records
Each subdomain is resolved to check for CNAME records pointing to external services. Error pages from cloud providers (e.g. "NoSuchBucket", "There isn't a GitHub Pages site here") confirm the resource is unclaimed.
Claim the resource
The attacker creates a new resource on the cloud provider with the exact name referenced by the CNAME record (e.g. registering the deleted S3 bucket name).
Serve malicious content
The subdomain now resolves to the attacker's resource. They can serve phishing pages, steal cookies, host malware, or intercept traffic, all under the victim's trusted domain.
Common causes
Orphaned DNS records
DNS CNAME records that point to cloud services which have been deleted, expired, or migrated to a different provider. This is the most common root cause of subdomain takeover.
No DNS inventory management
Organisations without a centralised DNS inventory lose track of which records exist, what they point to, and whether the target resources are still active.
Resource deletion without DNS cleanup
Cloud resources are decommissioned by development or operations teams without coordinating with the team that manages DNS records, leaving dangling CNAMEs behind.
Shadow IT and forgotten projects
Proof-of-concept projects, marketing campaigns, and temporary services create DNS records that are forgotten when the project ends and the cloud resource is removed.
How to detect it
Automated detection
- SecPortal's subdomain enumeration and DNS analysis identifies dangling CNAME records pointing to deprovisioned cloud resources
- Continuous monitoring detects newly orphaned records when cloud resources are deleted without corresponding DNS cleanup
- External scanning fingerprints cloud provider error pages across all discovered subdomains to identify takeover candidates
Manual testing
- Resolve all CNAME records and check if the target resources return provider-specific error pages indicating the resource is unclaimed
- Check certificate transparency logs for historical subdomains that may no longer be actively managed
- Attempt to register the orphaned resource name on the cloud provider to confirm takeover is possible (in authorised testing only)
How to fix it
Audit DNS records regularly
Conduct periodic audits of all DNS records to identify CNAME entries pointing to external services. Verify that every target resource is still active and under your control.
Remove stale CNAME records
Immediately delete DNS records for any cloud resource that has been decommissioned. Establish a process requiring DNS cleanup as part of the resource deprovisioning workflow.
Automate subdomain-to-resource tracking
Use infrastructure-as-code and automated tooling to maintain a mapping between DNS records and cloud resources, alerting when a resource is deleted but its DNS record persists.
Monitor for dangling records continuously
Deploy continuous DNS monitoring that checks for CNAME records resolving to unclaimed resources and alerts your security team when a potential takeover condition is detected.
Compliance impact
Related vulnerabilities
Detect subdomain takeover risks
SecPortal enumerates subdomains and checks for dangling DNS records that could be claimed. Start scanning for free.
No credit card required. Free plan available forever.