What Is Subdomain Takeover?

A subdomain takeover occurs when an attacker gains control over a subdomain of a target domain. According to Mozilla Developer Network, subdomain takeover happens when "a subdomain has a canonical name (CNAME) in the Domain Name System (DNS), but no host is providing content for it." This creates an orphaned DNS record where the DNS entry still points to an external service that is no longer in use by the organization, allowing an attacker to claim that service and host content under the victim's subdomain. HackerOne describes it as a situation where "a virtual host hasn't been published yet or a virtual host has been removed" but the DNS record persists, enabling attackers to control what content appears at that subdomain.

How does subdomain takeover work?

Subdomain takeover exploitation follows a specific sequence relying on organizational DNS misconfiguration.

Orphaned DNS records create the fundamental vulnerability. Organizations configure subdomains pointing to external services like Heroku applications, AWS S3 buckets, GitHub Pages, Azure services, or Shopify stores. For example, api.example.com CNAME api-example.herokuapp.com points the subdomain to a Heroku application. When the service is later decommissioned or the bucket or project is deleted, the DNS record pointing to the external service is not removed, creating an orphaned CNAME entry that points to a non-existent or unclaimed resource.

Service-specific vulnerability determines whether takeover is possible. Common vulnerable services include AWS S3 (bucket deletion without DNS cleanup), Heroku (app deletion leaving DNS), GitHub Pages (repository deletion or domain removal), Microsoft Azure (deleted resources), Shopify (removed stores), and Firebase (decommissioned projects). Each service has different claim mechanisms, but the pattern is consistent: if a DNS record points to a service resource that no longer exists or is unclaimed, attackers can create that resource under their control.

Attack exploitation begins with attacker identification of the orphaned CNAME record through subdomain enumeration. The attacker creates an account with the vulnerable hosting provider and claims the resource name referenced in the DNS record. For example, if the CNAME points to api-example.herokuapp.com, the attacker creates a Heroku app with that exact name. For S3 buckets, the attacker creates a bucket with the name specified in the DNS record and uploads malicious content. For GitHub Pages, the attacker creates a repository and configures it with the target domain.

Attack capabilities once takeover succeeds include hosting phishing pages at the victim's subdomain, serving malware appearing to come from the legitimate domain, conducting cross-site scripting attacks against the parent domain if cookie scope allows, accessing cookies set from the parent domain in some configurations, and bypassing Content Security Policy through subdomain origin trust. The subdomain can be used in OAuth flows if incorrectly configured, capturing session cookies or authorization codes. Cross-site request forgery attacks become possible using the trusted subdomain origin.

Mozilla MDN, OWASP, and Microsoft Azure Security documentation all emphasize that subdomain takeover occurs due to operational process failures rather than technical vulnerabilities. Organizations forget to remove DNS records when decommissioning services, creating the opportunity for attackers to claim abandoned infrastructure and host malicious content under legitimate domains.

How does subdomain takeover differ from related techniques?

Subdomain takeover differs from domain hijacking in scope and method. Domain hijacking requires gaining full control of the entire domain through registrar account compromise, typically changing ownership or nameserver details. Hijacking affects the entire domain and all subdomains, disrupting all services. Subdomain takeover affects only a single misconfigured subdomain without requiring any credential compromise or active attack against domain infrastructure. The attacker simply claims an abandoned third-party service that existing DNS records point to.

Domain shadowing requires active compromise of DNS or registrar credentials to create unauthorized subdomains under legitimate domains. Domain shadowing is an access-based attack requiring credential theft through phishing or credential stuffing. Subdomain takeover requires no compromise whatsoever—only identification of orphaned DNS records and registration with the third-party service provider. Domain shadowing creates new malicious subdomains, while subdomain takeover claims existing subdomains through service provider mechanisms.

Subdomain enumeration is reconnaissance rather than exploitation, identifying all subdomains of a target domain. Enumeration tools discover both legitimate and orphaned subdomains but take no action beyond discovery. Subdomain takeover is the exploitation phase that follows enumeration when orphaned records are discovered. However, subdomain enumeration provides the means for attackers to discover vulnerable subdomains, making it a prerequisite step for identifying takeover opportunities.

