Honeypots gezielt einsetzen: Frühwarnsystem mit Canarytokens und T-Pot

Key Takeaways

• Honeypots sind kein Nischenthema, sondern ein kosteneffizientes Frühwarnsystem, das Angreifer entlarvt, bevor sie echten Schaden anrichten.
• Canarytokens lassen sich in unter einer Stunde ohne eigene Infrastruktur deployen und liefern nahezu falsch-positive-freie Alarme.
• T-Pot bietet eine vollständige Honeypot-Plattform für tiefere Bedrohungsanalyse und eignet sich für KMU mit einem verfügbaren Linux-Server.
• Die DSGVO erfordert beim Einsatz von Honeypots eine klare Zweckbindung und einen VVT-Eintrag – beides ist mit wenig Aufwand umsetzbar.
• Alerts aus Honeypots sollten in ein zentrales SIEM fließen, damit Korrelation mit echten Events möglich ist.

Warum Honeypots für KMU mehr als ein Nischenthema sind

Angreifer, die in ein Netzwerk eindringen, agieren selten sofort destruktiv. Sie bewegen sich lateral, erkunden die Umgebung, suchen nach Zugangsdaten und eskalieren Rechte – dieser Prozess dauert im Median Stunden bis Tage. Genau dieses Zeitfenster ist das entscheidende: Wer einen Angreifer in dieser Phase erkennt, kann den Schaden begrenzen oder vollständig verhindern.

Honeypots nutzen dieses Fenster systematisch. Es handelt sich um absichtlich attraktive Köder – Systeme, Dateien oder Credentials, die keinen legitimen Betrieb kennen und daher bei jeder Interaktion einen Alarm auslösen. Im Gegensatz zu signaturbasierten Antiviren-Lösungen erzeugen Honeypots nahezu keine Fehlalarme: Wer eine Fake-SQL-Datenbank anspricht, hat sich im Netzwerk bereits unzulässig bewegt.

Für KMU ohne dediziertes Security-Team ist das besonders wertvoll. Kein SIEM der Welt kann den Unterschied zwischen einem legitimen Admin-Zugriff auf einen Datenbankserver und einem Angreifer zuverlässig erkennen – ein Honeypot-Datenbankserver hingegen schon. Jeder Kontakt ist ein Alarm, ohne Schwellenwert-Tuning und ohne Signaturdatenbank.

Canarytokens: Fallen ohne eigene Infrastruktur

Das Konzept

Canarytokens (canarytokens.org) sind leichtgewichtige Token, die bei Zugriff oder Aktivierung einen HTTP-Callback auslösen. Der Dienst wird von Thinkst Canary betrieben und ist in der Basis-Variante kostenlos. Der Mechanismus ist simpel: Man erzeugt ein Token, bettet es in einen Kontext ein, der für einen Angreifer attraktiv aussieht – und wartet. Sobald das Token aktiviert wird, erhält man eine E-Mail-Benachrichtigung mit IP-Adresse, User-Agent und Zeitstempel.

Das klingt trivial, ist in der Praxis aber außerordentlich wirkungsvoll – gerade weil legitime Nutzer die Token nie sehen oder aktivieren sollten.

Welche Token-Typen es gibt

Canarytokens unterstützt eine Vielzahl von Formaten:

• Word-Dokument – Eine präparierte .docx-Datei, die beim Öffnen einen HTTP-Request absetzt. Eignet sich als gefälschtes Passwortliste.docx oder Gehaltsübersicht_2026.docx auf einem Fileserver.
• DNS-Token – Eine Subdomain, die bei DNS-Lookup einen Alarm auslöst. Nützlich in Konfigurationsdateien oder als Fake-Datenbankhost.
• AWS-API-Key – Gefälschte AWS-Zugangsdaten, die bei Verwendung sofort einen Alert erzeugen.
• WireGuard-Config – Eine Fake-VPN-Konfiguration, die bei Verbindungsversuch alarmiert.
• SQL-Server-Verbindungsstring – Eine Datenbankverbindung, die bei Kontakt einen Alert auslöst.
• Microsoft Excel mit versteckter Formel – Für Office-Umgebungen, in denen externe Verbindungen aus Dokumenten erlaubt sind.

