OSINT — Geführte Demonstration

Ein Ziel. Ein echtes. Wir werden ihm nichts senden. Und am Ende kennen wir: seine Subdomains, seine Technologien, seine Schlüsselmitarbeiter, seine Lecks und seine fünf wahrscheinlichen Schwachstellen.

Die Wahl des Ziels für diese Demo

Wir verwenden ein öffentliches Bug-Bounty-Programm, bei dem das Unternehmen Tests ausdrücklich in einem festgelegten Rahmen erlaubt. Sie können bei sich zu Hause dasselbe tun, indem Sie ein Programm auf HackerOne oder Bugcrowd auswählen. In der folgenden Demo verwenden wir zur Veranschaulichung den fiktiven Namen demo-corp.com — aber alles, was Sie sehen, lässt sich auf einem realen, autorisierten Ziel reproduzieren.

Was Sie nach dieser Lektion können

In 90 Minuten von einem einfachen Domainnamen zu einer Infrastrukturkarte gelangen.
crt.sh, subfinder, amass -passive, dnsx (passiver Modus), theHarvester, whatweb verwenden.
Lebende von toten Subdomains unterscheiden, ohne sie zu berühren.
Drei unabhängige Quellen abgleichen, bevor man Schlüsse zieht.
Ein zweiseitiges Zieldossier erstellen, das ab Modul 4 nutzbar ist.

Schritt 0 — Der Ausgangspunkt

Eine einzige Zeile:

Ziel: demo-corp.com
Programm: öffentliches Bug Bounty, Scope in-scope = *.demo-corp.com

Das ist alles. Wir starten von da.

Erstellen Sie das Arbeitsverzeichnis:

mkdir -p ~/osint/demo-corp/{dns,subs,tech,people,leaks,archive}
cd ~/osint/demo-corp

Jede Quellenfamilie bekommt ihr eigenes Unterverzeichnis. Disziplin von Anfang an.

Schritt 1 — Grundlegendes DNS (2 Minuten)

Die wesentlichen Einträge, einer nach dem anderen:

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

Typische Ausgabe:

=== A ===
104.21.44.15
172.67.187.219
=== AAAA ===
=== MX ===
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
=== NS ===
ada.ns.cloudflare.com.
kirk.ns.cloudflare.com.
=== TXT ===
"v=spf1 include:_spf.google.com include:mailgun.org -all"
"google-site-verification=abc123def456..."
"MS=ms84726311"
"stripe-verification=xyz789..."
=== SOA ===
ada.ns.cloudflare.com. dns.cloudflare.com. 2354...
=== CAA ===
0 issue "letsencrypt.org"
0 issue "digicert.com"

Lesart:

A: zwei IPs im Cloudflare-Pool (104.21.x und 172.67.x). Die Website steht hinter Cloudflare — wir werden die echte IP nicht ohne Aufwand sehen.
MX: Google Workspace. Kein eigener Mailserver.
NS: ada.ns.cloudflare.com — Cloudflare verwaltet auch das DNS. Konsistent.
TXT:
- SPF autorisiert Google und Mailgun. Zwei SaaS-Dienste identifiziert.
- google-site-verification: Sie nutzen die Google Search Console.
- MS=: Sie nutzen Microsoft (oft Bing Webmaster).
- stripe-verification: Sie wickeln Zahlungen über Stripe ab. Das bedeutet PCI-DSS irgendwo.
CAA: nur Let's Encrypt und DigiCert dürfen Zertifikate ausstellen. Gutes Zeichen für die Hygiene.

In 2 Minuten wissen wir bereits: Cloudflare, Google Workspace, Mailgun, Stripe. Wir haben kein einziges Paket an demo-corp.com gesendet.

Schritt 2 — DMARC und E-Mail-Sicherheitslage (1 Minute)

dig +short _dmarc.demo-corp.com TXT

Ausgabe:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@demo-corp.com"

