OSINT und Aufklaerung fuer Verteidiger: Die eigene Angriffsflaeche kartieren

Open-Source-Intelligence (OSINT) ist die Praxis, bereits oeffentlich verfuegbare Informationen zu sammeln und auszuwerten: DNS-Eintraege, Code-Repositorys, Stellenanzeigen, Mitarbeiterprofile, Certificate-Transparency-Logs, Cloud-Speicher und unzaehlige weitere Spuren, die eine Organisation hinterlaesst. Angreifer setzen auf OSINT, weil es leise, guenstig ist und das Ziel kaum direkt beruehrt. Fuer Verteidiger ist dieselbe Disziplin ein Geschenk: Wenn Sie Ihre Organisation so betrachten wie ein Aussenstehender, finden Sie die Schwachstellen, bevor jemand anderes sie ausnutzt. Dieser Artikel betrachtet Aufklaerung aus der Blue-Team-Perspektive — verstehen, wie das Profiling funktioniert, um es zu erkennen, weniger preiszugeben und den eigenen Fussabdruck fortlaufend zu ueberwachen.

Was OSINT-Aufklaerung wirklich ist#

Aufklaerung ist die erste Phase nahezu jedes Angriffs. Bevor ein Angreifer ein Login-Formular beruehrt oder eine Phishing-Mail sendet, baut er ein Bild des Ziels auf: welche Domains und Subdomains existieren, welche Technologien den Web-Stack antreiben, wer dort in welchen Rollen arbeitet und welchen Dritten vertraut wird. OSINT ist die passive Haelfte dieser Arbeit. Sie stuetzt sich auf Quellen, die die Organisation — absichtlich oder versehentlich — veroeffentlicht hat, sowie auf Aggregatoren, die das oeffentliche Internet indexieren. Da noch nichts ausgenutzt wird, erzeugt OSINT wenig bis keinen Datenverkehr gegen Ihre Systeme, weshalb es schwer zu erkennen ist und proaktive Selbsteinschaetzung hier wichtiger ist als Detektion.

Wie Angreifer das Bild aufbauen#

Ein typischer Profiling-Ablauf beginnt mit einem einzigen Ausgangspunkt wie einem Firmennamen oder einer Hauptdomain und weitet sich aus. Von der Domain aus zaehlt ein Analyst DNS-Eintraege und Subdomains auf, zieht historische Daten von Passive-DNS-Anbietern und liest Certificate-Transparency-Logs, die jedes jemals ausgestellte TLS-Zertifikat oeffentlich festhalten — auch fuer intern klingende Hostnamen wie vpn-test oder staging-admin. Parallel sammelt er Personen: Namen, Titel und E-Mail-Muster aus beruflichen Netzwerken, Konferenzvortraegen und Pressemitteilungen, die die E-Mail-Namenskonvention (etwa vorname.nachname@firma.de) und das Organigramm offenbaren. Oeffentliche Code-Hosts werden nach geleakten Secrets, internen URLs und Abhaengigkeitslisten durchsucht. Cloud-Speicher und fehlkonfigurierte Object-Buckets werden auf lesbare Dateien geprueft. Das Ergebnis ist eine Karte Ihrer externen Flaeche und eine Zielliste von Menschen — alles zusammengestellt, ohne Sie je anzugreifen.

Ihre exponierte Angriffsflaeche#

Die Flaeche, die ein Angreifer sieht, ist groesser, als die meisten Teams annehmen. Sie umfasst vergessene Subdomains, die auf ausgemusterte Dienste zeigen (ein klassisches Subdomain-Takeover-Risiko), ins Internet exponierte Entwicklungs- und Staging-Umgebungen, abgelaufene aber noch aufloesende DNS-Eintraege, in veroeffentlichten Dokumenten eingebettete Metadaten (Autorennamen, interne Dateipfade, Softwareversionen), in clientseitigem JavaScript referenzierte API-Endpunkte sowie Technologie-Fingerabdruecke aus HTTP-Headern und Fehlerseiten. Jedes davon ist eine legitime oeffentliche Tatsache — das Verteidigungsziel ist nicht, das Internet vergessen zu lassen, sondern sicherzustellen, dass das Oeffentliche gewollt, aktuell und nicht sensibel ist.

Detektion: Aufklaerungssignale erkennen#

