Zum Hauptinhalt springen

OSINT — Praktischer Workshop

Sie nehmen sich ein reales Ziel — ein öffentliches Bug-Bounty-Programm — vor und zerlegen es vollständig passiv. Ergebnis: ein vollständiges Zieldossier mit fünf priorisierten und eingestuften Angriffspunkten.

Zeitaufwand: 2 bis 3 Stunden.

Ergebnis: ein vollständiger Ordner ~/osint/<ziel>/ mit einem zweiseitigen fiche-cible.md an der Spitze.

Strikter Rahmen

Sie müssen ein öffentliches Bug-Bounty-Programm wählen, dessen Scope Aufklärung ausdrücklich erlaubt. Kein anderes Ziel ist akzeptabel. Verwenden Sie HackerOne — Open programs, Bugcrowd — Public programs oder Intigriti. Bleiben Sie strikt passiv: Dieser Workshop umfasst keinerlei Scan, keine Anfrage an das Ziel.


Schritt 1 — Das Ziel wählen (10 Min.)​

Öffnen Sie die Liste der öffentlichen Programme. Wählen Sie ein Programm, das:

  • *.exemple.com ausdrücklich in seinem Scope erlaubt.
  • keine vorherige Registrierung für passive Aufklärung verlangt.
  • ein Unternehmen mittlerer Größe betrifft (nicht Google — zu massiv, keine 5-Personen-Startup — zu dürftig für OSINT). Ein B2B-SaaS mit 100 bis 1000 Mitarbeitern ist ideal.

Notieren Sie:

Gewähltes Programm: <Name>
Plattform: HackerOne / Bugcrowd / Intigriti
Programm-URL: ...
Root-Domain: ziel.com
Scope in: *.ziel.com, ziel.io
Scope out: blog.ziel.com, salesforce.ziel.com (SaaS von Drittanbietern)
Disclosure-Richtlinie: Responsible Disclosure, 90 Tage

Dieser Block kommt an den Anfang Ihrer Datei fiche-cible.md. Er belegt, dass Sie autorisiert sind. Das ist Ihr RoE für diesen Workshop.


Schritt 2 — Das Verzeichnis vorbereiten (2 Min.)​

CIBLE=<ihr-ziel-ohne-www>   # z. B.: acme.io
mkdir -p ~/osint/$CIBLE/{dns,subs,tech,people,leaks,archive}
cd ~/osint/$CIBLE
touch fiche-cible.md

Beginnen Sie fiche-cible.md mit dem Scope-Block aus Schritt 1. Ohne den haben Sie keine gültige Entschuldigung, falls jemand Sie fragt: „Warum haben Sie sich meine Firma angeschaut?“


Schritt 3 — DNS und E-Mail-Sicherheitslage (10 Min.)​

Wiederholen Sie die Schleife aus der Demonstration:

for t in A AAAA MX NS TXT SOA CAA; do
echo "=== $t ==="
dig +short $CIBLE $t
done | tee dns/racine.txt

dig +short _dmarc.$CIBLE TXT | tee dns/dmarc.txt

Beantworten Sie in fiche-cible.md folgende Fragen:

  • Steht die Domain hinter einem CDN? Welchem?
  • Welches sind die E-Mail-Anbieter?
  • Nennt das SPF SaaS-Dienste? Welche?
  • Ist die DMARC-Richtlinie none, quarantine oder reject? (none = Phishing-Vektor)

Schritt 4 — Subdomains (20 Min.)​

Drei Quellen, zum Abgleich. Strikt passiv.

# Quelle 1 — Certificate Transparency
curl -s "https://crt.sh/?q=%25.$CIBLE&output=json" \
| jq -r '.[].name_value' \
| tr '[:upper:]' '[:lower:]' \
| sed 's/^\*\.//' \
| sort -u > subs/from-crt.txt

# Quelle 2 — subfinder
subfinder -d $CIBLE -silent -all -o subs/from-subfinder.txt

# Quelle 3 — amass passiv
amass enum -passive -d $CIBLE -o subs/from-amass.txt

# Fusion
cat subs/from-*.txt | sort -u > subs/all-passive.txt
wc -l subs/all-passive.txt

Passive Auflösung (über öffentliche Resolver, niemals beim Kunden):

dnsx -l subs/all-passive.txt -a -resp -silent -r 1.1.1.1,8.8.8.8 \
-o subs/resolved.txt

Öffnen Sie subs/resolved.txt. Identifizieren Sie:

  • Die IPs außerhalb des CDN (jene, die nicht mit 104.16-31, 172.64-71, 141.101, 173.245 beginnen — die Cloudflare-Blöcke — oder mit denen von Fastly, Akamai usw.). Diese IPs zeigen oft auf den echten Server hinter dem CDN. Goldenes Ziel.
  • Die Subdomains mit aufschlussreichen Schlüsselwörtern:
    • dev, staging, test, preprod, internal, old, legacy, admin, panel, jenkins, gitlab, sonar, vault, backup, vpn, ssh, rdp.
  • Die privaten IPs (10.x, 172.16-31.x, 192.168.x), die in einem öffentlichen DNS veröffentlicht sind: zu meldender Konfigurationsfehler.

