Subdomain Takeover - Übernahme verwaister Subdomains - Definition & Erklärung

Subdomain Takeover ist eine häufige Schwachstelle in der modernen Cloud-Infrastruktur: Teams richten Subdomains für temporäre Services ein, löschen den Service - vergessen aber den DNS-Eintrag. Monatelang zeigt staging.company.com via CNAME auf eine bereits gelöschte Heroku-App. Wer diese App auf Heroku neu anlegt (gleicher App-Name), übernimmt automatisch die Subdomain.

Technisches Grundprinzip

Normaler Ablauf (sicher):

staging.company.com → CNAME → myapp.herokuapp.com → aktive App

Vergessener DNS-Eintrag (verwundbar):

staging.company.com → CNAME → myapp.herokuapp.com → App GELÖSCHT!

Was passiert:

Browser fragt: staging.company.com?
DNS antwortet: CNAME myapp.herokuapp.com
Heroku: “myapp” nicht mehr registriert → Fehler 404

Angriff:

Angreifer findet verwaisten DNS-Eintrag
Meldet sich bei Heroku an und erstellt App “myapp”
App ist jetzt wieder aktiv!
staging.company.com → zeigt auf Angreifer-App!

Auswirkungen:

Phishing-Seiten unter legitimer Domain company.com
Gleiche Domain = Browser akzeptiert Cookies von company.com! (document.cookie → Session-Cookies lesbar wenn HttpOnly fehlt!)
SPF/DMARC-Bypass: E-Mails von staging.company.com erscheinen legitim
XSS-Angriffe gegen Nutzer von company.com (Same-Origin-Policy!)
Content-Spoofing für Social Engineering

Betroffene Dienste und Erkennungsmerkmale

GitHub Pages

CNAME zeigt auf: username.github.io
Fehler-Hinweis: “There isn’t a GitHub Pages site here”
Takeover: GitHub-Account erstellen + gleichnamiges Repository + Pages aktivieren

Heroku

CNAME zeigt auf: appname.herokuapp.com
Fehler-Hinweis: “No such app” oder eigene Heroku-Fehlerseite
Takeover: Heroku-Account + gleichnamige App erstellen

AWS S3 Bucket

CNAME zeigt auf: bucket.s3.amazonaws.com
Fehler-Hinweis: “NoSuchBucket” in XML-Response
Takeover: AWS-Account erstellen + gleichnamigen Bucket in gleicher Region

Azure

App Service: *.azurewebsites.net - gelöscht aber DNS noch aktiv
CDN: *.azureedge.net
Traffic Manager: *.trafficmanager.net
Azure Static Web App: *.azurestaticapps.net

Netlify

CNAME zeigt auf: *.netlify.app oder *.netlify.com
Takeover: Netlify-Account + Site mit Custom Domain beanspruchen

Fastly

CNAME auf *.fastly.net → Fastly Customer-Service-Config gelöscht
Takeover: Fastly-Account + gleiches Backend beanspruchen

WordPress.com

CNAME auf *.wordpress.com → Blog gelöscht
Takeover: neues WordPress.com-Blog mit gleichem Custom-Domain-Anspruch

Alle anfälligen Dienste (200+ dokumentiert): https://github.com/EdOverflow/can-i-take-over-xyz - zeigt ob ein Dienst anfällig ist und wie der Takeover erfolgt.

Erkennung im Pentest

1. Subdomain-Discovery

# Alle Subdomains finden (via CT-Logs + DNS-Brute-Force):
subfinder -d company.com -all -v -o subdomains.txt
amass enum -d company.com -o subdomains-amass.txt

# Aus Certificate Transparency (crt.sh):
curl -s "https://crt.sh/?q=%25.company.com&output=json" | \
  python3 -c "import json,sys; [print(c['name_value']) for c in json.load(sys.stdin)]" \
  | sort -u > subdomains-ct.txt

2. DNS-Auflösung und CNAME-Prüfung

# Alle Subdomains auf CNAME prüfen:
cat subdomains.txt | while read sub; do
  cname=$(dig +short CNAME $sub)
  if [ -n "$cname" ]; then
    echo "$sub → $cname"
  fi
done

3. Automatisiertes Scanning mit subjack

# Automatisches Takeover-Detection-Tool:
./subjack -w subdomains.txt -t 50 -timeout 30 -ssl \
          -c fingerprints.json -v

# fingerprints.json: Signaturen für alle bekannten Dienste
# Ergebnis: Liste anfälliger Subdomains!

4. Nuclei Templates für Subdomain Takeover

nuclei -l subdomains.txt -t nuclei-templates/takeovers/ -v

5. Manuelle Prüfung

# CNAME zu unbekanntem Dienst → HTTP-Request senden:
curl -v https://staging.company.com
# Antwort: "No such app", "NoSuchBucket", "404 Not Found" → PRÜFEN!
# Ist der Dienst noch registriert? Kann ich den Claim übernehmen?

6. Subdomain-Takeover-Nachweis (ethisch)

<!-- Harmloser Proof of Concept - nur Nachweis der Möglichkeit! -->
<html><body>
[SECURITY RESEARCH] Subdomain takeover possible here.
Contact: security@company.com
</body></html>
<!-- Kein Cookie-Diebstahl! -->

Schutzmaßnahmen

1. Sofortmaßnahme: DNS-Einträge beim Service-Teardown löschen!

Prozess-Checkliste beim Löschen einer Cloud-Ressource:

Service/App löschen → SOFORT DNS-CNAME-Eintrag löschen!
S3-Bucket löschen → CNAME-Eintrag löschen
Azure-App löschen → Custom-Domain aus DNS entfernen
Staging/Test-Umgebung abschalten → DNS-Einträge bereinigen

Problem: Teams löschen den Service aber vergessen DNS! DNS-Management muss Teil des Offboarding-Prozesses sein.

2. Regelmäßige DNS-Audits

Monatliches Audit: Alle CNAMEs prüfen - zeigen sie auf aktive Services? (Automatisierbar mit subjack oder nuclei)

DNS-Monitoring-Services:

SecurityTrails: DNS-Änderungen überwachen
Passive DNS (CIRCL): Historische DNS-Daten
CT-Log-Monitoring (certspotter): neue Zertifikate für Subdomains

3. Ownership-Verification in Cloud-Services nutzen

Viele Cloud-Services verlangen Ownership-Verification:

Azure: “Custom Domain Verification” (TXT-Record im DNS)
AWS CloudFront: Certificate Validation
GitHub Pages: CNAME + Repository-Ownership

Wenn Service Ownership-Verify hat: Takeover benötigt Control über DNS UND Service → schwieriger! Aber: Nicht alle Services prüfen Ownership!

4. DNS-Inventory im Asset-Management

ALLE DNS-Einträge inventarisieren:

Welche Subdomain zeigt auf welchen Cloud-Service?
Wer ist Owner/Responsible?
Ablaufdatum des zugrundeliegenden Service-Vertrags?

Tooling für DNS-Inventory:

Cloudflare, Route53, Azure DNS: API-Abfrage möglich
Automatisierte Checks in CI/CD: neuer Deploy → DNS validieren

5. Automatisierte Takeover-Detection in CI/CD

# GitHub Actions / GitLab CI:
- name: Check for subdomain takeovers
  run: |
    nuclei -l dns/cnames.txt -t takeovers/ -severity critical,high
# → Täglicher Scan aller bekannten CNAMEs
# → Fail-CI wenn neuer Takeover-Risk erkannt!