AD Sensitive Privilege Use Audit: Failure plus Success

Was ist AD Sensitive Privilege Use Audit?

AD Sensitive Privilege Use Audit prüft die Sichtbarkeit auf Hostebene: Zeichnet Windows Anforderungen sensibler Privilegien auf jedem Domänencontroller, Mitgliedsserver oder jeder Arbeitsstation im Prüfungsumfang auf? Ein Export der Domänen-GPO kann eine Antwort nahelegen. Um die Prüfung abzuschließen, sind jedoch die vom Zielhost gemeldete Auditrichtlinie und die Ereignisse erforderlich, die Ihre Überwachungsplattform erreichen.

Dieser Leitfaden wurde am 4. Oktober 2026 anhand von Microsoft Learn und dem etc-collector-Quellcode-Commit 20268a321609c193b79c5da6764f3f56950449cb geprüft. Ausgangspunkt ist eine konkrete Einschränkung: Die EtcSec-Kontrolle AUDIT_PRIVILEGE_USE_DISABLED akzeptiert Failure allein. Ein Ergebnis ohne gezählten Befund belegt daher nicht, dass sowohl Success als auch Failure aktiviert sind.

Microsoft empfiehlt beide Ergebnisse für diese Unterkategorie auf Domänencontrollern, Mitgliedsservern und Arbeitsstationen. Success erfasst erfolgreiche Versuche; Failure erfasst erfolglose Versuche. Siehe die Microsoft-Empfehlung zu Sensitive Privilege Use. Prüfen Sie Ihre genehmigte Baseline und dokumentieren Sie Ausnahmen, statt den Produktschwellenwert als vollständige Richtlinienanforderung zu behandeln.

So funktioniert die Überprüfung

Beginnen Sie mit den Rechnern, die Sie abdecken möchten. Listen Sie die Domänencontroller, relevanten Mitgliedsserver und privilegierten Arbeitsstationen zusammen mit dem für die jeweilige Gruppe zuständigen Richtlinienverantwortlichen auf. Eine erfolgreiche Abfrage auf einem DC belegt nicht den Zustand eines anderen DC oder eines Mitgliedsservers. Erfassen Sie bei jedem Ergebnis die Hostidentität und den Beobachtungszeitpunkt.

Den Unterschied zwischen Konfiguration und Hostzustand erläutert unser Leitfaden zum Abgleich der GPO-Auditkonfiguration mit wirksamen Hosteinstellungen. Dieser Artikel behandelt Account Logon, Account Management und Policy Change. Hier betrifft die Entscheidung das Success-Bit von Sensitive Privilege Use und die daraus folgende Telemetrie.

Die Überprüfung umfasst drei Prüfschritte. Identifizieren Sie zunächst die erwartete Baseline und genehmigte Ausnahmen. Fragen Sie anschließend die Systemauditrichtlinie auf dem tatsächlichen Host ab. Gleichen Sie schließlich relevante lokale Ereignisse mit ihren zentralen Kopien ab und prüfen Sie die Felder, die ein Analyst benötigt. Schließen Sie jeden Prüfschritt mit einem eigenen Nachweis ab: Eine genehmigte Ausnahme ersetzt keine fehlgeschlagene Erfassungsprüfung, und ein gefülltes Ereignisprotokoll ersetzt keine Richtlinienabfrage.

Wenn die Nachweise voneinander abweichen, halten Sie diese Abweichung fest. Beispielsweise kann eine erfasste GPO nur Failure enthalten, während ein Host beide Ergebnisse meldet. Der sinnvolle nächste Schritt ist festzustellen, wie dieser Host verwaltet wird und ob sein Zustand dauerhaft ist. Eine GPO nur zu ändern, damit ein Export konsistent aussieht, kann eine berechtigte lokale Einstellung entfernen oder das eigentliche Konfigurationsproblem ungelöst lassen.

Erkennung: Richtlinie auf jedem Host auslesen

Führen Sie die folgende schreibgeschützte Abfrage auf jedem Zielhost mit einem Konto aus, das dessen Auditrichtlinie lesen darf. Diese Befehle verwenden die in Microsofts Referenz zu auditpol get dokumentierte Syntax mit Namen oder GUID. Sie wurden anhand dieser Referenz geprüft, für diesen Artikel jedoch nicht in einer AD-Umgebung ausgeführt.

auditpol /get /subcategory:"Sensitive Privilege Use"

Auf Hosts mit einer anderen Anzeigesprache können Sie die von Microsoft dokumentierte GUID für Sensitive Privilege Use abfragen, die auch der Collector verwendet:

auditpol /get /subcategory:"{0cce9228-69ae-11d9-bed3-505054503030}" /r

Ohne /user fragt auditpol die Systemrichtlinie ab. Bewahren Sie Ausgabe, Host, Zeitstempel, Befehl und etwaige Fehler auf. Ein Berechtigungsfehler ist ein unbekanntes Ergebnis, für das autorisierter Zugriff erforderlich ist; er bedeutet nicht, dass die Richtlinie deaktiviert ist. Untersuchen Sie benutzerspezifische Richtlinien gesondert, wenn sie für ein bestimmtes Konto oder ein unerwartetes Ereignisergebnis relevant sind.

