Active Directory Backup Operators, Print Operators, Server Operators Rechteausweitung: Die Gruppen, die niemand prüft

Active Directory Backup Operators, Print Operators, Server Operators Rechteausweitung erklärt

Active Directory Backup Operators, Print Operators, Server Operators Rechteausweitung ist eine Risikoklasse, die die meisten auf Domain Admins fokussierten Reviews nie prüfen, weil keine dieser vier eingebauten Gruppen — Backup Operators, Print Operators, Server Operators oder Account Operators — standardmäßig in Domain Admins oder Enterprise Admins verschachtelt ist. Doch Microsofts eigene Dokumentation führt alle vier als Active-Directory-Sicherheitsgruppen auf, und Microsoft klassifiziert sie separat als geschützte Konten und Gruppen — dieselbe Schutzstufe wie Domain Admins und Schema Admins.

Genau diese Einstufung ist der Hinweis. Die Mitgliedschaft in nur einer dieser vier Gruppen genügt, um vollen Lese-/Schreibzugriff auf jede Datei eines Domain Controllers, Kernel-Codeausführung, Befehlsausführung auf Dienstebene oder domänenweite Kontomanipulation zu erreichen. Keiner dieser Fälle ist eine Fehlkonfiguration oder ein fehlender Patch — sie sind das beabsichtigte Verhalten der Windows-Benutzerrechte, standardmäßig auf eine Gruppe angewendet, der ein Angreifer nur ein einziges Konto hinzufügen muss.

Wie jede Gruppe Domain-Admin-nahe Rechte gewährt

Der Mechanismus ist die GPO Default Domain Controllers Policy, die diesen Gruppen auf jedem DC der Domäne bestimmte Windows-Benutzerrechte zuweist:

Diese Standardwerte sind direkt von Microsoft dokumentiert: Die Richtlinienseite „Back up files and directories" führt Administrators, Backup Operators und Server Operators als Standardinhaber auf Domain Controllern auf, und die Richtlinienseite „Load and unload device drivers" führt Administrators und Print Operators auf. Der Umfang von Account Operators wird in derselben Referenz zu Sicherheitsgruppen beschrieben: Mitglieder können die meisten Kontotypen erstellen und ändern, doch die Gruppe selbst hat standardmäßig keine Mitglieder, und Microsofts Empfehlung lautet, das so zu belassen.

Die Angriffskette: Vier separate Wege hinein

Schritt 1 — Backup Operators zu ntds.dit

SeBackupPrivilege umgeht NTFS-ACLs vollständig, wodurch sich die AD-Datenbank direkt von einem laufenden DC abziehen lässt, ohne je die Domain-Admin-Gruppe zu berühren. Das in mehreren öffentlichen Write-ups dokumentierte Muster — Semperis, Hacking Articles und nhimg.org — nutzt diskshadow.exe, um eine Volume-Schattenkopie zu erstellen, damit die gesperrte Datei ntds.dit kopiert werden kann, und anschließend robocopy (das SeBackupPrivilege respektiert), um die Kopie sowie einen Export des SYSTEM-Registry-Hives vom Rechner abzuziehen:

# diskshadow script (run from an account holding SeBackupPrivilege)
set context persistent nowriters
add volume c: alias cvol
create
expose %cvol% z:
exec "cmd.exe" /c robocopy /b z:\windows\ntds . ntds.dit
exec "cmd.exe" /c reg save hklm\system c:\temp\system.hive

Offline liefern ntds.dit und der SYSTEM-Hive jeden Passwort-Hash der Domäne — ein direkter Weg zu einem Pass-the-Hash-Login als Domain Admin, ganz ohne Exploit und ohne CVE. Das führt zu denselben Geheimnissen, die unser Beitrag ACL-Missbrauch und DCSync für ACL-basierte Pfade behandelt — nur über einen Dateisystem-Bypass statt über ein Replikationsrecht.

Schritt 2 — Print Operators zu SYSTEM über einen geladenen Treiber

SeLoadDriverPrivilege erlaubt es einem Print Operator, einen Kernelmodus-Treiber auf einem Domain Controller zu laden. Wie Tarlogics Recherche zu diesem Recht und mehrere Sammlungen offensiver Security-Notizen (z. B. HackTricks) beschreiben, wird dieses Recht üblicherweise missbraucht, indem ein legitim signierter, aber ausnutzbarer Treiber geladen wird — die Capcom.sys-Technik ist das am besten dokumentierte öffentliche Beispiel —, um beliebigen Code im Kernel-Space als NT AUTHORITY\SYSTEM auszuführen. Von dort aus ist es trivial, das aktuelle Konto zu Domain Admins hinzuzufügen oder ntds.dit direkt zu dumpen. Diese Rechte-Missbrauchsklasse ist Teil einer größeren Kategorie gefährlicher Windows-Benutzerrechte, die unser Beitrag zu gefährlichen Benutzerrechten in Active Directory neben SeDebugPrivilege und SeTcbPrivilege behandelt.

Schritt 3 — Server Operators zur Dienst-Übernahme

Server Operators erben dieselben Sicherungs-/Wiederherstellungsrechte wie Backup Operators, erhalten aber zusätzlich SERVICE_ALL_ACCESS über die meisten Dienste auf einem DC. Hacking Articles' Write-up zur Gruppe beschreibt Schritt für Schritt, wie der Binärpfad eines legitimen Dienstes auf eine vom Angreifer kontrollierte ausführbare Datei umgebogen und der Dienst neu gestartet wird — der Dienst führt die Payload anschließend als SYSTEM aus. Veröffentlichte Recherchen zum Missbrauch von SeRestorePrivilege (üblicherweise über eine Server-Operators-Mitgliedschaft erreicht) zeigen zusätzlich, dass sich damit geschützte Systembinärdateien überschreiben und Dienst-DLLs kapern lassen — zusammen mindestens drei unabhängige Wege von einer einzigen Gruppenmitgliedschaft zu SYSTEM auf einem DC.

