Andrea Pierini Senior Sicherheitsberater

Ich habe viele Jahre damit verbracht, zu untersuchen, wie Cyberangreifer Windows-Berechtigungen missbrauchen, um ihre Zugriffsrechte von Konten mit geringen Berechtigungen bis hin zu „NT AUTHORITY\SYSTEM“ zu erweitern. Was als Neugierde hinsichtlich einer Handvoll Primitiven zur Identitätsübernahme begann, entwickelte sich nach und nach zu einem systematischen Katalog von Angriffstechniken, bei denen der Missbrauch von Windows-Berechtigungen im Mittelpunkt steht . Viele dieser Techniken sind auch in modernen, gepatchten Umgebungen nach wie vor relevant.

In diesem Beitrag werde ich Ihnen die aus Sicht eines Angreifers attraktivsten Windows-Berechtigungen vorstellen: jene, die eine direkte Berechtigungserweiterung ermöglichen. Lesen Sie weiter, um mehr zu erfahren:

  • Welche Berechtigungen stellen das größte Risiko für Ihre Umgebung dar?
  • Warum Angreifer es auf diese Berechtigungen abgesehen haben
  • Wie Angreifer diese Berechtigungen missbrauchen können, um lokale SYSTEM-Rechte zu erlangen – oft mit überraschend geringem Aufwand

Wie Windows-Berechtigungen Ihr Cybersicherheitsrisiko erhöhen können

Seit 2018 tausche ich mich mit Fachleuten aus den Bereichen IT und Cybersicherheit über die Gefahren des Missbrauchs von Windows-Berechtigungen aus. Von der klassischen Token-Manipulation bis hin zur „Potato“-Exploit-Familie hat dieses Thema in den letzten zehn Jahren einen Großteil der Forschung zur lokalen Berechtigungsausweitung unter Windows geprägt.

Dennoch ist diese Botschaft nach wie vor von großer Bedeutung. Viele unterschätzen nach wie vor diese Berechtigungen, ihre Funktionsweise und den Umfang der Kontrolle, den sie Angreifern ermöglichen können. Dieses Risiko besteht aus zwei Gründen fort:

  • Berechtigungen sind nicht dasselbe wie Zugriffsrechte. Unternehmen, die ihre ACLs und Delegierungen sorgfältig prüfen, übersehen häufig die Berechtigungen, die nicht privilegierten Benutzerkonten zugewiesen wurden.
  • Microsoft stellt keine Sicherheitspatches für den Missbrauch von Berechtigungen bereit. Der Missbrauch einer Berechtigung, über die Sie rechtmäßig verfügen, stellt keine Verletzung der Sicherheitsgrenzen dar. Die Techniken, die ich in diesem Beitrag beschreibe – einschließlich der „Potato“-Exploits – haben viele Jahre und unzählige Windows-Versionen überstanden, da sie auf Funktionen und nicht auf Fehlern beruhen. Daher müssen Ihre Abwehrmaßnahmen architektonischer Natur sein.

Der Missbrauch von Berechtigungen wird in der Regel mit der lokalen Berechtigungserweiterung (Local Privilege Escalation, LPE) in Verbindung gebracht. Wir alle wissen jedoch, dass eine vollständige Kompromittierung der Domäne oft genau dort beginnt: mit einer lokalen Berechtigungserweiterung, die es einem Angreifer ermöglicht, auf einem einzelnen Rechner die höchste Zugriffsebene zu erlangen. Von diesem Punkt an können Angreifer häufig erweiterte Rechte, Anmeldedaten, Tokens oder andere offengelegte Ressourcen missbrauchen, um sich lateral zu bewegen und ihren Eskalationspfad innerhalb Ihrer Umgebung fortzusetzen.

In gemeinsam genutzten Umgebungen wird dieses Risiko noch kritischer. Denken Sie beispielsweise an einen RDP-Server, einen Jump-Host oder ein beliebiges System, auf das mehrere Benutzer zugreifen. Der Erwerb lokaler Administratorrechte auf einem solchen Rechner kann Folgen haben, die weit über den Host selbst hinausreichen.

Wenn Sie whoami /priv und mehr als nur eine Handvoll Beiträge sehen möchten, ist dieser Blog genau das Richtige für Sie.


Was sind Windows-Berechtigungen?

Microsoft definiert eine Berechtigung als„das Recht eines Kontos, beispielsweise eines Benutzer- oder Gruppenkontos, verschiedene systembezogene Vorgänge auf dem lokalen Computer auszuführen, wie beispielsweise das Herunterfahren des Systems, das Laden von Gerätetreibern oder das Ändern der Systemzeit.“

In der Praxis stellen Privilegien einen Mechanismus dar, der das traditionelle, auf ACLs basierende Berechtigungsmodell ergänzt und manchmal sogar außer Kraft setzt. Aus sicherheitstechnischer Sicht ist es wichtig, einige Punkte zu verstehen:

  • Berechtigungen werden über Zuweisung von Benutzerrechten im Policy für lokale oder Policy (Abbildung 1). Sie lassen sich jedoch auch programmgesteuert über die Windows-API verwalten, und zwar mithilfe von Funktionen wie LsaOpenPolicy() und LsaAddAccountRights().