Trennen Sie das Richtlinienergebnis von der Ereignisstichprobe. Alte Ereignisse können eine Richtlinienänderung überdauern. Ein vor der Abfrage beobachtetes Ereignis belegt daher nicht die aktuelle Einstellung. Umgekehrt kann ein ruhiges Beobachtungsfenster keine relevante Operation enthalten. Dokumentieren Sie das Zeitfenster und die erwartete Aktivität, bevor Sie entscheiden, ob fehlende Ereignisse auf ein Erzeugungs- oder Erfassungsproblem hinweisen.

Erkennung: 4673/4674 entlang der Erfassungspipeline validieren

Microsoft dokumentiert 4673 als Aufruf eines privilegierten Dienstes und 4674 als versuchte Operation an einem privilegierten Objekt. Beide können auch zu Non Sensitive Privilege Use gehören. Prüfen Sie den Kontext von Privileg und Operation; die Ereignisnummer allein identifiziert die sensible Unterkategorie nicht.

Verwenden Sie diese lokale Abfrage des Security-Protokolls, um XML zu prüfen. Sie nutzt die Optionen für Abfrage, umgekehrte Reihenfolge und Ausgabeformat aus der Microsoft-Referenz zu wevtutil:

wevtutil qe Security /q:"*[System[(EventID=4673 or EventID=4674)]]" /rd:true /f:xml

Wählen Sie für die zentrale Suche ein begrenztes Beobachtungsfenster, das zu Ihrer Prüfung passt. Ordnen Sie lokale Datensätze ihren empfangenen Kopien anhand von Hostidentität, Zeit, Ereignis-ID und, soweit erhalten, Datensatz-ID zu. Prüfen Sie die Normalisierung von Auditergebnis und Privilegiennamen durch den Connector anhand des ursprünglichen XML, insbesondere wenn die zentrale Ansicht Felder zusammenführt oder leere Werte entfernt.

Der ergänzende Leitfaden zu zentraler Ereigniserfassung und Parservalidierung unterstützt diese Arbeit an Transport und Feldzuordnung. Bewahren Sie ein tatsächlich beobachtetes Beispiel jedes relevanten Ereignistyps auf. Ist ein erforderliches Beispiel nicht verfügbar, dokumentieren Sie den ungeprüften Fall, statt vollständige Abdeckung zu behaupten.

Diese Unterscheidung ist in Microsofts Dokumentation zu 4672 ausdrücklich beschrieben. Verwenden Sie 4672 für den Anmeldekontext und halten Sie die Prüfungen von Erzeugung und Weiterleitung für 4673/4674 getrennt. Bewerten Sie unerwartete Konten, Privilegien und Prozesse anhand genehmigter administrativer Aktivitäten, bevor Sie ein Ereignis als möglichen Missbrauch eskalieren.

Behebung: Failure plus Success nach der Bereitstellung prüfen (Remediation)

1. Verwaltete Unterkategorie korrigieren

Wenn die genehmigte Baseline beide Ergebnisse verlangt, konfigurieren Sie Audit Sensitive Privilege Use unter Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use. Wählen Sie Success plus Failure in der GPO oder dem Konfigurationssystem, das die Zielgruppe tatsächlich verwaltet.

Dokumentieren Sie den Änderungsverantwortlichen, die Zielhosts, die Ausnahmeliste, die vorherige Konfiguration und die Rollback-Entscheidung. Erproben Sie die Änderung auf repräsentativen Rechnern, bevor Sie sie auf den übrigen Umfang ausweiten. Die Einführung sollte der ermittelten Hostgruppe und Verwaltungsgrenze folgen, statt anzunehmen, dass alle relevanten Computer von derselben Standardrichtlinie gesteuert werden.

2. Vorrang gegenüber der alten Richtlinie prüfen und Hostzustand erneut auslesen

Prüfen Sie Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Microsoft empfiehlt, diese Einstellung aktiviert zu lassen, und dokumentiert SCENoApplyLegacyAuditPolicy als Mechanismus, der die Anwendung von Richtlinien auf Kategorieebene verhindert. Ziehen Sie die Microsoft-Referenz zum Vorrang gegenüber der alten Richtlinie heran, wenn Sie grundlegende und erweiterte Auditeinstellungen abgleichen.

Nachdem die verwaltete Änderung jeden Host erreicht hat, wiederholen Sie die oben gezeigte GUID-basierte auditpol-Abfrage. Vergleichen Sie die Ausgaben vor und nach der Änderung. Weicht ein Host weiterhin ab, untersuchen Sie die zuständige Verwaltungsquelle und die Richtlinienverarbeitung. Erklären Sie die Behebung nicht allein anhand des GPO-Editors für abgeschlossen.

3. Backup/Restore als gesonderte Entscheidung behandeln

