IT-Landschaften verändern sich schnell. Testumgebungen entstehen, neue Services werden bereitgestellt, Projekte starten und enden. In vielen Organisationen wächst die Umgebung dynamisch mit den Anforderungen, und das oft schneller, als Prozesse und Dokumentation nachkommen. Systeme entstehen, verändern sich und verschwinden wieder. Besonders das Offboarding erhält im Alltag nicht immer Priorität, die es verdient.
Mit der Zeit entsteht so eine Umgebung, die nicht mehr vollständig bekannt ist. Ein Teil ist dokumentiert und bewusst betrieben. Ein anderer Teil ist erreichbar, ohne aktiv beobachtet zu werden. Und manche Systeme sind nur einzelnen Personen bekannt.
Was aus dem Internet alles erreichbar ist
External Exposure beschreibt Systeme, Dienste und Schnittstellen, die aus dem Internet erreichbar oder exponiert sind. Dazu zählen klassische Webanwendungen ebenso wie APIs, Login-Portale, Cloud-Ressourcen, administrative Oberflächen oder Systeme.
Entscheidend ist nicht die geplante Nutzung, sondern die tatsächliche Erreichbarkeit. Systeme, die ausschließlich über abgeschottete Zugriffswege verfügbar sind, werden häufig mit geringeren Sicherheitsanforderungen betrieben. Wird ein solches System für eine Demonstration oder einen kurzfristigen Zugriff geöffnet und anschließend nicht wieder sauber eingeschränkt, bleibt es unbemerkt erreichbar. Intern wird dann weiterhin davon ausgegangen, dass es geschützt sei.
Die Angriffsfläche entsteht dabei nicht nur durch bewusst freigeschaltete Systeme innerhalb der eigenen Domain oder des eigenen IP-Adressbereichs. Auch neue Domains für Projekte, spezialisierte Themenbereiche oder externe Hosting-Infrastrukturen erweitern den öffentlich sichtbaren digitalen Fußabdruck. Besonders in eigenständig organisierten Umgebungen kann diese zusätzliche Angriffsfläche entstehen, ohne dass sie zentral sichtbar wird.
Unbekannte Systeme bedeuten unbekannte Risiken
Ein System, das niemand (mehr) aktiv betreut oder kennt, kann von außen weiterhin erreichbar sein. Es wird nicht gepatcht, nicht überwacht und nicht priorisiert. Gleichzeitig kann es als Einstiegspunkt dienen, Zugriff auf Daten ermöglichen oder für weitere Angriffe missbraucht werden.
Ein klassisches Beispiel ist das sogenannte Subdomain-Takeover. Für ein Projekt wird eine Subdomain eingerichtet, die auf einen externen Dienst zeigt. Nach Projektende wird der externe Dienst abgeschaltet und kann somit vorübergehend nicht mehr erreicht werden. Die für das Projekt angelegte Subdomain bleibt jedoch weiterhin bestehen. Zeigt sie auf einen externen Dienst, etwa über einen CNAME-Eintrag, entsteht ein potenzielles Risiko: Wird dieser Dienst entfernt, bleibt der Verweis bestehen. Ein Angreifer kann den Zielservice erneut registrieren und die Subdomain übernehmen. So etwas kann für gezieltes Phishing gegen die Organisation oder Verteilung von Schadsoftware in einem vertrauenswürdigeren Kontext genutzt werden. Für externe Nutzer wirkt die Adresse weiterhin vertrauenswürdig, obwohl sie unter fremder Kontrolle ist.
Ein anderes Szenario sind Systeme, die außerhalb zentraler Prozesse betrieben werden. Fachbereiche oder Projektteams setzen eigene Lösungen auf, die technisch funktionieren, aber nie vollständig in zentrale Inventare aufgenommen werden. Sobald sich Verantwortlichkeiten ändern oder Wissen verloren geht, bleiben diese Systeme zurück.
Die Herausforderung besteht nicht nur darin, solche Systeme zu erkennen, sondern auch darin, sie organisatorisch einzuordnen.
External Exposure erkennen und beobachten
Die eigene Angriffsfläche ist ein sich stetig verändernder Zustand. Neue Systeme kommen hinzu, bestehende werden angepasst und ältere bleiben oft länger bestehen als geplant. Eine einmalige Erhebung liefert deshalb nur eine Momentaufnahme. Die IT-Landschaft, wie sie heute bekannt ist, kann morgen bereits unvollständig sein.
In der Praxis zeigt sich das besonders bei dynamischen Umgebungen wie Cloud-Infrastrukturen, projektgetriebenen Setups oder autonomen Organisationseinheiten. Selbst bei etablierten Change-Prozessen kann im Alltag etwas übersehen werden. Systeme werden kurzfristig bereitgestellt, Änderungen erfolgen unter Zeitdruck und nicht jeder Schritt wird sauber dokumentiert.
Eine Organisation kann mit solchen Situationen umgehen, indem sie ihre Angriffsfläche kontinuierlich beobachtet. Sichtbarkeit entsteht nicht durch eine einmalige Erhebung, sondern durch einen laufenden Prozess. Systeme müssen regelmäßig erfasst, überprüft und in einen aktuellen Kontext gebracht werden. Nur so lässt sich verhindern, dass Teile der Infrastruktur aus dem Blick geraten.
Die Erkennung von External Exposure basiert in der Praxis auf der Kombination unterschiedlicher Informationsquellen. Jede Methode liefert für sich genommen nur einen Ausschnitt. Eine Subdomain allein sagt wenig aus. Ein offener Port ohne Kontext ebenso. Erst die Zusammenführung dieser Signale ergibt ein belastbares Lagebild. Bei einer Vielzahl an Systemen lassen sich die Erkennungen ohne Automatisierung kaum konsistent auswerten.
DNS-Enumerierung
Durch systematische Abfragen von DNS-Einträgen lassen sich Subdomains und damit verbundene Systeme identifizieren. Das umfasst nicht nur aktiv genutzte Einträge, sondern auch solche, die nach Projektende oder Systemwechsel nie entfernt wurden. Besonders relevant sind dabei CNAME-Einträge, die auf externe Dienste zeigen: Ist der Zieldienst nicht mehr aktiv, aber der Eintrag noch vorhanden, entsteht ein potenzieller Angriffspunkt. Ergänzend dazu liefern Brute-Force-Abfragen bekannter Subdomain-Muster Hinweise auf Systeme, die bewusst nicht beworben werden. Zu diesen zählen beispielsweise Staging-, Test- oder Administrationsumgebungen.
TLS-Zertifikatsinformationen
Öffentlich einsehbare Zertifikatsdaten aus Certificate-Transparency-Logs (z.B. über crt.sh) geben Hinweise auf Domains und Subdomains, für die Zertifikate von öffentlichen Zertifizierungsstellen ausgestellt wurden. Dadurch entsteht ein historisches, aber unvollständiges Verzeichnis öffentlich genutzter Domains, das sich gut für die Identifikation zusätzlicher oder vergessener Systeme eignet. Zertifikate aus internen PKI-Systemen oder selbstsignierte Zertifikate sind darin nicht enthalten.
Zusätzlich lassen sich Subject-Alternative-Names (SAN) auswerten: Zertifikate können mehrere Domains und Subdomains bündeln und so weitere zugehörige Systeme sichtbar machen.
Port- und Service-Scans
Durch Scans von IP-Adressbereichen können erreichbare Dienste und offene Ports identifiziert werden. Das Ergebnis geht dabei über eine einfache Erreichbarkeitsprüfung hinaus: Banner-Informationen und Service-Fingerprinting geben Hinweise auf eingesetzte Software, Versionen und Protokolle. Damit werden Systeme identifiziert, die auf ungewöhnlichen Ports laufen oder veraltete Dienste betreiben. Kombiniert mit ASN-Daten lässt sich dieser Scan gezielt auf die eigene Infrastruktur einschränken.
Bei der Interpretation der Ergebnisse ist jedoch Vorsicht geboten. Versionsinformationen aus Bannern entsprechen nicht immer dem tatsächlichen Patch-Stand: Viele Linux-Distributionen übernehmen Sicherheitskorrekturen durch Backporting, ohne die Versionsnummer zu erhöhen. Ein gemeldeter Versionsstand kann damit verwundbar wirken, obwohl der entsprechende Fix bereits eingespielt wurde. Scan-Ergebnisse sollten deshalb nicht isoliert bewertet werden.
Weitere OSINT-Methoden
Die Angriffsfläche einer Organisation reicht oft über bekannte Domains und IP-Bereiche hinaus. Über die Autonomous System Number (ASN) lassen sich zusätzliche, potenziell zugehörige IP-Adressbereiche identifizieren. Diese Zuordnung ist jedoch nicht immer eindeutig, insbesondere bei gemeinsam genutzter oder ausgelagerter Infrastruktur.
Reverse WHOIS dreht die Perspektive um und zeigt, welche weiteren Domains mit derselben Organisation in Verbindung stehen können. Dazu zählen etwa Projektdomains, ältere Marken oder Infrastruktur aus übernommenen Unternehmen.
Eine häufig unterschätzte Quelle sind öffentliche Code-Repositories. In Commits oder Konfigurationsdateien hinterlassene Hostnamen, URLs oder API-Endpunkte können auf Systeme hinweisen, die weder im DNS noch in Zertifikatsdaten sichtbar sind. Ergänzend dazu liefern gezielte Suchanfragen mit Suchoperatoren sowie historische Web-Archive weitere Hinweise auf öffentlich erreichbare Infrastruktur.
Nur was sichtbar ist, kann aktiv geschützt werden
Wer nur sieht, was erreichbar ist, weiß noch nicht, was davon relevant ist. Ein exponiertes System ist nicht automatisch kritisch. Es sollte jedoch verstanden, bewertet und eingeordnet werden. Dafür braucht es mehr als technische Erkennung.
External Exposure schafft die Grundlage, um die eigene Angriffsfläche sichtbar zu machen. Der eigentliche Mehrwert entsteht jedoch erst dann, wenn diese Sichtbarkeit mit weiteren Informationen verbunden wird: mit Asset-Daten, mit Change-Prozessen, mit Schwachstelleninformationen und vor allem mit klaren Verantwortlichkeiten.
Sichtbarkeit allein löst das Problem nicht. Erst wenn bekannt ist, welches System betroffen ist, wem es gehört und welche Rolle es im Betrieb spielt, lassen sich sinnvolle Maßnahmen ableiten. So wird aus einer fragmentierten Sicht ein belastbares Lagebild, auf dessen Basis Entscheidungen getroffen werden können.