Zuweisung von Benutzerrechten (Berechtigungen) über den GPO-Editor
Abbildung 1. Zuweisung von Benutzerrechten (Berechtigungen) über den GPO-Editor
  • Berechtigungen können aktiviert oder deaktiviert werden. Eine Standardberechtigung ist eine Berechtigung, die automatisch aktiviert wird, sobald das System feststellt, dass sie benötigt wird.
  • Bestimmte Berechtigungen setzen Objektberechtigungen (ACLs) ausdrücklich außer Kraft. Dies ist die Hauptursache für die meisten der hier behandelten Missbräuche.
  • Die meisten Berechtigungen sind nur innerhalb eines Prozesses mit hoher Integritätsstufe (IL) zugänglich, was bedeutet, dass für ihre Nutzung eine Shell mit erweiterten Rechten erforderlich ist. Sobald Sie jedoch über diese Shell mit erweiterten Rechten verfügen, können Sie die Berechtigungen nach Belieben missbrauchen.
  • Der mit Abstand wichtigste Befehl in dieser Forschungsarbeit lautet whoami /priv, das alle dem aktuellen Token zugewiesenen Berechtigungen zusammen mit deren Aktivierungs- bzw. Deaktivierungsstatus anzeigt. Eine aktivierte Berechtigung ist einsatzbereit. Eine deaktivierte Berechtigung erfordert lediglich einen API-Aufruf, um AdjustTokenPrivileges() um diese Funktion zu aktivieren, sofern sie nicht als Standardberechtigung gilt.

Was sind Windows-Zugriffstoken?

Um den Missbrauch von Berechtigungen zu verstehen, müssen Sie zunächst wissen, was Zugriffstoken sind. Dabei handelt es sich um Objekte, mit denen Windows den Sicherheitskontext eines Prozesses oder Threads darstellt (Abbildung 2).

Aufbau des Windows-Zugriffstokens
Abbildung 2. Aufbau eines Windows-Zugriffstokens

Ein System erstellt während des Anmeldevorgangs über NtCreateToken(). Dieses Token wird dann immer dann verwendet, wenn ein Prozess oder Thread versucht, mit einem schützbaren Objekt zu interagieren. Wenn ein neuer Prozess oder Thread gestartet wird, wird ihm eine Kopie des Tokens des übergeordneten Prozesses bzw. Threads zugewiesen.

Ein Token enthält unter anderem:

  • Die SID des Benutzers und des Eigentümers
  • SIDs für jede Gruppe, der der Benutzer angehört
  • Die Anmelde-SID
  • Die DACL, die angewendet wird, wenn der Benutzer sicherheitsrelevante Objekte erstellt, ohne einen Sicherheitsdeskriptor anzugeben
  • Der Token-Typ (primär oder Identitätsübernahme)
  • Die aktuelle Stufe der Identitätsübernahme: „SecurityAnonymous“, „SecurityIdentification“, „SecurityImpersonation“ oder „SecurityDelegation“
  • Die vollständige Liste der Berechtigungen, über die der Benutzer oder seine Gruppen verfügen (Abbildung 3)
Berechtigungen in der Token-Struktur
Abbildung 3. Berechtigungen in der Token-Struktur

Es gibt eine wichtige Einschränkung: Sobald die PrimaryTokenFrozen Ist das Bit für ein Token gesetzt, können Sie diesem keine neuen Berechtigungen hinzufügen. Sie können lediglich bereits vorhandene Berechtigungen aktivieren oder deaktivieren, und zwar über AdjustTokenPrivileges. Sie können den Token-Typ jedoch ändern, indem Sie DuplicateToken, was die Tür für Identitätsbetrugsszenarien öffnet.
Aufgrund dieser Konzeption werden die Ihnen zustehenden Berechtigungen größtenteils bereits bei der Anmeldung festgelegt. Es stellt sich daher folgende Frage: Wer hat sich angemeldet und womit?


Auf welche Windows-Konten haben es Angreifer abgesehen?

Bevor wir uns mit bestimmten Berechtigungen befassen, sollten Sie wissen, welche Konten standardmäßig über gefährliche Berechtigungen verfügen. Hier eine kurze Liste:

  • Administratoren und das lokale System verfügen im Wesentlichen über alle Berechtigungen.
  • Vordefinierte Gruppen wie „Backup-Operatoren“, „Server-Operatoren“ und „Druck-Operatoren“ verfügen über eine Reihe leistungsstarker Berechtigungen, die häufig übersehen werden.
  • Lokale und Netzwerkdienstkonten verfügen in der Regel über die Berechtigungen „SeImpersonatePrivilege“ und „SeAssignPrimaryTokenPrivilege“, die ausreichen, um die SYSTEM-Ebene zu erreichen.
  • Verwaltete Dienstkonten und virtuelle Konten verfügen über dieselben Berechtigungen wie Dienstkonten.
  • Anwender von Drittanbieteranwendungen, wie beispielsweise IIS-Anwendungspools, SQL Server-Dienstkonten und Sicherungsagenten, werden häufig mit mehr Berechtigungen konfiguriert, als sie benötigen.

Auch hier betrachtet Microsoft den Missbrauch legitimer Berechtigungen als Verstoß gegen eine Sicherheitsgrenze und nicht als Verstoß gegen eine Sicherheitsbarriere. Techniken zum Missbrauch von Berechtigungen gelten nicht als Fehler und werden daher nicht behoben.


Wie Angreifer Windows-Berechtigungen aufspüren und für ihre Zwecke missbrauchen

Wie verschaffen sich Angreifer also Zugriff auf Konten mit ausnutzbaren Berechtigungen? Der Vorgang umfasst in der Regel einen oder mehrere der folgenden Ansätze:

  • Kompromittierung von Dienstkonten, beispielsweise durch unsichere Dienstkonfigurationen, die Ausführung von Remote-Code in Webanwendungen oder SQL-Injection, was zu xp_cmdshell Ausführung
  • Das Abfangen der NTLM- oder Kerberos-Authentifizierung mithilfe von Techniken wie Zwangsmaßnahmen, Relay-Angriffen oder dem Erfassen von Anmeldedaten
  • Das Stehlen von Zugangsdaten oder das Durchführen von Kerberoasting durch das Beschaffen von Daten aus Dienstkonten und das Offline-Knacken von Hashes
  • Manipulation von Tokens durch das Vortäuschen von Tokens aus privilegierten Prozessen oder deren direkten Diebstahl
  • Teilweise oder willkürliche Schreibvorgänge durch den Einsatz von Direct Kernel Object Manipulation (DKOM), wodurch Angreifer mit Schreibzugriffen auf Kernel-Ebene – die häufig über anfällige Treiber erlangt werden – die APIs des Benutzermodus vollständig umgehen können. Durch das Auffinden der _TOKEN Struktur durch _EPROCESS Durch das Ändern der Berechtigungsfelder können Angreifer zusätzliche Berechtigungen hinzufügen und aktivieren (Abbildung 4).
