Was wissen Angreifer, bevor sie angreifen? Eine Einführung in Open Source Intelligence und Reconnaissance

Die meisten Penetrationstests beginnen direkt mit dem Scannen von Systemen und dem Ausnutzen von Schwachstellen. Kriminelle Angreifer, aber auch Red Team Assessments beginnen zuerst mit der Reconnaissance. Ausgenommen sind sogenannte Assumed-Breach-Szenarien, die bewusst von einem bereits erfolgten Einbruch ausgehen.
In dieser Phase werden die Informationen über ein Unternehmen und die Mitarbeiter des Unternehmens zusammengetragen, die ohnehin schon öffentlich verfügbar sind.
Öffentlich verfügbar heißt nicht offensichtlich: Der Aufwand liegt nicht im Finden einzelner Informationen, sondern darin, viele für sich harmlose Fundstücke zu einem Bild zu verknüpfen, das über Erfolg oder Misserfolg der späteren Angriffsphasen entscheiden kann.

Dieser Artikel beschreibt, wie eine strukturierte Open Source Intelligence (OSINT)-Recherche abläuft, welche Werkzeuge nützlich sind, und wie Verteidiger dieselbe Methodik einsetzen können, um ihre eigene Angriffsfläche zu verkleinern.

[Hinweis: Sämtliche Ausgaben in den Code-Boxen sind konstruiert. Sie orientieren sich am Format der echten Tools, nutzen aber nur Platzhalter (beispiel.de, IPs aus 192.0.2.0/24) und keine echten Daten.]

Was ist OSINT?

Open Source Intelligence, kurz OSINT, bezeichnet die systematische Sammlung von Informationen aus öffentlich zugänglichen Quellen, um daraus verwertbare Erkenntnisse über Personen, Organisationen, Systeme oder Ereignisse zu gewinnen. Die Quellen reichen von Webseiten, Suchmaschinen und öffentlichen Registern bis zu sozialen Netzwerken. Öffentlich auffindbar heißt dabei nicht automatisch legal nutzbar. Manche Daten kursieren zwar frei, ihr Gebrauch bewegt sich aber im rechtlichen Graubereich oder klar außerhalb der Legalität, etwa bei Infostealer-Logs. OSINT ist außerdem nicht auf die IT-Sicherheit beschränkt. Dieselben Methoden kommen zum Beispiel auch im Journalismus oder in Ermittlungsverfahren zum Einsatz.

Wie läuft eine OSINT-Recherche ab?

Zuerst gilt es, zwei Begriffspaare zu klären.

Passive vs. aktive Reconnaissance

Passive Reconnaissance greift nie direkt auf die Systeme des Ziels zu. Alle Informationen stammen aus dritten Quellen. Dazu gehören zum Beispiel Suchmaschinen, öffentliche DNS-Resolver, Zertifikatsregister oder Leak-Datenbanken. Weil die Anfragen an Dritte gehen und nicht an das Ziel selbst, taucht die passive Aufklärung in keinem Log des Ziels auf.

In der aktiven Phase dagegen wird direkt mit der Zielinfrastruktur interagiert, etwa durch Portscans, Anfragen an den Webserver oder Brute-Force von Subdomänen gegen den Nameserver. Die Ergebnisse sind hier teils detaillierter, hinterlassen aber auch Spuren. Aktive Maßnahmen sollten grundsätzlich nur mit entsprechender Berechtigung durchgeführt werden, da sie sich je nach Art der Interaktion schnell in einem rechtlich sensiblen Bereich bewegen können.

Die Grenze ist allerdings nicht immer scharf: Manche Techniken liefern aktiv wirkende Ergebnisse aus rein passiven Quellen, etwa Shodan.

OSINT vs. Recon/Reconnaissance

OSINT und Reconnaissance werden zwar oft synonym behandelt, sind aber genau gesehen nicht dasselbe. OSINT beschreibt die Quelle der Information, also offen und öffentlich. Reconnaissance dagegen beschreibt die Phase im Angriff, also das Aufklären des Ziels. Weil während dieser Phase genutzte Techniken oft über OSINT hinausgehen, ist OSINT ein Baustein der Reconnaissance, nicht ihr Synonym.

In der Praxis arbeitet sich ein Pentester vom Groben zum Feinen vor. Genau diesem Weg folgt auch dieser Artikel: vom Namen des Unternehmens bis zur konkreten Angriffsfläche, mit diesen Stationen:

Unternehmensname → Hauptdomäne → DNS & WHOIS → Subdomänen (crt.sh, passives DNS) → IP-Bereiche & AS (RIPE) → Dienste (Shodan, Censys) → Cloud-Storage → Dateien & Metadaten → Repositories → Menschen → Leaks → physische Welt

Was verrät der Namensraum einer Organisation?

Das Domain Name System (DNS) ist eine öffentliche Datenbank und so etwas wie das Telefonbuch des Internets. Es übersetzt Namen in IP-Adressen und stellt darüber hinaus eine ganze Reihe weiterer Einträge (Records) bereit, die Rückschlüsse auf die Infrastruktur eines Unternehmens zulassen.

