AD-Auditing und Erkennung: Richtlinie und Ereignis-IDs

Eine gehärtete Konfiguration verkleinert die Angriffsfläche, macht Angriffe auf Active Directory aber nicht unmöglich – sie macht sie schwieriger und lauter. Lauter nützt jedoch nur, wenn jemand oder etwas zuhört. Die meisten AD-Kompromittierungen, die bis zur vollständigen Domänenkontrolle gelangen, gelingen nicht, weil eine Erkennung technisch unmöglich gewesen wäre, sondern weil die nötige Überwachungsrichtlinie, die SACLs und die Protokoll-Pipeline nie eingeschaltet wurden. Dieser Beitrag behandelt die konkrete Konfiguration der erweiterten Überwachungsrichtlinie, die relevanten Ereignis-IDs, SACLs auf sensiblen Objekten und die Sammel-Pipeline (WEF, Defender for Identity, Honeytokens), um von „Wir haben Protokolle“ zu „Wir würden es bemerken“ zu kommen.

Erweiterte Überwachungsrichtlinie per GPO konfigurieren

Die herkömmliche Überwachungsrichtlinie (die neun Basiskategorien) ist zu grob. Verwenden Sie Advanced Audit Policy Configuration (erweiterte Überwachungsrichtlinienkonfiguration), angewendet über eine GPO, die mit der OU Domain Controllers verknüpft ist:

Gruppenrichtlinienpfad: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

Aktivieren Sie diese Unterkategorien (Erfolg und Fehler, sofern nicht anders angegeben):

Anwenden und überprüfen:

# GPO anwenden, dann die effektiven Einstellungen auf einem DC bestätigen
auditpol /get /category:*

# Eine bestimmte Unterkategorie prüfen
auditpol /get /subcategory:"Directory Service Access"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

Zeigt auditpol nach einer GPO-Aktualisierung „No Auditing“ an, prüfen Sie, ob die Überwachungseinstellungen unter Local Policies die erweiterte Überwachungsrichtlinie überschreiben – die Vermischung von herkömmlicher und erweiterter Überwachungsrichtlinie auf demselben Computer verursacht genau das. Setzen Sie Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings auf Enabled.

Die wichtigsten Ereignis-IDs

Die Erkennung von DCSync verdient besondere Aufmerksamkeit: Sie erscheint nicht als eigenes „DCSync“-Ereignis. Sie erscheint als Ereignis 4662 mit den beiden oben genannten Replikations-GUIDs, ausgelöst von einem Sicherheitsprinzipal, der kein Computerkonto eines Domänencontrollers und kein ausgewiesenes Replikationsdienstkonto ist. Jeder andere Prinzipal, der diese erweiterten Rechte ausübt, ist ein starkes Indiz dafür, dass gestohlene Anmeldeinformationen genutzt werden, um sich als Domänencontroller auszugeben.

SACLs auf sensiblen Objekten

Die Ereignisse 4662 und 5136 werden nur ausgelöst, wenn auf dem Objekt eine System Access Control List (SACL) konfiguriert ist. Wenden Sie SACLs – nicht nur die Überwachungsrichtlinie – an auf:

• das Domänenobjekt selbst (DC=domain,DC=com) – für die Erkennung von DCSync erforderlich, da Replikationsrechte am Domänenstamm ausgewertet werden.
• AdminSDHolder (CN=AdminSDHolder,CN=System,DC=domain,DC=com).
• privilegierte Gruppen: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators.
• das Konto krbtgt.
• GPOs, die mit der OU Domain Controllers und allen Tier-0-OUs verknüpft sind.

Konfigurieren Sie dies über Advanced Security Settings > Auditing am Objekt oder per PowerShell:

$path = "AD:\DC=domain,DC=com"
$acl = Get-Acl $path
$sacl = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0",   # Jeder – später im SIEM filtern
    "WriteProperty,ExtendedRight",
    "Success",
    [guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"                # DS-Replication-Get-Changes
)
$acl.AddAuditRule($sacl)
Set-Acl -Path $path -AclObject $acl

Prüfen Sie, ob die SACLs vorhanden sind:

(Get-Acl "AD:\DC=domain,DC=com").Audit | Format-Table IdentityReference, ActiveDirectoryRights, AuditFlags

