Mouvements latéraux — Atelier pratique

Vous montez un contrôleur de domaine Active Directory volontairement mal configuré et une station d'attaque Kali, tous les deux en Docker. Vous partez d'un accès réseau minimal et vous progressez, étape par étape, jusqu'à lire un fichier réservé à un compte de service.

Ce que vous saurez faire

• Provisionner un domaine AD complet en une commande, sans machine virtuelle Windows.
• Enchaîner reconnaissance, password spray, énumération des partages, fuite de credentials et bascule d'identité — la chaîne d'attaque la plus fréquente en pentest interne en 2026.
• Rédiger un compte rendu défendable devant un client, avec la mesure corrective attendue à chaque maillon.

Plan de l'atelier

1. Démarrer le lab
2. Étape 1 — reconnaissance réseau
3. Étape 2 — password spray
4. Étape 3 — énumération des partages
5. Étape 4 — lecture du partage team-notes
6. Étape 5 — bascule d'identité vers svc_sql
7. Étape 6 — lecture du flag
8. Rapport
9. Liste de vérification
10. Nettoyage

Ce qu'il vous faut

• Docker Desktop 4.x lancé (Windows, macOS ou Linux).
• Le repository inskillsec-docusaurus cloné localement.
• Environ 4 Go d'espace disque et 3 Go de RAM libres.

Démarrer le lab

cd inskillsec-docusaurus/labs/docker/module-10-mouvements-lateraux
docker compose up -d

Le premier boot prend une bonne minute côté DC (provision du domaine, création des utilisateurs, mise en place des partages). L'attaquant attend automatiquement que le DC soit healthy avant de démarrer. Vous pouvez suivre la provision :

docker logs -f m10-dc01

Quand vous voyez la ligne [m10] === Daemon en premier plan ===, la provision est terminée. Ouvrez alors un shell sur l'attaquant :

docker compose exec attaquant bash

Vous êtes maintenant dans un Kali sur le réseau 10.20.30.0/24 avec comme cible dc01.corp.acme.local en 10.20.30.10.

Étape 1 — reconnaissance réseau

Vous n'avez aucun credential. Vous scannez le DC pour identifier les ports classiques d'un contrôleur de domaine.

nmap -Pn -p22,53,88,135,139,389,445,464,636,3268,3269 10.20.30.10

Ce que vous devez voir :

• 88/tcp (Kerberos) et 464/tcp (Kerberos password change) ouverts — signature typique d'un DC.
• 389/tcp et 636/tcp (LDAP et LDAPS) ouverts.
• 445/tcp (SMB) ouvert.
• 3268/tcp et 3269/tcp (global catalog) ouverts.

Notez chaque port dans votre rapport : c'est votre carte du terrain.

Pourquoi on cible ces ports plutôt que d'autres

Un DC Windows expose une signature réseau très reconnaissable. La combinaison Kerberos + LDAP + global catalog est quasi impossible à confondre avec une autre application. Si vous scannez tout un /24 de serveurs, l'apparition de ces ports vous dit immédiatement « c'est le DC, concentrez-vous ici ». Le reste (SMB, RPC endpoint mapper) est ouvert sur beaucoup de serveurs Windows non-DC.

Étape 2 — password spray

Vous supposez trois noms d'utilisateurs communs (alice, bob, svc_sql) et vous testez une petite wordlist de mots de passe saisonniers.

echo -e "alice\nbob\nsvc_sql" > /tmp/users.txt
echo -e "Summer2025!\nWinter2024!\nPassword1" > /tmp/passwords.txt

crackmapexec smb 10.20.30.10 \
  -u /tmp/users.txt \
  -p /tmp/passwords.txt \
  --continue-on-success

Repérez les lignes qui commencent par [+] : elles indiquent une authentification réussie. Vous devez obtenir au moins bob:Summer2025!.

Pourquoi ces trois utilisateurs et pas d'autres

Dans un pentest réel, la liste d'utilisateurs vient d'OSINT (LinkedIn, site corporatif, fuite de mail). Ici on la simule : on parie que l'entreprise a une comptable (alice), un support niveau 1 (bob) et au moins un compte de service SQL Server (svc_sql). Cette liste minimale prouve un point important : quelques bons noms suffisent pour amorcer le spray. Vous n'avez pas besoin d'une liste de 500 utilisateurs pour trouver le premier accès.

Pourquoi limiter à trois mots de passe

Le password spray se distingue du brute force par sa discrétion : quelques mots de passe testés contre beaucoup d'utilisateurs, sans jamais dépasser la politique de verrouillage. Trois candidats saisonniers, c'est déjà suffisant pour trouver des comptes RH, support ou nouveaux arrivants qui n'ont pas encore changé leur mot de passe. Si vous testez trop, vous verrouillez des comptes et l'admin détecte l'attaque.

Étape 3 — énumération des partages

Depuis le contexte de bob, listez les partages accessibles :

crackmapexec smb 10.20.30.10 -u bob -p 'Summer2025!' --shares

Vous devez voir apparaître :

Partage	Permissions	Commentaire
sysvol	READ	Partage AD standard, souvent vide
netlogon	READ	Partage AD standard, souvent vide
team-notes	READ	Notes internes de l'équipe support
backups	(aucun)	Refus — c'est notre cible finale

