Honeypots & Deception

Honeypots sind Systeme ohne produktiven Zweck, deren einzige Aufgabe darin besteht, angegriffen zu werden – jede Interaktion ist damit per Definition mindestens verdächtig. Low-Interaction-Honeypots emulieren einzelne Dienste oder Protokolle nur oberflächlich; sie sind ressourcenschonend, schnell ausgerollt und risikoarm, liefern aber begrenzte Einblicke und sind für Angreifer leichter als Attrappe erkennbar. High-Interaction-Honeypots stellen reale Betriebssysteme und Anwendungen bereit und erlauben tiefe Analysen von Werkzeugen und Vorgehensweisen – um den Preis eines deutlich höheren Betriebs- und Absicherungsaufwands. Die ENISA hat in ihrer Grundlagenstudie 30 Honeypot-Lösungen entlang genau dieser Taxonomie evaluiert, darunter server- wie clientseitige Varianten.

Honeytokens übertragen das Köder-Prinzip von Systemen auf Daten und Zugangsdaten: präparierte API-Schlüssel, Dokumente, Datenbankeinträge, DNS-Namen oder E-Mail-Adressen, die im regulären Betrieb niemand verwendet. Wird ein solches Objekt geöffnet oder ein hinterlegter Schlüssel benutzt, ist das ein nahezu eindeutiger Kompromittierungsindikator – auch dort, wo klassische Sensorik fehlt, etwa in SaaS-Diensten oder bei Datenabfluss. Frei verfügbare Dienste wie Canarytokens von Thinkst stellen über 30 Token-Typen bereit, von AWS-Schlüsseln über Office-Dokumente bis zu Kubeconfig-Dateien, und ermöglichen den Einstieg mit minimalem Aufwand. NIST beschreibt dieses Vorgehen („Tainting“) neben der Umlenkung von Angreifern („Misdirection“) als Ansatz der Cyber-Resiliency-Technik Deception.

Klassische Detektion über SIEM, EDR oder NDR muss Angriffe aus großen Mengen legitimer Ereignisse herausfiltern – mit entsprechendem Grundrauschen und Tuning-Aufwand. Deception kehrt diese Logik um: Da legitime Nutzer Decoys und Honeytokens nicht berühren, hat praktisch jeder Alarm Relevanz. Deception-Plattformen orchestrieren Köder zentral, speisen Alarme ins SIEM beziehungsweise SOC ein und liefern kontextreiche Telemetrie für die Incident Response. Mit MITRE Engage existiert seit 2022 zudem ein eigenes Framework, das Denial-, Deception- und Adversary-Engagement-Aktivitäten strukturiert und an real beobachtetem Angreiferverhalten ausrichtet. Für Betreiber kritischer Anlagen kann Deception die nach § 31 BSIG geforderten Systeme zur Angriffserkennung ergänzen – ersetzen kann sie sie nicht.

Deception wirkt dort, wo sich Angreifer nach dem initialen Zugriff bewegen: in internen Netzsegmenten, im Active Directory, auf Datei- und Backup-Systemen, in Cloud-Umgebungen und zunehmend auch in OT-Netzen. Bewährt haben sich Decoy-Systeme in jedem relevanten Segment sowie Honeytokens in Repositories, Konfigurationsdateien und Credential-Speichern – also entlang der Wege, die Lateral Movement und Privilegien-Eskalation typischerweise nehmen. Ein öffentlich im Internet exponierter Honeypot liefert dagegen vor allem Grundrauschen aus Massen-Scans und trägt zur Erkennung gezielter Angriffe auf das eigene Netz wenig bei. Entscheidend ist Glaubwürdigkeit: Namenskonventionen, Patchstände und Metadaten der Köder müssen zur realen Umgebung passen, und Deception-Infrastruktur gehört strikt vom Produktivnetz getrennt.

Der Betrieb von Honeypots auf eigener Infrastruktur ist als reine Detektionsmaßnahme zulässig – der Angreifer greift von sich aus auf Systeme des Betreibers zu, eine strafbare „Anstiftung“ liegt darin nicht. Klar davon abzugrenzen ist der „Hackback“: Aktive Zugriffe auf fremde Systeme sind Unternehmen in Deutschland nicht gestattet und bleiben mangels Erlaubnisnorm strafbar (u. a. §§ 202a ff. StGB); Deception endet an der eigenen Netzgrenze. Datenschutzrechtlich lässt sich die Verarbeitung der dabei anfallenden Daten (etwa IP-Adressen) regelmäßig auf das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO stützen – Erwägungsgrund 49 nennt die Gewährleistung der Netz- und Informationssicherheit ausdrücklich, soweit die Verarbeitung dafür unbedingt notwendig und verhältnismäßig ist. Sorgfalt verlangt der Fall, dass ein kompromittierter High-Interaction-Honeypot als Sprungbrett für Angriffe auf Dritte missbraucht wird: Die strafrechtliche Literatur diskutiert hier Beihilfe-Risiken für Betreiber, weshalb ausgehender Verkehr technisch strikt zu begrenzen ist.

Deception erkennt nur Angreifer, die tatsächlich mit Ködern interagieren – sie ersetzt weder Prävention noch flächendeckende Detektion, sondern ergänzt beide um eine hochpräzise zusätzliche Signalquelle. Erfahrene Angreifer versuchen, Honeypots per Fingerprinting zu enttarnen; Emulations-Artefakte, unplausible Systeme oder fehlende Nutzungsspuren zerstören die Illusion und entwerten die Maßnahme. Der Betrieb erfordert deshalb laufende Pflege: Aktualisierung der Decoys, Anpassung an Veränderungen der Umgebung, definierte Playbooks für Alarme und klare Zuständigkeiten im SOC. Bereits die ENISA-Studie identifizierte Bedienbarkeit, Dokumentation und Personalbedarf als wesentliche Hürden der Honeypot-Nutzung – moderne Plattformen und Honeytoken-Dienste senken diese Schwelle deutlich, beseitigen den Pflegeaufwand aber nicht vollständig.