L’utilisateur analyst dispose déjà d’un shell sur lab-linux, et CORP.LOCAL\svcuser se connecte déjà à LAB-WIN01. Aucun de ces points d’ancrage ne correspond à un accès administratif. L’objectif de l’évaluation est de déterminer si une erreur de configuration locale permet à l’un ou l’autre de ces comptes de franchir la frontière des privilèges locaux pour obtenir les droits root ou SYSTEM, et si ce risque peut être démontré sans exécuter d’exploit. Une commande autorisée dans sudoers, un chemin de service modifiable ou des identifiants stockés peuvent constituer une preuve suffisante lorsque le compte, la configuration et les prérequis concordent.
Tous les travaux de ce cours s’effectuent au sein d’environnements de laboratoire hors ligne et figés (Ubuntu 22.04 et Windows Server 2022) dont nous sommes propriétaires ou que nous sommes explicitement autorisés à évaluer. Cette méthode produit des conclusions étayées, et non des charges utiles (payloads), des chaînes d’exploitation ou des techniques de contournement. Sous Ubuntu, une requête sudo et son résultat peuvent laisser des traces d’autorisation dans /var/log/auth.log et dans le journal système, tandis que les activités liées aux privilèges sous Windows doivent être corrélées au journal de sécurité (Security log) ou aux traces relatives au service concerné.
L’environnement de laboratoire figé permet de visualiser la frontière des privilèges ainsi que les emplacements où sont consignées les preuves associées :
Ce schéma illustre pourquoi l’énumération commence au niveau de l’hôte. La configuration pertinente et la preuve de son utilisation se situent généralement de part et d’autre d’une même frontière de privilèges ; par conséquent, pour valider une découverte, il faut disposer des deux éléments, et non simplement d’un paramètre suspect isolé.
Une frontière visible ne garantissant pas l’existence d’un chemin pour la franchir, chaque phase d’énumération produit quatre résultats interdépendants. Une liste d’hypothèses regroupe, par ordre de priorité, les catégories de vecteurs d’attaque possibles, telles que les commandes Linux déléguées, les tâches planifiées, une configuration vulnérable de service Windows ou des identifiants exposés à un compte non administrateur. Une hypothèse ne constitue pas une découverte avérée ; elle ne le devient que lorsque la configuration de l’hôte remplit les prérequis du vecteur.
Par exemple, le simple fait qu’un utilisateur analyst repère un exécutable doté de privilèges élevés ne prouve pas qu’une élévation de privilèges est possible. Il faut déterminer le propriétaire du fichier, vérifier si analyst peut agir sur celui-ci, identifier le composant privilégié qui l’exécute et confirmer si le contexte d’exécution permet réellement d’atteindre le niveau root. Sous Windows, il ne suffit pas de repérer un service ; il faut connaître le compte de service, le chemin d’accès au binaire, les contrôles d’accès ainsi que les permissions détenues par CORP.LOCAL\svcuser.
Ces mêmes éléments permettent de répondre aux questions des équipes de défense. Sous Ubuntu, l’analyse des activités sudo (acceptées ou refusées) permet d’identifier le compte à l’origine de la demande, l’utilisateur cible, le répertoire de travail et la commande exécutée ; les fichiers de configuration tels que /etc/sudoers et /etc/sudoers.d/ expliquent pourquoi l’action a été autorisée. Un défenseur peut comparer ces enregistrements aux règles de délégation établies et générer une alerte en cas d’utilisation inhabituelle de commandes privilégiées ou de modifications imprévues des fichiers de configuration.
Les résultats de l’évaluation permettent de distinguer un chemin d’attaque plausible d’une situation avérée d’élévation de privilèges nécessitant un signalement :