Windows Event Forwarding an einen Collector

Die lokalen Ereignisprotokolle eines Domänencontrollers sind kein dauerhafter Beweis – ein Angreifer mit Domain-Admin-Rechten kann sie löschen, und die Protokolle eines einzelnen DCs liefern ein unvollständiges Bild. Leiten Sie sie an einen zentralen Collector weiter:

1. Auf dem Collector: wecutil qc, um den Dienst Windows Event Collector zu konfigurieren.
2. Erstellen Sie ein Abonnement (quellinitiiert ist bei großer Skalierung am einfachsten) für die oben genannten Überwachungsunterkategorien; verteilen Sie es über einen per GPO gesetzten Registrierungswert SubscriptionManager, der die DCs auf den Collector verweist.
3. Stellen Sie auf den DCs sicher, dass der Dienst Windows Remote Management (WS-Management) läuft und das Konto Network Service (vom Weiterleitungsdienst verwendet) das Security-Protokoll lesen kann: Nehmen Sie NT AUTHORITY\NETWORK SERVICE in die integrierte Gruppe Event Log Readers auf (auf DCs domänenweit) oder erweitern Sie die Zugriffs-SDDL des Security-Kanals per Gruppenrichtlinie.
4. Prüfen Sie die Zustellung:

Get-WinEvent -LogName "ForwardedEvents" -MaxEvents 20 -ComputerName <collector>
wecutil gr <SubscriptionName>

Bewahren Sie weitergeleitete Protokolle an einem Ort auf, an dem die Domänenadministratoren der überwachten Domäne sie nicht löschen können – eine separate Log-Management- oder SIEM-Ebene, idealerweise in einer anderen Vertrauens- bzw. Verwaltungsgrenze als die überwachten DCs.

Microsoft Defender for Identity und Honeytokens

Microsoft Defender for Identity installiert Sensoren auf DCs und AD-FS-Servern und korreliert Netzwerk- und Ereignistelemetrie, um Aufklärung, die Verwendung von Golden Tickets, DCSync und Muster von Lateral Movement zu erkennen, ohne dass Sie jede Erkennungsregel selbst bauen müssen. Es ist eine starke Ergänzung zu – kein Ersatz für – die oben beschriebene Überwachungsrichtlinie und die SACLs, denn Defender for Identity nutzt selbst die lokale ETW- und Überwachungstelemetrie des DCs.

Honeytoken-Konten: Legen Sie Köderkonten ohne legitimen geschäftlichen Zweck an – idealerweise mit einem verlockenden Namen oder SPN, ohne jemals eine Anmeldeaktivität und mit einem plausibel wirkenden (aber ungenutzten) Kennwort – und alarmieren Sie bei jedem Authentifizierungsversuch gegen sie. Defender for Identity unterstützt das Kennzeichnen von Konten als Honeytokens nativ; ohne es alarmieren Sie direkt bei 4768-/4769-/4624-Ereignissen, deren Zielprinzipal das Honeytoken-Konto ist. Ein einziger Treffer ist ein Signal mit hoher Aussagekraft, da kein legitimer Prozess das Konto jemals berühren sollte.

Was dadurch nicht mehr funktioniert

Funktional nichts – Überwachung ist passiv. Die eigentlichen Kosten liegen im Protokollvolumen: Wird die Überwachung von Directory Service Access (4662) breit aktiviert, statt SACLs auf wirklich sensible Objekte zu beschränken, kann das auf ausgelasteten DCs enorme Ereignismengen erzeugen und sowohl die lokale Protokollaufbewahrung als auch Ihren WEF-Collector überlasten. Planen Sie Collector-Speicher und SIEM-Aufnahmekapazität anhand eines Pilots mit einer Teilmenge der DCs, bevor Sie die Überwachungsrichtlinie gesamtstrukturweit ausrollen, und bevorzugen Sie gezielte SACLs gegenüber „alles überwachen“.

Sobald die Erkennung steht, kombinieren Sie sie mit Härtung der Domänencontroller, um einzuschränken, was Angreifer tun können, bevor Sie sie sehen, und mit Objekt- & ACL-Sicherheit, um die Menge der Objekte zu verkleinern, deren Kompromittierung überhaupt so schwer wiegt, dass sie eine SACL benötigen.