Passives OSINT ist weitgehend unsichtbar, aber der Uebergang von passiver zu aktiver Aufklaerung — wenn ein Angreifer beginnt, Ihre Assets abzutasten — hinterlaesst Telemetrie, die Sie erfassen koennen. Achten Sie in Web- und WAF-Logs auf Enumerationsmuster: Wellen von 404-Fehlern ueber erratene Pfade, Anfragen nach gaengigen Admin- oder Backup-Dateien und Directory-Brute-Force-User-Agents. Ueberwachen Sie DNS-Query-Logs auf schnelles Subdomain-Raten gegen Ihre autoritativen Server. Richten Sie Certificate-Transparency-Monitoring ein, damit Sie alarmiert werden, sobald ein Zertifikat fuer einen Namen unter Ihren Domains ausgestellt wird — das erwischt Schatten-IT ebenso wie Angreifer, die aehnlich aussehende Domains fuer Phishing bereitstellen. Setzen Sie Canary-Tokens ein: gefaelschte Zugangsdaten, Honeypot-Dokumente oder Koeder-Subdomains, die nie beruehrt werden sollten; jede Interaktion damit ist ein hochsicheres Signal. Korrelieren Sie Scan-Spitzen aus einer einzelnen ASN oder Cloud-Range in Ihrem SIEM und alarmieren Sie bei Zugriff auf Endpunkte, die existieren, aber nirgends verlinkt sind.

Detektionsquellen, die sich lohnen#

Konkret sollten Sie folgende Quellen in Ihr Monitoring einspeisen: Certificate-Transparency-Feeds gefiltert auf Ihre registrierten Domains; Passive-DNS-Aenderungsalarme; Neu-Subdomain-Erkennung aus Ihren eigenen wiederkehrenden Scans; GitHub- und Paste-Site-Ueberwachung fuer Ihre Domainnamen und internen Kennungen; Marken- und Typosquat-Ueberwachung fuer aehnlich aussehende Domains; sowie WAF/CDN-Analysen fuer Scan-Wellen. Auf Endpunkt- und Netzwerkseite sehen EDR- und NDR-Telemetrie passives OSINT meist nicht, aber sie sind Ihr Sicherheitsnetz fuer den Moment, in dem Aufklaerung zu Interaktion wird. Das Prinzip ist Defense in Depth: Das Lesen oeffentlicher Daten koennen Sie nicht erkennen, also erkennen Sie den Moment, in dem dieses Lesen genutzt wird. Es hilft zudem, diese Feeds mit Kontext anzureichern — markieren Sie, welche Assets geschaeftskritisch sind, welche Subdomains zu welchem Team gehoeren und welche aehnlich aussehenden Domains bereits gemeldet wurden — damit ein Alarm mit genug Information ankommt, dass ein Analyst ihn rasch triagieren kann, statt als isoliertes, mehrdeutiges Ereignis unbearbeitet in einer Warteschlange zu liegen.

Mitigation und Hardening#

Die OSINT-Exposition zu reduzieren ist vor allem diszipliniertes Hygiene-Handwerk. Inventarisieren Sie jede Domain und Subdomain und mustern Sie aus, was Sie nicht brauchen; ein kleinerer Fussabdruck ist ein kleineres Ziel. Entfernen Sie DNS-Eintraege, die auf ausgemusterte Ressourcen zeigen, um Subdomain-Takeover-Pfade zu schliessen. Halten Sie Nicht-Produktivumgebungen aus dem oeffentlichen Internet fern oder hinter Authentifizierung und IP-Allowlists. Entfernen Sie Metadaten aus Dokumenten vor der Veroeffentlichung und standardisieren Sie Vorlagen ohne interne Pfade. Pruefen Sie oeffentliche Code-Repositorys auf Secrets und erzwingen Sie Pre-Commit-Secret-Scanning plus serverseitigen Push-Schutz, damit Zugangsdaten nie in die Historie gelangen. Verallgemeinern Sie Fehlerseiten und entfernen Sie versionsverratende Header, um Technologie-Fingerprinting zu erschweren. Da E-Mail-Konventionen trivial erratbar sind, behandeln Sie eine gueltige Adresse nicht als Geheimnis — investieren Sie das Budget stattdessen in phishing-resistente Authentifizierung.

Die menschliche Flaeche reduzieren#