So lassen sich unter anderem Mailserver (MX), IPv4- und IPv6-Adressen (A und AAAA), Aliaseinträge (CNAME) oder die zuständigen Nameserver (NS) auslesen.
SPF- und DMARC-Records im TXT-Bereich geben Aufschluss darüber, welche E-Mail-Sicherheitsmechanismen konfiguriert sind. Ein fehlender oder schwacher DMARC-Record ist für Angreifer beispielsweise ein Hinweis, dass sich die Domäne in einer Phishing-Kampagne leichter fälschen lässt.

Auch historische DNS-Daten sind interessant. Über passive DNS-Dienste lassen sich auch Subdomänen finden, die nicht mehr aktiv genutzt werden. Diese sind klassische Kandidaten für vergessene und ungepatchte Systeme.

Abgefragt werden die Records unter anderem mit `dig`, dem Standardkommando für DNS-Abfragen; ` +short` kürzt die Ausgabe auf das Wesentliche:

```
shell
$ dig +short MX beispiel.de
10 aspmx.l.google.com.    # Mail läuft über Google Workspace

$ dig +short TXT beispiel.de
"v=spf1 include:_spf.google.com ~all" # # ~all statt -all: gefälschte Mails werden nicht abgewiesen

$ dig +short TXT _dmarc.beispiel.de
"v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"

$ dig +short NS beispiel.de
ns1.hosting-provider.de.  # Zeigt die Nameserver
ns2.hosting-provider.de.
```
Das `~all` am Ende des SPF-Records ist ein sogenannter Softfail: E-Mails von nicht autorisierten Servern werden zwar als verdächtig markiert, aber nicht abgewiesen. Erst ein `-all` (Hardfail) weist sie ab. In Kombination mit dem `p=none` im DMARC-Record heißt das, dass sich die Domäne vergleichsweise leicht für Phishing missbrauchen lässt.

Zur Domäne gehört außerdem der WHOIS-Eintrag. `whois` liefert zu einer registrierten Domain Registrierungsdaten wie Registrar, Anlage- und Ablaufdatum sowie teils organisatorische oder technische Kontakte:

```
$ whois beispiel.de
Domain:   beispiel.de
Nserver:  ns1.hosting-provider.de
Status:   connect
Changed:  2019-03-12T09:41:00+01:00     # Domain seit 2019 aktiv
```

Seit Inkrafttreten der DSGVO sind die personenbezogenen Daten in vielen europäischen Ländern zwar ausgenommen, für die technische Zuordnung bleibt WHOIS aber weiterhin nützlich. Auch im Rahmen eines Pentests führen wir oft zuerst eine WHOIS-Abfrage der Systeme durch, um die Eigentümer einer Domäne oder eines IP-Adressbereichs zu verifizieren. Dies dient unter anderem dazu, sicherzustellen, dass die vorliegende Testgenehmigung den tatsächlichen Inhaber der zu prüfenden Systeme abdeckt. 

Was steht in den Registern des Internet?

Neben DNS gibt es weitere öffentliche Register. Die erste Quelle, die in einem Pentest geprüft wird, ist Certificate Transparency. Jedes von einer Zertifikatsautorität (CA) ausgestellte TLS-Zertifikat wird in öffentlich einsehbare Logs geschrieben. Diese Logs sind eine Fundgrube für Subdomänen. Wer zum Beispiel ein Zertifikat für `intern-vpn.beispiel.de` beantragt, macht damit die Existenz dieses Hosts öffentlich. Über `crt.sh` lässt sich das durchsuchen, per Weboberfläche oder direkt über die JSON-Schnittstelle; mit `jq` filtert man die Hostnamen aus der Antwort:

```
$ curl -s 'https://crt.sh/?q=%25.beispiel.de&output=json' | jq -r '.[].name_value' | sort -u
beispiel.de
intern-vpn.beispiel.de      # spannend: VPN-Gateway
staging.beispiel.de         # spannend: Staging-Umgebung
www.beispiel.de
```

Interessant sind nicht die offensichtlichen Hosts wie `www`, sondern die, die man sonst nirgends findet, etwa ein VPN-Gateway oder eine Staging-Umgebung.

Eine zweite Quelle sind die Regional Internet Registries. Sie verwalten die Vergabe von IP-Adressen und sogenannten AS-Nummern. Für Europa ist das die RIPE-Datenbank. Über sie lässt sich herausfinden, welche IP-Bereiche und welches autonome System (AS) einem Unternehmen zugeordnet sind. Das ist bei der Recherche auch der Übergang von einer einzelnen Domäne zu einem ganzen Netzblock. 
Der Zusatz `-h whois.ripe.net` richtet die Abfrage gezielt an den RIPE-Server. Während `whois` auf eine Domäne die Registrardaten liefert, gibt dieselbe Abfrage auf eine IP-Adresse den zuständigen RIR-Eintrag zurück, also den Netzblock und die zugehörige AS-Nummer:

```
$  whois -h whois.ripe.net 192.0.2.1
inetnum:  192.0.2.0 - 192.0.2.255
netname:  BEISPIEL-NET
descr:    Beispiel GmbH  # bestätigt den Eigentümer des Netzblocks
origin:   AS64500        # autonomes System des Unternehmens
```

Über die AS-Nummer (hier `AS64500`) springt man von einer einzelnen IP auf alle Netzblöcke, die dasselbe Unternehmen ankündigt. Ergänzend liefert `bgp.he.net` einen guten Überblick über die AS-Nummer, angekündigte Präfixe und Peering-Beziehungen.

Vom Namen zur Angriffsfläche: die Werkzeuge

Die Abfragen bis hierher zeigen das Grundprinzip. In der Praxis führt man diese Schritte nicht einzeln von Hand aus, sondern verkettet spezialisierte Werkzeuge. Eine gängige Verkettung von Werkzeugen sieht zum Beispiel so aus: `subfinder` sammelt passiv Subdomänen aus verschiedenen Quellen, `dnsx` löst diese Kandidaten auf und behält nur die real existierenden Hosts, und `httpx` prüft schließlich, welche davon einen erreichbaren Webdienst betreiben, samt Statuscode, Seitentitel und erkannter Technologie:

```
$ subfinder -d beispiel.de -silent | dnsx -silent | httpx -silent -title -status-code -tech-detect
www.beispiel.de     [200] [Beispiel GmbH]  [nginx,PHP]
vpn.beispiel.de     [200] [Login]          [Ivanti Connect Secure]   # bekannte Appliance
old.beispiel.de     [403] []               [Apache/2.2.15]           # EOL-Version
```

Die Technologie-Erkennung von `httpx` ist der eigentliche Mehrwert: Eine End-of-Life (EOL)-Apache-Version oder eine namentlich bekannte VPN-Appliance sind sofort Ansatzpunkte für die nächste Phase.

Reicht das passive Ergebnis nicht, geht `amass` (OWASP) tiefer und kombiniert passive Quellen mit aktiver Enumeration:

```
$ amass enum -passive -d beispiel.de
www.beispiel.de
autodiscover.beispiel.de
dev-api.beispiel.de   # Entwicklungs-API, oft schwächer geschützt
```

Im Hinblick auf persönliche Daten deckt `theHarvester` E-Mail-Adressen, Namen und Subdomains auf einen Schlag ab. Das Werkzeug bündelt dafür Dutzende öffentliche Quellen, von Suchmaschinen über Zertifikatslogs bis zu Diensten wie Have I Been Pwned, und fasst deren Treffer zu einem einheitlichen Ergebnis zusammen. Über den Parameter `-b` wählt man aus, welche dieser Quellen abgefragt werden:

```
$ theHarvester -d beispiel.de -b crtsh,bing,duckduckgo
[*] Emails found:
max.mustermann@beispiel.de
a.schmidt@beispiel.de   # Schema: vorname.nachname
```

Aus den gefundenen Adressen lässt sich das Namensschema ableiten und für weitere Mitarbeiter anwenden.

Am Ende einer solchen Kette steht oft eine Liste, die zu lang ist, um jeden Host einzeln im Browser zu öffnen. Hier helfen Screenshot-Werkzeuge wie `gowitness` oder `aquatone`: Sie rufen jeden Host auf und legen eine Bildergalerie an, in der man vergessene Admin-Panels oder Standardloginseiten auf einen Blick erkennt:

```
$ gowitness scan file -f hosts.txt
[+] vpn.beispiel.de     200  "Login"
[+] jira.beispiel.de    200  "Jira"
[+] Screenshots → ./screenshots/        # als Galerie im Report
```

Der Nutzen liegt hier nicht im Terminal, sondern in der erstellten Galerie: 500 Hosts überfliegt man visuell deutlich schneller.

Was ist über die Cloud öffentlich zugänglich?

Nicht alles läuft auf eigenen Servern. Objektspeicher wie AWS S3, Azure Blob Storage oder Google Cloud Storage sind heute mindestens so relevant wie klassische Webserver und werden regelmäßig versehentlich öffentlich lesbar konfiguriert. Weil sich die Namen solcher Buckets oft aus Firmen-, Produkt- oder Projektnamen ableiten, lassen sie sich über Permutationen erraten und automatisiert prüfen. Werkzeuge wie `cloud_enum` oder `s3scanner` übernehmen das: Sie testen aus einer Liste von Schlüsselwörtern systematisch mögliche Bucket-Namen durch:

```
$ cloud_enum -k beispiel -k beispiel-gmbh -k beispielapp
[+] OPEN S3 Bucket:  https://beispiel-backup.s3.amazonaws.com    # öffentlich lesbar!
[+] Azure Blob:      https://beispiel.blob.core.windows.net
```

