Active Directory: Gefährliche Benutzerrechte via GPO SeDebug SeTcb – SeLoadDriver-Rechteausweitung zu SYSTEM

Was ist eine gefährliche Benutzerrechtezuweisung in Active Directory

Eine GPO SeDebug SeTcb oder SeLoadDriver an Nicht-Administratoren zuweisen zu lassen, zählt zu den gefährlichsten stillen Fehlkonfigurationen in Active Directory. Gruppenrichtlinien verteilen nicht nur Software oder Laufwerke — der Bereich Security Settings einer GPO kann auch lokale Benutzerrechte ("Rechte"/"Privileges" im Windows-Zugriffstoken-Modell, zu unterscheiden von Objektberechtigungen) an jedes Sicherheitsprinzipal vergeben, einschließlich Authenticated Users, Domain Users oder einer benutzerdefinierten Gruppe. Wenn der Abschnitt [Privilege Rights] einer GPO ein hochwirksames Recht wie SeDebugPrivilege, SeLoadDriverPrivilege oder SeTcbPrivilege an Konten vergibt, die keine lokalen Administratoren sind, erbt jeder Computer, auf den die GPO angewendet wird, einen direkten, exploit-freien Weg von "beliebiges Domänenkonto" zu SYSTEM. Sicherheitsteams und Auditoren markieren dieses Muster — gefährliche, per GPO vergebene Benutzerrechte — zunehmend als eigenständigen Active-Directory-Befund, getrennt von der bekannteren Fehlkonfiguration "GPO fügt einen Benutzer zu den lokalen Administratoren hinzu".

Dies ist keine Schwachstelle in Windows — es ist ein Fehler bei der Erstellung von Gruppenrichtlinien, meist eingeführt, um einen Monitoring-Agenten, ein Backup-Produkt oder ein Helpdesk-Tool freizuschalten, das legitim erhöhte Rechte benötigt, und dann belassen (oder in unzusammenhängende GPOs kopiert), lange nachdem die ursprüngliche Begründung entfallen ist. GPO-Fehlkonfigurationen zählen zu den häufigeren Wegen, wie Gruppenrichtlinien zum Angriffsvektor werden, gerade weil sie unauffällig sind: Nichts bricht, kein Alarm löst aus, und die GPO wird bei jedem Richtlinien-Refresh weiter angewendet.

Der Wirkungsradius skaliert mit der Verknüpfung der GPO, nicht mit der Begründung der Zuweisung. Eine GPO, die gebaut wurde, um den Monitoring-Agenten eines einzelnen Servers zu reparieren, und dann der Einfachheit halber an einer OU oder am Domänenstamm verknüpft wird, vergibt still dasselbe Recht an jeden Computer unter dieser Verknüpfung — und macht aus einer eng begrenzten, vertretbaren Ausnahme einen domänenweiten Eskalationspfad, den niemand abgesegnet hat, und eine weitere Variante der versteckten Wege gefährlicher Gruppenverschachtelung zu Domain Admin.

GPO SeDebug SeTcb: Warum Active Directory diese Benutzerrechte als gefährlich einstuft

Windows erzwingt über das Zugriffstoken rund drei Dutzend Benutzerrechte. Die meisten sind in den falschen Händen harmlos — "Zeitzone ändern" ist kein Weg zu SYSTEM. Drei von ihnen sind die Ausnahme.

SeDebugPrivilege ("Programme debuggen")

SeDebugPrivilege erlaubt seinem Inhaber, ein Handle auf jeden Prozess oder Thread auf der Maschine zu öffnen und dabei die Zugriffsprüfung zu umgehen, die einen Nicht-Eigentümer sonst daran hindern würde, den Prozess eines anderen Benutzers anzufassen — einschließlich Prozessen, die NT AUTHORITY\SYSTEM gehören. Da LSASS als SYSTEM läuft und zwischengespeichertes Anmeldeinformationsmaterial im Speicher hält, kann ein Konto mit SeDebugPrivilege ein Handle auf LSASS öffnen und verwertbare Anmeldeinformationen daraus dumpen — dieselbe Primitive, auf die sich Tools wie das sekurlsa-Modul von Mimikatz stützen, und dieselbe Primitive hinter Living-off-the-Land-Techniken wie dem Dumpen von LSASS über den MiniDump-Export von comsvcs.dll. Standardmäßig besitzen nur Administratoren dieses Recht.

SeLoadDriverPrivilege ("Gerätetreiber laden und entfernen")