Einblicke in die Funktionsweise von Windows-Zugriffstoken mithilfe von WinDbg
Abbildung 4. Interne Strukturen des Windows-Zugriffstokens, dargestellt mit WinDbg

Auf welche Windows-Berechtigungen zielen Angreifer ab?

Nachdem Sie nun einen Überblick über die Risiken haben, die mit dem Missbrauch von Windows-Berechtigungen verbunden sind, wollen wir uns nun näher mit den Berechtigungen befassen, auf die Angreifer am ehesten abzielen, warum diese Berechtigungen für böswillige Akteure attraktiv sind und wie sie ausgenutzt werden.


SeCreateTokenPrivilege: Hat jemand Zugriffstoken?

„SeCreateTokenPrivilege“ ist ein leistungsstarkes, tokenbezogenes Privileg, das es einem Prozess ermöglicht, APIs zum Erstellen von Token aufzurufen, insbesondere ZwCreateToken, um ein vollständig individuelles Zugriffstoken mit beliebigen Berechtigungen und Gruppenmitgliedschaften zu erstellen:

      NTSTATUS ZwCreateToken(
PHANDLE                            TokenHandle,
ACCESS_MASK                     DesiredAccess,
POBJECT_ATTRIBUTES         ObjectAttributes,
TOKEN_TYPE                        Type,
PLUID                                   AuthenticationId,
PLARGE_INTEGER                 ExpirationTime,
PTOKEN_USER                      User,
PTOKEN_GROUPS                Groups,
PTOKEN_PRIVILEGES            Privileges,
PTOKEN_OWNER                 Owner,
PTOKEN_PRIMARY_GROUP PrimaryGroup,
PTOKEN_DEFAULT_DACL     DefaultDacl,
PTOKEN_SOURCE                Source
);

Unter Windows Server 2016 / Windows 10 Version 1809 und früheren Versionen kann das resultierende Token dazu verwendet werden, sich als Threads auszugeben, ohne dass zusätzliche Berechtigungen zur Identitätsübernahme erforderlich sind. Microsoft hat diesen spezifischen Angriffsvektor in späteren Windows-Versionen behoben, doch das resultierende Token kann weiterhin zum Schreiben und Überschreiben geschützter Dateien genutzt werden – eine nützliche Möglichkeit für Angreifer, selbst in eingeschränkten Szenarien.


SeDebugPrivilege: SYSTEM-Zugriff auf den Punkt gebracht

„SeDebugPrivilege“ ist eines der mächtigsten Berechtigungen im Windows-Berechtigungsmodell. Es ermöglicht dem Inhaber, einen Debugger an jeden beliebigen Prozess anzuschließen – unabhängig davon, wem dieser Prozess gehört oder durch welche ACLs er geschützt ist – und den Speicher des Prozesses zu lesen oder zu ändern.

Entscheidend ist, dass „SeDebugPrivilege“ die üblichen DACL-Prüfungen umgeht. Es umgeht zwar nicht die Mechanismen für geschützte Prozesse (z. B. PPL, ELAM-signierte Prozesse), doch machen diese nur einen geringen Anteil der auf einem typischen System ausgeführten Prozesse aus.

Zu den Missbrauchsszenarien gehören:

  • Code-Injektion. Angreifer können mithilfe der klassischen Abfolge bösartigen Code in privilegierte Prozesse einschleusen VirtualAlloc() → WriteProcessMemory() → CreateRemoteThread(). Ziel lsass.exe, winlogon.exeoder einen beliebigen Prozess unter „NT AUTHORITY\SYSTEM“, und Sie können beliebigen Code auf der höchsten Berechtigungsstufe ausführen.
  • Vortäuschung des übergeordneten Prozesses. Angreifer können einen neuen Prozess erstellen und einen privilegierten Prozess als dessen übergeordneten Prozess festlegen, wodurch der untergeordnete Prozess das privilegierte Token erbt (Abbildung 5).
Vortäuschung des Elternprozesses mit SeDebugPrivilege
Abbildung 5. Vortäuschung des Elternprozesses mit „SeDebugPrivilege“

In der Praxis gewährt jeder Dienst oder jede Anwendung, die einem Konto das SeDebugPrivilege erteilt, diesem Konto faktisch SYSTEM-Zugriff. Es gibt nur wenige berechtigte Gründe dafür, dieses Privileg in großem Umfang zu vergeben.


SeBackupPrivilege und SeRestorePrivilege: Von der lokalen Rechteerweiterung bis zur Extraktion von NTDS.DIT

Angreifer können die Berechtigungen „SeBackupPrivilege“ und „SeRestorePrivilege“ missbrauchen, um auf sensible Dateien zuzugreifen und in bestimmten Szenarien die NTDS.DIT-Datenbank von Domänencontrollern (DCs) zu extrahieren, was möglicherweise zu einer vollständigen Kompromittierung des Active Directory führen kann … ein besorgniserregendes Szenario.


SeBackupPrivilege: Der schnelle Weg zur Extraktion von Anmeldedaten