Praktisches Deployment-Beispiel

Ein sinnvolles Setup für ein mittelständisches Unternehmen mit Windows-Fileserver:

1. Zwei Token-Typen erstellen: Word-Dokument und DNS-Token
2. Datei benennen: Zugangsdaten_IT_intern_VERTRAULICH.docx
3. Datei auf dem Fileserver in einem Ordner ablegen, der für normale Mitarbeiter nicht erreichbar, für einen Angreifer mit Domain-User-Rechten jedoch sichtbar ist
4. DNS-Token als Hostnamen in einer alten web.config oder .env-Datei im Webserver-Verzeichnis hinterlegen

Sobald ein Angreifer diese Dateien öffnet oder die DNS-Adresse auflöst, geht der Alert raus. Kein Mitarbeiter hat einen legitimen Grund, diese Dateien anzufassen.

# Beispiel-DNS-Token-Eintrag in einer .env-Datei
DB_HOST=prod-legacy-db.xyz123abc.canarytokens.com
DB_PORT=5432
DB_USER=svc_backup
DB_PASS=Backup2024!

Für einen Angreifer sieht das wie ein vergessenes Backup-Script aus. Der erste DNS-Lookup auf den Hostnamen liefert sofort einen Alert – mit der auflösenden IP-Adresse.

Alerting konfigurieren

Canarytokens unterstützt neben E-Mail auch Webhooks. Damit lassen sich Alerts direkt in Microsoft Teams, Slack oder – noch besser – in eine SIEM-Plattform wie Wazuh leiten. Der Webhook-Payload enthält alle relevanten Felder:

{
  "manage_url": "https://canarytokens.org/manage?token=...",
  "memo": "Fileserver - Zugangsdaten Fake",
  "time": "2026-07-23T10:42:01Z",
  "src_ip": "10.0.3.42",
  "input_channel": "DNS",
  "geo_info": {
    "ip": "10.0.3.42",
    "loc": "DE"
  }
}

In Wazuh lässt sich ein Custom-Decoder schreiben, der diesen Payload parst und eine High-Severity-Regel auslöst.

T-Pot: Vollständige Honeypot-Plattform für tiefere Analyse

Was T-Pot ist

T-Pot ist eine von der Deutschen Telekom Security GmbH entwickelte und als Open-Source veröffentlichte Honeypot-Plattform. Sie bündelt über 20 verschiedene Honeypot-Dienste in einem Docker-Compose-Stack und visualisiert alle Angriffe in einem Kibana-Dashboard. Für KMU, die mehr als token-basierte Fallen wollen, bietet T-Pot einen vollständigen Einblick in Angriffsversuche auf Netzwerkebene.

Installation und Systemanforderungen

T-Pot läuft auf Ubuntu Server 22.04 LTS oder Debian 12. Die Systemanforderungen sind moderat:

• 8–16 GB RAM (je nach aktivierten Honeypots)
• 4 CPU-Kerne
• 128 GB SSD
• Dedizierte IP-Adresse, idealerweise im DMZ-Segment oder eigenem VLAN

# T-Pot Installation (als root auf frischem Ubuntu 22.04)
git clone https://github.com/telekom-security/tpotce
cd tpotce
sudo ./install.sh --type=user

Nach der Installation sind folgende Honeypot-Dienste aktiv (Auswahl):

Dienst	Simuliert	Port
Cowrie	SSH- und Telnet-Brute-Force	22, 23
Dionaea	Malware-Download-Server	21, 80, 443
Elasticpot	Elasticsearch-API	9200
Heralding	Credential-Harvesting (FTP, SMTP, POP3)	21, 25, 110
Rdpy	RDP-Honeypot	3389
Mailoney	SMTP-Honeypot	25
Honeytrap	Generischer TCP/UDP-Listener	diverse

Was T-Pot sichtbar macht

Intern eingesetzt – etwa in einem VLAN ohne Produktivbetrieb – zeigt T-Pot jeden lateralen Bewegungsversuch im Netzwerk. Sobald ein Angreifer einen Portscanner einsetzt oder versucht, per SSH auf einen unbekannten Host zuzugreifen, landet er im T-Pot. Da legitime Systeme niemals Verbindungen zu dieser IP initiieren, ist jeder eingehende Verbindungsversuch ein Alarm.

