Subdomain Takeover: How It Works, Detection, and Prevention

What Is Subdomain Takeover?

Subdomain takeover happens when a DNS record, most commonly a CNAME, points to an external service where the associated resource no longer exists under the original owner's control. The DNS record remains active, but the destination is unclaimed. Anyone who registers that resource on the hosting platform inherits all traffic the DNS record sends their way.

Consider this scenario: your team deploys a marketing site at campaign.example.com using GitHub Pages. They create a CNAME record pointing to yourorg.github.io. Six months later, the campaign ends and the team deletes the GitHub Pages repository, but nobody removes the DNS record. Now campaign.example.com still points at GitHub Pages, but GitHub Pages has no content for it. An attacker creates a new repository named yourorg.github.io (or configures any repo with that custom domain), and GitHub serves their content for every visitor to campaign.example.com.

The attack surface is larger than most organizations realize. Every subdomain pointing to a third-party service is a potential takeover candidate the moment that service is deprovisioned. Using a subdomain scanner to maintain a complete inventory of your DNS records is the first step toward preventing this class of vulnerability.

How Subdomain Takeover Works: The DNS Mechanics

To understand takeover, you need to understand how CNAME records delegate trust. When a browser resolves blog.example.com and encounters a CNAME pointing to example.herokuapp.com, the DNS resolver follows the chain to Heroku's nameservers and returns whatever IP Heroku assigns. The browser then connects to that IP and sends the HTTP Host header blog.example.com. The receiving web server uses this header to decide which content to serve.

This creates a trust delegation: the DNS owner has told the world "for this subdomain, ask that platform what to serve." If the platform no longer has a resource registered for that hostname, it typically returns an error page or a 404. But if anyone registers a new resource that matches the hostname, the platform starts serving their content, because the DNS delegation is still active and the platform has no reason to refuse a valid custom-domain configuration.

The Three Conditions for Takeover

1. Active DNS record: A CNAME (or in some cases an A record) points the subdomain to an external service.
2. Unclaimed resource: The target resource on the external service has been deleted, expired, or was never properly claimed.
3. Claimable platform: The external service allows new users to register and claim the same resource identifier (bucket name, app name, repository name, custom domain).

If all three conditions are met simultaneously, the subdomain is vulnerable. Removing any one condition eliminates the vulnerability: delete the DNS record, reclaim the resource, or migrate to a platform that verifies domain ownership before allowing custom domain configuration.

Types of Dangling DNS Records

While CNAME records are the most commonly exploited vector, subdomain takeover is not limited to CNAMEs. Any DNS record type that delegates resolution or traffic to a third party can be vulnerable.

CNAME Records (Most Common)

CNAME records are aliases that point one hostname to another. When the target hostname stops serving content for the original domain, the alias becomes a dangling pointer. Services like GitHub Pages, Heroku, AWS S3, and Shopify are frequently involved because they allow users to configure custom domains pointing at shared infrastructure.

A Records Pointing to Released IPs

When an A record points to a cloud IP address (EC2 Elastic IP, Azure public IP, GCP external IP) and that IP is released back to the provider's pool, another customer can potentially be allocated the same IP. While less reliable for attackers (IP allocation is usually random), researchers have demonstrated targeted IP takeover by rapidly claiming and releasing IPs until obtaining the target address.

NS Delegation Takeover

If a subdomain has NS records delegating to a nameserver that the organization no longer controls (for example, a lapsed domain used as a nameserver, or a deprovisioned Route53 hosted zone), an attacker who registers the lapsed nameserver domain gains full control over all DNS responses for the delegated subdomain. This is the most dangerous form of takeover because the attacker controls all record types, not just HTTP content.

MX Records

MX records pointing to decommissioned mail servers can be exploited to intercept email intended for the subdomain. This is particularly dangerous for subdomains that might receive password-reset emails or internal communications.

Commonly Vulnerable Services

Not every service is equally exploitable. Some platforms verify domain ownership before allowing custom domain configuration, making takeover impossible even with a dangling CNAME. Others have no verification at all. The following services have confirmed takeover vectors as of 2026:

This table is not exhaustive. The can-i-take-over-xyz repository maintains the authoritative, community-updated list of vulnerable services with proof-of-concept status.

Real-World Impact and Documented Incidents

Subdomain takeover is not a theoretical vulnerability. It has been exploited against major organizations with real consequences:

• Microsoft: Researchers have discovered dozens of dangling subdomains across microsoft.com, including ones pointing to deprovisioned Azure resources. Some were claimed and used to demonstrate cookie theft across the parent domain.
• Starbucks: A subdomain pointing to an unclaimed Azure Traffic Manager instance was taken over, demonstrating full content control under the starbucks.com brand. The finding earned a bug bounty payout.
• Uber: Multiple subdomains with dangling CNAMEs to decommissioned services were reported through their bug bounty program, including endpoints that could have been used for credential phishing targeting employees and riders.
• UK Government (.gov.uk): Several government subdomains were found with dangling records pointing to decommissioned cloud services, creating potential vectors for authoritative-looking phishing campaigns.
• Legal firms and financial institutions: Numerous subdomain takeovers have been reported (and responsibly disclosed) against organizations where brand trust is critical, such as banks, insurance companies, and law firms using temporary campaign microsites that were improperly decommissioned.

