Il y a des semaines où le travail le plus utile n'est pas celui qu'on montre. Avant de me remettre sur des labs offensifs, j'ai passé un long moment à remettre de l'ordre dans ma base de connaissances personnelle — un wiki interne où j'archive chaque méthodologie d'audit, chaque protocole de test, chaque fiche technique accumulée depuis le début de ma formation. Ce n'est qu'une fois ce ménage fait que j'ai pu reprendre deux exercices bien plus concrets : une chaîne d'exploitation sur une application vulnérable, et un CTF centré sur l'intégration continue.
Ranger avant d'attaquer
Documenter au fil de l'eau, c'est facile à dire et plus difficile à tenir. À force d'enchaîner les labs, les brouillons s'accumulent, les fiches restent à moitié classées, certaines études de cas ne sont même pas encore reliées au sommaire du site. J'ai donc pris le temps de trier : republier les fiches en attente, nettoyer les doublons de brouillons, vérifier que chaque catégorie (Pentest, Active Directory, Forensics, Réseau, GRC) pointe bien vers ses bonnes pages, et reconstruire le site pour m'assurer qu'aucun lien ne pointait dans le vide.
C'est un exercice ingrat mais qui paie : une base de connaissances qu'on ne peut plus retrouver n'a aucune valeur, aussi bonne soit la méthodologie qu'elle contient. Et c'est précisément avec cette base remise d'aplomb que j'ai enchaîné sur deux nouveaux cas.
AWSGoat M2 — quand une petite faille en cache une plus grosse
Le premier cas portait sur le module Payroll d'AWSGoat, une application volontairement vulnérable. Le point de départ était classique : un formulaire de connexion qui laissait passer une injection SQL, suffisante pour usurper l'identité d'un compte au niveau de privilège intermédiaire. Rien d'extraordinaire en soi — sauf que ce premier accès a ouvert la porte à un second problème, bien plus intéressant : un paramètre d'identifiant, dans une requête de mise à jour de profil, qui n'était jamais comparé à la session de l'utilisateur connecté.
Résultat : depuis un compte intermédiaire, il devenait possible de modifier les informations d'un compte de niveau supérieur — jusqu'à en écraser le mot de passe. Deux failles prises séparément auraient été gênantes ; mises bout à bout, elles offraient une prise de contrôle totale sur le compte super-admin, sans jamais connaître le moindre mot de passe légitime. C'est ce genre de chaînage qui me rappelle pourquoi une faille "mineure" mérite toujours d'être creusée jusqu'au bout plutôt que cochée comme accessoire.
CTF Wonderland — empoisonner un pipeline
Le second terrain de jeu était un CTF construit autour de Jenkins, Gitea et GitLab, où l'objectif n'était plus d'attaquer une application mais la chaîne qui la construit et la déploie. Chaque challenge cachait un secret dans le credential store Jenkins, accessible uniquement en réussissant à faire exécuter du code dans un pipeline qu'on ne contrôle pas directement.
La technique de base — injecter une étape dans un Jenkinsfile puis déclencher un build via une pull request — a suffi pour deux des quatre challenges. Le troisième demandait une approche différente : aucune trace dans l'état courant du dépôt, mais un secret oublié quelque part dans l'historique Git, retrouvé en triant chronologiquement des centaines de commits pour repérer l'intrus. Le quatrième, lui, m'a résisté : la mécanique reliant un pipeline de test à un pipeline de production restait floue en fin de session, et je l'ai laissé de côté plutôt que de forcer une piste bancale.
La leçon la plus transférable de ces quatre challenges tient en une phrase : le masquage automatique des secrets dans les logs Jenkins (****) ne reconnaît que la valeur brute exacte. Il suffit de transformer la donnée avant de l'afficher — un simple encodage — pour qu'elle traverse le filtre sans être repérée. Une astuce toute bête, mais qui en dit long sur la différence entre une protection qui coche une case et une protection qui tient vraiment la route.
Ce que je retiens
Ranger une base de connaissances et empoisonner un pipeline n'ont l'air d'avoir rien en commun. Pourtant les deux exercices demandent la même discipline : suivre un fil jusqu'au bout, ne pas s'arrêter à la première explication qui semble suffisante, et accepter qu'un quart du travail reste parfois inachevé d'une session à l'autre. Le CTF continue, la base de connaissances continue de grossir — et c'est très bien ainsi.