SeLoadDriverPrivilege erlaubt dem Inhaber, über die NtLoadDriver()-API einen Kernel-Modus-Treiber zu laden. Kernel-Treiber laufen ohne Sicherheitsgrenze zum Rest des Betriebssystems, sodass ein Konto mit diesem Recht einen bekannt verwundbaren, signierten Treiber registrieren und laden kann (der Treiber Capcom.sys ist ein gut dokumentiertes Beispiel) und ihn als Primitive nutzt, um Kernel-Speicher zu lesen/schreiben oder beliebigen Code als SYSTEM auszuführen — eine Technik, die gemeinhin BYOVD (Bring Your Own Vulnerable Driver) genannt wird. Dieser Pfad ist selbst gegen Hosts mit moderner EDR relevant, da ein signierter verwundbarer Treiber von Code-Integritätsprüfungen vertraut wird, die unsignierten Code blockieren.

SeTcbPrivilege ("Als Teil des Betriebssystems agieren")

SeTcbPrivilege ist das direkteste der drei Rechte: Es erlaubt dem Inhaber, die normalerweise der Windows Trusted Computing Base vorbehaltenen Authentifizierungs-APIs aufzurufen, was die Impersonation jedes Kontos auf dem System einschließt, SYSTEM eingeschlossen. Ein Angreifer mit diesem Recht muss keine Anmeldeinformationen dumpen oder einen Treiber laden — er kann einen Dienst erstellen, der die vertrauenswürdigen Anmelde-APIs direkt aufruft und SYSTEM unmittelbar imitiert. Auf einem korrekt konfigurierten System sollte kein Nicht-Administrator-Konto jemals SeTcbPrivilege besitzen.

🚨 Gefahr: Alle drei Rechte gelten als kritisch, weil keines davon einen Code-Execution-Exploit erfordert. Vergibt die GPO das Recht, ist die Eskalation eine dokumentierte, unterstützte Nutzung einer Windows-API — kein Bug.

Die Angriffskette: Von der GPO-Fehlkonfiguration zu SYSTEM

Schritt 1 — Die Zuweisung entdecken

Ein Angreifer, der bereits über einen Domänen-Fuß besitzt (ein gephishter Benutzer, ein niedrig privilegiertes Dienstkonto), enumeriert die auf interessante OUs angewendeten GPOs — Domänencontroller, Tier-0-Server, Jump-Hosts — und liest den Abschnitt [Privilege Rights] der GptTmpl.inf jeder GPO in SYSVOL, die standardmäßig jeder authentifizierte Benutzer lesen kann:

# Enumeriert bei jeder GPO den User-Rights-Assignment-Abschnitt für die drei kritischen Rechte
Get-GPO -All | ForEach-Object {
    $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
    $report.GPO.Computer.ExtensionData.Extension.UserRightsAssignment |
        Where-Object { $_.Name -match 'SeDebugPrivilege|SeLoadDriverPrivilege|SeTcbPrivilege' } |
        Select-Object @{n='GPO';e={$report.GPO.Name}}, Name, Member
}

Schritt 2 — Prüfen, ob das Konto betroffen ist

Der Angreifer prüft, ob sein aktuelles Konto — oder eine Gruppe, die er kontrolliert, einschließlich einer breiten Gruppe wie Authenticated Users, falls die GPO so weit gefasst ist — als Mitglied der Zuweisung aufgeführt ist, und mit welchen Computern die GPO verknüpft ist. Eine am Domänenstamm oder an einer OU mit Domänencontrollern verknüpfte GPO macht daraus statt "interessant" ein "domänenbeendendes" Problem.

Schritt 3 — Das Recht bewaffnen

• Mit SeDebugPrivilege: Ein Handle auf lsass.exe öffnen und Anmeldeinformationsmaterial für Offline-Cracking oder Replay dumpen.
• Mit SeLoadDriverPrivilege: Einen verwundbaren signierten Treiber registrieren und laden, dann für eine SYSTEM-Shell ausnutzen.
• Mit SeTcbPrivilege: Die vertrauenswürdigen Anmelde-APIs aufrufen, um SYSTEM direkt zu imitieren — kein Treiber oder Credential-Dump nötig.

Jedes der drei Rechte verwandelt "Domänenbenutzer in dieser OU" in "lokales SYSTEM auf jeder von der GPO berührten Maschine" — was, falls die OU Tier-0-Assets enthält, funktional einem Angriffspfad direkt zu Domain Admin entspricht. Von lokalem SYSTEM auf einem Domänencontroller ist der Angreifer einen Schritt von DCSync-Rechten und dem gesamten Anmeldeinformationssatz der Domäne entfernt.

