Zum Inhalt springen

AD-Honeytokens: Honey-Konten, Honey-SPNs und Köder

Honey-Konten, Honey-SPNs, AS-REP-Köder, gefälschte GPP-Kennwörter und lesend überwachte Köderobjekte in AD einrichten und nahezu ohne Fehlalarme darauf alarmieren.

Florian Amette7 Min. Lesezeit

Die meisten AD-Erkennungen sind statistisch: viele 4769-Anforderungen mit RC4, mehr fehlgeschlagene Anmeldungen als üblich, eine Gruppenänderung zu ungewöhnlicher Uhrzeit. Sie müssen feinjustiert werden und erzeugen Fehlalarme, die Analysten beibringen, sie zu ignorieren. Täuschung (Deception) kehrt dieses Modell um. Sie platzieren Objekte, die kein legitimer Benutzer, Dienst oder Skript jemals berührt, und behandeln jede Interaktion damit als Sicherheitsvorfall. Ein gut platziertes Honeytoken macht aus Kerberoasting, AS-REP roasting, Password Spraying und LDAP-Aufklärung nahezu sichere Signale.

Dieser Leitfaden baut fünf Köder: ein Honey-Admin-Konto, einen Honey-SPN, einen für AS-REP roasting anfälligen Köder, ein gefälschtes Kennwort in Gruppenrichtlinieneinstellungen (GPP) und ein lesend überwachtes Köderobjekt. Anschließend behandelt er Alarmierung, Überprüfung und die nötigen Ausnahmen, damit Ihre eigenen Werkzeuge die Köder nicht auslösen. Er setzt voraus, dass die Grundlagen zu Überwachungsrichtlinie und SACLs aus dem Grundlagenleitfaden zu Auditing und Erkennung umgesetzt sind.

Designprinzipien

Ein Köder funktioniert nur, wenn er attraktiv, wirkungslos und überwacht ist:

  • Attraktiv. Er taucht in der Aufzählung auf, die Angreifer ohnehin durchführen: BloodHound-Sammlung, SPN-Auflistung, adminCount=1-Abfragen, SYSVOL-Durchsuchungen. Namen, Beschreibungen und Datumswerte sollten sich in Ihre Namenskonvention einfügen. svc-sql-backup funktioniert. honeypot01 nicht.
  • Wirkungslos. Er gewährt nichts. Keine echten Gruppenmitgliedschaften mit Rechten, keine Delegierung, keine Anmelderechte und ein Kennwort aus 64 oder mehr zufälligen Zeichen, das nirgendwo festgehalten wird.
  • Überwacht. Für jeden Köder gibt es eine Erkennungsregel, die durchgängig getestet wurde, bevor Sie sich darauf verlassen.

Führen Sie ein Register der Köder – mit Name, SID, Zweck, Regel-ID und Verantwortlichem – außerhalb von AD in Ihrer SOC-Dokumentation. Je weniger Personen wissen, welche Konten Köder sind, desto besser. Das schließt die meisten Domänenadministratoren ein.

Messen: was Angreifer heute sehen

Betrachten Sie Ihre Domäne so, wie es Aufklärungswerkzeuge tun, damit die Köder zur Landschaft passen:

PowerShell
# Vorhandene Benutzer-SPNs (was ein Kerberoasting-Werkzeug auflistet)
Get-ADUser -Filter 'servicePrincipalName -like "*"' -Properties servicePrincipalName, pwdLastSet, description |
  Select-Object SamAccountName, @{n='SPN';e={$_.servicePrincipalName -join ';'}},
    @{n='PwdLastSet';e={[datetime]::FromFileTime($_.pwdLastSet)}}, Description

# Konten mit adminCount=1 (was Abfragen nach "privilegierten Konten" auflisten)
Get-ADUser -LDAPFilter '(adminCount=1)' | Select-Object SamAccountName, DistinguishedName

Übernehmen Sie die vorgefundene Benennung, OU-Platzierung und den Beschreibungsstil. Echte für Kerberoasting anfällige Konten sollten behoben und nicht bloß um Köder ergänzt werden. Siehe Schutz vor Kerberoasting.

Die Köder bauen

Legen Sie alle Köder in einer normal aussehenden OU an, nicht in einer eigenen OU namens „Decoys“. Wenden Sie Deny log on locally, Deny log on through Remote Desktop Services und Deny access to this computer from the network auf eine Gruppe an, die sie enthält. Konfigurieren Sie dies über eine GPO unter Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Honey-Admin-Konto

Ein Köder, der wie ein vergessener Administrator aussieht:

PowerShell
# Windows PowerShell 5.1: System.Web ist unter .NET Framework verfügbar
Add-Type -AssemblyName System.Web
function New-DecoyPassword {
  ConvertTo-SecureString ([System.Web.Security.Membership]::GeneratePassword(64,10)) -AsPlainText -Force
}
New-ADUser -Name 'adm-jmorel' -SamAccountName 'adm-jmorel' -Path 'OU=Admins,OU=Corp,DC=corp,DC=example,DC=com' `
  -Description 'Infra admin - legacy' -AccountPassword (New-DecoyPassword) -Enabled $true -AccountNotDelegated $true

Nehmen Sie es in eine Gruppe auf, die wie eine Admin-Gruppe benannt ist, aber keine Rechte besitzt, oder setzen Sie adminCount=1, damit es in Abfragen nach „privilegierten“ Konten erscheint. Fügen Sie es nicht zu Domain Admins oder einer echten Tier-0-Gruppe hinzu. Das würde den Köder zu einem echten Tier-0-Konto machen.

Honey-SPN

Hängen Sie einen plausiblen SPN an ein Köder-Dienstkonto. Jedes 4769 für diesen SPN bedeutet, dass jemand ein Ticket für einen Dienst anfordert, den es nicht gibt:

PowerShell
New-ADUser -Name 'svc-sqlrpt' -SamAccountName 'svc-sqlrpt' -Path 'OU=Service Accounts,OU=Corp,DC=corp,DC=example,DC=com' `
  -AccountPassword (New-DecoyPassword) -Enabled $true -Description 'SQL Reporting Services'
Set-ADUser 'svc-sqlrpt' -ServicePrincipalNames @{ Add = 'MSSQLSvc/sqlrpt01.corp.example.com:1433' }

Stellen Sie sicher, dass kein DNS-Eintrag und kein Host namens sqlrpt01 existiert, damit kein Client versehentlich versucht, ihn zu erreichen.

Für AS-REP roasting anfälliger Köder

AS-REP roasting zielt auf Konten, bei denen Do not require Kerberos preauthentication gesetzt ist. Ein Köder mit diesem Flag erzeugt 4768 mit PreAuthType 0, wenn jemand ihn angreift:

PowerShell
New-ADUser -Name 'svc-scanlegacy' -SamAccountName 'svc-scanlegacy' -Path 'OU=Service Accounts,OU=Corp,DC=corp,DC=example,DC=com' `
  -AccountPassword (New-DecoyPassword) -Enabled $true -Description 'Legacy scanner (Unix)'
Set-ADAccountControl -Identity 'svc-scanlegacy' -DoesNotRequirePreAuth $true

Mit einem zufälligen Kennwort aus 64 Zeichen ist der erbeutete Hash offline nutzlos. Die Anforderung selbst ist der Alarm.

Gefälschtes GPP-Kennwort

Angreifer durchsuchen SYSVOL nach wie vor nach cpassword-Werten. Das Entfernen echter GPP-Kennwörter kommt zuerst. Danach liefert Ihnen eine Köder-Datei Groups.xml in einer nicht verknüpften GPO, deren cpassword zu einem glaubwürdigen, aber falschen Kennwort für das Honey-Admin-Konto entschlüsselt wird, zwei Alarmpunkte:

  1. Ereignis 5145 (Audit Detailed File Share) für den Zugriff auf genau diesen Groups.xml-Pfad in der SYSVOL-Freigabe, sofern Sie das Volumen auf den DCs verkraften.
  2. 4771, 4776 oder 4625, wenn der Angreifer das entschlüsselte Kennwort am Köderkonto ausprobiert.

Verwenden Sie eine GPO, die nirgendwo verknüpft ist, damit kein Client sie jemals verarbeitet. Verwenden Sie kein Kennwortmuster aus Ihrer echten Umgebung wieder.

Lesend überwachtes Köderobjekt

LDAP-Aufklärung wie BloodHound oder ADExplorer liest jedes Objekt. Eine SACL, die Lesezugriffe auf ein einzelnes Köderobjekt überwacht, macht aus diesem Durchlauf ein 4662:

PowerShell
$dn   = 'CN=adm-jmorel,OU=Admins,OU=Corp,DC=corp,DC=example,DC=com'
$acl  = Get-Acl "AD:\$dn"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]'S-1-1-0',
    [System.DirectoryServices.ActiveDirectoryRights]'ReadProperty',
    [System.Security.AccessControl.AuditFlags]'Success')
$acl.AddAuditRule($rule)
Set-Acl -Path "AD:\$dn" -AclObject $acl

Das erfordert DS Access > Audit Directory Service Access (Erfolg) auf den Domänencontrollern. Beschränken Sie die SACL auf dieses eine Objekt. Leseüberwachung auf stark genutzten Objekten flutet das Protokoll. Wie Sie diese Art von Angriffsgraph aus Verteidigersicht lesen, erfahren Sie unter Attack Path Management.

Platzierung und Lebenszyklus

Köder altern wie echte Konten. Ein Dienstkonto, dessen pwdLastSet heute ist und das sich nie angemeldet hat, wirkt platziert. Legen Sie Köder an und lassen Sie sie einige Wochen ruhen, bevor Sie sich auf sie verlassen. Staffeln Sie die Erstellungsdaten und vermeiden Sie es, alle in einer einzigen Änderung anzulegen, die im selben 4720-Schwall auftaucht.

Verteilen Sie Köder auf die Orte, an denen Angreifer suchen: mindestens einen in jeder Domäne der Gesamtstruktur, einen in der OU, in der Ihre echten Admins liegen, und einen zwischen den Dienstkonten. In großen Umgebungen hilft ein Köder pro OU eines größeren Geschäftsbereichs, zu erkennen, aus welchem Teil des Netzwerks die Aufklärung kam, denn das Feld IpAddress in 4768 und 4769 zeigt den Quellhost.

Überprüfen Sie die Köder zweimal im Jahr. Bestätigen Sie, dass sie noch existieren, ihre SACLs und SPNs noch haben und ihre Regeln noch auslösen. Ein Aufräumprojekt für Objekte, das Ihre Köder löscht, ist ein stiller Weg, Abdeckung zu verlieren.

Durchsetzen: Alarmregeln

Schreiben Sie eine Regel pro Köder, verknüpft mit der SID, wo das Ereignis sie enthält, und ansonsten mit dem Namen:

KöderEreignis-IDsBedingung
Honey-Admin4768, 4771, 4776, 4624, 4625TargetUserName entspricht dem Köder
Honey-SPN4769ServiceName entspricht dem Köderkonto
AS-REP-Köder4768TargetUserName entspricht dem Köder (beliebiger PreAuthType)
Gefälschtes GPP5145, 4771, 4776RelativeTargetName endet mit dem Pfad der Köder-GPO, oder das Ziel ist das Köderkonto
Lesend überwachtes Objekt4662ObjectName entspricht der GUID des Köders, AccessMask 0x10 (Eigenschaft lesen)

Eine lokale Prüfung für Tests oder für kleine Umgebungen ohne SIEM:

PowerShell
$decoys = 'adm-jmorel','svc-sqlrpt','svc-scanlegacy'
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4768,4769,4771,4776; StartTime=(Get-Date).AddHours(-1) } |
  Where-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    ($d | Where-Object { $_.Name -in 'TargetUserName','ServiceName' }).'#text' | Where-Object { $_ -in $decoys }
  } | Select-Object TimeCreated, Id, MachineName

Leiten Sie diese Alarme an die Rufbereitschaft weiter, nicht in eine tägliche Prüfwarteschlange. Wenn Sie Microsoft Defender for Identity einsetzen, kennzeichnen Sie jeden Köder zusätzlich unter Settings > Identities > Entity tags > Honeytoken als Honeytoken, damit der Sensor selbst dann einen eigenen Alarm auslöst, wenn Ihre SIEM-Regel versagt. Der Glossareintrag Honeytoken fasst das Konzept für Stakeholder zusammen.

Honey-Konten sind nur so gut wie die Ereignisabdeckung dahinter. Alle obigen Regeln setzen voraus, dass die Ereignisse von jedem DC das SIEM erreichen – genau das leistet Windows Event Forwarding.

Überprüfen

Testen Sie jeden Köder nach einem Änderungsticket von einer normalen, der Domäne beigetretenen Arbeitsstation aus als Standardbenutzer. Warnen Sie vorher das SOC oder führen Sie den Test als geplante Purple-Team-Übung durch:

PowerShell
# Honey-SPN: ein Dienstticket anfordern und dann bestätigen, dass ein 4769 das SIEM erreicht hat
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'MSSQLSvc/sqlrpt01.corp.example.com:1433'
klist

# Honey-Admin: eine fehlgeschlagene Kerberos-Anmeldung erzeugt 4771 auf dem DC
runas /user:CORP\adm-jmorel cmd.exe   # ein falsches Kennwort eingeben

Für das lesend überwachte Objekt öffnen Sie es in Active Directory Users and Computers mit dem Attribut-Editor und bestätigen dann ein 4662 mit Ihrem Benutzer als SubjectUserName. Halten Sie für jeden Köder die durchgängige Latenz von der Aktion bis zur Benachrichtigung fest. Wiederholen Sie den Test vierteljährlich und nach jeder Änderung am SIEM oder Collector.

Was dadurch nicht mehr funktioniert

Köder ändern das Verhalten der Produktion nicht, geraten aber mit legitimen Werkzeugen in Konflikt, die jedes Objekt lesen oder berühren:

  • Entra Connect und andere Synchronisierungsmodule lesen jedes Objekt im Bereich. Legen Sie lesend überwachte Köder in einer OU außerhalb des Synchronisierungsbereichs ab oder schließen Sie das Synchronisierungskonto per SID von der 4662-Regel aus.
  • Bewertungs- und Inventarisierungswerkzeuge (PingCastle, von Ihrem eigenen Team ausgeführte BloodHound-Sammlungen, CMDB-Konnektoren, Defender-for-Identity-Sensoren) lösen Lese-SACLs aus und fordern möglicherweise Diensttickets an. Schließen Sie deren Dienstkonten ausdrücklich aus und dokumentieren Sie die Ausnahme – wohl wissend, dass Angreifer versuchen könnten, sich hinter denselben Konten zu verstecken.
  • Schutz vor Password Spraying und Kontosperrung. Dass ein Köder durch Angreiferaktivität gesperrt wird, ist in Ordnung – stellen Sie aber sicher, dass keine Helpdesk-Automatisierung ihn entsperrt oder sein Kennwort zurücksetzt.
  • Skripte zur Kontobereinigung, die Konten nach 90 Tagen Inaktivität deaktivieren, deaktivieren auch Ihre Köder. Schließen Sie sie im Skript per SID aus, nicht über ein Namensmuster, das ein Angreifer lernen könnte.
  • Auditoren und Penetrationstester werden sie auslösen. Das ist gewollt, aber stimmen Sie den Reaktionsprozess vor dem Auftrag mit ihnen ab.

Weiterführende Lektüre: Die Referenz der AD-Sicherheitsereignis-IDs erklärt jedes oben verwendete Feld, der Schutz vor Kerberoasting beseitigt die echten angreifbaren Konten, zwischen denen die Köder stehen, und der Bereich Auditing, Protokollierung & Erkennung listet die übrigen Beiträge der Serie auf.

Häufige Fragen

Sollte ein Honey-Konto deaktiviert sein?

In der Regel nicht. Ein deaktiviertes Konto fällt in Aufklärungsergebnissen auf, und viele Werkzeuge filtern es heraus, sodass Angreifer es ignorieren. Lassen Sie das Konto aktiviert, mit einem langen, zufälligen Kennwort, das niemand kennt, verweigern Sie ihm über das Zuweisen von Benutzerrechten und Anmeldezeiten die interaktive und die Netzwerkanmeldung, und lassen Sie es plausibel aussehen. Jeder Authentifizierungsversuch, ob erfolgreich oder nicht, erzeugt auf dem Domänencontroller dennoch die Ereignisse 4768, 4771 oder 4776 – und genau darauf alarmieren Sie.

Erkennt ein Honey-SPN jeden Kerberoasting-Versuch?

Nein. Er erwischt Angreifer, die Tickets für jeden SPN der Domäne anfordern – das tun die meisten Werkzeuge standardmäßig. Ein vorsichtiger Angreifer, der gezielt nach SPNs auf privilegierten oder kürzlich genutzten Konten filtert, kann ihn überspringen. Machen Sie den Köder attraktiv – mit einem glaubwürdigen Dienstnamen, einem alten Datum der letzten Kennwortänderung und der Mitgliedschaft in einer Gruppe, die privilegiert aussieht, aber keine Rechte hat – und kombinieren Sie ihn mit einer volumenbasierten Erkennung auf Ereignis 4769.

Ersetzen Honeytokens Microsoft Defender for Identity oder ein SIEM?

Nein, sie setzen auf dem auf, was Ihre DC-Ereignisse sammelt. Defender for Identity kann Konten als Honeytokens kennzeichnen und nativ bei deren Verwendung alarmieren, während ein SIEM eine einfache Regel auf 4768, 4769, 4771, 4776, 4624 oder 4662 für den Namen oder die SID des Köders benötigt. Der Wert von Honeytokens liegt darin, dass die Regel nahezu frei von Fehlalarmen ist – der Alarm kann also jemanden direkt benachrichtigen, statt in einer Warteschlange zu landen.

AD-Honeytokens: Honey-Konten, Honey-SPNs und Köder

Verwandte Leitfäden

Kerberos & Authentifizierung

Abwehr von Kerberoasting und AS-REP-Roasting

Kerberoasting- und AS-REP-Roasting-Angriffsfläche verkleinern: SPNs inventarisieren, veraltete entfernen, auf gMSA und AES umstellen, Honey-SPN und RC4-4769 erkennen.

Grundlagen
Auditing, Protokollierung & Erkennung

Windows Event Forwarding für Domänencontroller

Eine WEF-Pipeline für Domänencontroller aufbauen: quellinitiierte Abonnements, GPO, Protokollzugriff, XPath-Abfragen, Collector-Dimensionierung und Integritätsprüfungen.

Fortgeschritten