Honeypot und Deception Technology - Angreifer friuehzeitig entlarven

Honeypots haben den höchsten Signal-to-Noise-Ratio aller Sicherheitstools: jeder Zugriff auf einen Honeypot ist ein echter Angriff. Kein False Positive möglich - legitime Nutzer berühren Honeypots nie.

Honeypot-Typen und Deployment

Klassifikation nach Interaktionslevel:

Low-Interaction Honeypots:
  → Emulieren bestimmte Services (SSH, HTTP, SMB)
  → Sammeln: Login-Versuche, verwendete Exploits, Angreifer-IPs
  → Risiko: gering (keine echte Shell)
  → Tools: Honeyd, Dionaea, Glastopf
  
  Einsatz:
  → Internet-facing: sammle Angreifer-IPs, Exploit-Versuche
  → Intern: erkennt Netzwerk-Scans (wer scannt Honeypot?)

High-Interaction Honeypots:
  → Vollwertiges System (real oder VM)
  → Angreifer kann wirklich einloggen, Code ausführen
  → Sammelt: komplette TTPs des Angreifers
  → Risiko: Angreifer könnte pivot → Isolierung Pflicht!
  
  Einsatz:
  → Security Research
  → TTP-Sammlung für Threat Intelligence
  → Sehr sorgfaeltig deployen!

Cowrie (SSH/Telnet Honeypot):
  # Docker:
  docker run -p 22:2222/tcp -p 23:2223/tcp cowrie/cowrie

  # Was Cowrie aufzeichnet:
  → Login-Versuche (Username + Passwort)
  → SSH-Key Fingerprints
  → Ausgeführte Befehle (in Fake-Shell)
  → Downloads versucht
  → Laterale Bewegungsversuche

T-Pot (Multi-Honeypot Platform):
  → 20+ Honeypots in einem (Cowrie, Dionaea, Elasticpot, etc.)
  → ELK-Stack: Visualisierung aller Angriffe
  → Threat Map: wo kommen Angriffe her?

Canary Tokens: Deception im Unternehmensnetz

Canary Tokens - einfachste Deception-Massnahme:

Konzept: Tokens/Fallen überall verteilen
  → Kein Angreifer weiss: was ist real, was ist Falle?
  → Kosten: fast null (viele kostenlos!)
  → Signal: 100% False-Positive-frei (wird nie beruehrt!)

Canary Token Typen (canarytokens.org - kostenlos!):

  Web-Token (HTTP):
  → Fake-URL in Dokument: wenn aufgerufen → Alert
  → In Mailbox, Word-Docs, Prasentationen
  → "Vertragsvorlage.docx" enthaelt Token → geöffnet von AMS.exe?

  DNS-Token:
  → Fake-Domain: lookup = Alert
  → In Passwort-Manager gespeichert (als "Backup-Server")
  → Wenn Angreifer Passwort-Manager kopiert und verbindet → ALERT!

  Cloned Website Token:
  → Klon von Login-Seite (fake)
  → Angreifer sieht Login-Seite → gibt Credentials ein → Alert!

  AWS Keys (Fake):
  → Fake AWS Access Key im Code oder Config
  → Jede API-Anfrage mit diesen Keys → sofortiger Alert
  → Wo war der Key gespeichert? Kompromittiert!

  SQL-Server-Token:
  → Fake-DB-Query wenn ausgeführt → Alert
  → In Production-DB als Tabelle/View "customer_exports"

  Active Directory Honey Credentials:
  → Fake-AD-Account: legitime Aussehen, nie benutzt
  → Jeder Login-Versuch = Indicator of Compromise!
  
  # PowerShell: Honey Account erstellen:
  New-ADUser -Name "svc-backup-old" `
    -Description "Legacy Backup Service Account" `
    -AccountPassword (ConvertTo-SecureString "..." -AsPlainText -Force) `
    -Enabled $true `
    -PasswordNeverExpires $true
  
  # Alert: jede Authentifizierung dieses Accounts → SOC-Alert (P1!)
  
  Honey File auf Dateiserver:
  "Vertraulich - Gehälter_alle_Mitarbeiter_2026.xlsx"
  → Canarytokens-Macro: wenn geöffnet → Alert
  → Jedes Öffnen dieser Datei = Indikator für Insider Threat!

Deception Technology: Enterprise-Lösungen

Moderne Deception-Plattformen:

Attivo Networks (SentinelOne ThreatDefend):
  → Automatisches Honeypot-Deployment im Netz
  → Dynamic Deception: Honeypots sehen aus wie echte Systeme
  → AD Deception: Fake AD-Objekte (User, GPOs, Computer)
  → Integration: SIEM, SOAR (automatische Isolation bei Beruehrung)

Illusive Networks (Proofpoint):
  → Fokus: Lateral Movement erkennen
  → Fake Credentials in Memory (wie echte Tokens)
  → Wenn Angreifer Credentials stiehlt und nutzt → Alert!
  → Zero False Positives (Konzept-Vorteil)

Canarytokens.org (kostenlos):
  → 20+ Token-Typen
  → Keine Installation nötig
  → Ideal für: KMU, erste Deception-Schritte
  → Limitation: kein zentrales Management

Eigener Honeypot-Stack:
  T-Pot + Canarytokens + AD Honey Accounts:
  → Kosten: Hardware/VM + Zeit
  → Für: Tech-Unternehmen, Security Teams

Rechtliche Aspekte:
  → Honeypots: in Deutschland erlaubt (eigenes Netz)
  → Angreifer-Daten sammeln: im eigenen Netz unkritisch
  → KEIN "Hacking Back" (illegal!)
  → Datenschutz: IP-Adressen sind personenbezogene Daten → 72h max? Oder berechtigtes Interesse
  → Betriebsrat: bei internem Deployment → Betriebsvereinbarung

Honey-Infrastruktur implementieren

Schritt-für-Schritt Deception-Deployment:

Minimales Setup (Tag 1, kostenlos):
  1. canarytokens.org besuchen
  2. HTTP-Token erstellen → in Dokument einbetten
  3. DNS-Token erstellen → in Passwort-Manager
  4. AWS-Fake-Key → in Test-Repository (public!)
  5. E-Mail-Adresse für Alerts konfigurieren

AD Honey Accounts (Woche 1):
  → 3-5 Fake-Accounts in verschiedenen OUs
  → Namen: legitim klingend (svc-backup, it-admin-old, etc.)
  → Event 4624 (Login-Erfolg): sofortiger P1-Alert!
  → Event 4625 (Login-Fehler): Alert (jemand versucht es)

Netzwerk-Honeypots (Monat 1):
  → VM in jedem VLAN: lauscht auf SSH, RDP, HTTP
  → Alert bei Verbindungsversuch (niemand sollte sich verbinden!)
  → T-Pot: alle Angriffsdaten zentral sammeln

Honey-Datei-Strategie:
  → 10 verlockende Dateinamen (Gehälter, Passwörter, Backups)
  → Canarytokens-Macro eingebettet
  → Auf Dateiserver: in Ordnern die Insider sehen können
  → Normaler Benutzer: braucht diese Dateien NIE
  → Insider/Angreifer: öffnet interessante Dateien

Integration in SOC-Workflow:
  → Alle Canarytoken-Alerts → direkt SIEM-Hochpriorit"at
  → Playbook: Canarytoken ausgelöst → sofort Isolation des Endpoints
  → Post-Incident: welche anderen Systeme wurden beruehrt?