Menschen sind die reichste OSINT-Quelle, und Sie koennen Mitarbeitern nicht verbieten, oeffentliche Profile zu haben. Erhoehen Sie stattdessen die Kosten, diese Informationen zu nutzen. Schulen Sie Personal darin, Pretexting und gezieltes Phishing zu erkennen, das echte Projekte oder Kollegen referenziert. Erzwingen Sie phishing-resistente Multi-Faktor-Authentifizierung (FIDO2-Sicherheitsschluessel oder Passkeys), damit ein erbeutetes Passwort plus ein ueberzeugender Koeder nicht ausreicht. Begrenzen Sie, wie viel operative Detailtiefe in Stellenanzeigen erscheint — die exakte Auflistung Ihres Sicherheits-Stacks hilft Bewerbern und Angreifern gleichermassen. Etablieren Sie einen klaren, bekannten Kanal zur Meldung verdaechtiger Kontakte und belohnen Sie Meldungen, statt den Meldenden zu bestrafen. Denken Sie schliesslich daran, dass Fuehrungskraefte und privilegierte Administratoren ueberproportional ins Visier geraten, gerade weil ihre oeffentlichen Profile reichhaltiger und ihre Zugriffe breiter sind; erweitern Sie daher den staerksten Schutz und die aufmerksamste Ueberwachung genau auf diese Konten, statt jede Identitaet als gleich zu behandeln.

Haeufige Fallstricke#

Teams stolpern auf vorhersehbare Weise. Sie ueberwachen die Produktion sorgfaeltig und vergessen den Wildwuchs vergessener Subdomains und alter Marketing-Microsites. Sie behandeln Certificate Transparency als Rauschen statt als kostenloses Fruehwarnsystem. Sie scannen ihre Flaeche einmal waehrend eines Audits und nie wieder, sodass Drift binnen Wochen neue Expositionen einfuehrt. Sie reagieren auf ein geleaktes Secret, indem sie die Datei loeschen, vergessen aber, die Zugangsdaten zu rotieren, sodass diese in der Git-Historie und in Angreiferhand gueltig bleiben. Und sie verwechseln Obskuritaet mit Sicherheit — einen Endpunkt zu verstecken schuetzt ihn nicht. Nehmen Sie an, dass alles Oeffentliche bereits bekannt ist, und sichern Sie es entsprechend.

Checkliste fuer Verteidiger#

Nutzen Sie dies als wiederkehrende Routine. Fuehren Sie ein Live-Inventar von Domains, Subdomains und oeffentlichen IP-Bereichen. Fuehren Sie wiederkehrende externe Erkennung durch und vergleichen Sie die Ergebnisse, um neue Expositionen zu erfassen. Abonnieren Sie Certificate-Transparency-Alarme fuer alle Ihre Domains. Ueberwachen Sie Code-Hosts und Paste-Sites auf Ihre Kennungen und rotieren Sie jedes exponierte Secret sofort. Setzen Sie Canary-Tokens ueber Speicher, Zugangsdaten und Koeder-Hosts. Entfernen oder authentifizieren Sie jede Nicht-Produktivumgebung. Entfernen Sie Dokument-Metadaten und verallgemeinern Sie Fehlerantworten. Erzwingen Sie ueberall phishing-resistente MFA. Fuehren Sie gezielte Phishing- und Pretexting-Sensibilisierung durch. Pruefen und beschneiden Sie oeffentliche Stellenanzeigen und die soziale Exposition sensibler Rollen. Wiederholen Sie den gesamten Zyklus nach festem Plan, denn die Angriffsflaeche ist nie statisch.

Werkzeuge und Automatisierung der Selbstaufklaerung#

Die Selbstaufklaerung von Hand einmal im Quartal durchzufuehren skaliert nicht, weil sich Cloud-Ressourcen, DNS-Eintraege und oeffentliche Repositorys taeglich veraendern. Der defensive Gegenentwurf ist eine kontinuierliche Attack-Surface-Management-Routine, die dieselben Quellen abfragt, die ein Angreifer nutzen wuerde, und die Ergebnisse gegen einen bekannten Sollzustand vergleicht. Praktisch heisst das: geplante Laeufe, die Subdomains aufzaehlen, Certificate-Transparency-Feeds abgreifen, oeffentliche IP-Bereiche pruefen und Code-Hosts nach Ihren Kennungen durchsuchen, wobei jeder Lauf ein Diff gegen den vorherigen erzeugt. Nur die Aenderung gegenueber dem letzten bekannten Zustand ist ein Alarm wert; ein stabiler, dokumentierter Bestand erzeugt kein Rauschen. Wichtig ist, den Sollzustand als versioniertes Inventar zu fuehren, sodass jede neue Exposition entweder als bewusste Aenderung bestaetigt oder als Drift untersucht wird. Behandeln Sie die Selbstaufklaerung wie einen Build-Job: reproduzierbar, protokolliert und mit einem klaren Besitzer, der auf Abweichungen reagiert, statt sie in einem Bericht versickern zu lassen.