The common thread: every one of these organizations had proper security teams and policies. The issue was operational, not technical. Decommissioning a service without cleaning up the DNS record is a process gap that no firewall or WAF can prevent.

Detection: Finding Vulnerable Subdomains

Detecting subdomain takeover candidates requires two steps: first, building a complete subdomain list for your domain; second, testing each subdomain's DNS records against known vulnerable service fingerprints.

Step 1: Enumerate All Subdomains

You cannot protect subdomains you do not know about. Use a subdomain checker like SubDomainsFinder.com for instant passive enumeration, or combine multiple tools (Subfinder, Amass, crt.sh) for maximum coverage. Certificate Transparency logs are particularly useful here because they reveal historical subdomains that may have been decommissioned but still have DNS records.

Step 2: Identify Dangling Records

For each subdomain with a CNAME record, resolve the target and check if the destination service returns a claimable error fingerprint. Manual checks work for a handful of subdomains, but at scale you need automated tooling. The detection tools listed below perform this fingerprint matching against databases of known vulnerable service responses.

Step 3: Validate and Triage

Not every matching fingerprint is exploitable. Some services have added verification steps since the fingerprint was documented, and some error pages are served by CDNs for legitimate internal reasons. Validate each finding by attempting to claim the resource (in a non-production context with authorization) or by confirming the service's current registration policy allows takeover.

Best Tools for Subdomain Takeover Detection

These open-source tools automate the detection workflow. Each approaches the problem differently. For comprehensive coverage, use a subdomain analyzer for enumeration first, then feed the results into one or more of these takeover-specific scanners.

can-i-take-over-xyz (EdOverflow)

Not a scanner but the reference knowledge base that every other tool depends on. This GitHub repository maintains a community-curated list of services, their takeover status (vulnerable, not vulnerable, edge-case), the specific error fingerprints to look for, and proof-of-concept documentation. If you only bookmark one resource on this topic, make it this one.

Repository: github.com/EdOverflow/can-i-take-over-xyz

Nuclei (ProjectDiscovery) with Takeover Templates

Nuclei is a fast, template-based vulnerability scanner. Its takeovers/ template directory contains fingerprint-matching rules for dozens of services. The advantage of Nuclei is that it integrates subdomain takeover checks into a broader vulnerability scanning workflow, so you can run it against your full subdomain list and catch takeover candidates alongside other web vulnerabilities. Its Go-based engine handles thousands of targets per minute.

Repository: github.com/projectdiscovery/nuclei

# Install nuclei
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Run takeover templates against your subdomain list
nuclei -l subdomains.txt -t takeovers/ -o takeover-results.txt

subjack (haccer)

A purpose-built subdomain takeover tool written in Go. subjack checks a list of subdomains against a JSON fingerprint file and reports which ones return vulnerable responses. It is fast, single-purpose, and straightforward to integrate into CI/CD pipelines for continuous monitoring.

Repository: github.com/haccer/subjack

# Install subjack
go install github.com/haccer/subjack@latest

# Check subdomains from a file
subjack -w subdomains.txt -t 100 -timeout 30 -ssl -o results.txt -v

subzy (PentestPad)

A modern alternative to subjack with an actively maintained fingerprint database. subzy checks for subdomain takeover by testing CNAME records against its built-in fingerprint list. It supports concurrent checks and outputs results in a clean, parseable format.

Repository: github.com/PentestPad/subzy

# Install subzy
go install -v github.com/PentestPad/subzy@latest

# Run against targets
subzy run --targets subdomains.txt --concurrency 50 --hide_fails

dnsReaper (punk-security)

A Python-based subdomain takeover tool that can pull subdomains directly from cloud provider APIs (AWS Route53, Azure DNS, Cloudflare, Digital Ocean) without needing a pre-built subdomain list. This makes it particularly useful for organizations that want to audit their actual DNS zone files rather than relying on external enumeration. Supports Docker deployment for easy CI integration.

Repository: github.com/punk-security/dnsReaper

# Run with Docker against a domain
docker run punksecurity/dnsreaper single --domain example.com

# Scan AWS Route53 zones directly
docker run punksecurity/dnsreaper aws --aws-access-key-id KEY --aws-access-key-secret SECRET

OWASP Amass (with Takeover Detection)

Amass, primarily known as a comprehensive subdomain enumeration tool, also includes built-in subdomain takeover detection. When running in enumeration mode, it can flag CNAME records pointing to potentially claimable resources. This combines enumeration and detection in a single workflow.

Recommended Workflow

For a thorough takeover audit, combine enumeration and detection:

# 1. Enumerate subdomains (multiple sources for coverage)
#    Use SubDomainsFinder.com for instant results, or:
subfinder -d example.com -all -o subs.txt