Extern eingesetzt – auf einer dedizierten IP im Internet oder in der DMZ – liefert T-Pot außerdem eine realistische Einschätzung des aktuellen Bedrohungsdrucks: Wie viele automatisierte Scanner treffen pro Stunde ein? Welche Exploits werden aktiv versucht? Welche Passwörter werden für SSH-Brute-Force genutzt? Diese Daten eignen sich gut für Threat-Intelligence-Reports an die Geschäftsführung.

Das Kibana-Dashboard von T-Pot visualisiert Angriffe auf einer Weltkarte und zeigt Statistiken nach Honeypot-Typ, Quell-IP und angegriffenem Port.

Interne vs. externe Platzierung

Intern (empfohlen für KMU als Frühwarnsystem):

• T-Pot in einem eigenen VLAN, von dem aus legitimer Traffic niemals ausgeht
• Firewall-Regel: Jeder Traffic zu T-Pot-IPs aus dem internen Netz = sofortiger Alert
• Korrelation mit Wazuh-Events auf echten Systemen möglich

Extern (für Threat-Intelligence und Bedrohungseinschätzung):

• Dedizierte IP, vollständig vom Produktivnetz getrennt
• Ergebnisse fließen in die eigene Risikoeinschätzung ein
• Aussagen über genutzte Exploit-Kits und Brute-Force-Passwortlisten möglich

Rechtliche Aspekte: DSGVO und NIS-2

DSGVO-Konformität

Honeypots erfassen IP-Adressen, Zeitstempel und teilweise eingegebene Zugangsdaten von Angreifern. IP-Adressen gelten unter der DSGVO als personenbezogene Daten, was folgende Anforderungen mit sich bringt:

• Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an IT-Sicherheit) trägt den Einsatz von Honeypots in der Regel. Die Interessenabwägung fällt zugunsten des Betreibers aus, solange die Daten ausschließlich zur Angriffserkennung verwendet werden.
• Zweckbindung: Daten aus Honeypots dürfen nicht für andere Zwecke – etwa Marketing oder HR – verwendet werden.
• Speicherbegrenzung: Rohdaten sollten nach spätestens 30–90 Tagen gelöscht werden, soweit sie nicht für konkrete Incident-Dokumentation benötigt werden.
• VVT-Eintrag: Der Honeypot-Betrieb ist im Verzeichnis der Verarbeitungstätigkeiten zu dokumentieren, inklusive Kategorien der Daten, Zweck und Löschfristen.

NIS-2-Relevanz

Für Unternehmen, die unter NIS-2 fallen (Betreiber wesentlicher oder wichtiger Einrichtungen), schreibt die Richtlinie unter Art. 21 technische Maßnahmen zur Angriffserkennung vor. Intrusion-Detection-Maßnahmen – unter die Honeypots explizit fallen – sind ein anerkanntes Mittel zur Erfüllung dieser Anforderung. Ein dokumentierter Honeypot-Betrieb mit definierten Alerting-Prozessen und Eskalationswegen stärkt die Nachweisbarkeit gegenüber Aufsichtsbehörden erheblich.

Integration in Wazuh

Wer bereits Wazuh als SIEM betreibt, kann Honeypot-Alerts direkt integrieren. Das ermöglicht Korrelation: Wenn eine interne IP zuerst den Canarytoken-Alarm auslöst und kurz darauf versucht, sich auf einem echten System anzumelden, ist das ein kritischer Befund, der sofortige Reaktion erfordert.

Canarytokens-Webhook → Wazuh Custom Integration

# /var/ossec/integrations/custom-canarytokens.py
import sys
import json

alert_file = open(sys.argv[1])
alert = json.load(alert_file)
alert_file.close()

src_ip = alert.get("src_ip", "unknown")
memo = alert.get("memo", "Canarytoken triggered")
channel = alert.get("input_channel", "unknown")
ts = alert.get("time", "")

