Elevation de privileges Windows : vecteurs et durcissement

L'élévation de privilèges sous Windows est l'une des phases les plus déterminantes d'une intrusion réelle, et pourtant l'une des plus défendables. Cet article s'adresse aux équipes bleues, aux ingénieurs de détection et aux administrateurs système qui doivent comprendre la mécanique pour pouvoir s'en défendre. Nous décrirons, au niveau conceptuel, comment un attaquant disposant déjà d'un accès à faibles privilèges tente de devenir SYSTEM ou administrateur de domaine, quelle télémétrie révèle ces tentatives et comment durcir un parc Windows pour que les vecteurs les plus courants n'existent tout simplement pas. Il n'y a ici aucune charge utile prête à l'emploi : l'objectif est une détection et une atténuation durables, pas un mode d'emploi de compromission.

Ce que signifie réellement l'élévation de privilèges

L'élévation de privilèges est le passage d'un contexte de sécurité à un autre plus puissant sur le même hôte ou le même domaine. Les défenseurs la divisent généralement en deux familles. L'élévation verticale passe d'un utilisateur standard ou de faible intégrité à un compte à privilèges élevés comme NT AUTHORITY\SYSTEM, un administrateur local ou un administrateur de domaine. L'élévation horizontale se déplace latéralement vers un autre utilisateur de privilège similaire pour atteindre des données ou une confiance que le compte d'origine n'avait pas. L'élévation ne se produit presque jamais isolément : elle se situe entre l'accès initial et le mouvement latéral dans le cycle d'attaque, et c'est souvent l'étape où une infection mineure devient une compromission totale. C'est pourquoi détecter les tentatives d'élévation a une grande valeur même lorsqu'elles échouent, car une tentative ratée révèle un accès dont vous ignoriez l'existence.

Comment Windows impose les privilèges dès le départ

Pour défendre la frontière, il faut savoir où elle se trouve. Windows attribue à chaque processus un jeton d'accès qui porte le SID de l'utilisateur, les SID de groupe, un niveau d'intégrité (Faible, Moyen, Élevé, Système) et un ensemble de privilèges tels que SeDebugPrivilege, SeImpersonatePrivilege et SeBackupPrivilege. Le Contrôle de compte d'utilisateur (UAC) scinde la connexion d'un administrateur en deux jetons : un jeton filtré d'intégrité moyenne pour le travail quotidien et un jeton complet d'intégrité élevée qui n'apparaît qu'après une invite d'élévation. La plupart des techniques d'élévation sont, au fond, des tentatives d'obtenir un jeton que l'utilisateur n'aurait jamais dû posséder, ou d'exécuter du code dans un processus qui le détient déjà. Comprendre les jetons, les niveaux d'intégrité et les privilèges constitue donc le vocabulaire commun de toute détection et de toute atténuation qui suit.

Les vecteurs courants et où ils se logent

Les vecteurs d'élévation se regroupent en une poignée de mauvaises configurations récurrentes, et les nommer de façon défensive permet d'auditer leur absence. Les mauvaises configurations de services sont le cas classique : un service qui s'exécute en tant que SYSTEM mais dont le binaire, ou le dossier, est inscriptible par des utilisateurs non privilégiés permet de remplacer ce que le service exécute. Le problème apparenté du chemin de service sans guillemets fait que Windows essaie d'abord des exécutables de niveau supérieur. Des autorisations de service faibles permettent de reconfigurer directement le chemin du binaire. Côté installateur, les stratégies jumelées AlwaysInstallElevated laissent tout utilisateur installer des paquets en tant que SYSTEM. L'abus de jetons exploite les comptes disposant de privilèges d'usurpation, courant sur les comptes de service web et de base de données. Le détournement de l'ordre de recherche des DLL place une bibliothèque là où un processus privilégié la chargera. Enfin, le vol d'identifiants depuis la mémoire, le registre ou les fichiers d'installation sans surveillance permet souvent de sauter l'élévation entièrement. Aucun outil d'attaque n'est nécessaire pour trouver cela ; un audit de configuration le trouve en premier.

Détection : la télémétrie qui expose l'élévation

L'élévation est bruyante si l'on écoute les bons canaux. Activez et transférez le journal de sécurité Windows avec Sysmon et votre EDR, et centrez la détection sur quelques signaux durables. L'événement 4672 ("Privilèges spéciaux attribués à la nouvelle ouverture de session") se déclenche lorsqu'une session reçoit des privilèges sensibles comme SeDebugPrivilege ; corrélez le compte et le processus parent. Les événements 4673 et 4674 enregistrent les opérations privilégiées de service et d'objet. L'élévation par service apparaît via 7045 (un nouveau service a été installé) et 4697, plus l'ID d'événement 1 de Sysmon (création de processus) montrant une chaîne parent-enfant inattendue comme services.exe lançant cmd.exe. La manipulation et l'injection de jetons apparaissent comme les ID 8 (CreateRemoteThread) et 10 (ProcessAccess) de Sysmon visant lsass.exe avec des masques d'accès suspects. Les vecteurs du registre comme AlwaysInstallElevated apparaissent comme l'ID d'événement 13 de Sysmon. Les meilleures détections les combinent : un processus d'intégrité moyenne qui engendre soudain un enfant d'intégrité élevée, ou un compte de service qui obtient l'usurpation puis lance un shell.

Construire des détections qui survivent aux environnements réels

