Articles

5. Recon für Einsteiger — wie du die ersten Schwachstellen findest

Ein ausführlicher, praxisorientierter Leitfaden für Einsteiger in Bug Bounty / Pentesting. Fokus: strukturierte Recon, sichere Testumgebung, praktische Tools & Beispiel-Workflows.

4. Dein erstes Bug-Bounty-Programm – Scope lesen und verstehen

Viele Einsteiger im Bug Bounty Hunting stellen sich dieselbe Frage: Wo fange ich an?

3. Bug Bounty Hunting – Tipps für den Einstieg

Bug Bounty Hunting klingt nach schnellem Geld – aber die Wahrheit ist: Es ist ein Marathon, kein Sprint.

2. XSS never dies

Warum XSS nie aussterben wird.

1. ROP in einer Format-String Schwachstelle

Analyse einer ROP-chain bei einer Format-String Schwachstelle im Rahmen.

5. Recon für Einsteiger — wie du die ersten Schwachstellen findest

Planted September 21, 2025

Logo

In diesem Blogeintrag präsentiere mehr oder weniger in Stichpunkten, worauf du beim Recon-Prozess achten, welche Tools und Werkzeuge du benutzen solltest und wie ein Recon-Workflow aussehen könnte.

Kurzfassung (TL;DR)

Recon ist das planvolle Sammeln von Informationen über ein Ziel, um mögliche Angriffsflächen zu finden. Beginne mit Scope, sammle Subdomains & Hosts, enumeriere Dienste (Port-/Service-Scan - falls sinnvoll und erlaubt), sammel Inhalte (Wayback, öffentliche Dateien), such nach Verzeichnissen/Endpunkten (fuzzing), und konzentriere dich auf die low-hanging fruit wie veraltete Software, offene Debug-Endpoints, XSS/IDOR/SQLi-prädisponierte Endpunkte. Arbeite reproduzierbar: Notizen + Screenshots + minimalinvasive Tests. Immer nur im erlaubten Scope und in Testumgebungen.

1. Mindset & Regeln (wichtig!)

  • Legalität zuerst: Prüfe den Scope des Programms (URL-Liste, Subdomain-Regeln, autorisierte IPs). Ohne ausdrückliche Erlaubnis nichts außerhalb des Scopes angreifen.
  • Ethik & Kommunikation: Wenn du eine potenzielle kritische Schwachstelle findest, halte den Test minimalinvasiv und dokumentiere deine Schritte. Melde verantwortungsvoll über das Programm/Plattform.
  • Sichere Umgebung: Nutze lokale Labore (z. B. DVWA, WebGoat, Burp Academy, HackTheBox Labs) oder dedizierte Targets. Nie Live-Daten zerstören oder exfiltrieren. Tipp: Nutze eine VM für deine In-Scope Tests/Analysen.
  • Reproduzierbarkeit: Führe Recon in klaren Schritten aus und dokumentiere Befehle, Zeitstempel und Resultate.

2. Recon-Phasen — Übersicht

  1. Scope & Ziele definieren — Was ist erlaubt? Welche Subdomains / IPs?
  2. Passive Recon — ohne aktiven Traffic gegenüber Ziel: OSINT, Certs, DNS, Wayback.
  3. Active Recon — Port-Scans, Dienst-Enumeration, Directory Fuzzing.
  4. Content Discovery — Endpunkte, Parameter, Dateien, JS-Dateien.
  5. Vulnerability-Hunting (light) — gezielte, risikoarme Tests (z. B. reflektive XSS Proof-of-Concepts).
  6. Reporting — reproduzierbar, mit PoC und Empfehlungen.

3. Vorarbeiten — Scope genau lesen

  • Lies den Programm-Scope sorgfältig: zugelassene Subdomains, Pfade, Parameter, Ausnahmen.
  • Notiere ausgeschlossene Tests (DoS, Social Engineering, physische Zugriffe usw.).
  • Wenn etwas unklar ist — nutze das Programm-Kontaktformular, bevor du fragst (nicht für jedes Detail, nur bei echten Unklarheiten).

4. Passive Recon — was du sammeln solltest

Ziel: möglichst viele Hinweise ohne direkten Traffic auf das Ziel.

  • Subdomains & Zertifikate
    • Suche in Certificate Transparency Logs (crt.sh, Censys) nach Subdomains.
    • Notiere Wildcards, Subdomain-Patterns (api., dev., staging., admin., mail.).
  • DNS
    • A/AAAA, MX, TXT (SPF, DMARC), NS, CNAMEs — können interne Hinweise liefern.
    • Reverse DNS kann Cloud-/CDN-Provider aufzeigen (CloudFront, Akamai, etc.).
  • WHOIS / Hosting
    • Registrar, Hosting Provider, ASN → hilfreich, wenn du nach IP-blöcken suchst (nur zur Info).
  • Webarchive / Wayback
    • Alte Endpunkte, urls, parameter, Kommentare → alte admin-URLs oder debug-pages finden.
  • JavaScript & öffentliche Repos
    • Öffentliche JS-Dateien, GitHub/GitLab Repos, S3 Buckets mit offengelegten configs.
  • Leak Searches
    • Pastebins, StackOverflow, Job-Postings können internere Hinweise (IP, API-URLs) enthalten.