# Strukturierter Output für Wazuh-Log-Parsing
print(json.dumps({
    "integration": "canarytokens",
    "canary_channel": channel,
    "canary_memo": memo,
    "src_ip": src_ip,
    "timestamp": ts
}))

Ergänzend dazu eine Wazuh-Erkennungsregel:

<rule id="100200" level="12">
  <decoded_as>json</decoded_as>
  <field name="integration">canarytokens</field>
  <description>Canarytoken ausgeloest: $(canary_memo) via $(canary_channel) von $(src_ip)</description>
  <group>honeypot,canary,intrusion_detection,</group>
</rule>

Level 12 entspricht in Wazuh einem kritischen Alert und löst je nach Konfiguration E-Mail, PagerDuty oder SOAR-Playbooks aus.

T-Pot → Wazuh via Filebeat

T-Pot schreibt alle Events in einen lokalen Elasticsearch-Stack. Über Filebeat lassen sich die Logs aus den einzelnen Container-Logpfaden lesen und an den Wazuh-Indexer weiterleiten. Der einfachste Weg: Filebeat-Autodiscover auf den T-Pot-Docker-Containern aktivieren, relevante Module (cowrie, dionaea) konfigurieren und den Wazuh-Indexer als Output eintragen. Damit landen T-Pot-Events direkt neben internen Windows- und Linux-Logs im Wazuh-Dashboard – korrelierbar per IP-Adresse.

Praktische Checkliste zum Einstieg

Für einen strukturierten Start ohne großen Aufwand:

• Canarytokens.org: Drei bis fünf Token erstellen (Word-Dokument, DNS-Token, AWS-Key)
• Token-Dateien auf Fileserver, Webserver und in Backup-Verzeichnissen ablegen – mit verlockenden Dateinamen
• E-Mail-Alerting auf eine überwachte Security-Mailbox konfigurieren
• Webhook auf Wazuh oder Microsoft-Teams-Channel einrichten
• T-Pot auf dediziertem Server oder VM im internen VLAN deployen
• Firewall-Regel: Jeder interne Traffic zu T-Pot-IP = sofortiger Alert
• Wazuh-Custom-Integration für Canarytoken-Webhooks einrichten
• VVT-Eintrag ergänzen, Zweckbindung und Löschfristen dokumentieren
• Monatliches Review der T-Pot-Kibana-Dashboards einplanen

Grenzen des Ansatzes

Honeypots sind kein vollständiger Ersatz für ein SIEM oder EDR. Sie decken nur Bereiche ab, in die ein Angreifer aktiv eingreift. Ein Angreifer, der ausschließlich legitime Accounts missbraucht und nie einen Honeypot berührt, bleibt unsichtbar. Ergänzend braucht es Log-Monitoring auf echten Systemen, Zugriffsprotokollierung in Microsoft 365 und idealerweise EDR auf Endgeräten.

Außerdem: Canarytokens funktionieren nur dann zuverlässig, wenn Mitarbeiter die Dateien nicht aus Versehen öffnen. Benennung und Ablageort müssen so gewählt werden, dass kein legitimer Zugriff erfolgt. Ein kurzes Awareness-Briefing an IT-Mitarbeiter – ohne die konkreten Token-Positionen zu nennen – ist sinnvoll.

Fazit

Honeypots gehören zu den kosteneffizientesten Sicherheitswerkzeugen, die KMU einsetzen können. Canarytokens sind in einer Stunde deployed, T-Pot in einem halben Tag. Beide liefern hochwertige, nahezu falsch-positive-freie Alarme – genau das, was ein kleines IT-Team braucht, das keine Zeit für Alert-Tuning hat.

Wer diesen Ansatz professionalisieren möchte und Honeypot-Alerts in eine kontinuierlich überwachte SIEM-Umgebung einbetten will, findet bei Vyrex Security einen Managed-SIEM/SOC-Dienst auf Wazuh-Basis, der Canarytoken-Webhook-Integration und T-Pot-Anbindung als Bestandteil des Onboardings enthält. Alerts aus Ihren Honeypots landen damit direkt im SOC – mit definierten Eskalationswegen, Incident-Response-Playbooks und einer Dokumentation, die NIS-2-Prüfungen standhält.