Worum es hier geht
Recon ist 60 bis 70 Prozent der Arbeit auf Bug-Bounty. Wer nicht gut findet, wo die Targets ihre Assets hingestellt haben, findet auch keine Lücken. Klassisch wird das mit Maltego, SpiderFoot oder einer eigenen Bash-Toolchain gebaut.
Dieser Artikel zeigt, ob Claude Code als Orchestrator und Korrelator zu den Standard-OSINT-Tools eine echte Maltego-Alternative ist. Kurzfassung: Ja, für etwa 80 Prozent der Recon-Workflows. Maltego bleibt überlegen bei visueller Graph-Analyse — Claude Code überlegen bei Repeatability und JSON-zu-Asset-Inventar.
Wichtig vorab: Diese Techniken gehören ausschließlich in dokumentierten Bug-Bounty-Scope (z. B. auf HackerOne) oder in andere autorisierte Kontexte. Nichts davon gegen Systeme ohne Erlaubnis.
Die Pipeline in einem Bild
Target-Domain
↓
[1. Subdomain-Discovery] subfinder + amass + assetfinder + dnsx
↓
[2. Tech-Fingerprinting] httpx + whatweb
↓
[3. URL-Discovery] gau + waybackurls + katana
↓
[4. People-OSINT] theHarvester + Hunter.io API + Sherlock
↓
[5. Korrelation + Map] Claude Code aggregiert, klassifiziert, priorisiert
↓
Asset-Inventar.md (mit Vulnerability-Hypothesen)
Jeder Tool-Output ist JSON. Claude Code liest alle JSON-Files im Verzeichnis, dedupliziert, korreliert (welche Subdomain hat welche Tech, welcher User-Account ist mit welcher Domain assoziiert) und produziert ein einziges INVENTORY.md, das man dann manuell durchgeht.
Stufe 1 — Subdomain-Discovery automatisieren
Drei Tools parallel, in ~/recon/<target>/subdomains/:
mkdir -p subdomains && cd subdomains
# Passive Quellen (Cert-Transparency, DNSDumpster, etc.)
subfinder -d $TARGET -all -silent -oJ -o subfinder.json
# Aktive + passive, langsamer aber thorough
amass enum -d $TARGET -active -json amass.json
# Schneller passive-only Wrapper
assetfinder --subs-only $TARGET > assetfinder.txt
Drei Tools, weil keines alle Quellen abdeckt. subfinder hat 60+ Datenquellen, amass macht zusätzlich brute-force und permutations, assetfinder ist als Backup-Quelle gut.
Dann übernimmt Claude den Merge:
claude
> Lies alle Files in diesem Verzeichnis. Erstell eine deduplizierte Liste
> aller eindeutigen Subdomains. Outputformat: ein-Subdomain-pro-Zeile,
> sortiert. Schreib das nach merged.txt. Anzahl unique am Ende ausgeben.
Claude öffnet die JSON, parst, dedupliziert, schreibt merged.txt. Das spart genau die 5 Minuten Bash-Glue, die man sonst tippt.
Stufe 2 — Tech-Fingerprinting
cat ../subdomains/merged.txt | httpx -title -tech-detect -status-code \
-json -o httpx.json -threads 50
httpx prüft, welche Subdomain wirklich live ist, welche Tech sie nutzt (WordPress, Nginx, Cloudflare, Go-Backends) und welche Status-Codes sie zurückgibt.
Jetzt der Claude-Schritt, der wirklich Wert bringt:
> Lies httpx.json. Klassifiziere Subdomains in:
> - "Marketing/CMS" (WordPress, Drupal, etc.)
> - "Custom-App" (eigene Tech-Stacks)
> - "Cloud-Storage" (S3, GCS, Azure-Blob)
> - "Dev/Staging" (Hostnames mit dev-, test-, staging-, internal-)
> - "Security-relevant" (Admin-Panels, VPN-Endpoints, API-Gateways)
> Sortier pro Kategorie nach Interessantheit für Pentest. Schreib nach
> classified.md mit Begründung pro Eintrag.
Das ist Maltego-Territorium — visuell wäre das ein Graph mit Nodes nach Tech-Color. Hier ist es eine sortierte Markdown-Tabelle. Für einen grep-basierten Workflow ist das schneller, weil man es filtern und in einen VS-Code-Workspace ziehen kann.
Stufe 3 — URL-Discovery aus Web-Archive
Hier glänzt eine Tool-Kombo:
# Wayback Machine + Common Crawl
gau --subs $TARGET > urls-passive.txt
# Aktiver Crawl der Live-Subdomains
katana -list ../tech/live-only.txt -d 2 -jc -kf all -o urls-active.txt
# Filtern auf interessante Dateitypen
cat urls-passive.txt urls-active.txt | sort -u | grep -E '\.(php|asp|aspx|jsp|js|json|xml|sql|bak|env|log|conf)$' > urls-interesting.txt
Claude bekommt das urls-interesting.txt plus die Anweisung:
> Hier ~12000 URLs aus passive + active Discovery. Cluster sie nach:
> - Wahrscheinliche Login-Endpoints
> - Wahrscheinliche API-Endpoints
> - Backup/Config-Files (.bak, .env, .git, .DS_Store)
> - Admin-Routen
> - Static Assets (für Pattern-Mining)
> Pro Cluster: Top 10 mit Begründung.
Genau hier liegt der Mehrwert: In so einem Lauf findet die Klassifizierung typischerweise Perlen, die man aus 12.000 Zeilen nicht rausgegrept hätte — etwa einen alten, längst vergessenen .git-Ordner-Eintrag im Web-Archiv.
Stufe 4 — People-OSINT für Phishing-Surface (im Bug-Bounty-Scope)
Hier ist die rechtliche Grenze besonders eng. Manche Bug-Bounty-Programme erlauben Social Engineering, die meisten nicht. Das gehört nur in den Scope, wenn es explizit erlaubt ist.
# Mitarbeiter-E-Mails über public Quellen (LinkedIn, GitHub, theHarvester)
theHarvester -d $TARGET -b google,bing,linkedin -l 500 -f harvest.json
# Wenn Hunter.io API-Key da: hochwertigere Daten
curl -s "https://api.hunter.io/v2/domain-search?domain=$TARGET&api_key=$HUNTER_KEY" > hunter.json
# Username-Lookup über 250+ Plattformen
sherlock $USERNAME --output sherlock-$USERNAME.json
Claude korreliert die User-Accounts:
> Lies harvest.json + hunter.json + alle sherlock-*.json.
> Erstell pro Person:
> - Name
> - Bekannte E-Mail-Adressen (mit Quelle)
> - Aktive Social-Media-Accounts (mit URL)
> - Wahrscheinliche Rolle (aus LinkedIn/GitHub-Bio)
> - Tech-Stack-Hinweise (von GitHub-Repos)
> Schreib pro Person eine Card in people/.
Das ist Maltego-Map auf textueller Ebene. Für 5-10 Personen funktioniert das super, ab 50+ wird Maltego mit Visual-Graph schneller.
Stufe 5 — Korrelation und Vulnerability-Hypothesen
Der Endpunkt der Pipeline ist eine INVENTORY.md mit allen Findings:
> Lies alle Files in diesem Verzeichnis (subdomains/, tech/, urls/, people/).
> Generier ein INVENTORY.md mit:
>
> 1. Asset-Übersicht: alle live Subdomains, gruppiert nach Tech
> 2. High-Priority Targets: Subdomains die Admin-Panels haben oder
> auf veraltete Tech zeigen
> 3. Dokumentierte Backup-/Config-Files mit URL
> 4. Vulnerability-Hypothesen pro Asset:
> - Was wäre die wahrscheinlichste Schwachstelle aus historischen
> Daten der gleichen Tech?
> - Welcher Test wäre als nächstes sinnvoll?
> 5. Dependencies: welche Targets sollten zuerst getestet werden?
>
> WICHTIG: Keine Halluzinationen. Wenn du eine Vulnerability vermutest
> aber nicht belegen kannst, schreib "Hypothese, nicht verifiziert".
> Wenn du eine CVE nennst, gib Nummer und Datum.
Output ist eine Liste mit 30-50 priorisierten Targets, jedes mit erklärtem "Warum interessant". Das ist der Pentest-Plan für die nächsten Tage.
Was Claude besser macht als Maltego
Repeatability. Eine Maltego-Map ist visuell und lebt im UI. Die Pipeline hier ist ~/recon/<target>/run.sh plus Claude-Prompt-Templates. Sie lässt sich gegen ein neues Target in 20 Minuten zu Output-Markdowns reproduzieren.
JSON-Aggregation. Maltego ist gut für visuelle Inspection, aber wenn du 12000 URLs strukturieren willst, ist Claude im Stream-Reading von JSONs unschlagbar.
Long-tail Korrelation. "Ist die E-Mail von Person A im PGP-Schlüssel von Server B referenziert?" — solche Queries beantwortet Claude über die JSON-Outputs schnell. In Maltego ist das eine Multi-Click-Operation.
Cost. Maltego Pro Lizenz: 999 USD/Jahr. SpiderFoot HX: 89 USD/Monat. Die Claude-Pipeline: kostet die Anthropic-Credits, die du ohnehin für Claude Code nutzt — also effektiv ein niedriger zweistelliger Betrag pro Monat.
Was Maltego besser macht
Visualisierung. Wenn ein Bug-Bounty-Manager im Standup verstehen soll, wie 30 Subdomains zusammenhängen, ist ein Graph mit gerichteten Edges schneller verstanden als eine Markdown-Tabelle.
Tracker-Visualisierung. Wenn du E-Mail-Adressen oder Telefonnummern über 50 Datenbanken durchsuchen willst (Pipl, Spokeo, etc.), hat Maltego mehr fertige Transforms.
Dark-Web-Analyse. Maltego hat Module für Tor-Hidden-Services und Dark-Web-Marketplaces, die Claude Code nicht ersetzt.
Forensik-Workflows. Wenn du Image-EXIF, Metadata-Forensik oder Ähnliches brauchst, ist Maltego mit seinen 1000+ Transforms überlegen.
Ein Setup für reproduzierbare Bug-Bounty-Recon
~/recon/
├── _templates/
│ ├── recon.sh # Pipeline-Skript
│ ├── claude-prompts.md # Standard-Prompts pro Stage
│ └── INVENTORY-TEMPLATE.md # Output-Schema
├── target-1.com/
│ ├── subdomains/
│ ├── tech/
│ ├── urls/
│ ├── people/
│ ├── INVENTORY.md
│ └── .claude/settings.json # Tool-Allowlist
└── target-2.com/
└── (gleiche Struktur)
.claude/settings.json hat eine Allowlist für Bash(subfinder *), Bash(amass *), Bash(httpx *), Bash(theHarvester *), Bash(sherlock *) — kein Approval-Spam, kein Risiko, dass Claude etwas Unbekanntes startet.
recon.sh ist 80 Zeilen Bash, parallelisiert die ersten 4 Stages und ruft am Ende claude < claude-prompts.md für die Korrelation auf.
Fazit
Für strukturierte, reproduzierbare Recon ist Claude Code + die ProjectDiscovery-Toolkette eine ernste Maltego-Alternative — gerade für Bug-Bounty-Hunter, die einzeln arbeiten und keine Team-Visualisierung brauchen.
Für Forensik, visuelle Reports und sehr breite Tracker-Lookups bleibt Maltego das bessere Werkzeug. Beide kombinieren ist möglich: Claude für Discovery + JSON-Aggregation, Maltego für die finale visuelle Story zum Kunden.
Rechtlicher Hinweis
Die hier gezeigten Techniken dürfen ausschließlich in einem der folgenden Kontexte angewendet werden:
- Eigenes Lab / eigene Hardware (z. B. eigener Router, eigene VMs)
- Capture-The-Flag-Umgebung (HackTheBox, TryHackMe, OverTheWire)
- Schulungsumgebung (DVWA, Juice Shop, WebGoat, HackerLab)
- Autorisierter Pentest mit schriftlichem Auftrag
- Bug-Bounty-Programm im dokumentierten Scope (HackerOne, Intigriti, YesWeHack)
Die Anwendung dieser Techniken gegen Systeme Dritter ohne ausdrückliche schriftliche Erlaubnis ist in Deutschland nach §§ 202a, 202b, 202c, 303a, 303b StGB strafbar. Wir übernehmen keine Haftung für Missbrauch.
Du bist Pentester, Bug-Bounty-Hunter oder CTF-Spieler? Komm in die Zone "Hacking & Security" im Discord — da diskutieren wir Techniken und teilen Lab-Setups.