Hier ist die rechtliche Grenze aber besonders schmal. Die bloße Frage, ob ein Bucket existiert und öffentlich ist, unterscheidet sich deutlich vom Herunterladen seines Inhalts. Wer also fremde Daten tatsächlich ausliest, bewegt sich schnell im Bereich des unbefugten Zugriffs, auch wenn der Bucket "offen" war.

Was verrät ein Microsoft 365- und Azure-Tenant?

Weil heute fast jedes Unternehmen eine hybride Umgebung mit Microsoft 365 oder Entra ID (früher Azure AD) betreibt, lohnt sich ein eigener Blick auf diese Namensräume. Microsoft stellt eine Reihe von Endpunkten bereit, die Tenant-Informationen ganz ohne Authentifizierung herausgeben, die Grundlage für gezielte Phishing- und Password-Spraying-Kampagnen.

Ein erster Ansatzpunkt ist der Nachweis, ob und mit welchem Tenant eine Domäne überhaupt bei Microsoft liegt. Der OpenID Connect Discovery-Endpunkt liefert die Tenant-ID zu einer Domäne:

```
$ curl -s 'https://login.microsoftonline.com/beispiel.de/.well-known/openid-configuration' | jq -r '.token_endpoint'
login.microsoftonline.com/8f7e...c21a/oauth2/v2.0/token   # Tenant-ID in der URL
```

Ob eine Domäne innerhalb des Tenants "managed" (Authentifizierung direkt bei Microsoft) oder "federated" (z. B. über ADFS, Okta oder Ping) ist, verrät der `getuserrealm`-Endpunkt. Das ist relevant, weil sich föderierte Anmeldungen anders angreifen lassen als reine Cloud-Konten:
```
$ curl -s 'https://login.microsoftonline.com/getuserrealm.srf?login=user@beispiel.de&xml=1'
<NameSpaceType>Federated</NameSpaceType>   # föderiert, z. B. ADFS/Okta
<AuthURL>https://adfs.beispiel.de/adfs/ls/...</AuthURL>   # externer IdP sichtbar
```

Mit dem Wissen über DNS lässt sich das ergänzen: Zeigt der DKIM-Selektor einer Domäne per CNAME auf einen `*.onmicrosoft.com`-Eintrag, ist darin der interne Tenant-Name enthalten. Oft ist das die aussagekräftigste Einzelinformation, weil sich damit die restlichen Azure-Namensräume durchprobieren lassen:

```
$ dig +short selector1._domainkey.beispiel.de CNAME
selector1-beispiel-de._domainkey.beispielgmbh.onmicrosoft.com.   # Tenantname: beispielgmbh
```

Deutlich bequemer als der manuelle Weg über OpenID Connect- und DKIM-Abfragen ist `azmap.dev`, eine kostenlose API von Sprocket Security. Sie bildet eine Domain in einem einzigen Aufruf auf Tenant-ID und Tenantnamen ab:
```
$ curl -s 'https://azmap.dev/api/tenant?domain=beispiel.de' | jq
{
 "tenant_id": "8f7e...c21a",
 "tenant_name": "beispielgmbh",      # interner Tenantname, ohne DKIM-Umweg
 "domain": "beispiel.de"
}
```

Mit `&extract=true` gibt die API zusätzlich alle E-Mail-Domains aus, die zum selben Tenant gehören. Das ist praktisch, um von einer bekannten Domain auf Schwester- und Tochtergesellschaften zu schließen und den Scope zu erweitern:

```
$ curl -s 'https://azmap.dev/api/tenant?domain=beispiel.de&extract=true' | jq -r '.email_domains[]'
beispiel.de
beispiel-shop.de
tochterfirma.at
```

Zu beachten ist: `azmap.dev` ist ein Drittanbieter-Dienst, dessen zugrunde liegende Technik sich laufend ändert, weil Microsoft solche Endpunkte immer wieder schließt. Ergebnisse sind also gegen den aktuellen Stand zu prüfen und die kostenlose API sollte nicht überlastet werden.

Für die eigentliche Asset-Suche gilt in Azure eine feste Namenskonvention: Jeder Dienst hängt unter einem eigenen DNS-Suffix, etwa Blob Storage unter `<name>.blob.core.windows.net` oder statisches Webhosting unter der zusätzlichen `web`-Subdomäne. Weil diese Namen vorhersehbar sind, lassen sie sich, ausgehend vom Tenant- oder Firmennamen, automatisiert durchprobieren.

Ein Sonderfall ist `<tenant>.atp.azure.com`: Existiert dieser Host, nutzt das Unternehmen sehr wahrscheinlich Microsoft Defender for Identity. Für Angreifende ist das ein Hinweis, mit welcher Erkennung im Active Directory zu rechnen ist.

Werkzeuge bündeln diese Schritte: `AADInternals` ist ein PowerShell-Toolkit für Entra ID-Recon, dessen Aufruf `Invoke-AADIntReconAsOutsider Tenant-ID`, verifizierte Domains, Managed/Federated-Status und die Defender-for-Identity-Erkennung auf einmal zusammenträgt. `MicroBurst` enumeriert per `Invoke-EnumerateAzureSubDomains` die Azure-Service-Subdomains eines Tenants (Blob, Web, Key Vault, Mail), und `o365creeper` oder `TeamsEnum` prüfen, ob einzelne E-Mail-Adressen im Tenant existieren.

