Termin vereinbaren

Honeypots & Deception

Wie Sie mit Honeypots, Honeytokens und Deception-Plattformen Angreifer im internen Netz früh erkennen – mit hoher Signalqualität und konstruktionsbedingt wenigen Fehlalarmen.

Angreifer, die Perimeter- und Endpoint-Schutz überwunden haben, bewegen sich oft lange unbemerkt durch interne Netze. Deception-Technologien setzen genau hier an: Köder-Systeme (Honeypots), präparierte Daten und Zugangsdaten (Honeytokens) sowie zentral orchestrierte Täuschungsumgebungen, die für legitime Nutzer keinerlei Funktion haben. Weil niemand einen Grund hat, diese Ressourcen zu berühren, ist nahezu jede Interaktion ein belastbares Angriffssignal – die Zahl der Fehlalarme ist konstruktionsbedingt gering. Dieser Beitrag ordnet die Varianten, die sinnvolle Platzierung, die Rechtslage in Deutschland sowie Grenzen und Betriebsaufwand ein.

Das Wichtigste im Überblick

01

Low- vs. High-Interaction-Honeypots

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.

02

Honeytokens und Canaries

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.

03

Deception-Plattformen im Detection-Stack

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.

04

Sinnvolle Platzierung

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.

05

Rechtliche Einordnung in Deutschland

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.

06

Grenzen und Betriebsaufwand

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.

Standards & Quellen

Die Inhalte dieser Seite basieren auf den folgenden öffentlich verfügbaren Leitfäden und Studien.

ENISA · 2012

Proactive Detection of Security Incidents II – Honeypots

Grundlagenstudie mit Evaluation von 30 Honeypot-Lösungen entlang der Taxonomie Low-/High-Interaction (server- und clientseitig) inklusive der Hürden beim Einsatz.

MITRE · 2022

MITRE Engage v1.0

Framework zur Planung von Denial-, Deception- und Adversary-Engagement-Aktivitäten; Nachfolger von MITRE Shield, veröffentlicht im Frühjahr 2022.

NIST · 2021

NIST SP 800-160 Vol. 2 Rev. 1: Developing Cyber-Resilient Systems

Beschreibt Deception als Cyber-Resiliency-Technik mit den Ansätzen Misdirection (Umlenkung in kontrollierte Umgebungen) und Tainting (markierte Ressourcen).

Thinkst · 2026

Canarytokens Documentation

Dokumentation des kostenfreien Honeytoken-Dienstes mit über 30 Token-Typen, u. a. Cloud-Schlüssel, Office-Dokumente und DNS-basierte Trigger.

KriPoZ – Kriminalpolitische Zeitschrift · 2024

Research Honeypots – Strafbarkeitsrisiken für IT-Sicherheitsforschende?

Juristische Analyse strafrechtlicher Risiken des Honeypot-Betriebs, u. a. zur Beihilfe-Problematik bei Missbrauch eines Honeypots als Angriffs-Sprungbrett.

Bundesministerium der Justiz / gesetze-im-internet.de · 2025

Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG)

§ 31 BSIG verpflichtet Betreiber kritischer Anlagen zu Systemen zur Angriffserkennung nach dem Stand der Technik; Fassung nach der NIS-2-Umsetzung.

Deception gezielt in Ihre Detektion integrieren?

Wir bewerten mit Ihnen, wo Honeypots und Honeytokens in Ihrer Umgebung den größten Erkennungsgewinn bringen – herstellerneutral, rechtlich sauber eingeordnet und in Ihr SOC integriert. Sprechen Sie mit uns.