In der Microsoft-Dokumentation wird zu SeBackupPrivilege Folgendes angegeben: „ermöglicht es dem Benutzer, Datei- und Verzeichnisberechtigungen zu umgehen, um eine Sicherungskopie des Systems zu erstellen.„Mit anderen Worten: Dieses Recht gewährt Lesezugriff auf jede Datei im System, unabhängig von den Zugriffskontrolllisten (ACLs), sofern Sie die Datei mit FILE_FLAG_BACKUP_SEMANTICS.

Der offensichtlichste Missbrauch besteht darin, die für die Offline-Extraktion von Anmeldedaten erforderlichen Windows-Registrierungsstrukturen zu löschen:

reg save HKLM\SYSTEM c:\temp\system.hive
reg save HKLM\SAM c:\temp\sam.hive

Sobald ein Angreifer im Besitz dieser beiden Dateien ist, kann er beliebige Offline-Tools einsetzen, um die lokalen NTLM-Hashes zu extrahieren. Auf einem Server, auf dem die Wiederverwendung lokaler Administratorkennwörter nach wie vor viel zu häufig vorkommt, kann diese Möglichkeit böswilligen Akteuren einen Einstiegspunkt für die laterale Bewegung über ein gesamtes Segment hinweg verschaffen (Abbildung 6).

Wiederherstellung von NT-Hash-Werten aus einer SAM-Hive-Sicherung mithilfe von „SeBackupPrivilege“
Abbildung 6. Wiederherstellung von NT-Hashes aus einer SAM-Hive-Sicherung mithilfe von SeBackupPrivilege

Über die Registrierungsdatenbank hinaus kann „SeBackupPrivilege“ dazu verwendet werden, jede Datei zu lesen, auf die das Dateisystem normalerweise keinen Zugriff gewähren würde:

      source = CreateFile(
L"c:\users\administrator\supersecretfile4admins.doc",
GENERIC_READ,
0,
NULL,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS,
NULL
);

Der Schlüssel ist der FILE_FLAG_BACKUP_SEMANTICS Flag, das Windows dazu veranlasst, einen Sicherungsvorgang zu erkennen und die normale DACL-Auswertung zu umgehen.


SeRestorePrivilege: Uneingeschränkter Schreibzugriff

Während „SeBackupPrivilege“ Lesezugriff auf alle Elemente gewährt, gewährt „SeRestorePrivilege“ Schreibzugriff auf alle Elemente, einschließlich der Dateien, die durch TrustedInstaller sowie Systemregistrierungsschlüssel. Zwei API-Aufrufe aktivieren dieses Verhalten:

  • CreateFile() mit FILE_FLAG_BACKUP_SEMANTICS
  • RegCreateKeyEx() mit REG_OPTION_BACKUP_RESTORE

Bei uneingeschränktem Schreibzugriff wird die Angriffsfläche enorm groß. Eine einfache und häufig genutzte Technik besteht darin, einen Windows-Dienst so zu manipulieren, dass er eine vom Angreifer kontrollierte Payload ausführt. Angreifer gehen dabei ganz einfach wie folgt vor:

  1. Erstellen Sie eine schädliche Dienst-DLL oder eine schädliche ausführbare Datei.
  2. Verwendung RegCreateKeyEx() mit REG_OPTION_BACKUP_RESTORE um die des Dienstes zu überschreiben ServiceDLL Registrierungswert:
    std::string buffer = "c:\windows\system32\hackerservice.dll";
    LSTATUS stat = RegCreateKeyExA(
    HKEY_LOCAL_MACHINE,
    "SYSTEM\CurrentControlSet\Services\dmwappushservice\Parameters",
    0, NULL, REG_OPTION_BACKUP_RESTORE, KEY_SET_VALUE, NULL, &hk, NULL
    );
    stat = RegSetValueExA(
    hk, "ServiceDLL", 0, REG_EXPAND_SZ,
    (const BYTE*)buffer.c_str(), buffer.length() + 1
    );
  3. Verwendung CreateFile() mit FILE_FLAG_BACKUP_SEMANTICS um die DLL in den Ordner „C:\Windows\System32“ zu kopieren. (Der Speicherort kann beliebig sein; dieses Beispiel verdeutlicht lediglich, dass die Berechtigung das Schreiben in geschützte Systemdateien oder sogar deren Überschreiben ermöglicht.)
  4. Starten Sie den Ziel-Dienst neu. Der als „SYSTEM“ ausgeführte Dienst lädt nun die DLL des Angreifers.

Abbildung 7 zeigt ein Beispiel für diese Technik unter Verwendung von dmwappushservice, der standardmäßig vorhanden ist, wird als SYSTEM ausgeführt und kann von jedem Benutzer gestartet werden. Die gleiche Technik lässt sich jedoch nutzen, um jeden beliebigen Dienst auszunutzen.

Manipulation des Pfads eines Dienst-Images mithilfe von SeRestorePrivilege
Abbildung 7. Manipulation des Pfads eines Dienst-Images mithilfe von SeRestorePrivilege

Backup-Administratoren: Doppelte Berechtigungen, doppeltes Risiko

Mitglieder der integrierten Gruppe „Backup Operators“ verfügen sowohl über die Berechtigung „SeBackupPrivilege“ als auch über die Berechtigung „SeRestorePrivilege“. Noch kritischer ist jedoch, dass sie sich lokal an Domänencontrollern anmelden dürfen – eine Fähigkeit, die in den meisten AD-Umgebungen ein stark unterschätztes Risiko birgt.

Diese Kombination bedeutet, dass jeder Angreifer, der sich Zugang zur Gruppe „Backup Operators“ verschafft, die Datei „NTDS.DIT“ mithilfe von Tools wie „wbadmin.exe“ direkt von einem Domänencontroller aus sichern kann:

      wbadmin start backup -backuptarget:e: -include:c:\windows\ntds