Lesart: p=none. Die DMARC-Richtlinie ist vorhanden, bewirkt aber nichts. Konkretes Ergebnis: Ein Angreifer kann E-Mails spoofen, die angeblich von demo-corp.com gesendet wurden, und diese E-Mails kommen beim Empfänger an, selbst wenn sie DMARC nicht bestehen. Das ist ein Phishing-Vektor, den man für Modul 6 vermerken sollte.

Speichern Sie das in dns/dmarc.txt.

Schritt 3 — Subdomains über `crt.sh` (3 Minuten)

Certificate Transparency, die beste Quelle für die erste Welle an Subdomains. Wir fragen im JSON-Format ab und bereinigen mit jq:

curl -s 'https://crt.sh/?q=%25.demo-corp.com&output=json' \
  | jq -r '.[].name_value' \
  | tr '[:upper:]' '[:lower:]' \
  | sed 's/^\*\.//' \
  | sort -u \
  > subs/from-crt.txt

wc -l subs/from-crt.txt

Typische Ausgabe:

127 subs/from-crt.txt

Ein Auszug:

admin.demo-corp.com
api.demo-corp.com
api-dev.demo-corp.com
api-staging.demo-corp.com
beta.demo-corp.com
blog.demo-corp.com
cdn.demo-corp.com
customer.demo-corp.com
demo-corp.com
dev.demo-corp.com
docs.demo-corp.com
help.demo-corp.com
internal.demo-corp.com
jenkins.demo-corp.com
jira.demo-corp.com
mail.demo-corp.com
monitoring.demo-corp.com
old-admin.demo-corp.com
partners.demo-corp.com
prod.demo-corp.com
sso.demo-corp.com
staging.demo-corp.com
status.demo-corp.com
support.demo-corp.com
vpn.demo-corp.com
web.demo-corp.com
www.demo-corp.com

Drei Zeilen, die einen Angreifer lächeln lassen:

internal.demo-corp.com — eine Subdomain, die eigentlich nicht hätte öffentlich werden sollen.
jenkins.demo-corp.com — ein CI/CD-Server, historisch eine Fundgrube an Schwachstellen.
old-admin.demo-corp.com — das alte Admin-Panel. Das riecht nach Vergessenheit.

In 3 Minuten sind wir von 1 Namen auf 127 gekommen.

Schritt 4 — Abgleich mit `subfinder` und `amass -passive`

subfinder befragt rund zwanzig Drittanbieter-APIs (Shodan, VirusTotal, SecurityTrails, DNSDumpster…) und liefert eine Liste. 100 % passiv.

subfinder -d demo-corp.com -silent -all -o subs/from-subfinder.txt
wc -l subs/from-subfinder.txt

143 subs/from-subfinder.txt

Ebenso amass im passiven Modus:

amass enum -passive -d demo-corp.com -o subs/from-amass.txt

Dann fusionieren wir:

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

178 subs/all-passive.txt

Von 127 auf 178. Jede Quelle hat ein paar Funde beigetragen. Deshalb gleicht man ab.

Schritt 5 — Passive Auflösung mit `dnsx`

Achtung: dnsx löst die Namen auf. Jede Auflösung läuft über einen öffentlichen DNS-Resolver (standardmäßig Google 8.8.8.8). Das bleibt für das Ziel passiv, sofern Sie einen Resolver verwenden, der nicht dem Ziel gehört. Prüfen Sie, dass die NS von demo-corp.com nicht Ihre Resolver sind (das ist hier der Fall: Cloudflare verwaltet deren DNS, aber Ihr dnsx wird 1.1.1.1 von Cloudflare Public befragen — das ist ein anderer Dienst).

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

Ausgabe:

admin.demo-corp.com [104.21.44.15]
api.demo-corp.com [104.21.44.15]
api-dev.demo-corp.com [3.98.14.202]
api-staging.demo-corp.com [104.21.44.15]
internal.demo-corp.com [192.168.10.5]
jenkins.demo-corp.com [3.98.14.209]
old-admin.demo-corp.com [66.42.11.198]

Drei aufschlussreiche Zeilen:

internal.demo-corp.com löst auf 192.168.10.5 auf — eine private IP, die im öffentlichen DNS veröffentlicht ist. Die Subdomain ist für den Zugriff per VPN gedacht, aber ihre Präsenz im DNS bestätigt, dass dieser Dienst existiert. Zu melden.
api-dev.demo-corp.com auf 3.98.x.x — AWS-Block ca-central-1, nicht hinter Cloudflare. Das ist der echte Server, der exponiert ist. Priorisiertes Ziel für die aktive Phase.
old-admin.demo-corp.com auf 66.42.x.x — Vultr. Ein vergessener Server, außerhalb des Haupt-CDN. Ebenfalls ein priorisiertes Ziel.

Notieren Sie diese drei Zeilen. Sie werden das gesamte Modul 4 leiten.

Schritt 6 — Passives technologisches Fingerprinting

Achtung: whatweb und wappalyzer laden die Seite — das ist aktiv. Um strikt passiv zu bleiben, verwenden wir:

BuiltWith (über die Weboberfläche in Ihrem Browser — aber Ihr Browser lädt BuiltWith, nicht das Ziel).
Shodan: shodan host <IP> liefert, was Shodan bereits gesammelt hat.

shodan host 3.98.14.202 > tech/shodan-api-dev.txt
cat tech/shodan-api-dev.txt

Typische Ausgabe:

3.98.14.202
Hostnames: ec2-3-98-14-202.ca-central-1.compute.amazonaws.com
Country:  Canada
City:     Montréal
Organization: Amazon.com, Inc.

Open Ports: 22, 80, 443, 8080

22/tcp     SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
80/tcp     nginx/1.18.0
443/tcp    nginx/1.18.0 — TLSv1.3 — CN=api-dev.demo-corp.com
8080/tcp   Django DEBUG page found

Goldene Zeile: Django DEBUG page found. Shodan hat bereits gesehen, dass auf :8080 ein Django-Debug-Modus exponiert ist. Ein Django-Debug-Modus zeigt:

Den vollständigen Stacktrace im Fehlerfall.
Die Umgebungsvariablen (also oft geheime Schlüssel).
Manchmal den vollständigen SECRET_KEY.

Wir haben soeben, ohne ein einziges Paket an demo-corp.com zu senden, eine wahrscheinlich kritische Schwachstelle gefunden. Wir bestätigen sie in Woche 4.

Notieren Sie den Fund in tech/decouvertes.md:

- [KRITISCH] api-dev.demo-corp.com:8080 — Django im DEBUG-Modus (Quelle: Shodan)
- [INFO] api-dev.demo-corp.com: Nginx 1.18, OpenSSH 8.2 auf Ubuntu 20

Schritt 7 — Schlüsselpersonen (theHarvester + LinkedIn)

theHarvester -d demo-corp.com -b linkedin,bing,duckduckgo -l 500 \
  -f people/harvester.html

theHarvester befragt Drittanbieter-APIs und LinkedIn (im Allgemeinen über Bing). Typische Ausgabe:

[*] Emails found: 34
    admin@demo-corp.com
    contact@demo-corp.com
    j.dupuis@demo-corp.com
    m.tremblay@demo-corp.com
    ...

[*] Hosts found:
    (Ebenso, redundant mit dem, was wir schon haben)

[*] LinkedIn profiles (via Bing):
    Marie Tremblay - CTO at Demo Corp
    Jean Dupuis - Senior DevOps at Demo Corp
    Étienne Roy - Support Lead at Demo Corp
    ...

Das E-Mail-Muster wird sofort sichtbar: initiale.nom@demo-corp.com. Ausgehend von LinkedIn können Sie die E-Mail der meisten Mitarbeiter des Kunden erraten, ohne sie jemals danach zu fragen.

Konsolidieren Sie in people/personnes.csv:

prenom,nom,titre,email,linkedin
Marie,Tremblay,CTO,m.tremblay@demo-corp.com,https://www.linkedin.com/in/marietremblay
Jean,Dupuis,Senior DevOps,j.dupuis@demo-corp.com,...
Étienne,Roy,Support Lead,e.roy@demo-corp.com,...