Erkennung

Active Directory Monitoring deckt das breitere Set an Ereignis-IDs ab, die eine Alarmierung wert sind, wenn Sie Ihre Erkennung über diese drei Rechte hinaus ausbauen möchten. Auch das öffentliche Detection-Rules-Repository von Elastic liefert eine Regel "Group Policy Abuse for Privilege Addition", die auf das AD-Verzeichnisdienst-Änderungsereignis (Ereignis-ID 5136) achtet, das ausgelöst wird, wenn die GUID der Security Client-Side Extension einer GPO angefasst wird — das Signal, dass ihr GptTmpl.inf-Inhalt, einschließlich [Privilege Rights], geändert wurde — und genau diese Klasse hochwirksamer Rechte (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege) markiert — eine nützliche Referenz auch außerhalb von Elastic Security. Unabhängig von der Quelle: Behandeln Sie jeden Treffer als hochkritisch — es gibt keinen legitimen Grund, warum diese drei Rechte durch routinemäßige Richtlinien-Drift ein Nicht-Admin-Konto erreichen sollten.

Behebung

1. Jede GPO inventarisieren, die [Privilege Rights] berührt. Exportieren Sie jede GPO mit Get-GPOReport -All -ReportType Xml und suchen Sie nach UserRightsAssignment-Knoten; gehen Sie nicht davon aus, dass nur "Sicherheitsbaseline"-GPOs diesen Abschnitt berühren.
2. Die drei kritischen Rechte auf Administratoren beschränken. Die CIS-Benchmarks für Windows Server und Windows 11 setzen "Programme debuggen" (SeDebugPrivilege) beide als Baseline-Empfehlung auf ausschließlich Administratoren; wenden Sie denselben Standard auf SeLoadDriverPrivilege und SeTcbPrivilege an, sofern keine spezifische, dokumentierte, befristete Ausnahme vorliegt.
3. Jede Ausnahme zu ihrem Ursprung zurückverfolgen. Wenn ein Monitoring-Agent oder ein Backup-Produkt eines dieser Rechte tatsächlich benötigt, grenzen Sie die GPO auf die kleinstmögliche Sicherheitsgruppe statt einer breiten OU oder Authenticated Users ein und dokumentieren Sie die Ausnahme mit Verantwortlichem und Überprüfungsdatum.
4. Vor dem Rollout in einer isolierten OU testen. Rollen Sie eine verschärfte User-Rights-Assignment-Baseline zunächst in einer Pilot-OU aus — manche Legacy-Agenten versagen laut (und offensichtlich), wenn ein Recht, von dem sie abhängen, entfernt wird, was eine viel günstigere Entdeckung ist, als es in der Produktion herauszufinden.
5. GPO-Änderungen versionieren. Behandeln Sie GptTmpl.inf-Änderungen wie Code-Änderungen — ein GPO-Diff-/Review-Prozess macht aus einer stillen Rechtevergabe eine überprüfbare Änderung statt einer Überraschung.
6. Den Durchlauf regelmäßig wiederholen, nicht nur einmal. GPOs werden im Laufe der Zeit kopiert, geerbt und neu verknüpft, und eine saubere Baseline heute garantiert keine saubere Baseline im nächsten Quartal. Privileged-Access-Drift folgt genau diesem Muster: Rechte schleichen sich zurück, nachdem das ursprüngliche Audit abgeschlossen ist.

Wie EtcSec dies erkennt

Das Active-Directory-Audit von EtcSec prüft bei jeder verknüpften GPO den Abschnitt [Privilege Rights] gegen die drei hier behandelten kritischen Zuweisungen — PRIVILEGE_SEDEBUG_ABUSE, PRIVILEGE_SELOADDRIVER_ABUSE und PRIVILEGE_SETCB_ABUSE — und markiert jede Nicht-Standard-SID, der eines davon außerhalb der eingebauten Administratoren-Gruppe vergeben wurde, mit dem GPO-Namen und der verknüpften OU, sodass der Befund ohne manuellen Get-GPOReport-Durchlauf umsetzbar ist. Die Prüfung läuft automatisch bei jedem geplanten und manuellen AD-Audit mit und benötigt keine zusätzliche Konfiguration durch das Sicherheitsteam.