Les ID d'événement bruts génèrent du bruit, façonnez-les donc en règles fondées sur le comportement. Alertez sur les transitions de niveau d'intégrité : un arbre de processus où un parent d'intégrité moyenne produit un enfant d'intégrité élevée ou système sans événement de consentement UAC légitime mérite une enquête. Établissez une base de référence de vos services légitimes et alertez lorsque 7045 installe un service dont le chemin du binaire est dans C:\Users, C:\Windows\Temp ou un autre emplacement inscriptible par l'utilisateur. Surveillez les comptes détenant SeImpersonatePrivilege qui lancent des shells interactifs. Rattachez chaque règle aux techniques MITRE ATT&CK sous la tactique Élévation de privilèges (TA0004) pour rendre les lacunes visibles, et validez les règles par un exercice autorisé d'équipe violette plutôt que de supposer qu'elles se déclenchent. Alimentez les alertes dans un flux de tri qui capture le jeton, la chaîne parentale et l'artefact modifié, car ces trois faits reconstituent souvent toute la technique.

Atténuation et durcissement qui suppriment les vecteurs

La meilleure détection d'élévation est un vecteur qui n'existe plus. Imposez le moindre privilège : les utilisateurs standard ne doivent jamais être administrateurs locaux, et les comptes de service doivent être des Group Managed Service Accounts limités exactement au nécessaire. Auditez et corrigez les ACL de fichiers et de dossiers de chaque chemin de binaire de service pour que les non-administrateurs ne puissent pas y écrire, et résolvez chaque chemin de service sans guillemets. Réglez les deux valeurs AlwaysInstallElevated sur désactivé via la stratégie de groupe. Retirez les privilèges sensibles comme SeImpersonatePrivilege des comptes qui n'en ont pas besoin, et isolez les identifiants avec Credential Guard et la protection LSA (RunAsPPL) pour freiner le vol en mémoire. Maintenez les systèmes à jour, car de nombreux exploits d'élévation visent des vulnérabilités locales connues. Déployez le contrôle applicatif (WDAC ou AppLocker) afin qu'un binaire déposé ne puisse pas s'exécuter même si une ACL faiblit. Enfin, surveillez l'abus de chargement de pilotes, car les pilotes signés mais vulnérables sont un pont d'élévation de plus en plus courant.

Les pièges qui affaiblissent un programme par ailleurs solide

Plusieurs erreurs récurrentes vident une défense contre l'élévation. La première est de journaliser sans transférer : les événements existent sur le terminal mais n'atteignent jamais le SIEM, si bien que l'attaquant qui efface le journal local supprime la seule preuve. La deuxième est la fatigue d'alerte due aux événements 4672 bruts, qui se déclenchent constamment pour les administrateurs légitimes ; sans base de référence, les analystes apprennent à ignorer celui qui compte. La troisième est de trop faire confiance à l'UAC comme frontière de sécurité — Microsoft lui-même ne traite pas l'UAC par défaut comme telle. La quatrième concerne les ACL de service obsolètes introduites par des installateurs tiers bien après le durcissement initial, d'où la nécessité d'un audit continu. Enfin, les équipes oublient souvent les tâches planifiées et les dossiers de démarrage, qui offrent le même schéma que les services et méritent le même examen.

Une liste de contrôle pratique de durcissement et de détection

Utilisez-la comme un audit récurrent, pas comme un projet unique. 1) Confirmez qu'aucun utilisateur standard n'est administrateur local. 2) Énumérez les chemins de binaires de service et vérifiez qu'aucun n'est inscriptible par des non-administrateurs. 3) Résolvez chaque chemin de service sans guillemets. 4) Vérifiez que les deux valeurs AlwaysInstallElevated sont désactivées. 5) Examinez quels comptes détiennent SeImpersonatePrivilege, SeDebugPrivilege et SeBackupPrivilege, et retirez l'inutile. 6) Activez Credential Guard et la protection LSA là où c'est pris en charge. 7) Déployez WDAC ou AppLocker en mode application. 8) Envoyez les journaux Sécurité, Sysmon et EDR au SIEM et confirmez l'ingestion. 9) Alertez sur les sauts d'intégrité, les chemins 7045 suspects et l'accès à lsass.exe. 10) Validez toute la chaîne chaque trimestre par un test autorisé d'équipe violette.

Foire aux questions

Est-il parfois acceptable de désactiver l'UAC pour réduire les invites ? Non. Même si Microsoft ne classe pas l'UAC par défaut comme une frontière de sécurité formelle, il augmente tout de même le coût de nombreuses techniques d'élévation et fournit l'événement de consentement dont dépendent plusieurs détections. Réduisez les invites par un empaquetage correct des applications et le moindre privilège, jamais en désactivant l'UAC.

Avons-nous encore besoin de détections sur l'hôte si nous avons un EDR solide ? Oui. L'EDR est puissant mais pas omniscient, et ajouter Sysmon et des journaux de sécurité transférés fournit une source de preuve indépendante qui survit à un attaquant qui altère l'agent. La défense en profondeur s'applique aussi à votre propre visibilité, pas seulement au chemin de l'attaquant.

Conclusion

L'élévation de privilèges sous Windows semble intimidante parce qu'elle comporte de nombreuses techniques nommées, mais du siège du défenseur elle se réduit à un petit ensemble de mauvaises configurations évitables et à un petit ensemble de signaux de grande valeur. Supprimez les binaires de service inscriptibles, les chemins sans guillemets, les privilèges superflus et la stratégie AlwaysInstallElevated, et vous éliminez d'emblée la majeure partie de l'exposition du parc. Transférez le journal de sécurité avec Sysmon et votre EDR, alertez sur les transitions d'intégrité et les installations de service suspectes, et validez la couverture par des tests autorisés, et vous verrez les tentatives restantes. Comprendre l'attaque n'est utile ici que dans la mesure où cela rend la défense concrète — et sous Windows, la défense est bien à portée de main.