Deception Technology (Honeypot / Honeynet)

Deception Technology dreht den Spieß um: Statt nur Angriffe zu blockieren, werden Angreifer aktiv getäuscht und beobachtet. Jede Interaktion mit einem Honeypot ist ein hochzuverlässiges Warnsignal - denn legitime Nutzer haben keinen Grund, auf gefälschte Assets zuzugreifen.

Die Grundidee

• Echtes Netzwerk: Server A, Server B, Workstation C (produktiv)
• Mit Deception: zusätzlich Honeypot X, Honeytoken Y, Fake-Credential Z

Verhalten:

• Legitimer Nutzer: greift Server A/B und Workstation C zu → kein Alert
• Angreifer (intern): sucht im Netzwerk → findet Honeypot X → sofortiger Alert

Der entscheidende Vorteil: Null False Positives. Kein Produktivmitarbeiter hat jemals Grund, einen Honeypot zu berühren.

Arten von Deception-Assets

Honeypots (Einzelsysteme)

Low-Interaction Honeypots:

• Simulieren Services (SSH, RDP, SMB, HTTP)
• Hoch skalierbar, geringes Risiko
• Beispiele: Cowrie (SSH), Dionaea (Malware-Samples)

High-Interaction Honeypots:

• Vollständige VMs die echte Systeme simulieren
• Sammeln detaillierte Angriffsdaten
• Gefährlicher - Angreifer könnte ausbrechen

Kontext-Honeypots:

• Fake-Domain-Controller: Angreifer bei Kerberoasting oder DCSync-Versuchen erkennen
• Fake-Datenbank-Server: SQL-Injection-Versuche und Credential-Nutzung erkennen
• Fake-SharePoint/Fileshare: Ransomware-Verteilung, Datenexfiltration erkennen

Honeytokens (Digitale Köder)

Honeytokens sind gefälschte digitale Assets die bei Nutzung alarmieren:

• Fake Credentials: [admin_backup] mit Passwort in einer Passwort-Datei auf dem Server versteckt - funktioniert nicht, aber jeder Login-Versuch löst sofort einen Alert aus
• Fake AWS Keys: AWS_ACCESS_KEY_ID=AKIAIOSFODNN7HONEYTK in Git-Repo oder AWS Config - Benutzung löst CloudTrail-Alert aus (AWS erkennt fake keys)
• Fake API-Tokens in Code: Als auskommentierter Key im alten Code - wenn jemand diesen Key nutzt, ist ein Eindringling im Repo/System
• Microsoft Word-Dokumente: Q4_Confidential_Budget.docx sendet beim Öffnen einen HTTP-Request - wenn ein Angreifer die Datei öffnet, werden IP und Zeitstempel geloggt

Honeynets

Komplette gefälschte Netzwerksegmente:

• Mehrere Honeypots die zusammen ein realistisches Netzwerk bilden
• Angreifer verbringt Zeit im Honeynet - echte Systeme bleiben sicher
• Hochwertige Angriffsdaten für Threat Intelligence

Enterprise Deception Platforms

Anbieter	Ansatz	Besonderheit
Attivo Networks (jetzt SentinelOne)	AD-Deception, Endpoint	Integration mit EDR
Illusive Networks	Credential-Deception	Fake-Credentials überall
Thinkst Canary	Einfache Honeytokens	Sehr günstig, einfach
Cymmetria	Honeypot-Farms	Automatische Verteilung
Acalvio	KI-gesteuerte Deception	Adaptive Decoys

Einfacher Start: Canarytokens

canarytokens.org bietet kostenlose Honeytokens:

Verfügbare Token-Typen:

• Web-Bug (URL): In Dokument eingebettet - öffnen löst Alert aus
• DNS-Token: Alarm bei DNS-Anfrage
• AWS API-Key: Alarm wenn jemand die Keys nutzt
• MS Word-Dokument: Öffnen sendet Benachrichtigung
• QR-Code: Alarm wenn gescannt

Anwendung im Unternehmen:

• Fake AWS Keys in .env-Dateien (die eigentlich nie genutzt werden)
• Confidential_Report.docx auf Fileserver als Falle
• Fake-SSH-Keys in authorized_keys auf wichtigen Servern

Deception in Active Directory

AD ist das häufigste Angriffsziel. Spezifische AD-Honeytokens:

# Fake Admin-Account erstellen (Kerberoasting-Falle)
New-ADUser -Name "svc_backup_legacy" `
           -Description "Legacy backup service account" `
           -PasswordNeverExpires $true
# Account NIE für Produktivzwecke nutzen
# Login-Versuche auf diesen Account → sofortiger Alert

# Fake SPN setzen (Kerberoasting-Köder)
Set-ADUser svc_backup_legacy -ServicePrincipalNames @{Add="cifs/dc01-legacy.corp.local"}
# Kerberoasting gegen diesen SPN → Alert

Operativer Wert

Früherkennung: Angreifer die lateral movement betreiben treffen fast immer auf Honeytokens bevor sie ihr Ziel erreichen.

Threat Intelligence: Welche Credentials probiert der Angreifer? Welche Domains? Welche Tools? → Wertvolle IoCs.

Niedrige Wartung: Im Gegensatz zu SIEM-Regeln sind Honeytokens wartungsarm - einmal platziert, immer aktiv.

Compliance-Argument: NIS2 Art. 21 fordert “Detection und Monitoring” - Deception Technology erfüllt das mit minimalen False Positives.