Subdomain Takeover Detection

Subdomain Takeover Detection

A skill for identifying and analyzing domain/subdomain takeover vulnerabilities during security assessments.

What is Subdomain Takeover?

Subdomain takeover occurs when a subdomain points to a third-party service (like GitHub Pages, S3, Heroku, etc.) that has been deleted or is unclaimed. An attacker can claim that resource and control the subdomain, potentially:

• Phishing attacks - Display fake content on a trusted domain
• Session hijacking - Steal cookies via browser transparency
• CORS bypass - Access sensitive data from main domain
• OAuth token theft - Intercept redirect URIs
• CSP bypass - Inject malicious scripts
• Email spoofing - Manipulate MX records

Detection Workflow

Step 1: Identify Target Subdomains

Gather all subdomains of the target domain:

# Using subfinder
subfinder -d target.com -o subdomains.txt

# Using amass
amass enum -d target.com -o subdomains.txt

# Using chaos projectdiscovery
chaos -d target.com -o subdomains.txt

Step 2: Resolve DNS Records

Check DNS records for each subdomain:

# Using subjack (recommended)
subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt

# Using dnsreaper
dnsreaper -w subdomains.txt -o results.txt

# Manual check with dig
dig CNAME subdomain.target.com

Step 3: Identify Dangling Records

Look for CNAME records pointing to:

• AWS: *.s3.amazonaws.com, *.cloudfront.net, *.elb.amazonaws.com
• Azure: *.azurewebsites.net, *.cloudapp.net, *.blob.core.windows.net
• GCP: *.appspot.com, *.storage.googleapis.com
• GitHub: *.github.io, *.github.com
• Heroku: *.herokudns.com
• Fastly: *.fastly.net
• Netlify: *.netlify.app, *.netlify.com
• Vercel: *.vercel.app
• Shopify: *.myshopify.com
• Zendesk: *.zendesk.com
• Atlassian: *.atlassian.net
• Twitch: *.twitchcdn.net
• Ghost: *.ghost.io
• Surge: *.surge.sh
• Firebase: *.firebaseapp.com
• DigitalOcean: *.digitaloceanspaces.com

Step 4: Verify Takeover Possibility

For each potential target:

1. Check HTTP response - Look for provider-specific error pages
2. Check TLS certificates - Provider certificates indicate takeover potential
3. Attempt to claim - Create account and try to register the resource name

Step 5: Document Findings

Record:

• Subdomain and DNS record
• Target service provider
• Evidence (HTTP response, certificate, error message)
• Exploitation steps (if verified)
• Impact assessment

Automated Detection Tools

Primary Tools

Nuclei Templates

# Install nuclei templates
git clone https://github.com/projectdiscovery/nuclei-templates

# Run takeover templates
nuclei -u https://subdomain.target.com -tags takeover -t nuclei-templates/

# Specific templates
nuclei -u https://subdomain.target.com -t nuclei-templates/misconfigurations/

Provider-Specific Detection

AWS S3

Pattern: *.s3.amazonaws.com or *.s3-*.amazonaws.com

Detection:

curl -I https://subdomain.target.com
# Look for: "NoSuchBucket" or "404 Not Found" with S3 headers

Verification: Create S3 bucket with same name in different region

AWS CloudFront

Pattern: *.cloudfront.net

Detection:

curl -I https://subdomain.target.com
# Look for: "NoSuchDistribution" or CloudFront error pages

GitHub Pages

Pattern: *.github.io

Detection:

curl -I https://subdomain.target.com
# Look for: "404" with GitHub Pages error

Verification: Create GitHub Pages site with same name

Heroku

Pattern: *.herokudns.com

Detection:

curl -I https://subdomain.target.com
# Look for: "No such app" or Heroku error page

Verification: Create Heroku app with same name

Azure Websites

Pattern: *.azurewebsites.net

Detection:

curl -I https://subdomain.target.com
# Look for: "404" with Azure error page

GCP App Engine

Pattern: *.appspot.com

Detection:

curl -I https://subdomain.target.com
# Look for: "404" with GCP error page

Exploitation Verification

Before Testing

1. Confirm scope - Ensure target is in authorized scope
2. Document baseline - Record current DNS and HTTP responses
3. Plan rollback - Know how to undo changes if needed

Verification Steps

1. Create account on the third-party service
2. Attempt to claim the resource name
3. Verify DNS resolution - Check if subdomain now points to your resource
4. Test impact - Check for cookie leakage, CORS access, etc.
5. Document evidence - Screenshots, HTTP responses, DNS records

Impact Testing

# Check for cookie leakage
curl -v https://subdomain.target.com -H "Cookie: test=value"

# Check CORS policy
curl -I https://subdomain.target.com -H "Origin: https://attacker.com"

# Check CSP
curl -I https://subdomain.target.com | grep -i content-security-policy

# Check for OAuth redirect
curl "https://subdomain.target.com/oauth?redirect_uri=https://attacker.com"

Mitigation Recommendations

For Organizations

1. Remove vulnerable DNS records - Delete CNAMEs for unused subdomains
2. Claim domain names - Register resources with cloud providers
3. Implement monitoring - Use tools like aquatone for continuous scanning
4. Process improvement - Make DNS cleanup part of resource decommissioning
5. Domain verification - Use provider verification mechanisms

For Assessments

1. Report all findings - Even unverified potential takeovers
2. Prioritize by impact - Focus on subdomains with sensitive data
3. Provide remediation - Clear steps to fix each vulnerability
4. Verify fixes - Re-test after remediation

Safety and Ethics

Authorized Testing Only

• Never test domains without explicit authorization
• Never claim resources you don't have permission to test
• Always document scope and rules of engagement
• Report findings responsibly to the organization

Responsible Disclosure

1. Document findings with evidence
2. Report to security team or bug bounty program
3. Wait for remediation before public disclosure
4. Follow responsible disclosure timelines

Common False Positives

• Wildcard DNS - *.target.com pointing to valid IP
• Active resources - CNAMEs to existing, claimed services
• Load balancers - CNAMEs to active infrastructure
• CDN services - Legitimate CDN configurations

Always verify by checking HTTP responses and attempting to claim the resource.

Quick Reference

DNS Record Types to Check

• CNAME - Most common takeover vector
• A/AAAA - Direct IP records (less common)
• ALIAS/ANAME - Alias records (provider-specific)
• MX - Email records (email takeover)
• NS - Nameserver records (NS takeover)

Key HTTP Status Codes

• 404 - Resource not found (potential takeover)
• 403 - Forbidden (may indicate active resource)
• 500 - Server error (investigate further)
• 200 - Active resource (not vulnerable)

Error Page Indicators

• "NoSuchBucket" - AWS S3
• "No such app" - Heroku
• "404 Not Found" with provider branding
• Default error pages from cloud providers

Resources

• can-i-take-over-xyz - Comprehensive takeover guide
• 0xpatrik subdomain takeover - Detailed tutorial
• Stratus Security guide - Best practices
• HackerOne guide - Bug bounty perspective