Élévation de privilèges sous Windows : principes
Les environnements Windows d'entreprise, très répandus dans les réseaux professionnels, ont leurs propres mécanismes de droits et leurs propres pièges classiques. Cette leçon transpose le raisonnement de la précédente à cet écosystème, en insistant sur ce qui le distingue de Linux et sur les causes les plus fréquentes rencontrées par les auditeurs.
Rappel. Comme pour la leçon précédente, les principes exposés ici s'appliquent exclusivement dans un labo autorisé (machines virtuelles Windows volontairement vulnérables, ou plateforme d'entraînement légale). Aucune commande ou outil d'exploitation prêt à l'emploi n'est fourni.
Rappel : comptes et droits sous Windows
Sous Windows, les droits reposent sur des comptes utilisateurs et des groupes, avec une distinction centrale entre compte standard et compte administrateur. Dans un environnement d'entreprise organisé autour d'un domaine (un service centralisé de gestion des comptes et des machines), des comptes à privilèges plus larges, comme les administrateurs de domaine, peuvent potentiellement agir sur l'ensemble des machines qui dépendent de ce domaine. C'est cette centralisation qui rend le pivoting et le pass-the-hash, vus aux chapitres précédents, particulièrement impactants dans ce type d'environnement : un seul compte à privilèges élevés compromis peut avoir des conséquences sur un très grand nombre de machines.
Les grandes familles de causes, côté Windows
| Famille | Principe |
|---|---|
| Services mal configurés | Un service qui s'exécute avec des privilèges élevés (souvent le compte système) peut parfois être modifié ou remplacé par un utilisateur standard si les permissions du programme associé ou de son emplacement sont trop permissives, ce qui entraîne l'exécution du contenu modifié avec ces privilèges élevés. |
| Logiciels tiers vulnérables ou mal installés | Un logiciel installé avec des permissions trop larges sur son dossier ou ses fichiers peut être détourné de la même façon qu'un service mal configuré. |
| Informations sensibles stockées localement | Mots de passe en clair dans des scripts d'administration, des fichiers de configuration, ou des outils de déploiement laissés accessibles. |
| Jetons et sessions mal gérés | Dans certaines conditions, un processus peut hériter ou récupérer des informations d'authentification d'un autre compte resté actif sur la même machine (lien direct avec le pass-the-hash vu au chapitre 5). |
| Correctifs de sécurité manquants | Comme sous Linux, des failles connues du système d'exploitation ou de composants installés, non corrigées, permettent une élévation directe. |
Le rôle central des mises à jour et de l'inventaire
Dans un grand nombre d'audits réels, l'élévation de privilèges la plus simple à confirmer reste liée à un défaut de mise à jour : des correctifs de sécurité connus, publiés depuis longtemps, mais non appliqués sur certaines machines du parc, souvent par oubli ou par crainte d'un impact sur des logiciels métier anciens. C'est pourquoi un audit sérieux commence toujours par vérifier l'état des correctifs avant de chercher des configurations plus subtiles : c'est souvent la piste la plus rentable en termes de temps investi, et elle rejoint directement la méthodologie de priorisation du chapitre 3.
La démarche, depuis l'intérieur de la machine
Comme pour Linux, la démarche reprend la logique de la reconnaissance, appliquée depuis le compte limité déjà obtenu :
- Identifier le compte courant, ses groupes et ses privilèges explicitement accordés ;
- Inventorier les logiciels et services installés, et leur état de mise à jour ;
- Repérer les services ou programmes exécutés avec des privilèges élevés dont les fichiers ou l'emplacement seraient modifiables par le compte courant ;
- Rechercher des informations sensibles laissées dans des fichiers de configuration, des scripts d'administration ou des outils de déploiement ;
- Documenter chaque piste, comme pour toutes les phases précédentes du cours.
Des outils d'audit spécialisés existent également dans cet écosystème pour automatiser une partie de cet inventaire, avec la même réserve que pour Linux : ils orientent la recherche, mais ne remplacent pas la compréhension du contexte précis de la machine et de l'organisation.
Un exemple générique, sans commande d'exploitation
Décrivons, toujours de façon purement narrative, un scénario de labo : un service installé sur une machine Windows d'entraînement s'exécute avec des privilèges élevés, mais son dossier d'installation reste modifiable par un utilisateur standard, à la suite d'une erreur de configuration lors de l'installation du logiciel. Un utilisateur standard pourrait, en théorie, remplacer le programme exécuté par ce service, pour qu'à son prochain démarrage (automatique ou provoqué par un redémarrage), le contenu modifié s'exécute avec les privilèges du service, donc des privilèges plus élevés que ceux du compte initial.
La cause profonde est, encore une fois, un écart entre les privilèges d'exécution d'un programme et les permissions accordées sur ses propres fichiers : exactement le même principe que pour Linux, appliqué à un mécanisme différent (les services Windows plutôt que les tâches planifiées ou les bits de privilège).
Les défenses correspondantes
- Appliquer les correctifs de sécurité de façon régulière et systématique, sur l'ensemble du parc, pas seulement sur les machines jugées critiques ;
- Vérifier les permissions des dossiers et fichiers associés aux services qui s'exécutent avec des privilèges élevés, en particulier après l'installation de logiciels tiers ;
- Limiter le nombre de comptes à privilèges élevés et leur usage aux seules tâches qui le justifient réellement ;
- Éviter de laisser des comptes à privilèges élevés ouverts sur des postes de travail courants, pour limiter ce qu'un attaquant pourrait y récupérer ;
- Auditer régulièrement les services et logiciels installés, en particulier ceux ajoutés en dehors d'un processus de déploiement standardisé ;
- Centraliser et surveiller les journaux d'authentification et d'élévation de privilèges, pour détecter rapidement une tentative suspecte.
Pourquoi ce sujet est si central dans un rapport de pentest
L'élévation de privilèges change fondamentalement l'impact d'une mission : un accès limité à un simple compte d'utilisateur courant a un impact restreint, tandis qu'un accès administrateur sur une machine, ou pire, sur l'ensemble d'un domaine, peut représenter un contrôle quasi total du système d'information. C'est pourquoi une mission de type « red team » (que vous rencontrerez dans le dernier cours du parcours) considère souvent l'obtention de privilèges d'administration de domaine comme l'un de ses objectifs les plus significatifs à démontrer, dans un cadre strictement défini et autorisé.
À vous de jouer : prioriser une liste de constats
Un scan d'audit fictif sur un parc Windows remonte ces trois constats : (a) plusieurs machines n'ont pas reçu de correctifs de sécurité depuis plusieurs mois ; (b) un service installé par un logiciel tiers s'exécute avec des privilèges élevés et son dossier d'installation est modifiable par tout utilisateur standard ; (c) un script de déploiement contient un mot de passe administrateur en clair, accessible en lecture à tous les utilisateurs du domaine. En vous appuyant sur la grille de priorisation du chapitre 3 (exposition, criticité, facilité d'exploitation, intérêt pour la progression), classez ces trois constats du plus urgent au moins urgent et justifiez votre classement en une phrase chacun.
Voir une solution
Un classement défendable : (c) en premier, car un mot de passe administrateur en clair, accessible largement, ne demande presque aucune compétence technique pour être exploité et ouvre potentiellement un accès très large (facilité d'exploitation maximale, intérêt pour la progression très élevé) ; (b) ensuite, car il permet une élévation de privilèges locale fiable mais nécessite d'abord un accès à la machine concernée ; (a) enfin, en tant que risque réel mais plus diffus, qui dépend de la faille précise corrigée par les correctifs manquants, à vérifier au cas par cas. D'autres classements argumentés sont recevables : l'essentiel est la justification explicite, pas un ordre unique et absolu.
À retenir
- Sous Windows, les comptes à privilèges élevés d'un domaine peuvent avoir un impact sur un très grand nombre de machines, ce qui amplifie les conséquences d'une compromission.
- Les causes fréquentes : services mal configurés, logiciels tiers aux permissions trop larges, informations sensibles stockées localement, correctifs manquants.
- Vérifier l'état des correctifs reste souvent la piste la plus rentable et la plus simple à confirmer dans un audit.
- La défense repose sur la mise à jour systématique, l'audit des permissions de services, le moindre privilège et la surveillance des journaux.
- L'obtention de privilèges d'administration est souvent l'objectif le plus significatif d'une mission de type red team.
Une fois des privilèges élevés obtenus, un attaquant cherche souvent à garder un accès durable. La leçon suivante aborde ce sujet du point de vue défensif : comment détecter la persistance.