The fundamental distinction is that subdomain takeover results from process failures (forgetting to remove DNS records) rather than security breaches or technical vulnerabilities. Organizations create the vulnerability themselves through incomplete decommissioning procedures.

Why does subdomain takeover matter?

Subdomain takeover remains actively exploited despite widespread awareness, demonstrated by continued bug bounty reports and security research documentation. HackerOne bug bounty reports regularly include subdomain takeover vulnerabilities affecting major companies including Uber, Starbucks, HackerOne itself, Shopify, and numerous others. Bug bounty platforms explicitly list subdomain takeover as in-scope submissions with significant rewards, demonstrating continued real-world exploitability and organizational concern.

The vulnerability database reflects widespread exposure. The "Can I take over XYZ?" project documents 76 services vulnerable to subdomain takeover through various claim mechanisms. Nuclei, a widely-used security scanner, includes 72 detection templates specifically for identifying subdomain takeover vulnerabilities across different service providers. The variety of vulnerable services demonstrates that this is not a single-vendor issue but rather a systematic problem affecting cloud infrastructure broadly.

Subdomain takeover vulnerability persists "even after six years" of security community awareness, according to multiple security researchers. Developers continue to forget removing DNS records pointing to decommissioned third-party services, creating a constant stream of new vulnerable subdomains. The persistence suggests that organizational processes fail to incorporate DNS cleanup into infrastructure decommissioning procedures, making this an operational rather than awareness problem.

The economic impact demonstrated through bug bounty payouts indicates real security concern. Individual subdomain takeover reports command payouts ranging from $1,000 to $5,000+ depending on impact and affected organization. The financial rewards reflect the potential damage from subdomain takeover, including brand impersonation, phishing infrastructure, session hijacking through cookie access, Content Security Policy bypass, and OAuth flow exploitation.

The attack enables multiple exploitation paths beyond simple content hosting. Subdomains can be used to bypass same-origin policy restrictions, allowing cross-site scripting attacks that access parent domain resources. Session cookies set at the parent domain level may be accessible from compromised subdomains depending on cookie scope configuration. Content Security Policy configurations that trust subdomains can be bypassed by serving malicious scripts from taken-over subdomains. OAuth implementations may accept redirects to organizational subdomains, enabling authorization code or token theft through taken-over subdomains.

The detection difficulty varies significantly based on organizational maturity. Organizations with comprehensive subdomain inventories and regular DNS audits discover vulnerabilities during routine reviews. However, many organizations lack complete subdomain inventories, making orphaned records invisible until exploited or discovered through external security research. The gap between vulnerability creation (service decommissioning) and discovery can span months or years.

What are the limitations of subdomain takeover attacks?

Subdomain takeover attacks face several constraints that enable detection and prevention.

Detection via subdomain enumeration provides straightforward identification of potential vulnerabilities. Security scanners can identify all subdomains of an organization using DNS queries, zone transfers where available, certificate transparency log searches, and historical DNS records. Once enumerated, CNAME records can be verified to confirm targets resolve to active services. Tools like subfinder, amass, and crt.sh make this enumeration trivial, enabling both attackers and defenders to identify orphaned subdomains. Organizations performing regular subdomain enumeration discover vulnerable configurations before exploitation.

CNAME verification enables organizations to validate all CNAME records resolve to legitimate, active services under organizational control. Automated scanning can test each CNAME target for response codes indicating non-existent or unclaimed services. HTTP 404 errors, DNS NXDOMAIN responses, or service-specific error messages like "NoSuchBucket" from AWS indicate potential takeover opportunities for attackers but also alert defenders performing proactive scanning.

Service-specific claim verification has improved as providers recognize the security implications. Some services now verify actual domain ownership before allowing subdomain claims, requiring DNS TXT records or email verification to the domain owner. However, this protection is inconsistent across providers, with many still allowing claims based solely on CNAME configuration. The verification requirements vary by service, making thorough understanding of each provider's policies necessary for both attack and defense.

Subdomain monitoring through continuous DNS change detection alerts organizations to unexpected modifications or new subdomain claims. Monitoring systems can track certificate issuance for organizational domains through Certificate Transparency logs, revealing attempted takeovers when attackers obtain SSL certificates for claimed subdomains. DNS monitoring solutions alert on changes to existing records or creation of new records pointing to external services.

