OSINT-Pipelines mit Claude Code — Maltego-Alternative für Bug-Bounty-Recon

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.

Ich hab eine Woche lang ausprobiert, ob Claude Code als Orchestrator und Korrelator zu den Standard-OSINT-Tools eine echte Maltego-Alternative ist. Spoiler: Ja, für 80 Prozent der Recon-Workflows. Maltego bleibt überlegen wenn es um visuelle Graph-Analyse geht — Claude Code überlegen, wenn es um repeatability und JSON-zu-Asset-Inventar geht.

Wichtig vorab: Alle Tests in diesem Artikel waren in dokumentiertem Bug-Bounty-Scope auf HackerOne. Nichts 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 ich dann manuell durchgehe.

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 lasse ich Claude den Merge machen:

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 ich sonst tippe.

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 meinen Workflow ist das schneller, weil ich es mit grep filtern kann und in ein VS-Code-Workspace ziehen.

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.

Bei meinem Test-Target hat das einen .git-Ordner-Eintrag aus 2018 wieder gefunden — den ich sonst aus 12000 Zeilen nicht rausgegrept hätte.

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. Ich mach das nur wenn explizit im Scope.

# 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 mein Pentest-Plan für die nächsten Tage.

Was Claude besser macht als Maltego

Repeatability. Eine Maltego-Map ist visuell und lebt im UI. Meine Pipeline ist ~/recon/<target>/run.sh plus Claude-Prompt-Templates. Ich kann das 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 kann Claude über die JSON-Outputs schnell beantworten. In Maltego ist das ein Multi-Click-Operation.

Cost. Maltego Pro Lizenz: 999 USD/Jahr. SpiderFoot HX: 89 USD/Monat. Meine Pipeline: kostet die fal.ai/Anthropic-Credits die du eh für Claude Code nutzt — also effektiv 20 USD/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.

Mein Setup für reproduzierbare Bug-Bounty-Recon

Was ich nach der Woche behalte:

~/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 was 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.

Wie wir diesen Artikel geprüft haben

• Tests durchgeführt am: 2026-04-12 bis 2026-04-18
• Hardware: Kali Linux 2025.4 VM, 16 GB RAM, isolierter Tenant
• Software-Versionen: Claude Code 2.4.1, subfinder 2.6.6, amass 4.2, theHarvester 4.5, Sherlock 0.15, gau 2.2, httpx 1.6, katana 1.1
• KI-Unterstützung: Claude Code 2.4.1 als Pipeline-Orchestrator und JSON-Korrelator
• Targets: zwei autorisierte Bug-Bounty-Programme auf HackerOne, anonymisiert
• Sponsor/Affiliate: keines

---

Rechtlicher Hinweis

Die hier gezeigten Techniken wurden ausschließlich in einem der folgenden Kontexte getestet:

• 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.