# 2. Check for takeover with multiple tools (each has different fingerprints)
nuclei -l subs.txt -t takeovers/ -o nuclei-results.txt
subjack -w subs.txt -t 100 -ssl -o subjack-results.txt
subzy run --targets subs.txt --concurrency 50

# 3. Deduplicate and validate findings
sort -u nuclei-results.txt subjack-results.txt > all-findings.txt

Prevention and Remediation

Preventing subdomain takeover is an operational discipline, not a one-time fix. The vulnerability reappears every time a service is decommissioned without cleaning up DNS.

Immediate Remediation (If Vulnerable Now)

1. Remove the dangling DNS record immediately. This is the fastest fix and eliminates the vulnerability.
2. If the record must stay (other services depend on it), reclaim the resource on the external platform before an attacker does.
3. If the subdomain was already taken over, contact the hosting platform's abuse team with proof of domain ownership to have the malicious content removed.

Preventive Measures

• DNS record lifecycle management: Treat DNS records as first-class infrastructure. Include "remove DNS records" as a mandatory step in every service decommissioning checklist. Automate this through IaC (Terraform, Pulumi) so DNS records are destroyed alongside the resources they point to.
• Regular DNS audits: Run a subdomain analyzer against your domains weekly or monthly. Flag any CNAME record where the target returns NXDOMAIN or a known error fingerprint. Tools like dnsReaper can pull directly from your DNS provider's API for an authoritative view.
• Avoid generic CNAME targets: Instead of pointing at platform defaults (yourapp.herokuapp.com), use verified custom domains where the platform requires proof of DNS ownership before activation. Not all services support this, but those that do (Vercel, Cloudflare Pages, Netlify) are immune to takeover by design.
• Monitoring and alerting: Implement continuous monitoring for changes to your DNS records. If a record's target starts returning unexpected responses, alert your security team. Services like SubDomainsFinder.com help maintain an up-to-date subdomain list you can monitor against.
• Cookie scoping: Avoid setting cookies on the bare domain (.example.com) when possible. Use the most specific subdomain scope needed. This limits the blast radius if a subdomain is taken over.
• Content Security Policy: Deploy CSP headers on your main application that restrict which origins can be framed or loaded. While CSP cannot prevent a takeover, it can limit an attacker's ability to exploit a taken-over subdomain for cross-origin attacks against your main application.

Using SubDomainsFinder.com for Takeover Prevention

SubDomainsFinder.com provides the enumeration foundation that takeover detection depends on. By running a scan against your domain, you get a complete subdomain list with IP addresses, hosting providers, and open ports, giving you the full picture needed to identify dangling records.

• Passive enumeration from multiple certificate transparency sources reveals both current and historical subdomains
• IP and ASN resolution helps identify subdomains pointing to cloud infrastructure you may have deprovisioned
• Port scanning reveals services that are still exposed but potentially orphaned
• Results export directly into takeover-detection tools like nuclei, subjack, and subzy

Automating Takeover Detection in CI/CD

For organizations with many domains, manual audits are insufficient. Subdomain takeover detection should run on a schedule, the same way you run dependency vulnerability scans. Here is a practical approach to integrating takeover checks into your existing workflow:

# GitHub Actions example: weekly takeover check
name: Subdomain Takeover Audit
on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 09:00 UTC
  workflow_dispatch: {}

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Install tools
        run: |
          go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
          go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

      - name: Enumerate subdomains
        run: subfinder -d example.com -all -o subs.txt

      - name: Check for takeover
        run: nuclei -l subs.txt -t takeovers/ -o results.txt

      - name: Alert on findings
        if: hashFiles('results.txt') != ''
        run: |
          echo "::warning::Potential subdomain takeover found"
          cat results.txt

Adjust the schedule frequency based on how rapidly your infrastructure changes. Organizations that provision and decommission services frequently should check daily. Stable environments can get away with weekly checks.

Advanced Topics

Second-Order Subdomain Takeover

In a second-order takeover, the attacker does not directly control the subdomain but exploits a service that is loaded by a page on the subdomain. For example, if app.example.com loads JavaScript from cdn.example.com, and cdn.example.com is vulnerable to takeover, an attacker who claims cdn.example.com can inject arbitrary JavaScript into app.example.com without directly taking it over. This makes comprehensive subdomain auditing critical: every subdomain referenced by your application infrastructure is a potential attack vector.

Subdomain Takeover via Expired Domains

When a CNAME points to a third-party domain (not a platform hostname like herokuapp.com but an actual domain name) and that domain expires, anyone who registers the expired domain gains control. This is particularly dangerous with NS delegations: if you delegated sub.example.com to a nameserver on a domain that later expired, registering that domain gives full DNS control.

Interaction with Wildcard Certificates

A wildcard TLS certificate (*.example.com) covers all first-level subdomains. If an attacker takes over any subdomain and the organization uses a wildcard cert, the attacker cannot use it (they would need the private key). However, services like Let's Encrypt allow anyone who controls the content of a subdomain to obtain a valid DV certificate for it, meaning a taken-over subdomain will serve valid HTTPS regardless of the organization's own certificate setup.