Active Directory Auditrichtlinien-Konfigurationsluecken: Die Kategorien, die niemand aktiviert, bevor die Logs gebraucht werden

Was sind Active Directory Auditrichtlinien-Konfigurationsluecken

Die meisten Active-Directory-Teams gehen davon aus, dass die Umgebung „auditiert" wird, sobald sich das Security-Eventlog füllt. Das stimmt nicht – zumindest nicht in der Weise, die für die Erkennung eines Angriffs zählt. Active Directory Auditrichtlinien-Konfigurationsluecken sind die Unterkategorien, die Windows standardmäßig deaktiviert, nur halb konfiguriert oder stillschweigend überschreiben lässt – sodass die Ereignisse, die ein Ermittler später bräuchte, gar nicht erst entstehen. Windows organisiert das Logging über eine Advanced Audit Policy Configuration mit 10 Kategorien, die in Dutzende Unterkategorien unterteilt sind – erweitert von ursprünglich 9 Basiskategorien auf 53 granulare Unterkategorien seit Windows Vista und Windows Server 2008 (die Zahl ist seither weiter gewachsen, da spätere Windows-Versionen Unterkategorien wie Group Membership und PNP Activity hinzugefügt haben), wie Microsofts eigene Historie der Windows Server Advanced Auditing Policies beschreibt. Jede Unterkategorie ist ein unabhängiger Ein/Aus-Schalter. Bleibt eine davon deaktiviert, existiert jedes Ereignis, das sie erzeugt hätte, schlicht nicht – es gibt kein Log, das man später prüfen könnte, keine Lücke, die bei einer Incident-Review auffällt, nichts.

In der Praxis tauchen in AD-Umgebungen, deren Auditrichtlinie nie bewusst überprüft wurde, immer wieder vier blinde Flecken auf, die direkt den Prüfpunkten unseres Active Directory Security-Audits entsprechen:

• Account Management, das auf den Windows-Standardwerten belassen wird, statt vollständig (Erfolg und Fehlschlag) aktiviert zu sein, sodass Änderungen an Benutzern, Computern und Gruppen teilweise oder vollständig ungeloggt bleiben.
• Account Logon (die Kategorie, die auf Domänencontrollern tatsächlich die Kerberos-Authentifizierung abdeckt) komplett deaktiviert – diese ist selbst auf Servern standardmäßig aus.
• Policy Change, das nicht die Unterkategorien abdeckt, die über das eine von Windows ohnehin geloggte Ereignis hinaus relevant sind.
• Keine Honeypot- oder Decoy-Konten irgendwo im Verzeichnis, sodass kein nahezu false-positive-freier Stolperdraht für Enumeration oder Credential-Missbrauch existiert.

Jede einzelne davon ist für sich genommen klein. Zusammen bedeuten sie, dass genau die Kategorien, die Rechteausweitung, Credential-Missbrauch und das Verwischen von Spuren erkennen würden, am wenigsten wahrscheinlich überhaupt etwas loggen. Diese Lücken reihen sich ein neben die anderen Hardening-Prioritäten aus Active Directory härten: Was zuerst gesperrt werden muss – Auditrichtlinien bekommen selten dieselbe Aufmerksamkeit wie ACLs oder die Tier-0-Isolation, gerade weil ein fehlendes Log sich nicht von selbst bemerkbar macht. Anders als eine gefährliche ACL oder eine übermäßig berechtigte Gruppe erzeugt eine deaktivierte Audit-Unterkategorie kein Artefakt, über das man bei einer Routineprüfung stolpert – die einzige Möglichkeit, sie zu finden, besteht darin, die effektive Richtlinie direkt auf dem Domänencontroller zu prüfen, statt sich auf den GPO-Editor zu verlassen.

Wie die Windows-Auditrichtlinie tatsächlich funktioniert – und wo sie stillschweigend versagt

Microsoft veröffentlicht genau aus diesem Grund eine Baseline-Empfehlungstabelle: Die Standardrichtlinie von Windows Server lässt mehrere identitätsrelevante Unterkategorien deaktiviert, und nur ein Teil der Account-Management-Unterkategorien loggt Fehlschläge im Auslieferungszustand. Zwei Standardwerte stechen speziell für AD hervor:

• Audit Credential Validation (die Unterkategorie unter Account Logon, die NTLM- und Kerberos-Passwortvalidierung steuert) wird sowohl unter Windows Client als auch Windows Server standardmäßig mit No | No ausgeliefert – vollständig deaktiviert. Microsofts eigene Baseline-Empfehlung hebt sie auf Servern (den Domänencontrollern, um die es in diesem Artikel geht) auf Yes | Yes und auf Clients auf Yes | No an; die übrigen drei Account-Logon-Unterkategorien (Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events) haben überhaupt keinen Standardwert.
• Audit Policy Change (unter Policy Change) ist standardmäßig auf Yes | No gesetzt – nur Erfolg. Microsofts Baseline empfiehlt Yes | Yes.

Der zweite Punkt ist wichtig wegen eines Details, das Microsoft direkt am Ereignis selbst dokumentiert: Event ID 4719 („System audit policy was changed") „wird immer geloggt, unabhängig von der Einstellung der Unterkategorie ‚Audit Policy Change'". Das ist beruhigend für das eine Ereignis, das Administratoren meist kennen – aber Authentication Policy Change und Authorization Policy Change sind eigenständige, unabhängig schaltbare Unterkategorien innerhalb derselben Policy-Change-Kategorie, und für sie gilt dieser Freifahrtschein nicht. Sind sie nicht explizit aktiviert, hinterlässt ein Angreifer, der unbemerkt Kerberos-Delegationseinstellungen lockert oder eine Rechtevergabe ändert, keine Spuren.

Die Legacy-vs-Advanced-Override-Falle

Es gibt eine zweite, eher operative Falle – dieselbe Art von Problem wie bei den GPO-Fehlkonfigurationen, die Group Policy in einen Angriffsvektor verwandeln: Selbst wenn ein GPO eine Advanced-Unterkategorie korrekt aktiviert, kann diese Einstellung stillschweigend von der Legacy-9-Kategorien-Lokalen Sicherheitsrichtlinie überschrieben werden, sofern die Domäne nicht zusätzlich „Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" aktiviert – den Registrierungswert SCENoApplyLegacyAuditPolicy unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa, gemäß Microsofts Dokumentation zu dieser Richtlinie. Wird das übersprungen, kann die GPMC jede Unterkategorie als korrekt konfiguriert anzeigen, während der Domänencontroller stillschweigend weiterhin die alte kategorienbasierte Richtlinie anwendet.

Dieser Beitrag behandelt bewusst nur die Frage, ob diese Kategorien überhaupt eingeschaltet sind. Was zu tun ist, sobald sie es sind – welche konkreten Event-IDs man alarmieren sollte und wie man die Erkennungslogik aufbaut – behandelt Active Directory Monitoring: Die Security-Event-IDs, auf die es ankommt.

Erkennung: Prüfen, was tatsächlich aktiviert ist – nicht, was das GPO behauptet

Die effektive Richtlinie mit auditpol prüfen

Verlassen Sie sich nicht allein auf die Group Policy Management Console. Führen Sie auditpol direkt auf einem Domänencontroller aus, um die effektive Richtlinie zu sehen:

# Vollständige effektive Auditrichtlinie auf diesem DC
auditpol /get /category:*

# Nur die Kategorien, um die es in diesem Artikel geht
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Policy Change"

# Prüfen, ob die Legacy-Override-GPO-Einstellung tatsächlich gegriffen hat
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

Zeigt eine Unterkategorie „No Auditing" an, werden die Ereignisse aus der folgenden Tabelle auf diesem Rechner nicht generiert – Punkt, nichts, wonach man später suchen könnte:

Warum ein Honeypot-Konto die Lücke schließt

Ein Honey User ist ein Decoy-AD-Konto ohne echte Berechtigung, das so platziert wird, dass Enumeration-Tools (BloodHound, Password-Sprayer, Kerberoasting-Skripte) es finden und wie jedes andere Ziel ausprobieren. Da ein legitimer Benutzer oder Dienst es nie berührt, ist jedes 4768/4769/4624 gegen dieses Konto ein Signal mit nahezu 100 % Konfidenz – das Gegenteil des Alert-Fatigue-Problems, das die anderen drei Kategorien nach der Aktivierung erzeugen können. Effektive Decoys brauchen realistische Metadaten und Platzierung, keinen offensichtlichen Namen wie honeypot-admin-01, gemäß der Deception-Technology-Guidance in diesem Bereich. Dasselbe Prinzip liegt der Erkennung von ACL-Missbrauch und DCSync-Pfaden zugrunde: Eine Replikationsanfrage von einem Konto, das keinerlei Grund hat zu replizieren, ist genau die Art von rauscharmem, hochkonfidentem Signal, für das diese Audit-Kategorien existieren.

Ebenfalls prüfenswert: Angreifer, denen es gelingt, das Logging komplett zu deaktivieren, führen MITRE ATT&CK T1562.002 – Impair Defenses: Disable Windows Event Logging aus, eine Defense-Evasion-Technik, die gezielt die in diesem Artikel behandelte Auditrichtlinie angreift. Eine Umgebung, die diese Kategorien nie aktiviert hat, schenkt dieser Technik einen Erfolg, den sie sonst nicht hätte.

Behebung: Die vier Lücken schließen

Zuerst Account Logon und Account Management korrigieren

1. Account Logon vollständig aktivieren, Erfolg und Fehlschlag, über Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Account Logon: Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events.
2. Account Management auf Microsofts Baseline anheben (Erfolg und Fehlschlag) für User Account Management, Security Group Management, Computer Account Management und Other Account Management Events – nicht nur den Erfolgs-Standard.

Policy Change vervollständigen und das GPO-Override festschreiben

3. Policy Change vervollständigen: Authentication Policy Change und Authorization Policy Change zusätzlich zur bereits teilweise aktiven Unterkategorie Audit Policy Change aktivieren, damit Manipulationen an Kerberos-Richtlinien und Rechtevergaben tatsächlich Ereignisse erzeugen.
4. Das Legacy-Override-GPO setzen („Audit: Force audit policy subcategory settings...") domänenweit, dann die obige auditpol /get-Prüfung nach einem gpupdate /force erneut auf einem DC ausführen – die effektive Richtlinie verifizieren, nicht nur dem GPO-Editor vertrauen.

Ein Decoy-Konto einrichten und auf 4719 alarmieren

5. Mindestens ein Honeypot-Konto pro Domäne einrichten, mit realistischen Attributen und Gruppenzugehörigkeit, und bei jedem Authentifizierungsereignis dagegen alarmieren.
6. Alles Obige an ein SIEM weiterleiten und bedingungslos auf Event ID 4719 alarmieren – Microsofts eigene Empfehlung lautet, jede ungeplante Änderung der Auditrichtlinie als hochprioritären Untersuchungsauslöser zu behandeln, da Angreifer die Protokollierung gezielt deaktivieren, um ohne Beweise zu operieren.

Behandeln Sie dies als wiederkehrende Prüfung, nicht als einmaliges Projekt: Ein Neuaufbau eines Domänencontrollers, ein neues GPO, das die Legacy-Override-Einstellung zurücksetzt, oder eine Migration in einen neuen Forest können jede dieser vier Lücken unbemerkt wieder öffnen – und keine davon wird als Alarm auffallen, sondern erst Monate später als Abwesenheit, in einem Vorfall, bei dem die benötigten Logs nie geschrieben wurden. Diese Prüfung in einen wiederkehrenden AD-Audit-Workflow einzubinden, ist die einzige zuverlässige Möglichkeit, das Abdriften zu erkennen, bevor es zum Problem wird.

Wie EtcSec das erkennt

EtcSec prüft Active-Directory-Group-Policy-Objekte bei jedem Audit gezielt auf genau diese Lücken: AUDIT_POLICY_WEAK markiert Unterkategorien, die unterhalb von Microsofts Baseline liegen, DC_AUDIT_POLICY_INCOMPLETE markiert Domänencontroller, bei denen die effektive Richtlinie nicht mit dem übereinstimmt, was das GPO behauptet, ANSSI_R38_ADVANCED_AUDIT_NOT_ENABLED prüft die Konformität mit der ANSSI-Empfehlung R38 für die Abdeckung durch Advanced Audit Policy, und NO_HONEYPOT_ACCOUNTS markiert Verzeichnisse ohne ein einziges Decoy-Konto im gesamten Scope.