Subdomain Scanner
Subdomain Scanner
Finde Subdomains einer Domain mit Certificate Transparency Logs, Wordlist-Scan und Live-DNS-Auflösung via DNS-over-HTTPS.
Hinweis: Dieses Tool nutzt öffentliche Quellen (Certificate Transparency Logs via crt.sh, DNS-over-HTTPS via Google/Cloudflare). Nur für eigene Domains oder mit ausdrücklicher Genehmigung nutzen! Subdomain-Scanning fremder Systeme kann illegal sein.
Inhaltsverzeichnis
Schnellübersicht
- Wordlist-Scan: Häufige Subdomain-Namen testen
- Certificate Transparency: Subdomains aus CT-Logs (crt.sh)
- DNS-Lookup: Live-Auflösung via DoH (Google/Cloudflare)
- Wildcard-Detection: Wildcard-DNS erkennen
- Export: Ergebnisse als CSV oder JSON
- Theorie: Über Subdomain-Enumeration
- FAQ: Häufige Fragen zu Subdomain-Scanning
1. Subdomain-Scanner
Gib eine Domain ein und wähle die Scan-Methoden.
2. Theorie – Subdomain Enumeration
Verstehe die Grundlagen des Subdomain-Scannings.
Was ist eine Subdomain?
Eine Subdomain ist eine Unterteilung einer Domain:
- Hauptdomain: example.com
- Subdomain: www.example.com
- Weitere: mail.example.com, api.example.com
- Beliebig tief: dev.api.example.com
Warum Subdomain-Scanning?
Subdomain-Scanning ist wichtig für:
- Security-Audit: Vergessene Subdomains finden
- Bug-Bounty: Angriffsfläche kartieren
- Penetration-Test: Scope definieren
- Asset-Management: IT-Inventar
Methoden
Subdomains können gefunden werden durch:
- DNS-Brute-Force: Wordlist durchprobieren
- Certificate Transparency: CT-Logs (crt.sh)
- DNS-Zone-Transfer: AXFR (selten)
- Passive DNS: SecurityTrails, VirusTotal
- Suchmaschinen: Google "site:example.com"
Best Practices
- Legal: Nur eigene Domains oder Erlaubnis
- Rate-Limiting: Nicht zu schnell scannen
- User-Agent: Identifizierbar bleiben
- Wildcard-DNS: Beachten (False Positives)
- Kombination: Mehrere Methoden nutzen
- Dokumentation: Ergebnisse sichern
Wussten Sie schon?
Certificate Transparency (CT) ist ein öffentliches Log-System für SSL/TLS-Zertifikate. Seit 2018 müssen alle Certificate Authorities (CAs) jedes ausgestellte Zertifikat in CT-Logs eintragen. Dadurch sind alle Subdomains mit HTTPS öffentlich einsehbar – ein Segen für Bug-Bounty-Hunter, aber auch ein Risiko für Unternehmen, die vergessene Subdomains haben.
3. Geschichte des Subdomain-Scannings
Von DNS-Brute-Force zu Certificate Transparency.
Erste DNS-Wordlists
Erste Tools wie fierce nutzen Wordlists, um Subdomains zu finden. Begrenzte Listen mit häufigen Namen wie www, mail, ftp.
DNSRecon und dnsenum
DNSRecon und dnsenum werden populär. Sie kombinieren Zone-Transfer-Versuche, Wordlist-Scan und Google-Scraping. Erste echte Security-Tools.
Certificate Transparency
Google startet Certificate Transparency nach dem DigiNotar-Vorfall (2011). Alle SSL-Zertifikate werden in öffentliche Logs eingetragen. Erste Subdomain-Quelle aus CT.
crt.sh
crt.sh wird von Comodo gestartet – eine öffentliche Suchmaschine für CT-Logs. Auf einmal konnten Subdomains aus Zertifikaten abgefragt werden.
Sublist3r
Sublist3r wird veröffentlicht – ein Python-Tool, das viele Quellen kombiniert (CT, Google, Bing, etc.). Wird zum Standard in der Bug-Bounty-Community.
Amass
OWASP Amass wird veröffentlicht. Es kombiniert aktive und passive Methoden (DNS, CT, ASN, etc.) und wird zum umfassendsten Tool. CT wird Pflicht für alle CAs.
Moderne Tools
Subfinder, Assetfinder, Findomain werden populär. Cloud-basierte Services wie SecurityTrails, Shodan, Censys bieten API-Zugang. Subdomain-Enumeration ist Industriestandard.
4. FAQ – Häufige Fragen
Häufige Fragen zu Subdomain-Scanning
Es kommt darauf an:
- Eigene Domains: ✅ Legal und empfohlen
- Bug-Bounty-Programme: ✅ Meist erlaubt (Scope prüfen!)
- Penetration-Test: ✅ Mit Vertrag/Genehmigung
- Fremde Domains ohne Erlaubnis: ⚠️ Grauzone
- Mit böswilliger Absicht: ❌ Illegal (StGB §202c)
Wichtig:
- Passives DNS (CT-Logs) ist meist OK
- Aktives Scannen (Brute-Force) kann Logs verursachen
- In Deutschland:
§202c StGB(Hacker-Paragraph) - Für Bug-Bounty: Scope des Programms einhalten
Certificate Transparency (CT) ist ein öffentliches Log-System für SSL/TLS-Zertifikate:
- Ziel: Missbrauch von Zertifikaten erkennen
- Seit 2011: Nach DigiNotar-Vorfall eingeführt
- Seit 2018: Pflicht für alle CAs (Chrome)
- Öffentlich: Jeder kann Logs durchsuchen
Für Subdomain-Enumeration:
- Jedes Zertifikat enthält Domain-Namen
- crt.sh durchsucht CT-Logs
- Zeigt historische + aktuelle Subdomains
- Kostenlos und passiv (keine Spuren)
Nachteil: Nur Subdomains mit HTTPS sind sichtbar.
Wildcard-DNS bedeutet, dass alle Subdomains auf dieselbe IP zeigen:
- Konfiguration:
*.example.com → 1.2.3.4 - Effekt: Jede Subdomain existiert
- Beispiel:
blahblah.example.comlöst auf
Problem beim Scanning:
- False Positives: Jede Anfrage "erfolgreich"
- Keine Erkennung: Kann nicht zwischen echt/fake unterscheiden
- Erkennung: Zufällige Subdomain testen
Lösung: Unser Tool erkennt Wildcards automatisch und warnt!
Empfohlene Wordlists:
| Wordlist | Einträge | Verwendung |
|---|---|---|
| subdomains-top1m | 1 Mio. | Umfassend |
| SecLists DNS | ~20k | Standard |
| commonspeak2 | ~10k | Kombiniert |
| fierce | ~500 | Schnell |
Tipps:
- Kleine Listen: Schneller, weniger False Positives
- Große Listen: Mehr Treffer, aber langsamer
- Custom: Kombiniere häufige + domainspezifische
- SecLists: GitHub-Repo mit DNS-Wordlists
Unser Tool nutzt eine kuratierte Liste der ~50 häufigsten Subdomains.
DoH verschlüsselt DNS-Anfragen über HTTPS:
- Standard: RFC 8484
- Port: 443 (wie HTTPS)
- Verschlüsselt: Wie Web-Traffic
- Privatsphäre: ISP kann nicht mitlesen
Vorteile für Subdomain-Scanning:
- Browser-kompatibel: Fetch-API nutzbar
- Zuverlässig: Große Anbieter (Google, Cloudflare)
- JSON: Strukturierte Antworten
- Schnell: Caching auf Anbieterseite
Nachteil: DNS-Anfragen gehen an den Anbieter (Google/Cloudflare).
Top-Interessant für Security:
| Subdomain | Interesse |
|---|---|
| admin | Admin-Panel |
| dev / staging / test | Entwicklungsumgebung |
| api | API-Endpunkte |
| vpn / remote | VPN-Zugang |
| jenkins / gitlab | CI/CD-Systeme |
| internal | Interne Systeme |
| backup | Backup-Systeme |
| db / database | Datenbank-Zugänge |
| mail / webmail | Mail-Systeme |
| vpn / ssh | Remote-Zugang |
Warnung: Solche Subdomains sollten nicht öffentlich erreichbar sein!
Prävention:
- Wildcard-Zertifikate:
*.example.comstatt Einzel - Split-Horizon DNS: Intern vs. extern unterschiedlich
- Keine Dev-Subdomains öffentlich: Nur über VPN
- Zugriffskontrolle: Basic Auth auf Admin-Panels
- Monitoring: CT-Logs auf eigene Domains überwachen
- Redundanz vermeiden: Alte Subdomains aufräumen
Tools zur Überwachung:
- Cert Spotter: Überwacht neue Zertifikate
- Facebook CT Monitor: Kostenlos
- SecurityTrails: Kommerziell
Mögliche Gründe:
- Keine CT-Zertifikate: Domain nutzt Wildcard-Zertifikat
- Kleine Wordlist: Zu wenige Tests
- Split-Horizon: Subdomains nur intern sichtbar
- Keine DNS-Einträge: Manche Subdomains existieren nur über HTTP
- Firewall: DNS-Anfragen blockiert
- Wildcard-DNS: Alle Subdomains zeigen auf dieselbe IP
Verbesserung:
- Mehrere Methoden kombinieren (CT + Wordlist + DNS)
- Größere Wordlist nutzen (SecLists)
- Passive DNS-Dienste (SecurityTrails, VirusTotal)
- Subdomain-Tools wie Amass, Subfinder nutzen
Zusammenfassung
Die wichtigsten Punkte
- Subdomain: Unterteilung einer Domain (www, mail, api)
- Certificate Transparency: Öffentliche SSL-Logs (seit 2018 Pflicht)
- crt.sh: Suchmaschine für CT-Logs
- Wordlist-Scan: Häufige Subdomains per DNS prüfen
- DoH: DNS-over-HTTPS für Browser-basierte Scans
- Wildcard-DNS: Alle Subdomains auflösbar = False Positives
- Top-Targets: admin, dev, api, vpn, internal, backup
- Legal: Nur eigene Domains oder Bug-Bounty-Scope
- Schutz: Wildcard-Zertifikate, Monitoring, Aufräumen
- Unser Tool: CT + Wordlist + DoH-Lookup kombiniert