Wichtig für die rechtliche Einordnung: Das Abfragen von Tenant-Metadaten (Tenant-ID, Domänentyp, genutzte Dienste) ist unauthentifiziert und passiv. Sobald man aber gültige Benutzernamen durchprobiert (User Enumeration), nähert man sich aktivem Verhalten und braucht dafür eine Beauftragung.

Welche Auskünfte geben Suchmaschinen und Archive?

Suchmaschinen indexieren viel mehr, als über die normale Navigation einer Webseite erreichbar ist. Mit gezielten Suchoperatoren (sogenannten "Google Dorks") lässt sich das eingrenzen:

```
site:beispiel.de filetype:xlsx
site:beispiel.de intitle:"index of"
site:beispiel.de inurl:login
```

Damit findet man zum Beispiel offen liegende Verzeichnisse, versehentlich indexierte Dokumente oder Loginportale, die eigentlich nicht öffentlich beworben werden sollten. Die `robots.txt` einer Seite ist dabei ein interessanter Sonderfall. Sie soll Webcrawlern sagen, welche Pfade sie meiden sollen, und listet damit oft genau die Verzeichnisse auf, die besser versteckt wären (`/admin`, `/backup`, `/internal`).

Ein Blick in die Vergangenheit lohnt ebenfalls. Über die Wayback Machine des Internet Archive lassen sich frühere Versionen einer Seite abrufen. Inhalte, Pfade oder Kommentare, die längst entfernt wurden, sind dort häufig noch archiviert, inklusive alter Endpunkte oder Hinweise auf frühere Technik.

Wie durchsucht man exponierte Dienste? Shodan und Co.

Klassische Suchmaschinen wie Google indexieren Webinhalte. Shodan indexiert stattdessen die Dienste selbst. Es scannt das Internet und speichert, welche Ports offen sind, welche Software mit welcher Version antwortet, und welche Banner ausgeliefert werden. Damit lassen sich die exponierten Systeme eines Unternehmens finden, und zwar von einem offenen Datenbankport bis hin zu einem ungeschützten Dashboard. Mit `--fields` grenzt man die Ausgabe auf die relevanten Spalten ein:

```
$ shodan search --fields ip_str,port,product 'org:"Beispiel GmbH"'
192.0.2.10   3389   Microsoft RDP         # RDP offen im Internet
192.0.2.24   9200   Elasticsearch         # Datenbank ohne Auth?

# Es kann aber auch allgemeiner gesucht werden mit:
$ shodan host 192.0.2.0/24
```

Offenes RDP oder eine exponierte Datenbank ohne Authentifizierung sind typische Funde, die man ohne eigenen Scan direkt aus Shodan zieht.

Das lässt sich auch nutzen, um scheinbar aktive Aufklärung passiv zu erledigen. `smap` nimmt dieselben Ziele wie das Portscan-Werkzeug `nmap` entgegen, zieht die Portdaten aber ausschließlich aus Shodan, statt das Ziel selbst zu berühren:

```
$ smap beispiel.de
Host: 192.0.2.31 (beispiel.de)
443/tcp   open   https
80/tcp    open   http
# Daten stammen aus Shodan – es ging kein Paket an das Ziel
```

So erhält man einen Überblick über offene Ports und Dienste, ohne einen einzigen Scan gegen das Unternehmen. Der Preis dafür: Die Ergebnisse sind nur so aktuell und vollständig wie Shodans letzter Scan.

Shodan ist nicht die einzige Quelle dieser Art. Censys verfolgt einen ähnlichen Ansatz mit einem eigenen Scandatensatz. Der Censys-Zugang läuft inzwischen über ein Credit-Modell. Viele dieser Dienste ergänzen sich gut, da sie unterschiedliche Teile des Internets sehen. So deckt FOFA vor allem asiatische Netze gut ab.

Welche Informationen stecken in Dateien, die längst veröffentlicht sind?

Überall im Internet sind veröffentlichte Dokumente zu finden: Datenblätter, Geschäftsberichte, Präsentationen, Formulare oder Vorlagen. Oft stehen sie als PDF- oder Office-Datei direkt auf der Unternehmenswebseite zum Download bereit und tragen Metadaten in sich, an die beim Erstellen niemand gedacht hat.

Auslesen lassen sich diese Metadaten mit `exiftool`. Dieses Tool extrahiert die eingebetteten Informationen aus Dokumenten und Bildern:

```
$ exiftool -Author -Creator -Producer bericht.pdf
Author     : m.mustermann          # Benutzername → Namensschema
Creator    : Microsoft Word 2016   # eingesetzte Softwareversion
Producer   : Acrobat Distiller 11.0
```