5. Tools & typische Befehle (Einsteiger-freundlich)

Hinweis: Du brauchst nicht alle Tools. Wähle ein Set, mit dem du dich wohlfühlst.

Nützliche CLI-Tools & Beispiele

  • dig / nslookup — DNS-Abfragen
    Beispiel: dig +short A api.example.com
  • Subdomain-Finder (passiv/automatisch): subfinder, amass (amass passive), assetfinder
    Beispiel: subfinder -d example.com -silent
  • Certificate enumeration: (crt.sh manuell oder per API) — keine Befehlszeile nötig.
  • httpx (oder curl) — prüft, ob Host erreichbar ist und liefert Titel/Status
    Beispiel: echo subs.txt | httpx -status-code -title -threads 50
  • Portscan: nmap
    Schneller Scan: nmap -sS -Pn -T4 -p- --min-rate 1000 10.0.0.5
    Service/Version: nmap -sV -sC -p 22,80,443 10.0.0.5
  • Verzeichnisfuzzing: ffuf, gobuster, dirsearch
    Beispiel: ffuf -w wordlist.txt -u https://example.com/FUZZ -mc 200,301,302 -t 40
  • Wayback/Archive tooling: waybackurls oder gau (getallurls)
    Beispiel: echo example.com | waybackurls > wayback.txt
  • JavaScript-discovery: linkfinder, gf + regex patterns, retire (dep check)
  • Parameter & endpoint scraping: paramspider, arjun (param finder)
  • URL discovery & filtering: qsreplace, gf, httpx, dalfox for XSS scanning in later steps

GUI / Web Tools (Einsteiger)

  • Burp Suite (Community) — Proxy + Scanner + Intruder (für reproduzierbare Interaktion)
  • OWASP ZAP — Alternative zu Burp, Open Source
  • Web-based labs: PortSwigger Academy, HackTheBox, TryHackMe (für Übung)

6. Praktischer Recon-Workflow (Schritt für Schritt)

Hier ein konkreter Ablauf, den du Schritt für Schritt durchlaufen kannst.

Schritt A — Passive Subdomain-Sammlung

  1. subfinder -d example.com -o subs_raw.txt
  2. amass enum -passive -d example.com -o amass_passive.txt
  3. cat subs_raw.txt amass_passive.txt | sort -u > subs_all.txt

Schritt B — Prüfen, welche Subdomains lebendig sind

  1. cat subs_all.txt | httpx -threads 50 -status-code -title -o subs_alive.txt
  2. Filtere interne/forbidden/etc. Notiere 200/301/302/403 und TLS-Infos.

Schritt C — Port / Service Scan (nur für IPs im Scope!)

  1. nmap -sS -Pn -T4 -p- –min-rate 1000 -oA fullscan (nur wenn IP-Range im Scope)
  2. Für Web-Hosts typischer: nmap -sV -p 80,443,8080,8443 –script=http-enum

Schritt D — Content Discovery (Wayback + Fuzzing)

  1. echo target.com | waybackurls > wayback.txt
  2. cat wayback.txt | grep -E ‘.js$’ | sort -u > jsfiles.txt
  3. ffuf -w common_dirs.txt -u https://sub.example.com/FUZZ -o ffuf_sub_example.txt

Schritt E — JS-Analysis (APIs, Endpoints, Keys)

  1. Lade JS Dateien herunter: httpx + xargs -n1 curl -s > file.js
  2. Suche nach endpoint, api, token, Bearer mit grep/ripgrep.
  3. Notiere gefundene API-URIs, Parameter, und mögliche IDs.

Schritt F — Parameter/Endpoint Enumeration

  1. paramspider -d https://sub.example.com -o params.txt
  2. Pro Endpunkt: identifiziere GET/POST-Parameter, optionale ID-Parameter → candidates for IDOR/SQLi/XSS.

Schritt G — Priorisierung

  • Priorisiere Endpunkte nach:
    • Auth-frei zugänglich? (öffentliche Endpunkte)
    • Sensible Funktionalität (password reset, file upload, admin panels)
    • Eingabe-Parameter (IDs, filenames, query)
    • Alte / veraltete Software-Signatures

7. Häufige „low hanging fruit“ bei Recon

  • Exposed Admin/Dashboard URLs (z. B. /admin, /manage, /wp-admin bei WordPress).
  • Ungepatchte Software (alte Versionsstrings in HTML/Headers).
  • Ungeprüfte File-Uploads (Upload Endpoints ohne Content-Type Checks).
  • JS-gefundene API-Endpoints (keine Auth oder schwache Auth).
  • IDOR: Vorhersagbare IDs (z. B. /user/123/profile) → Testen mit anderen IDs (nur safe/in-scope!).
  • Reflektive XSS: Query-Parameter, Suchfelder, Rückgabefelder.
  • Insecure CORS oder misconfigured HSTS/HTTPS/Content-Security-Policy.

