Teil 3 – Reconnaissance (Information Gathering)

Recon ist der Grundstein jeder erfolgreichen Suche nach Schwachstellen. Wer systematisch Informationen sammelt, findet schneller Angriffspunkte, versteht die Architektur eines Ziels besser und schreibt deutlich überzeugendere Reports. In diesem Beitrag zeige ich dir eine saubere Recon-Methodik, nützliche Tools, typische Funde und wie du automatisierst, ohne Regeln zu brechen.

Was bedeutet Recon genau?

Recon (oder Reconnaissance) heißt: so viele relevante Informationen wie möglich über ein Ziel zusammentragen — legal, passiv und strukturiert. Dazu gehören Domains, Subdomains, IP-Blöcke, verwendete Dienste, öffentlich zugängliche Endpunkte, eingesetzte Technologien (z. B. Webserver, Frameworks) und öffentlich sichtbare Geheimnisse (fehlkonfigurierte S3-Buckets, exposed API-Keys in GitHub — nur aufnehmen, nicht nutzen).

Recon hat zwei Hauptformen:

• Passive Recon: Informationen aus öffentlich zugänglichen Quellen lesen — z. B. DNS-Einträge, Archive, Suchmaschinen, öffentliche Git-Repos, Certificates. Keine direkten Anfragen ans Ziel nötig.
• Aktive Recon: Direkte Abfragen (z. B. Portscans, Subdomain-Bruteforce, Banner-Grabbing). Effizienter, aber potenziell störender — daher immer Scope- und Plattform-Regeln beachten.

Grundprinzipien / Regeln zuerst

Bevor du startest:

1. Scope prüfen: Was ist erlaubt? Welche Domains/IPs? Welche Tests sind verboten (z. B. brutale Scans, DoS)?
2. Safe Harbor & Kontakt: Falls unsicher, kontaktiere das Programm/Owner.
3. Protokollieren: Jede Abfrage (Zeit, Tool, Parameter) dokumentieren.
4. Passive Methoden bevorzugen, solange du noch in der Lernphase bist.

Typische Recon-Schritte (Praktisches Vorgehen)

1. Zielübersicht anlegen
   Lege ein strukturiertes Dokument an: Zielname, Domains, Subdomains, IP-Ranges, Quellen, Datum. Das ist die Basis für alles Weitere.
2. Passive DNS- & Zertifikatsrecherche
   Suche in Certificate Transparency Logs nach Zertifikaten des Ziels (gibt oft Subdomains preis). Tools: crt.sh (web), APIs oder automatisierte Tools wie crtndb/censys (bei Bedarf).
3. Subdomain-Enumeration (passiv → aktiv)
   • Passiv: OSINT-Quellen, Public DNS, GitHub, Archive.org, passive Plattform-APIs.
   • Aktiv: Tools wie subfinder, assetfinder oder amass (mit aktiven und passiven Modi).
     Ergebnis: Liste potenzieller Subdomains mit Priorisierung (z. B. „login“, „admin“, „api“).
4. DNS & IP-Mapping
   Erstelle eine Zuordnung Subdomain → IP, prüfe CNAMEs und Cloud-Provider (CDN kann echte IPs verdecken). Nutze dig, host oder automatisierte Scripte.
5. Port- und Service-Scanning (vorsichtig)
   Nutze nmap selektiv — keinesfalls in aggressivem Modus ohne Erlaubnis. Konzentriere dich auf Web-Ports (80/443) und Dienste, die im Scope stehen. Notiere Versionen und Banner.
6. Technologie-Fingerprinting
   Erkenne eingesetzte Webserver, Frameworks, Bibliotheken (z. B. whatweb, wappalyzer oder automatisierte Requests). Dies hilft, wahrscheinliche Schwachstellenklassen einzugrenzen.
7. Content-Discovery / Fuzzing
   Führe gezieltes Verzeichnis-/Endpoint-Fuzzing mit Tools wie ffuf durch — aber nur gegen erlaubte Hosts. Suche nach Backup-Dateien, Admin-Panels, alten Endpoints und offenen APIs.
8. API-Sichtbarkeit & Public-Endpoints
   Untersuche JavaScript-Dateien nach API-URLs, prüfe Swagger/OpenAPI-Endpoints, beobachte Netzwerkrequests im Browser (DevTools). Viele sensible Endpoints sind nicht verlinkt, aber in JavaScript vorhanden.
9. Öffentliche Quellen & Leak-Checks
   Durchsuche GitHub, Pastebin, Google dorking nach potenziell geleakten Schlüsseln oder Konfigs. Notiere Funde — nutze sie nicht, sondern melde als Hinweis.
10. Priorisieren & Hypothesen bilden
    Gruppiere Funde nach Priorität: „hoch“ (auth-sensitive, admin), „mittel“ (API-Endpunkte, dev-URLs), „niedrig“ (static assets). Formuliere Tests, die du sinnvoll daraus ableitest.

Nützliche Tools (Kurzüberblick)

• subfinder / assetfinder / amass — Subdomain-Enumeration (amass kann sehr mächtig sein).
• crt.sh / Censys / Shodan — Certificate- und Internet-Scans (lesend nutzen).
• nmap — Service-/Port-Discovery (vorsichtig einsetzen).
• ffuf / dirsearch — Content-Discovery / Directory-Fuzzing.
• whatweb / wappalyzer — Technologie-Fingerprinting.
• Burp Suite / OWASP ZAP — Manuelles Analysieren von Requests (auch zum Finden versteckter API-Aufrufe).
• github-search / truffleHog / gitrob — Suche nach möglichen Geheimnissen in öffentlichen Repositories (nur lesen/reporten).
• Recon/automation-suites: Selbst erstellte Pipelines (Python) oder Frameworks, die Recon-Ergebnisse aggregieren.

Automatisierung — ja, aber mit Verstand

Automatisierung spart Zeit: z. B. nightly runs, deduplizierung von Subdomains, automatische Erkennung neuer Endpoints. Trotzdem:

• Setze Rate-Limits, um Systeme nicht zu belasten.
• Markiere Aktionen, die aktiv sind vs. passiv.
• Baue klare Logs und Versionierung deiner Recon-Läufe ein.
• Automatisiere nur das Sammeln; die Bewertung und Exploitation sollte manuell und bedacht erfolgen.

Typische Findings und warum sie wichtig sind

• Ungepatchte Services / alte Software: Hinweis auf mögliche bekannte CVEs.
• Admin-/Staging-Subdomains: Oft mit schwächerer Authentifizierung.
• Offene APIs: Unauth-/Broken Auth kann kritische Daten leaken.
• Subdomain Takeover-Potential: CNAME zeigt auf entfernten Cloud-Resource — möglich, dass jemand eine Resource anlegt und die Subdomain übernimmt.
• Exposed config/keys in GitHub: Sofort melden, da hohe Schwere.

Jeder dieser Punkte ist nicht automatisch ein Exploit – er ist eine Hypothese, die du weiter testest und sauber dokumentierst.

Praktische Übung (sicher und legal)

1. Ziel: Richte eine lokale Übungsinstanz (z. B. Juice Shop) ein.
2. Aufgabe: Führe eine komplette Recon-Runde durch — passive Quellen, subdomain-Tools (in deinem lokalen DNS-Setup), ein moderates nmap gegen die eigene VM und ffuf gegen den Webserver.
3. Liefergegenstand: Erstelle ein Recon-Report-File mit: gefundene Subdomains, offene Ports, interessante Endpoints, Priorisierung, Screenshots/Logs.
4. Reflexion: Was war überraschend? Welche Hypothese würdest du als Nächstes testen?