Wurden die Metadaten nicht entfernt, finden sich dort Informationen wie der Autorenname, der häufig auf interne Benutzernamenkonventionen schließen lässt (etwa `mmustermann` oder `m.mustermann`). Dazu kommen manchmal die Version der erzeugenden Software, ein interner Server- oder Rechnername oder sogar eine E-Mail-Adresse. In älteren Office-Dokumenten stecken stellenweise noch Kommentare oder Änderungsverläufe.

Bei Bildern werden die EXIF-Daten heute oft automatisch entfernt, sobald sie über eine Plattform hochgeladen werden. Verlassen sollte man sich darauf nicht. Und selbst wenn die Metadaten sauber sind, bleibt der Bildinhalt eine Informationsquelle. Von sichtbaren Bildschirmen über Gebäudeinfrastruktur bis zum Werksausweis am Revers verrät ein Foto oft mehr, als der Verfasser des Blogbeitrags oder der Stellenanzeige beabsichtigt hat.

Warum vergessen Repositories nichts?

Code-Plattformen wie GitHub oder GitLab sind für Entwicklerteams ein zentraler Bestandteil der Arbeit. Neben dem veröffentlichten Quellcode selbst lassen sich daraus oft Rückschlüsse auf eingesetzte Technologien, Frameworks und die technische Infrastruktur ziehen.

Besonders relevant ist die Versionshistorie. Weil Git jede Änderung als Commit speichert, bleiben Informationen auch dann noch erreichbar, wenn sie aus dem aktuellen Stand längst entfernt wurden. Committet ein Entwickler versehentlich ein Passwort oder einen API-Key und löscht ihn kurz darauf wieder, liegt das Geheimnis weiterhin in der Historie und ist für jeden einsehbar, der weiß, wo er suchen muss.

Schon die GitHub-Suche erlaubt eine gezielte Recherche nach bestimmten Dateitypen oder Zeichenfolgen in den Repositories eines Unternehmens:

```
"beispiel.de" path:*.pem
"beispiel.de" "password" path:*.env
```

Automatisieren lässt sich das mit Werkzeugen wie `TruffleHog` oder `Gitleaks`, die ein Repository samt vollständiger Commit-Historie nach Secrets durchsuchen. TruffleHog kann gefundene Credentials außerdem gegen den jeweiligen Dienst verifizieren, was die Zahl der Fehlalarme deutlich senkt:

```
$ trufflehog github --org=beispiel --only-verified
✅ Found verified result
Detector Type: AWS
Repository: github.com/beispiel/backend-api
File: config/old.env    Commit: a3f9c1             # aus altem Commit, im aktuellen Stand gelöscht
```

`--only-verified` bedeutet, dass der Key noch gültig ist. Der Fund in einem alten Commit belegt zugleich die Kernaussage dieses Kapitels: Löschen aus dem aktuellen Stand reicht nicht aus.

Was verraten Menschen über ihr Unternehmen?

Nicht nur die Infrastruktur und die Systeme geben zahlreiche Auskünfte, sondern auch die Menschen, die sie betreiben und bedienen. Eine ergiebige Quelle bei der OSINT-Recherche sind Stellenanzeigen. Diese haben das Potenzial, einen detaillierten Techstack abzubilden. Wenn ein Unternehmen zum Beispiel in der Stellenanzeige “Erfahrung mit Citrix NetScaler, FortiGate-Firewalls und einer On-Prem-Exchange-Umgebung” sucht, verrät es damit exakt, welche Produkte im Einsatz sind, inklusive Hinweisen auf mögliche Angriffspunkte. Aus einer Reihe von Anzeigen lässt sich oft ein erstaunlich vollständiges Bild der internen IT-Landschaft zusammensetzen.

Konferenzvorträge und Präsentationen von Mitarbeitern liefern Architekturdiagramme, Toolnamen und interne Prozesse. Auf Folien von Fachvorträgen sind schon Screenshots interner Systeme, Beispielkonfigurationen oder Hostnamen gelandet.

Berufsnetzwerke und soziale Medien helfen beim Aufbau eines Organigramms: Wer arbeitet wo, wer berichtet an wen, wer ist neu und damit womöglich noch unsicher im Umgang mit internen Abläufen. Namen plus die aus Metadaten oder Stellenanzeigen abgeleiteten Namenskonventionen ergeben valide E-Mail-Adressen und damit die Grundlage für gezieltes Phishing.

Zuletzt ist im Bezug auf den Menschen die Passwortwiederverwendung zu erwähnen. Ein Zugang, den jemand privat mehrfach nutzt und der in einem beliebigen Leak auftaucht, öffnet im schlimmsten Fall auch einen Zugang zum Unternehmen.

Was steckt in Leaks und Stealer-Logs?

Datenlecks sind regelmäßig ein Thema und werden in zwei Kategorien unterteilt.