Schritt 4 — Account Operators zu stiller Persistenz

Account Operators besitzt kein Betriebssystemrecht, doch seine AD-nativen Rechte sind weitreichend: neue Benutzer anlegen, die Passwörter der meisten Benutzer zurücksetzen und Mitglieder domänenweit zu den meisten Gruppen hinzufügen oder daraus entfernen. Der Cyber-Advisors-Beitrag zu Account Operators beschreibt die Gruppe oft als „einen Schritt von Domain Administrator entfernt" — sie kann Domain Admins, Enterprise Admins oder die anderen geschützten Gruppen nicht direkt antasten (diese sind durch die AdminSDHolder-ACL geschützt), doch sie kann frei Konten anlegen, sich selbst zu jeder nicht geschützten Gruppe mit delegierten Rechten hinzufügen und das Passwort jedes Kontos zurücksetzen, das nicht in einer geschützten Gruppe liegt. Das reicht für dauerhafte, wenig sichtbare Persistenz, ohne je eine Tier-0-Gruppe zu berühren.

🚨 Gefahr: Keine dieser vier Techniken erfordert eine Sicherheitslücken-Offenlegung, eine CVE oder einen fehlenden Patch. Sie sind das beabsichtigte, designbedingte Verhalten der Windows-Benutzerrechte — der einzige „Bug" ist, dass ein Konto Mitglied der Gruppe ist.

Erkennung

Gruppenmitgliedschaftsänderungen und Rechtenutzung werden beide nativ protokolliert — die Lücke besteht fast immer darin, dass niemand darauf achtet.

Korrelieren Sie all dies mit interaktiven oder RDP-Anmeldungen (Event-ID 4624, Anmeldetyp 2 oder 10) dieser vier Gruppen auf einem DC — unter jedem sinnvollen Tiering-Modell sollte keine von ihnen jemals eine solche brauchen. Unser Leitfaden zur Active Directory-Überwachung zu den relevanten Event-IDs behandelt die Audit-Richtlinien-Voraussetzungen für alle oben genannten Ereignisse. Kontinuierliche Enumerationstools wie etc-collector, PingCastle und Purple Knight können nicht-leere Mitgliedschaften dieser Gruppen zudem direkt melden, ohne auf ein Log-Ereignis zu warten.

Remediation

1. Halten Sie alle vier Gruppen leer. Das ist der dokumentierte Standardzustand; behandeln Sie jede Hinzufügung als vorfallwürdige Änderung, nicht als routinemäßige Delegation.
2. Delegieren Sie eng begrenzt statt in eingebaute Gruppen zu verschachteln. Braucht ein Team wirklich das Recht, Benutzerkonten zu erstellen, gewähren Sie es über eine auf eine OU begrenzte ACL-Delegation statt über eine Mitgliedschaft in Account Operators, die per Design domänenweit gilt.
3. Verlagern Sie Backup-Jobs weg von domänenweiten Rechten. Wo das Backup-Produkt es zulässt, verwenden Sie ein dediziertes, auf das jeweilige Backup-Ziel begrenztes Dienstkonto statt eines menschlichen oder gemeinsam genutzten Kontos, das SeBackupPrivilege/SeRestorePrivilege domänenweit über Server/Backup Operators hält.
4. Wenden Sie ein Tiering-Modell an. Kein Tier-1- oder Tier-2-Admin-, Helpdesk- oder Dienstkonto sollte je in eine Tier-0-Gruppe verschachtelt sein — diese vier eingeschlossen. Unser Beitrag Privileged Access Drift zeigt, wie verschachtelte Mitgliedschaften selbst nach einem sauberen Audit zurückschleichen, und unser Leitfaden Active Directory härten zeigt, wo das in eine breitere Absicherungs-Reihenfolge passt.
5. Aktivieren Sie die Audit-Richtlinie und alarmieren Sie darauf. Aktivieren Sie „Audit Sensitive Privilege Use" und „Audit Security Group Management", leiten Sie die Event-IDs 4728/4732/4756/4673 an Ihr SIEM weiter und alarmieren Sie bei jedem Treffer, der eine dieser vier Gruppen-SIDs betrifft.
6. Prüfen Sie regelmäßig nach, nicht nur einmal. Diese vier Gruppen sind genau die Art von Finding, das ein breiterer Review häufiger Active-Directory-Sicherheitsfehlkonfigurationen tendenziell mit zutage fördert — führen Sie die Prüfung als Teil jedes wiederkehrenden Audit-Zyklus durch, nicht als einmalige Bereinigung.

Wie EtcSec das erkennt

Die Checks ACCOUNT_OPERATORS_MEMBER, BACKUP_OPERATORS_MEMBER, PRINT_OPERATORS_MEMBER und SERVER_OPERATORS_MEMBER von EtcSec melden bei jedem AD-Audit jede nicht-leere Mitgliedschaft in diesen vier Gruppen — dieselbe nahezu nulltolerante Baseline, die Microsoft dokumentiert. PRIVILEGE_SEBACKUP_ABUSE und PRIVILEGE_SERESTORE_ABUSE erfassen separat Fälle, in denen SeBackupPrivilege oder SeRestorePrivilege per GPO über die eingebauten Standardwerte hinaus zugewiesen wurde — der andere Weg, wie diese Rechte in die falschen Hände geraten.