Die fortschreitende Professionalisierung der Computerkriminalität führt dazu, dass erste Angriffsversuche bereits wenige Minuten nach der Veröffentlichung eines Exploits in der CVE-Datenbank erfolgen. Honeypots spielen deshalb eine wichtige, mehrstufige Rolle – neben der klassischen Bindung der Ressourcen des Angreifers sind sie heute beispielsweise für die automatische Aktualisierung von DMZ- oder Firewallregeln verantwortlich. Außerdem sammeln sie Informationen über die im Rahmen eines Hacks verwendeten Werkzeuge, um die Konsequenzen eines Angriffs besser abschätzen zu können.

Ziel dieses Artikels ist die Vermittlung eines Überblicks verschiedener Begriffe, die in der Beschreibung der – häufig als quelloffene Software vorliegenden – Implementierungen von Honeypots auftauchen. Damit möchten wir Ihnen ermöglichen, die Eignung verschiedener Honeypot-Arten für Ihre spezifischen Einsatzzwecke zu beurteilen.

Besonders ausgeklügelte Angriffe erregten in der Vergangenheit unter anderem deshalb Aufmerksamkeit, weil Hacker in vielen Fällen Honeypots oder andere Teile der Sicherheitsinfrastruktur als Werkzeug für Angriffe heranzogen – so etwa über die Infektion eines Honeypots, der danach Malware im Produktivnetzwerk verteilt. Low-Interaction-Honeypots umgehen dieses Problem insofern, als sie die als Beute für Angreifer vorgesehenen Services in anderen Programmiersprachen emulieren. Daraus folgt, dass bekannte oder gefundene Exploits fehlschlagen, weil die veränderte Ausführungsumgebung (Stichwort C versus Python) die technischen Voraussetzungen für den Angriff entzieht.

Neben dem Einsammeln der in Brute-Force-Angriffen verwendeten Credentials sind in diesen Honeypots fortgeschrittene Maßnahmen möglich, die Ressourcen des Angreifers binden. Ein klassisches Beispiel ist das unter [1] bereitstehende EndleSSH. Der Dienst implementiert einen SSH-Handshake, um dem verbundenen Client danach einen niemals endenden und zufällig generierten Begrüßungs-Handshake zu senden. Insbesondere unsauber implementierte Portscanning-Bots "ernten" diesen danach stundenlang ab, um entweder wegen Speichermangel oder wegen Pufferüberlauf zu verenden.

Lohn der Mühen ist, dass die Rechenressourcen des Angreifers einige Zeit von lohnenderen Zielen ferngehalten sind. Unter [2] findet sich das in Python gehaltene Glastopf. Interessant ist an ihm, dass die verwundbaren Services mehr oder weniger 1:1 unter Verwendung der in Python enthaltenen Bibliotheken nachgebaut sind. Und da viele Angreifer Suchmaschinen verwenden, um verwundbare Systeme aufzuspüren, implementiert Glastopf typische Suchbegriffe, um sich in Google und Co. auffindbar zu machen.

Als Mittelweg spezifizieren die beiden Autoren Alexander Vetterl und Richard Clayton, auf die diese Art der Klassifizierung zurückgeht, den Medium-Interaction-Honeypot. Dieser emuliert nicht nur das jeweilige Einfallstor, sondern stellt dem Angreifer auch eine virtualisierte Shell samt Dateisystem zur Verfügung. Der Sinn davon liegt neben der längeren Beschäftigung des Angreifers in der Möglichkeit, nach dem initialen Breach heruntergeladene Komponenten zu erbeuten und zwecks Analyse vorzuhalten. Ein gutes Beispiel hierfür ist das als Weiterentwicklung von Kippo entstandene Cowrie [3]. In Hintergrundinformationen betonen die Entwickler mehrfach die Integration einer Emulation von curl. Der Gedanke dabei ist, dass ein Angreifer so seine Payloads herunterlädt. Diese lassen sich danach in die Signaturliste eines dateibasierten Scanners einpflegen.

High-Interaction-Honeypots zeichnen sich derweil durch das Deployment eines vollwertigen Betriebssystems aus. Aus der Logik folgt, dass die in der Einleitung genannte Nutzung dieser – per Definition verwundbaren – Maschine durch den Angreifer prinzipbedingt nicht ausgeschlossen ist, weshalb der damit einhergehende Wartungsaufwand am höchsten ist. Ob des erheblichen Aufwands für die Absicherung gilt, dass nur wenige Entwickler einen derartigen Honeypot anbieten. WetLand [4] ist ein gutes Beispiel, das aufgrund der Verwendung von Docker besonders aus der Menge heraussticht. Ein SSH-Proxy fängt die an den Container gesendeten Angriffsoperationen ab und stellt sie zur Analyse bereit.

