Defender for Identity Honeytoken: Köderkonten richtig einsetzen
Ein Defender for Identity Honeytoken ist eine Köder-Entität in Active Directory. Sie wird nicht produktiv genutzt und soll daher bei jeder Nutzung als starkes Signal für verdächtige Aktivität dienen.
- Starkes Detektionssignal: legitime Nutzung ist ausgeschlossen.
- Nutzen entsteht erst mit Monitoring, Workflow und klarer Incident Response.
- Platzierung entscheidet: dort, wo Angreifer nach Privilegien und Credentials suchen.
Richtig umgesetzt senkt das die Zeit bis zur Erkennung und reduziert teure Fehlalarme, weil der Trigger eindeutig ist.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
Ein Defender for Identity Honeytoken ist eine bewusst angelegte Köder-Identität (z. B. ein Account) im Active Directory, die keine legitime Aufgabe hat und daher bei jeder Nutzung einen Alert auslösen soll. Er ist eine Deception- und Detection-Funktion von Microsoft Defender for Identity und kein Ersatz für Härtung, Berechtigungsmanagement oder MFA.
Einleitung
Wenn ein Angreifer im Directory sucht, testet er Namen, Gruppen, Admin-Pfade und Credentials, bevor der eigentliche Angriff sichtbar wird. Genau hier hilft ein defender for identity honeytoken: ein Konto, das nur existiert, um bei Zugriff sofort Alerts zu triggern. Der Mehrwert ist pragmatisch: du bekommst ein frühes, gut interpretierbares Signal, statt erst auf lateral movement, Kerberoasting oder DCSync-Spuren zu warten.
Wofür Honeytoken-Accounts im Defender-for-Identity-Kontext gut sind
Honeytoken-Accounts sind dann am wertvollsten, wenn „normale“ Erkennung zu viel Rauschen produziert oder zu spät kommt. Ein Honeytoken-Trigger ist in der Regel eindeutig, weil das Konto nicht used wird: Jede Authentifizierung, Abfrage oder Zugriffsaktivität ist suspicious und potenziell malicious.
- Früher Hinweis auf Credential-Tests, Reconnaissance und Attack-Pfade in der Domain
- Klare Priorisierung im SOC: ein Alert mit hohem Signal-to-Noise
- Bessere Messbarkeit: Zeit bis Bewertung, Eindämmung und Recovery wird greifbar
Voraussetzungen, Berechtigungen und Lizenz-Realität
Technisch braucht es Microsoft Defender for Identity mit Defender for Identity sensor auf Domain Controllers (oder relevanten Windows Servern im premises Active Directory Umfeld), damit Activity und network Signale zuverlässig erfasst werden. Operativ braucht es Zugriff auf das Microsoft 365 Defender Portal, damit Alerts, Entity-Details und Identity timeline im Incident sauber genutzt werden können.
Bei Permissions gilt: Das Honeytoken darf keine produktiven Privilegien haben, aber es muss für Angreifer plausibel wirken. Vermeide Administrator- oder Default sensitive Active Directory groups Mitgliedschaften. Gib dem Konto keine echten Zugänge zu servers, apps oder management-Funktionen. Für die Konfiguration im Portal müssen passende Defender-/Security-Rollen vorhanden sein; ideal ist ein dediziertes Admin-Konto mit Least Privilege.
Schritt-für-Schritt: Honeytoken-Konto/Entität einrichten
Das Ziel ist eine glaubwürdige Entität, die sauber als Honeytoken markiert ist und deren Trigger getestet wurde, inklusive Workflow bis zur Reaktion.
1) Konto in Active Directory anlegen
- Erstelle einen dedizierten Account in der directory (kein shared Admin, kein gMSA für echte Dienste).
- Wähle einen plausiblen name (z. B. Service- oder Legacy-Anmutung), ohne „honey“/„trap“/„token“ im Namen.
- Setze ein starkes Passwort, schreibe es nirgends hin und stelle sicher, dass der Account nicht für access in Gruppen, cloud apps oder endpoints eingesetzt wird.
2) Honeytoken in Microsoft Defender for Identity markieren
- Öffne im Microsoft 365 Defender Portal den Defender for Identity Bereich und suche die entity (Account).
- Setze den Honeytoken-Status (Deception feature) und add optional einen Tag für die spätere Filterung.
- Prüfe, ob der Account in Defender for Identity korrekt gelistet ist (Identities/Entities) und der Sensor-Datenfluss aktiv ist.
3) Kontrollierter Test
- Trigger: einmalige, kontrollierte Anmeldung oder Abfrage in einer Test-Session (kein automatisches Script im Regelbetrieb).
- Verify: Alert erscheint, enthält Domain/Host/Quelle und lässt sich im Incident nachverfolgen.
- Dokumentiere: Wer bekommt Notifications, wer bestätigt, wer übernimmt Incident Response.
Platzierung und Architektur: Wo Honeytokens sinnvoll sind
Platzierung ist die eigentliche Architektur-Entscheidung. Honeytokens gehören dahin, wo attacks typischerweise Reconnaissance und Privilege-Discovery betreiben: nah an Admin-Strukturen, nicht in Benutzer-OU-Strukturen, die täglich changed werden.
- „Admin-nahe“ OUs oder Namensräume, in denen Angreifer after Administrator-ähnlichen accounts suchen
- Bereiche mit hoher Sensitivität (z. B. Tiering-Modelle), aber ohne produktive Nutzung des Köders
- Umgebungen mit vielen identities, wo detection sonst überfordert wird
Typischer Fehler: Honeytokens werden in Gruppenstrukturen platziert, die per Automation verwaltet werden, und triggern dann regelmäßig. Das zerstört Vertrauen in Alerts microsoft und kostet Zeit.
Monitoring, Alerts, Logging und Incident-Workflow
Ein Honeytoken ist nur so gut wie der Workflow dahinter. Im Microsoft Defender for Identity / Microsoft 365 Defender Kontext sollte ein Trigger automatisch als Incident behandelt werden: triage, scope, contain, eradicate.
- Triage: Quelle, Gerät, Benutzerkontext, Zeitpunkt, parallele alerts in Defender for Endpoint/Defender for Cloud Apps prüfen
- Eindämmung: betroffene Identitäten sperren, Credentials rotieren, verdächtige Sessions beenden
- Aufklärung: Identity timeline auswerten, Domain Controller Logs korrelieren, lateral movement Pfade prüfen
Für Organization und Audit ist Logging wichtig: Ein sauber dokumentierter Ablauf reduziert Aufwand bei internen Reviews und unterstützt Nachweisanforderungen, ohne dass daraus ein reines „Log-Sammeln“ wird.
Mini-Story: Was ein Trigger in der Praxis bedeutet
Ein Team sieht einen Honeytoken-Alert, ausgelöst von einem Gerät im Netzwerksegment der Datei-Server. Die Investigation zeigt: Der Angreifer hatte bereits lokale Admin-Rechte und enumerated Accounts in Active Directory. Durch schnelle Eindämmung (Account-Sperre, Device-Isolation, Credential-Reset) wird die Ausbreitung gestoppt, bevor Domain Admin Pfade genutzt werden.
Wann externe Unterstützung sinnvoll wird
Sinnvoll wird externe Hilfe, wenn Honeytokens zwar eingerichtet werden können, aber Monitoring, Zuständigkeiten und Response im Alltag nicht stabil laufen. Typische Signale sind: unklare Berechtigungen, zu viele false positives, fehlende Ownership für Alerts oder fehlende Integration in den Defender-XDR-Incident-Prozess.
CTA: Erstgespräch
Wenn du Honeytokens als belastbares Signal im Microsoft Security-Stack nutzen willst, braucht es saubere Platzierung, getestete Trigger und einen klaren Incident-Workflow. Vereinbare ein kostenloses Erstgespräch (30 Minuten, remote, kein Verkaufsgespräch, kein Angebot ohne dein OK, Antwort innerhalb von 24h).
Fazit
Ein Defender for Identity Honeytoken ist ein gezielter Köder im Active Directory, der bei jeder Nutzung ein starkes Alarmsignal liefert. Der Nutzen kommt nicht durch das Anlegen des Accounts, sondern durch Platzierung, Monitoring, Logging und einen klaren Response-Prozess. Richtig umgesetzt verkürzt das die Zeit bis zur Erkennung und macht Identitätsangriffe früher und günstiger beherrschbar.
Häufige Fragen
Ist ein Honeytoken ein Sicherheitsrisiko?
Nur wenn er falsch gebaut ist. Ein Honeytoken darf keine produktiven Rechte, Gruppenmitgliedschaften oder Zugänge haben. Dann ist er primär eine Entität zur detection, nicht ein zusätzlicher Angriffshebel.
Wie lange dauert die Implementierung?
Das Anlegen eines Accounts geht schnell, aber der entscheidende Teil ist der Workflow: Alerts, Verantwortlichkeiten, Notifications und ein getesteter Incident-Response-Prozess. Plane dafür bewusst Zeit ein, sonst bleibt es eine „Karteileiche“ im Directory.
Wie messe ich den Erfolg von Honeytokens?
Über operative Kennzahlen: Zeit bis zur bestätigten Bewertung eines Alerts, Zeit bis Eindämmung, Anzahl plausibler Trigger vs. Fehltrigger und Qualität der Korrelation mit weiteren Signalen im Microsoft 365 Defender Portal.
Brauche ich Microsoft Sentinel dafür?
Nein, Honeytoken-Alerts funktionieren im Microsoft Defender for Identity Umfeld. Sentinel kann helfen, wenn du zentrale Korrelation, langfristige Aufbewahrung und workflows über mehrere Quellen brauchst, ist aber keine technische Voraussetzung.