bob peut lire team-notes mais pas backups. C'est là qu'on va chercher un pivot.

Étape 4 — lecture du partage team-notes

smbclient '//10.20.30.10/team-notes' -U 'bob%Summer2025!' \
  -c 'ls; mget *; exit'

Vous récupérez deux fichiers : README-Onboarding.txt et deploy-notes.md. Lisez-les :

cat README-Onboarding.txt
cat deploy-notes.md

Cherchez toute mention de mot de passe, de credential, d'account. Vous devez tomber sur cette phrase dans README-Onboarding.txt :

connecte-toi avec le compte de service svc_sql. Le mot de passe est "Password1"

Vous tenez le pivot : svc_sql:Password1.

Ce que ce finding prouve dans un rapport

Un credential en clair dans un partage accessible à tout utilisateur authentifié, c'est le finding pentest numéro 1 en 2026. Il combine trois défauts :

1. Un partage ouvert trop largement (à tous les utilisateurs du domaine au lieu d'un groupe restreint).
2. Un mot de passe de service qui n'a pas été changé (Password1 utilisé depuis 2 ans d'après l'onboarding).
3. Un onboarding qui recommande de communiquer les mots de passe par fichier partagé au lieu d'un coffre.

Chacun de ces points doit apparaître explicitement dans la section « mesures correctives » de votre rapport.

Étape 5 — bascule d'identité vers svc_sql

Vérifiez d'abord que svc_sql a bien accès à backups, alors que bob n'y avait pas droit :

smbclient '//10.20.30.10/backups' -U 'bob%Summer2025!' -c 'ls' 2>&1 | head -3
# → NT_STATUS_ACCESS_DENIED

smbclient '//10.20.30.10/backups' -U 'svc_sql%Password1' -c 'ls' 2>&1 | head -5
# → liste des fichiers

C'est bien la même ressource et le refus tombe uniquement grâce à l'identité qui change. Vous venez de latéraliser sans exploit — juste avec un credential mal rangé.

Étape 6 — lecture du flag

smbclient '//10.20.30.10/backups' -U 'svc_sql%Password1' \
  -c 'get secret.txt /tmp/flag.txt; exit'

cat /tmp/flag.txt

Cherchez la ligne qui commence par Le drapeau que vous cherchez :. Le flag attendu est :

FLAG-M10-CREDENTIAL-LEAK-CHAIN-2026

Sauvegardez-le, il ira dans votre rapport.

Rapport

Écrivez rapport/lateralisation-m10.md dans le volume monté (/home/pentester/labs/rapport/) avec cinq sections :

1. Résumé exécutif — deux phrases : « en partant d'un accès réseau seul, j'ai obtenu la lecture d'un partage réservé à un compte de service ». Précisez le chemin en une ligne.
2. Chaîne d'attaque — une liste ordonnée des six étapes ci-dessus, avec pour chacune la commande exacte et une capture ou un extrait de sortie.
3. Faiblesses identifiées — un point par maillon : mot de passe faible sur bob, partage team-notes trop ouvert, credential en clair dans un fichier, mot de passe de service jamais changé.
4. Mesures correctives — pour chaque faiblesse, une action concrète (politique de mot de passe, coffre-fort d'équipe, restriction du partage à un groupe support, rotation programmée des comptes de service, migration vers gMSA).
5. Preuves — les commandes exécutées, les fichiers récupérés, le flag final. Un lecteur qui n'a pas assisté à l'attaque doit pouvoir la rejouer sans vous poser de questions.

Liste de vérification

• docker compose up -d a terminé sans erreur et docker compose ps montre les deux conteneurs running avec dc01 healthy.
• nmap a listé les ports AD attendus (88, 389, 445 au minimum).
• Le password spray a trouvé au moins bob:Summer2025!.
• crackmapexec --shares a listé team-notes accessible en lecture et backups en refus depuis bob.
• Vous avez lu README-Onboarding.txt et repéré le credential de svc_sql en clair.
• bob ne peut pas lire backups (NT_STATUS_ACCESS_DENIED) mais svc_sql le peut.
• Vous avez récupéré secret.txt et le flag FLAG-M10-CREDENTIAL-LEAK-CHAIN-2026.
• Votre rapport lateralisation-m10.md contient les cinq sections attendues.

Ce que ce lab n'aborde pas

• Kerberoasting fonctionnel. Les SPN sont visibles sur svc_sql et svc_backup (vous pouvez le vérifier avec impacket-GetUserSPNs), mais l'implémentation Kerberos de Samba AD 4.19+ rejette les requêtes TGS d'impacket avec KRB_AP_ERR_INAPP_CKSUM. Le concept est traité dans la leçon 10.1. Pour l'exploiter en vrai, allez sur HackTheBox Forest ou TryHackMe Attacktive Directory qui utilisent un vrai AD Windows.
• AS-REP Roasting — même raison, Samba force la pré-authentification.
• NTLM relay — demanderait un client Windows dans le compose. C'est aussi traité en théorie dans 10.1.

Nettoyage

Quand vous avez terminé :

cd inskillsec-docusaurus/labs/docker/module-10-mouvements-lateraux
docker compose down -v

Le -v supprime aussi les volumes qui contiennent la base LDAP AD, le sysvol et les partages. Le prochain up repartira d'un domaine fraîchement provisionné.