wbadmin get versions
wbadmin start recovery -version:07/12/2025-11:09 -itemtype:file
-items:c:\windows\ntds\ntds.dit -recoverytarget:c:\temp\srvdc1 -notrestoreacl
reg save HKLM\SYSTEM c:\temp\system

Der Ansatz mit der integrierten Datei „diskshadow.exe“ funktioniert ebenso gut und wird von den Verteidigern häufig übersehen:

      set metadata C:\temp\metadata.cab
set context clientaccessible
set context persistent
begin backup
add volume c: alias mydrive
create
expose %mydrive% z:

Bitte beachten Sie, dass diese Vorgehensweise bei „ntdsutil.exe“ nicht funktioniert, da hierfür Administratorrechte erforderlich sind.

Sobald ein Angreifer über die Datei „NTDS.DIT“ und den SYSTEM-Hive verfügt, kann er mithilfe von Tools wie „DSInternals“ oder „impacket-secretsdump“ alle Domänen-Anmeldedaten offline extrahieren, einschließlich des krbtgt-Hashes, der für die Durchführung eines Golden-Ticket-Angriffs erforderlich ist.

Darüber hinaus kann ein Angreifer, der sich Zugang zur Gruppe „Backup Operators“ verschafft, mit diesen beiden Berechtigungen die Eigentumsrechte und Zugriffsrechte für jede Datei oder jeden Ordner auf dem System festlegen, wodurch er allein durch Manipulation des Dateisystems Zugriff auf das SYSTEM-Konto erlangt.


SeImpersonatePrivilege und SeAssignPrimaryTokenPrivilege: Warum „Potato“-Exploits einfach nicht verschwinden wollen

Diese beiden Berechtigungen werden in der Praxis am häufigsten missbraucht, und sie sind der Grund für die Existenz der „Potato“-Exploit-Familie.

  • SeImpersonatePrivilege („Sich nach der Authentifizierung als ein Client ausgeben“) ermöglicht es einem Thread, sich als beliebiges Zugriffstoken auszugeben, und zwar über SetThreadToken(), ImpersonateLoggedOnUser(), oder CreateProcessWithToken().
  • SeAssignPrimaryTokenPrivilege („Das primäre Token eines Prozesses zuweisen“) ermöglicht es einem Prozess, einen Nachprozess mit einem anderen Primärtoken über CreateProcessAsUser(). Diese Berechtigung steht auch in einer Standard-IL-Shell der Stufe „Medium“ zur Verfügung.

Beide Berechtigungen werden in der Regel Dienstkonten, IIS-Anwendungspool-Identitäten, SQL Server-Dienstkonten und ähnlichen Prinzipalen zugewiesen. Kurz gesagt: Wenn Sie als Dienstkonto über RCE-Rechte verfügen, besitzen Sie mit ziemlicher Sicherheit mindestens eine dieser Berechtigungen.

Doch wie gelangen Angreifer an privilegierte Token, um sich als andere auszugeben? Es gibt verschiedene Techniken, zum Beispiel:

  • Erstellen einer benannten Pipe, wodurch ein Prozess mit erhöhten Rechten gezwungen wird, eine Verbindung dazu herzustellen, und anschließend den Aufruf ImpersonateNamedPipeClient() um das Token des Anrufers abzurufen
  • Verwendung von DCOM/RPC-Callbacks über CoImpersonateClient(), RpcImpersonateClient()
  • Unter Verwendung von „Potato“-Exploits, einer Familie bekannter Techniken zur Eskalation lokaler Berechtigungen (z. B. RottenPotato, JuicyPotato, SweetPotato, GodPotato), die diese Berechtigungen missbrauchen, indem sie die COM/RPC-Authentifizierung auf SYSTEM-Ebene zurück zu einem vom Angreifer kontrollierten Listener erzwingen

Diese Methode geht auf eine Beobachtung von James Forshaw aus dem Jahr 2016 zurück:

„Lokale DCOM-DCE/RPC-Verbindungen können auf einen empfangsbereiten TCP-Socket zurückgeleitet werden, wodurch Zugriff auf die NTLM-Authentifizierungsanfrage für den Benutzer „LocalSystem“ ermöglicht wird, die an den lokalen DCOM-Aktivierungsdienst weitergeleitet werden kann, um Berechtigungen zu erweitern.“

In den vergangenen 10 Jahren wurde dieser Kern-Exploit neu implementiert, angepasst und mithilfe einer bemerkenswerten Vielfalt an Techniken erneut als Angriffswerkzeug eingesetzt, die zusammen die „Potato“-Familie bilden. Der allgemeine Mechanismus folgt bei allen Varianten folgender Struktur:

  1. Starten Sie einen lokalen Listener auf einem TCP-Port, der als gefälschter COM- oder RPC-Endpunkt fungiert.
  2. Lösen Sie eine CLSID aus, indem Sie eine COM-Klasse instanziieren, die unter NT AUTHORITY\SYSTEM ausgeführt wird.
  3. Unmarshalling erzwingen über CoGetInstanceFromIStorage, wobei ein speziell angefertigtes IStorage OBJREF auf … zeigend 127.0.0.1: <listener>. Der SYSTEM COM-Server versucht, eine Verbindung zum Listener herzustellen, und führt die Authentifizierung für ausgehende Verbindungen mittels NTLM durch.
  4. Den NTLM-Handshake lokal abfangen über SSPI (AcceptSecurityContext → QuerySecurityContextToken), um ein SYSTEM-Identitätswechsel-Token zu erhalten.
  5. Sich als das Token ausgeben und die Berechtigungen erweitern über CreateProcessWithTokenW oder CreateProcessAsUser um eine Shell als SYSTEM zu starten.