Ein weiteres System zur Implementierung eines High-Interaction-Honeypots ist die in "An Interface Diversified Honeypot for Malware Analysis" von Samuel Lauren, Sampsa Rauti und Ville Leppänen vorgeschlagene Methode eines Betriebssystems mit dualem Syscall-Interface. Die drei Autoren schlagen ein modifiziertes Betriebssystem vor, das die als Syscall bezeichneten Einsprungpunkte in Betriebssystemfunktionalität dupliziert. Da das Betriebssystem und seine dazugehörenden Applikationen unter Verwendung der modifizierten Vektoren kompiliert wurde, ist jeder Zugriff auf normale Syscall-Nummern verdächtig und protokollierenswert. Vom Angreifer hochgeladene oder vor Ort kompilierte Payloads lassen sich erkennen und für Analysen vorhalten.

Für das Internet der Dinge (Internet of Things, IoT) vorgesehene Honeypots verwenden gerne eine zweistufige Architektur, in der ein Feld von Opfergeräten hinter einer für den Angreifer unsichtbaren Logging-Infrastruktur steht. Angreifer gehen davon aus, mit einem realen Gerät zu interagieren – dank des Loggings lassen sich verwendete Zugangsdaten und Exploits abgreifen. Das derzeit nur als Forschungspaper zur Verfügung stehende HoneyIoT verfeinert diese Vorgehensweise, indem anstelle der realen Gerätefarm ein KI-Modell zum Einsatz kommt.

Eine weitere Möglichkeit zur Unterteilung der Honeypot-Arten betrifft deren logischen Aufenthaltsort im Netzwerk. Diese auf den ersten Blick akademisch klingende Vorgehensweise ist wichtig, weil die Platzierung des Honeypots die Art der angezogenen Angreifer beeinflusst. Schon 2001 stellten Lance Spitzner und Marty Roesch fest, dass sich Honeypots entweder zur Erforschung neuer Angriffsweisen oder aber zum Aufhalten von bereits im Netzwerk befindlichen Eindringlingen eignen. Erstere Honeypot-Art findet sich als für Angreifer lohnend erscheinendes Ziel normalerweise in der DMZ des Netzwerks, wodurch mit reichlich Traffic zu rechnen ist. Der Administrator erhält durch die Analyse der Logdateien einen Bericht zu allem, was die Angreifer in seinem Netzwerk aussetzen.

Production-Honeypots versuchen, die Aufmerksamkeit eines Angreifers von echten Zielen abzulenken. Hier ist die Positionierung im Kern des Unternehmensnetzwerks empfehlenswert. Außerdem sollte das System so realistisch wie möglich erscheinen und nicht wie ein Honeypot aussehen. Zu guter Letzt sind die Ansprüche an das Monitoring wesentlich höher, weil detektierte Angreifer bereits Zugriff aufs Firmennetz haben. In diesem Zusammenhang kommt der Begriff des Honeynet ins Spiel. Dabei handelt es sich um ein Netzwerk aus Honeypots, die einem Angreifer ein realistischeres Betätigungsfeld anzubieten versuchen. Neben virtualisierten Systemen und der Verwendung preiswerter Prozessrechner (Stichwort OrangePi) bietet sich die Nutzung von Android-Smartphones an. Ein gutes Beispiel findet sich im Paper "A decentralized honeypot for IoT Protocols based on Android devices", das eine als HosTaGe [5] bezeichnete Simulationssoftware ausführt.

Die zu Beginn erwähnte Professionalisierung der Cyberkriminalität geht mit einer Steigerung der den Angreifern zur Verfügung stehenden Ressourcen einher. Die Nutzung von KI-Systemen kann helfen, bis zu einem gewissen Grad Humanressourcen-Parität zu erreichen. Im Paper "Honeypot's Best Friend? Investigating ChatGPT's Ability to Evaluate Honeypot Logs" [6] verwendeten die Autoren künstliche Intelligenz zur Bewertung der in einem ElasticSearch-Verbund generierten Analysedaten. Eine Sonderaufgabe bestand im Mapping gegen die in MITRE ATT&CK-Kriterien, um die Konsequenzen eines Angriffs leichter bewerten zu können. Die erreichten Ergebnisse waren beeindruckend – die Erklärung gelang mit 96 Prozent Wahrscheinlichkeit, während sich beim Mapping 72 Prozent der Attacken korrekt klassifizieren ließen.

Forscher an der Jiangsu-Universität in China haben mit klassischen Methoden des Machine Learning experimentiert. Der im Paper "Constructing Dynamic Honeypot Using Machine Learning" beschriebene Honeypot erzeugt sein für den Angreifer sichtbares Abbild durch Analyse der von nmap und p0f in der Umgebung aufgespürte Geräte. Lohn der Mühen war die Erzeugung dynamischer Honeypots, die für Erkennungssysteme wie das von Shodan bereitgestellte HoneyScore [7] nicht detektierbar waren.

Honeypots entwickeln sich ebenfalls permanent weiter. Dabei kommt es auf die richtige Art sowie die passende Platzierung der digitalen Fallen an. Besonders interessant sind Honeypots, die ganze Rechnerlandschaften simulieren und sich nicht mehr einfach als simulierte Umgebungen erkennen lassen. Mit dem richtigen Einsatz holen Admins entsprechend viele hilfreiche Informationen aus versuchten wie erfolgreichen Hackerangriffen heraus.