Von der Erkennung zur Reaktion: ein Runbook#

Eine Exposition zu finden hat nur Wert, wenn ein definierter Pfad sie schliesst. Legen Sie fuer jede Befundklasse im Voraus fest, wer verantwortlich ist und innerhalb welcher Frist reagiert wird. Ein geleaktes Secret in einem oeffentlichen Repository loest sofortige Rotation der betroffenen Zugangsdaten aus, gefolgt vom Entfernen aus der Historie — niemals nur das Loeschen der Datei, denn der Wert bleibt im Git-Verlauf gueltig. Eine verwaiste Subdomain, die auf einen ausgemusterten Dienst zeigt, loest das Entfernen des DNS-Eintrags aus, bevor sie uebernommen werden kann. Ein neu ausgestelltes Zertifikat fuer einen unerwarteten Namen loest eine Pruefung aus, ob es sich um Schatten-IT oder um eine Phishing-Vorbereitung handelt. Verankern Sie diese Reaktionen als kurzes, geuebtes Runbook mit Tickets, Fristen und einer Eskalationsstufe, statt jeden Fund ad hoc zu behandeln. Ein Programm, das findet, aber nicht behebt, erzeugt lediglich eine gepflegte Liste bekannter Schwaechen, die ein Angreifer ebenso lesen kann wie Sie.

FAQ: Ist OSINT-Aufklaerung illegal?#

Das Sammeln oeffentlich verfuegbarer Informationen ist grundsaetzlich rechtmaessig, genau deshalb setzen Angreifer darauf und genau deshalb koennen Sie es nicht verhindern. Was rechtliche und ethische Grenzen ueberschreitet, ist unbefugter Zugriff, Ausnutzung oder Social-Engineering-Kampagnen gegen Ihre Menschen. Fuer Verteidiger stellt das das Ziel neu: Sie versuchen nicht, Menschen am Lesen oeffentlicher Daten zu hindern, sondern sicherzustellen, dass die oeffentlichen Daten nicht sensibel sind, und den Moment zu erkennen, in dem Aufklaerung zum Angriff wird.

FAQ: Wie oft sollten wir den eigenen Fussabdruck bewerten?#

Fortlaufend fuer signalstarke Quellen und periodisch fuer den vollstaendigen Durchlauf. Certificate-Transparency-, Code-Host- und Paste-Site-Ueberwachung sollten nahezu in Echtzeit laufen, weil sie frische Expositionen aufdecken. Eine umfassende externe Erkennung — Subdomains, exponierte Dienste, Metadaten, Cloud-Speicher — sollte mindestens monatlich und nach jeder groesseren Infrastrukturaenderung laufen, da Cloud-Umgebungen und DNS schnell driften. Behandeln Sie Ihre Angriffsflaeche als lebendes Inventar, nicht als einmaligen Bericht.

Fazit#

OSINT-Aufklaerung ist unvermeidbar, weil sie Informationen nutzt, die Sie bereits oeffentlich gemacht haben. Die Verteidigungsantwort lautet: zuerst hinschauen. Profilieren Sie sich so, wie es ein Angreifer taete, verkleinern und kuratieren Sie das Exponierte, verdrahten Sie Fruehwarnquellen wie Certificate Transparency und Canary-Tokens und erkennen Sie den Schwenk von passiver Sammlung zu aktivem Abtasten. Aufklaerung ist leise, aber die Expositionen, die sie findet, sind Dinge, die Sie beheben koennen. Indem Sie die Methodik des Angreifers in eine fortlaufende Selbstbewertung verwandeln, machen Sie aus einem Informationsvorteil einen Verteidigungsvorteil und die erste Phase jedes Angriffs weit weniger ergiebig.