Das Audit der Nutzung von Backup- und Restore-Privilegien hängt zusätzlich von Audit: Audit the use of Backup and Restore privilege ab. Microsoft rät davon ab, diese gesonderte Einstellung zu aktivieren, da sie erhebliche Ereignismengen erzeugen kann. Aktivieren Sie sie nicht überall als Abkürzung zum Abschluss dieser Prüfung. Erfassen Sie bei jeder Ausnahme von dieser Empfehlung die erforderliche Sichtbarkeit, Arbeitslast, betriebliche Kapazität und Entscheidung des Verantwortlichen.

4. Übermittlung vor dem Prüfungsabschluss bestätigen

Prüfen Sie nach der Bereitstellung erneut die lokale Erzeugung und zentrale Auswertung mit genehmigten, kontrollierten Aktivitäten, die zum vorgesehenen Privileg passen. Vereinbaren Sie vor dem Test mit dem Überwachungsverantwortlichen das erwartete Ereignis. Eine allgemeine administrative Aktion garantiert nicht, dass beide Ereignis-IDs oder beide Ergebnisse erscheinen.

Wenn lokale Ereignisse vorhanden sind, zentrale Kopien aber fehlen, untersuchen Sie das Weiterleitungsabonnement, Agentfilter, Ingestionsfehler und die Parserkonfiguration. Fehlen lokale Ereignisse, prüfen Sie zuerst die Operation, Auditeinstellung und das Beobachtungsfenster. Dies sind verschiedene Fehler mit unterschiedlichen Verantwortlichen. Legen Sie für ungelöste Fälle einen Folgetermin fest und prüfen Sie erneut nach dem Neuaufsetzen von Hosts oder Änderungen an der verwaltenden Richtlinie.

So erkennt EtcSec dieses Problem

Im hier geprüften Quellcode-Commit liest AUDIT_PRIVILEGE_USE_DISABLED den Wert über advancedAuditLevel. Diese Hilfsfunktion verwendet eine ausgewählte GPO-Map für erweitertes Audit oder greift auf alte EventAudit-Daten zurück. Bei einem bekannten Wert unter 2 erzeugt der Detektor einen Befund der Stufe Medium mit Count 1. Wert 2 bedeutet nur Failure, Wert 3 bedeutet Success plus Failure: Beide erfüllen seinen Schwellenwert. Dieser Detektor verlangt Success nicht.

Wenn keine der ausgewählten Quellen die Einstellung liefert, gibt ok=false Count 0 zurück, behält die initialisierte Schwere Medium bei und enthält Details, die erklären, dass die Einstellung nicht per GPO konfiguriert ist. Die wirksame Hostrichtlinie bleibt unbekannt. Dies ist kein Nachweis für Compliance oder deaktiviertes Audit.

Die Quellenauswahl hat weitere Einschränkungen:

• Die Auswahl für erweitertes Audit bevorzugt Default Domain Controllers Policy, dann Default Domain Policy und anschließend den ersten verfügbaren Map-Eintrag. Die Auswahl für das alte EventAudit bevorzugt Default Domain Policy, dann Default Domain Controllers Policy und anschließend den ersten verfügbaren Eintrag. Diese Prioritäten unterscheiden sich.
• Eine fehlende Unterkategorie in der ausgewählten erweiterten Map löst keine Suche in anderen erweiterten Maps aus. Stattdessen kann die Hilfsfunktion auf die ausgewählte alte Kategorie zurückgreifen.
• Der SMB-Provider ignoriert beim Erfassen der Richtlinien Fehler beim Lesen von GptTmpl.inf und audit.csv. Ein EventAudit-Abschnitt, der ein anderes Feld enthält, kann das fehlende Feld Privilege Use bei seinem Nullwert belassen.
• Der Parser für audit.csv extrahiert GUID/Wert-Paare. Er bestätigt weder, dass eine Richtlinie auf einen Host angewendet wurde, noch bewahrt er einen vollständigen Herkunftsnachweis ihrer Anwendung auf.

Dieser Ablauf berechnet nicht Windows Resultant Set of Policy und berücksichtigt SCENoApplyLegacyAuditPolicy nicht vollständig. Er belegt auch weder Ereigniserzeugung noch Weiterleitung oder Auswertung. Nutzen Sie den Befund, um Untersuchungen zu priorisieren, und schließen Sie die Prüfung anschließend mit der auditpol-Ausgabe jedes Hosts und den Erfassungsnachweisen ab.

Prüfprotokoll

Bewahren Sie die Baseline-Entscheidung, das Hostinventar im Prüfungsumfang, die Richtlinienausgabe jedes Hosts, genehmigte Ausnahmen, den Vorher-Nachher-Vergleich und lokale mit zentralen Ereignissen abgeglichene Stichproben auf. Weisen Sie jedem unbekannten Ergebnis einen Verantwortlichen zu. Die Prüfung ist abgeschlossen, wenn jeder Host im Umfang ein dokumentiertes Ergebnis hat und die erforderliche Telemetrie überprüft wurde, wobei jede verbleibende Ausnahme ausdrücklich von ihrem Verantwortlichen akzeptiert wurde.