DNSSEC provides cryptographic validation of DNS records, making unauthorized modifications detectable through signature verification failures. However, DNSSEC adoption remains limited and doesn't prevent legitimate service decommissioning that creates orphaned records. DNSSEC validates that records haven't been tampered with but can't validate whether records should still exist.

Rate limiting by service providers can slow automated takeover attempts but provides limited defense since attackers typically claim one specific subdomain rather than attempting bulk operations. The attack requires creating only a single resource matching the orphaned DNS record, making rate limiting ineffective.

DNS TTL (time-to-live) values affect how quickly corrections propagate. Short TTL values allow rapid correction if takeover is detected, while long TTL values mean DNS caching prolongs exposure even after DNS records are removed. Organizations can minimize exposure time by maintaining short TTL values on external CNAME records, though this increases DNS query load.

How can organizations defend against subdomain takeover?

Defense against subdomain takeover requires comprehensive DNS inventory management combined with proactive monitoring.

DNS inventory and audit forms the foundation of defense. Maintain a comprehensive inventory of all subdomains documenting their business purposes, owning teams, and dependencies on external services. Regularly audit DNS records at minimum quarterly to verify all entries serve legitimate purposes and point to active services. Remove DNS records immediately when services are decommissioned through change management processes that require DNS cleanup. Document all legitimate subdomains in a centralized registry accessible to security and operations teams. Assign ownership to specific teams for each subdomain, creating accountability for maintenance and cleanup.

Subdomain discovery through automated enumeration identifies all existing subdomains for inventory validation. Regularly enumerate all subdomains using tools like subfinder, amass, or crt.sh to discover entries not in the official inventory. Identify subdomains that don't resolve or point to decommissioned services requiring DNS cleanup. Implement automated subdomain discovery in CI/CD pipelines, scanning for new subdomains whenever infrastructure changes deploy. Monitor for new subdomains using DNS monitoring services that alert on changes or additions to organizational DNS zones.

Service management procedures prevent orphaned CNAME creation. When decommissioning external services, remove DNS records BEFORE deleting service resources to prevent takeover windows. Implement change management requiring DNS record removal approvals as part of service decommissioning workflows. Use DNS aliases pointing to internal systems instead of external services where architecturally possible, reducing dependence on third-party infrastructure. Document service lifecycle including DNS cleanup requirements in runbooks and standard operating procedures.

Continuous monitoring enables rapid detection of takeover attempts. Deploy DNS monitoring to alert on new subdomain creation or modification of existing CNAME records. Monitor DNS resolution failures generating NXDOMAIN responses, which may indicate decommissioned services. Alert on unexpected CNAME changes that could indicate compromise or misconfiguration. Monitor for suspicious content served from subdomains through web application scanning or content verification.

Vulnerability scanning proactively identifies takeover opportunities before attackers do. Include subdomain takeover testing in security scanning programs using tools like dnsReaper or Nuclei templates specifically designed for subdomain takeover detection. Use automated tools to verify all CNAME records point to active, claimed resources under organizational control. Conduct regular penetration testing of DNS infrastructure including subdomain takeover attempts. Monitor Certificate Transparency logs for issued certificates on organizational subdomains, alerting on unexpected certificate requests.

Incident response procedures enable rapid remediation when takeover occurs or vulnerabilities are discovered. If takeover is detected, immediately remove the CNAME record to prevent continued exploitation. Identify how the subdomain was used by examining web content, analyzing traffic logs, and reviewing any data access. Scan users or systems that accessed the compromised subdomain for malware or credential theft. Review logs for data access or exfiltration through the compromised subdomain. Identify root cause by determining why the DNS record was not removed during service decommissioning, implementing process improvements to prevent recurrence.

Organizational practices embed DNS hygiene into operational culture. Implement DNS governance requiring approval for new subdomain creation through change management. Use namespace conventions that make purposes obvious, such as prod-api.example.com or test-cdn.example.com, improving inventory management and cleanup tracking. Require DNS record removal as part of service decommissioning checklists in ITIL or similar frameworks. Train development teams on subdomain takeover risks through security awareness programs focused on cloud service lifecycle management.

Organizations should treat DNS records as infrastructure requiring active lifecycle management rather than set-and-forget configuration, implementing continuous validation of all CNAME records.