Die zentrale Erkenntnis ist elegant: Die CLSID veranlasst SYSTEM, eine ausgehende Authentifizierung zu initiieren, CoGetInstanceFromIStorage Leitet diese Authentifizierung an den Listener des Angreifers weiter, und das lokale NTLM-Relay erfasst das Token. Keine Sicherheitslücke im herkömmlichen Sinne … lediglich Berechtigungen, die genau das tun, wofür sie vorgesehen sind.

Abbildung 8 veranschaulicht, wie das Tool „JuicyPotatoNG“ genutzt werden kann, um eine SYSTEM-Shell zu starten, indem die Funktion „SeAssignPrimaryTokenPrivilege“ aus einer Shell heraus missbraucht wird, die in einer „medium“-IL läuft.

Rechteausweitung mithilfe von „Potato“-Techniken, die die Funktionen „SeImpersonatePrivilege“ und „SeAssignPrimaryTokenPrivilege“ missbrauchen
Abbildung 8. Ausweitung von Berechtigungen mithilfe von „Potato“-Techniken, die „SeImpersonatePrivilege“ und „SeAssignPrimaryTokenPrivilege“ missbrauchen

SeLoadDriverPrivilege: Vom Gerätetreiber zur vollständigen Kompromittierung des Systems

„SeLoadDriverPrivilege“ legt fest, welche Benutzer Gerätetreiber oder anderen Code dynamisch in den Kernelmodus laden und von dort entfernen können. Dieses Recht ist besonders erwähnenswert, da Mitglieder der Domänengruppe „Druckerbediener“ dieses Recht auf Domänencontrollern standardmäßig besitzen.

Das Angriffsmuster ist hinlänglich bekannt: Ein signierter, aber anfälliger Kernel-Treiber wird geladen und anschließend vom Userland aus ausgenutzt, um auf den Kernel-Speicher zuzugreifen und dort Daten zu lesen oder zu schreiben. Dies ermöglicht den Diebstahl von Tokens, die Erlangung von Berechtigungen, die Umgehung von PPL, die Beendigung von AV-/EDR-Systemen oder die Ausführung beliebiger Code im Kernel-Modus.

Die kanonische Methode stützt sich auf die Tatsache, dass Benutzer Registrierungseinträge unter ihrem aktuellen Hive „HKCU“ erstellen können, und NtLoadDriver() akzeptiert Registrierungs-Pfade, die aus der SID des Benutzers gebildet werden, wodurch ein Benutzer ohne Sonderrechte einen Kernel-Treiber-Dienst registrieren kann, ohne auf HKLM zugreifen zu müssen:

      std::string data = "\??\C:\TEMP\evildriver.sys";
RegCreateKeyExA(HKEY_CURRENT_USER,
"SYSTEM\CurrentControlSet\Services\Evil",
0, NULL, NULL, KEY_SET_VALUE, NULL, &hk, NULL);
RegSetValueExA(hk, „ImagePath“, 0, REG_EXPAND_SZ,
(const BYTE)data.c_str(), data.length() + 1); RegSetValueExA(hk, „Type“, 0, REG_DWORD, (const BYTE)&val, sizeof(val));

