Subdomain Takeover

Exploitation MED v1.0.0 updated 2026-06-17

Identify and verify dangling DNS records pointing to deprovisioned cloud services that can be claimed by an attacker.

Tools

Machine-readable JSON available at:

https://reconatlas.pages.dev/api/checklists/subdomain-takeover

// checklist steps

subtko-01

Identify CNAME records pointing to external services

Resolve DNS records for all enumerated subdomains and flag CNAMEs that point to third-party cloud services (S3, GitHub Pages, Heroku, Azure, Shopify, Fastly).

cat subdomains.txt | xargs -I{} dig CNAME {} +short
httpx -l subdomains.txt -follow-redirects -status-code -title -o httpx-subs.txt
subjack -w subdomains.txt -t 100 -timeout 30 -o subjack-results.txt -ssl

Pipe the CNAME output through sort -u and cross-reference with the can-i-take-over-xyz list to identify vulnerable providers.

subtko-02

Check for dangling records

Verify that identified CNAMEs resolve to NXDOMAIN or return provider-specific error pages indicating the resource is unclaimed.

dig CNAME blog.target.com +short
curl -sk https://blog.target.com -o /dev/null -w '%{http_code}'
nuclei -l subdomains.txt -t takeovers/ -o takeover-results.txt

An NXDOMAIN response on the CNAME target combined with an active CNAME record on the subdomain is the classic indicator of a takeover opportunity.

subtko-03

Verify takeover feasibility per provider

Confirm that the specific cloud provider allows claiming the dangling resource by consulting provider-specific documentation and the can-i-take-over-xyz fingerprint database.

# GitHub Pages: check for 404 with 'There isn't a GitHub Pages site here'
curl -sk https://subdomain.target.com | grep -i 'There isn.t a GitHub Pages site here'
# S3: check for 'NoSuchBucket'
curl -sk https://subdomain.target.com | grep -i 'NoSuchBucket'
# Heroku: check for 'No such app'
curl -sk https://subdomain.target.com | grep -i 'no such app'

Not all dangling CNAMEs are exploitable — some providers do not allow registration of previously used resource names. Always check can-i-take-over-xyz for the current status.

subtko-04

Test for NS delegation takeover

Check whether any subdomain has NS records pointing to nameservers that can be registered, allowing full DNS control over the subdomain.

dig NS target.com +short
cat subdomains.txt | xargs -I{} dig NS {} +short | sort -u

NS delegation takeover is higher impact than CNAME takeover because it grants full DNS control, enabling the attacker to set arbitrary A, MX, and TXT records.

subtko-05

Document proof of concept safely

Claim the dangling resource on the target provider and serve a benign proof-of-concept page (e.g. a text file with your researcher handle) without impersonating the target.

echo 'This subdomain is vulnerable to takeover. Reported by <researcher-handle>.' > index.html

Never serve content that impersonates the target organisation, collects credentials, or serves malicious code. A simple text file is sufficient proof.

subtko-06

Check for wildcard DNS impact

Determine whether the target uses wildcard DNS records that may mask or amplify the impact of a subdomain takeover.

dig A *.target.com +short
dig A randomnonexistent12345.target.com +short

If a wildcard record exists, any subdomain that is not explicitly defined will resolve to the wildcard. This can make takeover detection harder and impact assessment broader.

Overview

Subdomain takeover occurs when a DNS record (typically a CNAME) points to an external service that has been deprovisioned. An attacker can claim the abandoned resource on the cloud provider and serve arbitrary content under the target’s subdomain, enabling phishing, cookie theft, and CSP bypass attacks.

Provider fingerprints

GitHub Pages: “There isn’t a GitHub Pages site here.”
S3: “NoSuchBucket” or “The specified bucket does not exist”
Heroku: “No such app”
Azure: “404 Web Site not found”
Shopify: “Sorry, this shop is currently unavailable.”

Severity considerations

Subdomain takeover on a domain that shares cookies with the main application (e.g. via Domain=.target.com) is significantly higher severity because the attacker can set or steal cookies for the parent domain.

// references

← All checklists JSON ↗