8. Beispiel: kurze Recon-Session (konkretes Mini-Beispiel)

  1. Ziel: sub.example.com (im Scope).
  2. httpx zeigt Status 200 und <title>Example App</title>? .
  3. curl auf https://sub.example.com/static/app.js → in JS: /api/v1/users/{id} und https://api.internal.example.com gefunden.
  4. ffuf findet /admin → 302 redirect to /admin/login.
  5. paramspider findet ?q= Parameter → teste auf reflektive XSS mit harmloser Payload (<script>alert(1)</script>) nur wenn im Scope und risikoarm.
  6. Ergebnis: API-Endpoint sichtbar + offene Admin-URL → priorisieren für sanfte Tests (auth checks, access control).

9. Wie du sicher testest (sichere PoCs)

  • Verwende harmlose, nicht-destruktive Payloads (z. B. '<svg/onload=alert(1)>' für reflektiven XSS).
  • Keine Datenexfiltration, keine Mass-Requests (vermeide DoS).
  • Wiederhole nur so viel wie nötig, um Reproduzierbarkeit zu beweisen.
  • Screenshots + Request/Response mit Burp/HTTPie sind oft ausreichend als PoC.

10. Dokumentation & Report-Template (kurz)

  • Titel: Kurze, aussagekräftige Überschrift
  • Ziel/Scope: betroffene Host/Subdomain, Datum & Uhrzeit (UTC)
  • Schweregrad: Vorschlag (Low/Med/High/Critical)
  • Beschreibung: Was ist das Problem? Warum relevant?
  • Proof of Concept: Reproduzierbare Schritte (Requests, minimaler Payload), Screenshots, Response-Snippets
  • Impact: Mögliche Folgen (Account takeover, data leak, RCE etc.)
  • Mitigation: Konkrete Vorschläge (Input validation, Auth checks, Rate-limit, CSP)
  • Anhänge: Burp-logs, curl-commands, nmap-output

11. Nützliche Wordlists & Ressourcen (ohne Links)

  • Wordlists: common, big.txt, raft-large-directories, discovery
  • JS-analysis: suche nach api, endpoint, token, client_id, aws, s3
  • Trainingsziele: PortSwigger Academy, OWASP Juice Shop, WebGoat, DVWA, HackTheBox / TryHackMe Web-rooms.

12. Tipps zur Effizienz (Zeit sparen)

  • Automatisiere Pipeline: Subdomain → httpx → wayback/JS scrape → ffuf auf gefundene Hosts.
  • Verwende jq, ripgrep und sed/awk für schnelle Extraktion aus Output.
  • Parallele Threads sinnvoll, aber achte auf Rate-Limits / DoS-Risiko.
  • Halte ein persönliches Recon-Playbook (Befehle, bevorzugte Wordlists, Notizen).

13. Warum Duplicate-Reports nicht immer schlecht sind

  • Ein Duplicate kann trotzdem valid sein (manche Plattformen zählen es), vor allem wenn es bestätigt wurde oder du Details ergänzt (PoC, Impact).
  • Bei manchen Programmen führten frühe Duplicates zu Einladungen zu Private Programs — ein Duplicate beweist oft, dass du zügig und zuverlässig bist.
  • Empfehlung: Wenn du einen Duplicate meldest, füge Mehrwert hinzu: besserer PoC, weitere betroffene Endpunkte, Exploit-Prävention.

14. Häufige Anfängerfehler & wie du sie vermeidest

  • Zu aggressiv scannen → IP/Host aus dem Programm gesperrt. (Lies Rate-Limits)
  • Nicht scoping/Übersehen von subdomains → verlorene Chancen.
  • Keine Dokumentation → Nachvollziehbarkeit geht verloren.
  • Blindes Crawling von sensitive endpoints → vermeide destructive Aktionen.

15. Beispiel-Checkliste (Quick Recon Checklist)

  • Scope gelesen & dokumentiert
  • Passive Subdomain-Liste erstellt
  • Lebende Hosts (httpx) identifiziert
  • Ports/Services (nmap) gescannt (im Scope)
  • Wayback/Archive URLs gespeichert
  • JS-Files geparst & API-Endpoints notiert
  • Directory Fuzzing durchgeführt (ffuf/gobuster)
  • Parameterliste (paramspider/arjun) angelegt
  • Priorisierte Testliste erstellt (auth-frei + high-impact)
  • Minimaler PoC vorbereitet & dokumentiert
  • Report-Template ausgefüllt

16. Weiterlernen — Übungsaufgaben

  • Führe Recon an einem Übungsziel (z. B. Juice Shop) durch und dokumentiere jede Phase.
  • Automatisiere Subdomain → httpx → JS-Scrape → ffuf als kleines Shell-Script.
  • Erstelle einen Report aus deiner Übung und vergleiche mit offiziellen Writeups.

Schlusswort

Recon ist eine Fähigkeit, die mit Systematik und Übung deutlich besser wird. Beginne klein, arbeite sauber und dokumentiere alles. Halte dich an Scope & Legalität — das macht dich zum vertrauenswürdigen Forscher, für den Unternehmen gern bounties vergeben.