Listen Sie in fiche-cible.md die 10 interessantesten Subdomains mit ihrer IP und einem Hinweis, was sie interessant macht.


Schritt 5 — Technologien (20 Min.)​

Ohne das Ziel zu berühren. Verwenden Sie:

  • BuiltWith in Ihrem Browser.
  • Shodan per CLI oder Web:
# Für jede in Schritt 4 identifizierte IP außerhalb des CDN:
shodan host <IP> > tech/shodan-<subdomain>.txt
  • Wappalyzer — Achtung, aktiv. Wenn Ihr Workshop-RoE light active erlaubt, können Sie es verwenden (ein einfaches Öffnen der Seite im Browser = ein HTTP-Treffer, der in den Logs des Ziels sichtbar ist). Andernfalls lassen Sie es sein.

Notieren Sie in tech/synthese.md, für jedes identifizierte Ziel:

  • Webserver und Version.
  • Anwendungs-Framework, falls erkennbar.
  • Von Shodan gesehene offene Ports (nicht von Ihnen gescannt — Shodan hat sie bereits gescannt, Sie konsultieren sie nur).
  • Dienst-Banner (SSH, Mail…).
  • Sichtbare Konfigurationsfehler: DEBUG-Modus, Fehlerseiten, die den Stack verraten, ein zu geschwätziger Server:-Header.

Schritt 6 — Personen (20 Min.)​

# Sucht E-Mails + LinkedIn-Profile (über Bing)
theHarvester -d $CIBLE -b linkedin,bing,duckduckgo -l 500 \
-f people/harvester.html

Ergänzen Sie manuell auf LinkedIn:

  • Aktive Mitarbeiter mit technischen Titeln (CTO, VP Eng, DevOps, SRE, Sec, IT).
  • Ehemalige Mitarbeiter (letzte Position: <ihr-ziel>, Vermerk „left in <Datum>“). Ihre öffentlichen GitHub-Profile enthalten manchmal Relikte.

Konsolidieren Sie people/personnes.csv:

prenom,nom,titre,email,linkedin,github

Ziel: mindestens 15 Personen identifiziert. Sie werden später nur 3 oder 4 angreifen, aber Sie brauchen den Pool.


Schritt 7 — Lecks (20 Min.)​

Drei Quellen, in dieser Reihenfolge:

1. HaveIBeenPwned nach Domain (falls Sie einen API-Schlüssel haben, sonst nutzen Sie die Weboberfläche pro einzelner E-Mail):

curl -s -H "hibp-api-key: $HIBP_KEY" \
"https://haveibeenpwned.com/api/v3/breacheddomain/$CIBLE" \
| jq . > leaks/hibp.json

2. GitHub Search für das Ziel und für jeden gelisteten Mitarbeiter:

https://github.com/search?type=commits&q=%22$CIBLE%22
https://github.com/search?type=code&q=%22$CIBLE%22+password
https://github.com/search?type=code&q=%22$CIBLE%22+AKIA
https://github.com/search?type=code&q=%22$CIBLE%22+secret

Das Muster AKIA sucht nach AWS-Schlüsseln. Das Muster password sucht nach … Passwörtern. Sie werden nicht immer etwas finden; wenn Sie etwas finden, ist es Gold wert.

3. Pastebin / Ghostbin / Rentry über Google:

site:pastebin.com "$CIBLE"
site:ghostbin.co "$CIBLE"
"$CIBLE" password ext:txt

Notieren Sie in leaks/synthese.md:

  • Anzahl der geleakten Ziel-E-Mails und in welchen Dumps.
  • Jeden Schlüssel, jedes Passwort, jedes Geheimnis, das in den letzten 3 Jahren gefunden wurde.

Schritt 8 — Wayback-Archive (10 Min.)​

curl -s "https://web.archive.org/cdx/search/cdx?url=$CIBLE/*&output=json&limit=500" \
| jq -r '.[1:] | .[] | .[2]' \
| sort -u > archive/urls.txt

grep -iE 'admin|backup|debug|swagger|api-doc|test|internal|dev|graphql|env|config|status' archive/urls.txt \
> archive/interessants.txt

wc -l archive/urls.txt archive/interessants.txt

Notieren Sie in fiche-cible.md die 5 bis 10 interessantesten in den Archiven gefundenen URLs — in Woche 4 erneut zu validieren.


Schritt 9 — Google Dorks (15 Min.)​

Öffnen Sie Google (oder DuckDuckGo, weniger auffällig) und führen Sie mindestens diese Abfragen aus, mit Variationen:

site:$CIBLE inurl:admin
site:$CIBLE inurl:login
site:$CIBLE inurl:.git
site:$CIBLE ext:sql
site:$CIBLE ext:env
site:$CIBLE ext:log
site:$CIBLE ext:bak
site:$CIBLE intitle:"index of"
site:$CIBLE "internal use only"
site:$CIBLE "confidential"
site:$CIBLE "-----BEGIN" # Anfang von PGP-/RSA-Schlüsseln
site:*.amazonaws.com "$CIBLE" # benannte S3-Buckets
site:*.blob.core.windows.net "$CIBLE" # Azure-Blobs
site:*.digitaloceanspaces.com "$CIBLE"

Machen Sie einen Screenshot von jedem nicht-trivialen Ergebnis. Klicken Sie nicht direkt von Google aus (der Klick läuft über einen Google-Redirector, landet aber beim Ziel = aktiv). Kopieren Sie die URL und fügen Sie sie später, in Woche 4, bewusst aktiv, in ein curl -I -A "Mozilla/5.0"-Fenster ein.


Schritt 10 — Konsolidierung (30 Min.)​

Öffnen Sie fiche-cible.md und füllen Sie folgende Abschnitte sorgfältig aus. Jeder Abschnitt hat Vollständigkeitskriterien.

# Zieldossier — <ZIEL>  (<Datum>)

## 0. Umfang und Autorisierung
[der Block aus Schritt 1, mit der URL des Programms]

## 1. Bestätigte Assets
- Root-Domain + Registrar
- <N> gesammelte Subdomains (Quellen: crt.sh, subfinder, amass)
- Interessanteste Subdomains (5-10, mit IP + Hinweis)

## 2. Adressierung
- Blöcke und Anbieter (Cloudflare, AWS, Azure, GCP, OVH, Vultr…)
- Identifizierte IPs außerhalb des CDN

## 3. Technologien
- Frontend, Backend, wahrscheinliche Datenbank
- Webserver und Versionen (via Shodan)
- Verbundene SaaS (Stripe, Twilio, Sentry, Datadog… in SPF oder Headern gesehen)

## 4. E-Mail-Sicherheitslage
- MX
- SPF (Liste der includes)
- DMARC (Richtlinie, Alignment)
- DKIM vorhanden?

## 5. Schlüsselpersonen (>= 15)
- Datei people/personnes.csv beigefügt

## 6. Öffentliche Lecks
- HIBP: <N> betroffene Konten, Dumps
- GitHub: gefundene Geheimnisse (Repo, Datei, Art des Geheimnisses angeben)
- Pastebin / Google: Funde

## 7. Fünf priorisierte Ziele (absteigende Reihenfolge)
1. <Ziel> — <Grund> — <geschätzter Aufwand zur Bestätigung>
2. ...
3. ...
4. ...
5. ...

## 8. Nächster Schritt (Modul 4)
- Plan der aktiven Phase: welche Subdomain, welches Tool, welches Zeitfenster.
- Mit dem RoE zu verhandelnde Punkte (falls eine Subdomain außerhalb des ursprünglichen Scopes entdeckt wurde).

Selbstbewertungsraster​

  • Das Bug-Bounty-Programm und sein Scope stehen am Anfang des Dossiers.
  • Mindestens 50 Subdomains gesammelt (100+ bei einem normalen Ziel anstreben).
  • Abgleich durchgeführt: crt.sh + subfinder + amass (alle drei, nicht nur eines).
  • Alle IPs sind klassifiziert als CDN / Nicht-CDN / privat.
  • E-Mail-Sicherheitslage dokumentiert (SPF, DMARC, DKIM).
  • Mindestens 15 Personen mit anhand des Musters erratener E-Mail.
  • Mindestens eine Leck-Quelle konsultiert (HIBP oder GitHub Search).
  • Wayback Machine konsultiert, Top-URLs notiert.
  • Fünf priorisierte Ziele mit Begründung eingestuft.
  • Kein Befehl hat das Ziel berührt. Kein Scan. Kein direktes curl.

Alles abgehakt? Ihr Dossier ist bereit, Woche 4 zu speisen.


Was in der Regel hakt​

  • Wenig Subdomains: Das Ziel ist klein oder größtenteils gut hinter einem CDN versteckt. Verbringen Sie mehr Zeit mit GitHub und LinkedIn.
  • Kein Zugang zu Shodan/HIBP: Kostenlose Versionen verfügbar, weniger umfangreich. Oder warten Sie bis zum Ende des Kurses, das Abonnement lohnt sich.
  • theHarvester liefert wenig: LinkedIn sperrt regelmäßig den Zugang über Bing. Erstellen Sie das Organigramm manuell, das dauert 30 Minuten.
  • Versuchung zu scannen: Das ist ein Zeichen, dass die passiven Quellen noch nicht genug ausgeschöpft sind. Suchen Sie weiter.

Was Sie aus diesem Workshop mitnehmen​

  • Einen reproduzierbaren Workflow in 2 Std. auf jedem autorisierten Ziel.
  • Ein zweiseitiges Dossier, das die Referenz für alle folgenden Module zu diesem Ziel sein wird.
  • Das Gespür, eine interessante Subdomain in einer Sekunde zu erkennen.
  • Die Disziplin, nichts zu senden, bevor man nicht alles angeschaut hat.