Klassische Credential-Leaks stammen aus kompromittierten Diensten. Über Have I Been Pwned (https://haveibeenpwned.com/) lässt sich prüfen, ob eine Adresse oder eine ganze Domäne in bekannten Leaks auftaucht. Dies ist für Verteidiger wie auch für Privatpersonen ein gutes Monitoringwerkzeug. Die Domänensuche zeigt aggregiert, welche E-Mail-Adressen oder Firmenaccounts betroffen sind, ohne einzelne Passwörter offenzulegen. Es liegt dann an den betroffenen Personen, ihre Passwörter zu ändern.

Stealer-Logs sind die gefährlichere, neuere Kategorie. Infostealer-Malware auf privaten oder schlecht verwalteten Geräten sammelt gespeicherte Passwörter, Session-Cookies und Browserdaten und lädt sie in großen Paketen ab, die in einschlägigen Foren und Marktplätzen gehandelt werden. Anders als ein Leak eines einzelnen Dienstes enthält ein Stealer-Log oft alle Zugänge eines Menschen auf einmal, teilweise inklusive aktiver Sessions, mit denen sich Multi-Faktor-Authentifizierung (MFA) teils umgehen lässt.

Solche Daten werden in kriminellen Foren, Telegram-Kanälen und auf einschlägigen Marktplätzen gehandelt, teils frei zugänglich, teils gegen Bezahlung. Konkrete Bezugsquellen nennen wir hier bewusst nicht. Für die Verteidigerseite genügt ohnehin der legale Weg. Neben Have I Been Pwned gibt es kommerzielle Credential-Monitoring-Dienste, die genau solche Quellen für die eigene Domäne beobachten und alarmieren, sobald Zugangsdaten auftauchen. So greift man auf dieselbe Erkenntnis zu, ohne selbst mit zwielichtigen Quellen in Kontakt zu kommen.

Was verrät die physische Welt?

OSINT ist nicht auf Netzwerk- und Personenebene begrenzt. Kartendienste mit Satelliten- und Street View-Ansicht zeigen Gebäude, Zufahrten, Parkflächen, Rauchereingänge und die Lage von Empfang und Sicherheitspersonal. Für einen physischen Sicherheitstest oder ein Social Engineering-Szenario ist das die Grundlage der Planung, noch bevor jemand vor Ort war.

Hinzu kommen die schon erwähnten Fotos: Ein Werksausweis, gut sichtbar auf einem Team-Foto oder einem Post in einem Berufsnetzwerk, verrät Layout, Farbe, Logo und Aufbau der Zutrittskarte. Das reicht bei einem solchen physischen Penetrationstest oft, um eine weitestgehend überzeugende Attrappe zu bauen.

Wo verläuft die rechtliche Grenze?

OSINT bewegt sich per Definition im öffentlich zugänglichen Bereich. Aber öffentlich einsehbar und rechtlich unbedenklich sind nicht dasselbe.

Aktive Reconnaissance gegen fremde Systeme braucht immer eine schriftliche Beauftragung mit klar definiertem Scope. Passives Sammeln aus öffentlichen Quellen ist zwar weit weniger heikel, aber sobald man Systeme des Ziels direkt berührt, und sei es nur ein Portscan, ist ohne Erlaubnis die Grenze zum unbefugten Zugriff schnell überschritten. Der Scope sollte auch festlegen, welche Quellen tabu sind, etwa der Kauf von Stealer-Logs.

Auch personenbezogene Daten unterliegen der DSGVO, wenn sie öffentlich auffindbar sind. Das Zusammentragen von Mitarbeiterprofilen zu einem Dossier hat einen anderen rechtlichen Charakter als das Betrachten einer einzelnen öffentlichen Seite. Was erhoben, gespeichert und im Bericht dokumentiert wird, sollte auf das für den Auftrag Notwendige beschränkt bleiben.

Gefundene Daten, gerade Credentials und personenbezogene Informationen, müssen sicher behandelt, nachvollziehbar dokumentiert und nach Abschluss des Auftrags kontrolliert gelöscht werden. Im Zweifel gilt: Was für den Nachweis eines Risikos nicht nötig ist, wird nicht gespeichert. Und ohne Genehmigung des Unternehmens beschränkt man die Suche auf die unbedenklichen, rein passiven Techniken.

Die Verteidigungsperspektive: Was können Unternehmen nun konkret tun?

Bis hierher stand die Angreiferseite im Vordergrund. Die gute Nachricht ist, dass dieselbe Methodik auch der Verteidigungsseite offensteht. Wer seine eigene Angriffsfläche regelmäßig aus der Außenperspektive betrachtet, findet die Probleme in der Regel zuerst. Die folgenden Maßnahmen setzen genau an den Quellen an, die in diesem Artikel beschrieben wurden.

• Ein aktuelles Asset-Inventar pflegen: Man kann nur schützen, was man kennt. Ein Verzeichnis aller nach außen erreichbaren Domänen, Subdomänen, IP-Bereiche und Dienste ist die Grundlage. Vergessene Altsysteme sind das eigentliche Risiko.
• Certificate Transparency überwachen: Wer die CT-Logs für die eigenen Domänen beobachtet, erfährt von neu ausgestellten Zertifikaten und damit von neuen, teils nicht autorisierten Hosts.
• Verwaiste DNS-Einträge aufräumen: CNAME- oder A-Records, die auf nicht mehr genutzte Cloud-Ressourcen zeigen, ermöglichen im schlimmsten Fall eine Subdomänen-Übernahme, bei der ein Angreifer die freigewordene Ressource selbst registriert. Solche "dangling records" müssen regelmäßig geprüft und entfernt werden.
• Legacy-Authentifizierung deaktivieren: Gerade in Microsoft 365-Umgebungen sind alte Auth-Protokolle ohne MFA ein bevorzugtes Ziel für Password Spraying.
• Credential Monitoring einsetzen: Leak- und Stealer-Quellen für die eigenen Domänen automatisiert beobachten, damit kompromittierte Zugänge auffallen, bevor Angreifer diese ausnutzen können.
• Phishing-resistente Authentifizierung einsetzen: MFA verpflichtend machen, möglichst mit FIDO2/Passkeys statt SMS oder Push, und kompromittierte Passwörter beim Login gegen bekannte Leak-Listen prüfen. Nach einem Stealer-Fund reicht ein Passwortwechsel oft nicht, auch die aktiven Sessions müssen invalidiert werden.
• E-Mail-Sicherheit härten: Sauber konfigurierte SPF-, DKIM- und DMARC-Records mit durchsetzender Policy (`p=reject`) erschweren das Spoofing der eigenen Domäne erheblich.
• Exponierte Inhalte entfernen lassen: Wurde etwas versehentlich veröffentlicht und indexiert, nach der Bereinigung an der Quelle auch die De-Indexierung anstoßen (etwa über die Google Search Console).
• Directory Listing und aussagekräftige Banner abschalten: "Index of"-Seiten und Software-Versionen in HTTP-Headern liefern genau die Details, die Google Dorks und Shodan auswerten.
• Secret Scanning in CI/CD verankern: Automatisierte Prüfungen, die Commits vor dem Push auf Secrets untersuchen (etwa Gitleaks als Pre-Commit-Hook oder in der Pipeline), verhindern das Leaken von Keys. Ist ein Secret veröffentlicht, gilt es als kompromittiert und muss rotiert werden. Es aus dem aktuellen Stand zu löschen, genügt nicht, denn in den vorherigen Commits bleibt es erhalten. Selbst ein Umschreiben der Historie (etwa mit `git filter-repo`) entfernt das Secret nicht zuverlässig, solange noch alte Tags, Branches, Forks oder von der Plattform gecachte Commits darauf verweisen. Deshalb gilt: rotieren, nicht nur löschen.
• Canary Token auslegen: Absichtlich platzierte Fake-Credentials (etwa in einem Repository oder Dokument) schlagen Alarm, sobald jemand sie verwendet, und machen Recon oder einen Leak-Zugriff sichtbar.
• Cloud-Speicher prüfen: Öffentlich erreichbare Buckets gehören in die regelmäßige Kontrolle, samt sinnvoller Default-Konfiguration, die neue Buckets nicht offen anlegt.
• Metadaten bereinigen: Dokumente vor der Veröffentlichung von Metadaten befreien, idealerweise automatisiert im Publishing-Prozess.
• Stellenanzeigen und Veröffentlichungen entschärfen: Konkrete Produkt- und Versionsnamen sind für die Personalsuche selten nötig. Anforderungen lassen sich meist allgemeiner formulieren, ohne den kompletten Techstack offenzulegen.
• Awareness schaffen: Mitarbeiter dafür sensibilisieren, was ein Foto vom Arbeitsplatz, ein detaillierter Konferenzvortrag oder eine sehr auskunftsfreudige Stellenanzeige preisgeben kann. Dazu gehört auch das Bewusstsein für Passwortwiederverwendung: Ein privat mehrfach genutztes Passwort, das in einem Leak auftaucht, wird schnell zum Einfallstor ins Unternehmen.

Am wirksamsten ist es, diese Prüfungen nicht einmalig durchzuführen, sondern die eigene Angriffsfläche laufend zu beobachten, mit denselben Werkzeugen und aus derselben Perspektive wie ein Angreifer.

Fazit

Ein Angriff beginnt fast immer mit der Reconnaissance und damit mit öffentlich verfügbaren Informationen. Vom DNS-Eintrag über das Zertifikatslog, die vergessene Subdomain und den versehentlich committeten API-Key bis zur auskunftsfreudigen Stellenanzeige entsteht Stück für Stück ein Bild des Unternehmens, das genügt, um den ersten echten Schritt vorzubereiten.

Für Verteidiger heißt das vor allem eines: Diese Informationen sind ohnehin in der Welt, die Frage ist nur, wer sie zuerst zusammensetzt. Wer die eigene Angriffsfläche mit denselben Werkzeugen und derselben Systematik untersucht wie ein Angreifer, stößt auf dieselben Punkte und kann sie schließen, bevor jemand anderes sie nutzt.