WCHAR winregPath[256];
wcscpy(winregPath, L"\Registry\User\");
wcscat(winregPath, sidstring);
wcscat(winregPath, L"\System\CurrentControlSet\Services\Evil");
RtlInitUnicodeString(&DriverServiceName, winregPath);
status = NtLoadDriver(&DriverServiceName);

Microsoft hat inzwischen alternative Registrierungsspeicherorte gesperrt, doch unter HKLM\System gibt es nach wie vor Pfade, in die geschrieben werden kann.

Es kommt nicht selten vor, dass GPOs das SeLoadDriverPrivilege an weit gefasste Gruppen vergeben, was wahrscheinlich auf die irrtümliche Annahme zurückzuführen ist, dass diese Berechtigung erforderlich ist, damit Benutzer Drucker installieren können. Die Folge ist eine unnötig offengelegte Berechtigung, die Angreifern einen direkten Weg zur Ausführung von Code auf Kernel-Ebene eröffnet.


SeManageVolumePrivilege: Zugriff auf die Änderung von ACLs

Mit dem Recht „SeManageVolumePrivilege“ kann ein Benutzer volumenbezogene Vorgänge wie die Defragmentierung, das Einbinden oder das Ausbinden von Volumes durchführen. Dieses Recht ist in einer Shell mit mittlerer IL-Stufe verfügbar. Aus Sicht eines Angreifers eröffnet die Ausnutzung dieses Rechts mehrere nützliche Möglichkeiten:

  • Das Einbinden von Datenträgern, die sensible Daten enthalten, wodurch möglicherweise Zugriffskontrollmechanismen umgangen werden, die regeln, inwieweit die Daten über das Dateisystem zugänglich sind
  • Die Manipulation von Dateisystemen auf Volume-Ebene, einschließlich der Änderung von Zugriffsrechten für ganze Volumes (Abbildung 9) – eine Berechtigung, die es einem Angreifer beispielsweise ermöglichen kann, die ACL für das gesamte Laufwerk „C:\“ zu ändern und anschließend mithilfe anderer Techniken beschreibbare Pfade in ansonsten geschützte Bereiche des Systems zu erstellen
Änderung der Berechtigungen für Datenträger mithilfe von „SeManageVolumePrivilege“
Abbildung 9. Ändern der Volume-Berechtigungen mithilfe von „SeManageVolumePrivilege“

Obwohl dieses Recht in der Praxis seltener anzutreffen ist als „SeImpersonatePrivilege“ oder „SeBackupPrivilege“, sollte sein Vorhandensein auf einem Nicht-Administrator-Konto als ernstzunehmendes Risiko betrachtet werden.


SeRelabelPrivilege: Geringere Integrität, höheres Risiko

„SeRelabelPrivilege“ ist eine weniger bekannte, aber interessante Berechtigung. Laut der Microsoft-Dokumentationlegtdiese Berechtigungfest, „welche Benutzerkonten die Integritätskennzeichnung von Objekten wie Dateien, Registrierungsschlüsseln oder Prozessen ändern dürfen, die anderen Benutzern gehören.“

Ohne dieses Privileg kann ein Prozess die Integritätskennzeichnung nur von Objekten herabsetzen, die ihm gehören. Mit dem Privileg „SeRelabelPrivilege“ kann ein Prozess die Integritätskennzeichnungen von Objekten ändern, die anderen Benutzern gehören, und dabei die Kennzeichnungen sogar über die eigene Integritätsstufe des aktuellen Prozesses hinaus anheben. Mit anderen Worten:

  • Mit „SeRelabelPrivilege“ können Sie die Eigentumsrechte an einer Ressource übernehmen, selbst wenn deren IL-Wert höher ist als der Ihre.
  • Sobald Sie die Eigentumsrechte übernommen haben, können Sie sich selbst uneingeschränkten Zugriff auf den Prozess und die Token gewähren.
  • Aus Sicht eines Missbrauchs ähnelt das Ergebnis dem von SeDebugPrivilege.
  • Die Manipulation der Pflichtangabe ist lediglich eine Folge davon.

Die ursprüngliche Motivation für dieses Recht bleibt unklar, seine Auswirkungen hingegen sind unbestritten. Es ermöglicht Ihnen, die Eigentumsrechte an Objekten zu übernehmen, die über Ihrer Integritätsstufe liegen (Abbildung 10), was es zu einem der gefährlichsten und am meisten unterschätzten Rechte im Windows-Sicherheitsmodell macht.

Nutzung von „SeRelabelPrivilege“, um die Kontrolle über einen privilegierten Prozess zu erlangen
Abbildung 10. Nutzung von „SeRelabelPrivilege“, um die Kontrolle über einen privilegierten Prozess zu erlangen

Jede Zuweisung außerhalb streng kontrollierter Verwaltungskonten sollte sorgfältig geprüft und als Warnsignal betrachtet werden.


SeTakeOwnershipPrivilege: Sie gehören nun uns

Dieses Privileg erfüllt genau den Zweck, den sein Name vermuten lässt: Es ermöglicht dem Inhaber, das Eigentumsrecht an jedem absicherbaren Objekt im System zu übernehmen. Die beiden entsprechenden API-Aufrufe verwenden beide die OWNER_SECURITY_INFORMATION Flag:

  • SetSecurityInfo()
  • SetNamedSecurityInfo()

Die Objektarten, auf die sich die Maßnahmen beziehen können, sind vielfältig: Dateien, Drucker, Freigaben, Dienste, Registrierungsschlüssel und Kernel-Objekte.

Sobald die Zugriffsrechte gesichert sind, kommen dieselben Techniken zur Manipulation von Dateien und der Registrierungsdatenbank zum Einsatz, die auch bei der Ausnutzung von „SeRestorePrivilege“ verwendet werden. Ein praktisches Beispiel hierfür ist das Anvisieren der msiserver (Windows Installer)-Dienst:

Schritt 1. Übernehmen Sie die Eigentumsrechte für den Dienstregistrierungsschlüssel:

      wchar_t infile[] = L"SYSTEM\CurrentControlSet\Services\msiserver";
PSID UserSid = GetCurrentUserSID();
dwRes = SetNamedSecurityInfoW(
infile,
SE_REGISTRY_KEY,
OWNER_SECURITY_INFORMATION,
UserSid, NULL, NULL, NULL
);

Schritt 2. Ändern Sie die Berechtigungen für den Registrierungsschlüssel, um Vollzugriff zu gewähren:

      ea[0].grfAccessPermissions = KEY_ALL_ACCESS;
ea[0].grfAccessMode = SET_ACCESS;
ea[0].grfInheritance = NO_INHERITANCE;
ea[0].Trustee.TrusteeForm = TRUSTEE_IS_SID;
ea[0].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
ea[0].Trustee.ptstrName = (LPTSTR)pSIDEveryone;
SetEntriesInAcl(NUM_ACES, ea, NULL, &pACL);

Schritt 3. Passen Sie die Einstellungen des Dienstes an ImagePath um einen beliebigen Befehl auszuführen:

      std::string buffer = "cmd.exe /c net localgroup administrators hacker /add";
stat = RegSetValueExA(
hk, "ImagePath", 0, REG_EXPAND_SZ,
(const BYTE*)buffer.c_str(), buffer.length() + 1
);

Wenn der Dienst vom Benutzer gestartet wird, führt er den vom Angreifer kontrollierten Befehl unter dem SYSTEM-Konto aus.


SeTCBPrivilege: Identitätsübernahme

„SeTCBPrivilege“ ist eines der eher ungewöhnlichen Privilegien in dieser Liste. In der Dokumentation wird es wie folgt beschrieben: „als Teil des Betriebssystems fungieren,“, doch die praktische Konsequenz besteht darin, dass man die Möglichkeit hat, LsaLogonUser() die Identität eines beliebigen Benutzers anzunehmen, ohne die Anmeldedaten dieses Benutzers zu benötigen.

Bei dem Mechanismus handelt es sich um „Service For User Logon“ (S4ULogon), eine Funktion, die es einem Prozess mit SeTCBPrivilege ermöglicht, ein Sicherheitstoken für einen beliebigen Benutzer zu erhalten. Entscheidend ist, dass der aufrufende Prozess verlangen kann, dass dem resultierenden Token zusätzliche Gruppenmitgliedschaften oder Berechtigungen hinzugefügt werden, darunter auch Gruppen, denen der Benutzer eigentlich nicht angehört:

      pS4uLogon->MessageType = MsV1_0S4ULogon;
// SzUsername = ZIELBENUTZER, ALS DER SICH DIE IMPERSONATION ERFOLGEN SOLL
InitUnicodeString(&pS4uLogon->UserPrincipalName, szUsername, pbPosition);
InitUnicodeString(&pS4uLogon->DomainName, szDomain, pbPosition);

// Fügen Sie „S-1-5-32-544“ (Lokale Administratoren) zum Token hinzu
ConvertStringSidToSid("S-1-5-32-544", &pExtraSid);
pGroups->Groups[pGroups->GroupCount].Attributes =
SE_GROUP_ENABLED | SE_GROUP_ENABLED_BY_DEFAULT | SE_GROUP_MANDATORY;
pGroups->Groups[pGroups->GroupCount].Sid = pExtraSid;
Status = LsaLogonUser(…)

Das daraus resultierende Identitätsübernahme-Token, das innerhalb des lokalen Systemkontexts gültig ist, kann verwendet werden, um die Identität von Threads zu übernehmen, ohne dass zusätzliche Berechtigungen wie „SeImpersonatePrivilege“ erforderlich sind. Dadurch wird „SeTcbPrivilege“ zu einer in sich geschlossenen Primitive zur Berechtigungserweiterung.

In PowerShell sieht der Kerberos-S4ULogon-Pfad wie folgt aus:

      $ident = [System.Security.Principal.WindowsIdentity]::new("administrator@domain.local")
$ctx = $ident.Impersonate()
try {
[System.IO.File]::WriteAllText("C:\Windows\System32\text.txt", "hello from Domain Admin")
}
finally {
$ctx.Undo()
}

Dieses Recht wird standardmäßig ausschließlich dem SYSTEM-Konto gewährt. Es gibt keinen berechtigten Grund, es anderen Konten zu gewähren. Jede Zuweisung an ein anderes Konto als das SYSTEM-Konto sollte als Fehlkonfiguration oder als Hinweis auf eine Kompromittierung betrachtet werden.


Risiken durch den Missbrauch von Windows-Berechtigungen minimieren: Praktische Gegenmaßnahmen für Active-Directory-Umgebungen

Folgendes können Sie noch heute tun, um das Risiko eines Missbrauchs von Zugriffsrechten zu verringern:

  • Der Befehl whoami /priv ist eine der ersten Maßnahmen, die ein Angreifer ergreift, sobald er sich Zugang verschafft hat. Daher sollte dies auch eine der ersten Maßnahmen sein, die Sie ergreifen, wenn Sie die Sicherheitslage eines sensiblen Kontos überprüfen.
  • Überprüfen Sie alle GPOs, die Berechtigungen zuweisen, über „Computerkonfiguration“ → „Windows-Einstellungen“ → „Sicherheitseinstellungen“ → „Lokale Richtlinien“ → „Zuweisung von Benutzerrechten“ domänenweit. Überprüfen Sie die tatsächlich geltenden Zuweisungen auf allen Systemen unter besonderer Berücksichtigung von Tier-0-Ressourcen. Dies ist der Hauptweg für die unbeabsichtigte Vergabe von Berechtigungen. Überprüfen Sie nicht nur die explizit konfigurierten Einstellungen, sondern auch policy daraus resultierenden policy, da die Vererbung und Priorisierung von GPOs häufig zu Zuweisungen führen, die von keinem einzelnen Administrator beabsichtigt waren. Entfernen Sie alles, was betrieblich nicht gerechtfertigt ist.
  • Überprüfen Sie die Mitgliedschaft in den integrierten Gruppen mit leistungsstarken Berechtigungssätzen: Backup-Operatoren, Druck-Operatoren, Server-Operatoren, Konto-Operatoren.
  • Dienstkonten sollten mit den minimal erforderlichen Berechtigungen ausgeführt werden. Standardmäßig verfügen Dienstkonten über die Berechtigung „SeImpersonatePrivilege“. Es ist möglich, die zugewiesenen Berechtigungen über die Required Privileges Registrierungsschlüssel in der Dienstkonfiguration; dies ist eine bewährte Sicherheitsmaßnahme. Beachten Sie jedoch, dass ein Angreifer diese Berechtigungen unter bestimmten Umständen wiedererlangen kann; betrachten Sie diesen Schritt daher eher als eine Ebene einer umfassenderen Strategie der mehrschichtigen Verteidigung und nicht als vollständige Abhilfemaßnahme.
  • Überwachen Sie whoami /priv Ausführung sowie für API-Aufrufe im Zusammenhang mit der Token-Bearbeitung (DuplicateToken, ImpersonateLoggedOnUser, CreateProcessWithToken, LsaLogonUser) in Ihrer EDR-Telemetrie.
  • Behandeln Sie jedes Konto, das sich lokal bei einem Domänencontroller anmelden kann, als Tier-0-Ressource, unabhängig davon, ob es in der Gruppe „Domänenadministratoren“ aufgeführt ist.

Lassen Sie nicht zu, dass der Missbrauch von Windows-Berechtigungen Ihr Unternehmen gefährdet

Es sei noch einmal betont: Da die in diesem Beitrag behandelten Berechtigungen wie vorgesehen funktionieren, besteht die Gefahr des Missbrauchs von Windows-Berechtigungen – und der damit verbundenen Angriffstechniken – selbst in gut gepatchten Umgebungen. Böswillige Akteure können diese Techniken nutzen, um Active Directory zu kompromittieren und ihre Berechtigungen in Ihrem gesamten Unternehmen zu erweitern. Unterschätzen Sie dieses Risiko nicht; ergreifen Sie noch heute Maßnahmen, um Ihre Cyber-Resilienz zu schützen.


Weitere wissenschaftliche Untersuchungen


Quellen