Diese Datei dient Modul 6 (Social Engineering).

Schritt 8 — Öffentliche Lecks

# HaveIBeenPwned nach Domain — erfordert einen API-Schlüssel (kostenpflichtig, aber günstig).
curl -s -H "hibp-api-key: $HIBP_KEY" \
  "https://haveibeenpwned.com/api/v3/breacheddomain/demo-corp.com" \
  | jq . > leaks/hibp.json

# Übersicht:
jq -r 'keys[] as $k | "\($k) → \(.[$k] | join(", "))"' leaks/hibp.json | head

Ausgabe:

j.dupuis  → Adobe, Collection#1, MyFitnessPal
support   → Collection#1
etienne.roy → LinkedIn, Dropbox

Zwei technische Konten (j.dupuis, etienne.roy) sind bereits in öffentlichen Dumps geleakt. Wenn der Kunde Passwörter wiederverwendet — und statistisch kann ein Pentester damit rechnen — werden wir in Woche 5 Password Spraying versuchen können.

Ergänzen Sie mit GitHub Search:

Gehen Sie zu github.com/search?type=commits&q=%22demo-corp.com%22.
Gehen Sie zu github.com/<mitarbeiter>?tab=repositories für jeden gelisteten Mitarbeiter.

Suchen Sie nach Repos mit Namen wie demo-corp-*, scripts, backups, dotfiles. Man findet dort regelmäßig:

Eine .env mit Geheimnissen.
Skripte mit fest codierten Passwörtern.
Interne URLs.

In unserer Demo enthält ein öffentliches dotfiles-Repo eines ehemaligen Mitarbeiters eine Datei deploy.sh mit:

ssh deploy@old-admin.demo-corp.com -i ~/.ssh/deploy-key

Bestätigtes Ziel: old-admin.demo-corp.com, Konto deploy. In Woche 4 auszunutzen.

Schritt 9 — Archive (Wayback Machine)

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

wc -l archive/urls-historiques.txt

Ausgabe:

612 archive/urls-historiques.txt

Ein grep nach aufschlussreichen Schlüsselwörtern:

grep -iE 'admin|backup|test|debug|swagger|api-doc|internal' archive/urls-historiques.txt

https://demo-corp.com/admin-old/
https://demo-corp.com/api/v1/debug
https://demo-corp.com/backup.sql          (2019)
https://demo-corp.com/swagger.json

backup.sql aus 2019 — wahrscheinlich seitdem gelöscht, aber wir überprüfen es in Modul 4: Die Wayback Machine garantiert nicht die serverseitige Löschung.

Schritt 10 — Das Dossier konsolidieren

Öffnen Sie ~/osint/demo-corp/fiche-cible.md und füllen Sie es mit dem Vorangegangenen. Priorisierte Ziele in Fettdruck hervorheben.

# Zieldossier — demo-corp.com  (2026-04-15)

## 1. Bestätigte Assets
- Root-Domain: demo-corp.com (Cloudflare DNS + Proxy)
- Subdomains: 178 gesammelt, davon:
  - **api-dev.demo-corp.com  → AWS ca-central-1 (3.98.14.202), Django DEBUG auf :8080**
  - **old-admin.demo-corp.com → Vultr (66.42.11.198), vermutetes Konto deploy**
  - internal.demo-corp.com  → 192.168.10.5 (privat), fälschlich veröffentlicht
  - jenkins.demo-corp.com   → AWS
  - jira.demo-corp.com      → Atlassian Cloud (Umfang noch zu klären)

## 2. Mit dem Kunden zu verhandelnder Umfang
- internal.demo-corp.com (veröffentlichte private IP): zum RoE hinzufügen?
- Atlassian- und Google-Subdomains: außerhalb des Umfangs.

## 3. Technologien
- Frontend (www): Next.js hinter Cloudflare
- API prod: unbekannt, von Cloudflare gefiltert
- API dev: Django, Nginx 1.18, Ubuntu 20 (Quelle: Shodan)
- Messaging: Google Workspace
- Verbundene SaaS: Stripe, Mailgun, Atlassian, Sentry

## 4. Wahrscheinliche Schwachstellen (in Woche 4 zu bestätigen)
- KRITISCH: Django DEBUG exponiert auf api-dev:8080
- HOCH   : old-admin.demo-corp.com — geerbtes Admin-Panel
- MITTEL : DMARC p=none → gefälschtes Phishing möglich
- MITTEL : backup.sql (2019) — noch auf dem aktuellen Server vorhanden?

## 5. Schlüsselpersonen (Quelle: LinkedIn + theHarvester)
- Marie Tremblay, CTO — m.tremblay@demo-corp.com
- Jean Dupuis, Sr DevOps — j.dupuis@demo-corp.com  [HIBP-Leck × 3]
- Étienne Roy, Support Lead — e.roy@demo-corp.com  [HIBP-Leck × 2]
+ 21 weitere in people/personnes.csv

## 6. Öffentliche Lecks
- HIBP: 2 hochwertige Konten mit wahrscheinlicher Wiederverwendung
- GitHub: dotfiles eines ehemaligen Mitarbeiters nennen old-admin.demo-corp.com und Konto deploy

## 7. Nächster Schritt (Modul 4)
1. Django DEBUG auf api-dev:8080 bestätigen — 30 Min.
2. old-admin.demo-corp.com kartieren: Ports, Versionen — 45 Min.
3. /backup.sql auf www überprüfen — 5 Min.
4. Vorsichtiges Password Spraying bei den 2 HIBP-Konten — 30 Min.

Fazit

In 90 Minuten, ohne irgendein Paket an demo-corp.com zu senden:

Wir haben 178 Subdomains.
Wir haben eine nahezu sichere kritische Schwachstelle (exponiertes Django DEBUG).
Wir haben zwei hochwertige Sekundärziele (old-admin, internal).
Wir haben einen Angriffsplan für Woche 4.
Wir haben geleakte Konten, die später ausnutzbar sind.
Das Ziel weiß von nichts.

Das ist die Kraft von gut durchgeführtem OSINT. Es ist das Modul mit dem höchsten Ertrag pro investierter Minute.

Nächste Lektion: Sie sind an der Reihe. Sie wählen ein Bug-Bounty-Programm aus und wiederholen dasselbe, eigenständig.

Was Sie nach dieser Lektion können​

Schritt 0 — Der Ausgangspunkt​

Schritt 1 — Grundlegendes DNS (2 Minuten)​

Schritt 2 — DMARC und E-Mail-Sicherheitslage (1 Minute)​

Schritt 3 — Subdomains über crt.sh (3 Minuten)​

Schritt 4 — Abgleich mit subfinder und amass -passive​

Schritt 5 — Passive Auflösung mit dnsx​

Schritt 6 — Passives technologisches Fingerprinting​

Schritt 7 — Schlüsselpersonen (theHarvester + LinkedIn)​

Schritt 8 — Öffentliche Lecks​

Schritt 9 — Archive (Wayback Machine)​

Schritt 10 — Das Dossier konsolidieren​

Fazit​

Was Sie nach dieser Lektion können

Schritt 0 — Der Ausgangspunkt

Schritt 1 — Grundlegendes DNS (2 Minuten)

Schritt 2 — DMARC und E-Mail-Sicherheitslage (1 Minute)

Schritt 3 — Subdomains über `crt.sh` (3 Minuten)

Schritt 4 — Abgleich mit `subfinder` und `amass -passive`

Schritt 5 — Passive Auflösung mit `dnsx`

Schritt 6 — Passives technologisches Fingerprinting

Schritt 7 — Schlüsselpersonen (theHarvester + LinkedIn)

Schritt 8 — Öffentliche Lecks

Schritt 9 — Archive (Wayback Machine)

Schritt 10 — Das Dossier konsolidieren

Fazit