Reconnaissance active — Atelier pratique

Vous refaites la démonstration seul(e). Trois conteneurs, une méthodologie propre, un rapport que vous remettriez à un client. C'est le squelette de la reconnaissance qui vous suivra dans toute votre carrière.

Compter : 90 min à 2 h.

Livrable : ~/labs/rapport/reconnaissance.md (2 pages) et tous les artefacts dans ~/labs/scans/ + ~/labs/captures/.

Le lab en une commande

Le module 01 a introduit le lab Docker à un conteneur. Ici on passe à trois conteneurs sur le même réseau privé : un attaquant Kali et deux cibles au profil très différent, pour vous forcer à faire varier vos scans. Le compose fait tout le travail :

cd labs/docker/module-04-recon-active
docker compose up -d

Trente secondes plus tard, vous avez un réseau 10.20.30.0/24 avec trois machines dedans. Comme si vous scanniez un vrai segment interne.

---

Ce que vous devez livrer

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

1. scans/decouverte.txt — sortie de l'ARP scan initial.
2. scans/12-ports.nmap + scans/20-ports.nmap — scans TCP complets par cible.
3. scans/12-versions.nmap + scans/20-versions.nmap — scans de versions.
4. scans/20-nse.nmap — scripts NSE ciblés sur les vulnérabilités attendues.
5. scans/20-udp.nmap + scans/20-snmp.txt — recon UDP et inventaire SNMP.
6. scans/20-smb.txt — énumération SMB (partages, utilisateurs, politique).
7. scans/12-web.txt — reconnaissance web (whatweb, gobuster, curl).
8. captures/scan-syn.pcap — trace tcpdump d'un scan SYN.
9. scans/scapy-verification.txt — sortie du script Scapy.
10. rapport/reconnaissance.md — deux pages, structure imposée.

---

Prérequis

Vous devez avoir terminé le module 01 : Docker Desktop opérationnel, image inskillsec/kali-lab déjà construite. Sinon, référez-vous à l'atelier du module 01 pour le premier build (une dizaine de minutes).

Vérification rapide :

docker images inskillsec/kali-lab
docker info | grep -i "operating"

Si inskillsec/kali-lab n'est pas listée, le compose la construira à la première commande — patientez.

---

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

cd labs/docker/module-04-recon-active
docker compose up -d

Trois conteneurs démarrent : l'attaquant (10.20.30.5), la cible Linux riche (10.20.30.20) et la cible web propre (10.20.30.12).

Vérifiez santé :

cd ..
./verifier-lab.sh module-04-recon-active     # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-04-recon-active    # PowerShell

Vous devez voir trois services running. Si m04-cible-linux reste en starting, patientez trente secondes de plus : Metasploitable 2 lance beaucoup de services (Apache, Samba, MySQL, PostgreSQL, distccd, SNMP…) avant d'être prêt.

Entrez dans l'attaquant :

cd module-04-recon-active
docker compose exec attaquant bash

Créez la structure de sortie :

mkdir -p ~/labs/{scans,captures,rapport}
cd ~/labs

Définition — pourquoi ce lab a besoin de cap_add: NET_ADMIN, NET_RAW

Un conteneur Docker classique tourne avec un ensemble restreint de capabilities Linux. Il ne peut pas modifier ses interfaces réseau, ni forger des paquets bruts (SYN sans ACK par exemple), ni faire tourner tcpdump. C'est bien pour un serveur web, c'est mortel pour un lab offensif.

Deux capacités sont indispensables ici. NET_RAW autorise l'ouverture de sockets raw, celles que Nmap utilise pour -sS (SYN scan), celles que Scapy utilise pour construire un paquet à la main, celles que arp-scan et tcpdump utilisent pour lire directement les trames Ethernet. NET_ADMIN autorise la manipulation des routes et la modification des interfaces — utile pour certains scripts NSE et pour arp-scan sur certains kernels.

Le compose du module 04 les ajoute au seul conteneur attaquant :

cap_add:
  - NET_ADMIN
  - NET_RAW

Les cibles n'y ont pas droit — elles n'ont aucune raison de scanner quoi que ce soit. C'est le principe du moindre privilège, appliqué au niveau conteneur.

---

Étape 2 — Découverte de couche 2 (5 min)

Le point de départ de toute reconnaissance interne : qui parle sur ce segment ?

sudo arp-scan --interface=eth0 --localnet | tee scans/decouverte.txt

Vous voyez trois lignes (ou quatre, avec la gateway 10.20.30.1 du réseau Docker). Notez les deux IPs cibles :

export CIBLE_LINUX=10.20.30.20
export CIBLE_WEB=10.20.30.12

Une découverte alternative, sans ARP :

sudo nmap -sn 10.20.30.0/24 -oN scans/decouverte-nmap.txt

Les deux méthodes doivent renvoyer le même nombre d'hôtes. Un écart révélerait un problème dans votre lab.

Définition — pourquoi ARP est la découverte la plus fiable en interne

Sur un segment de réseau local, chaque hôte doit connaître l'adresse MAC de ses voisins pour leur envoyer un paquet. Ce mécanisme, ARP, ne peut pas être filtré : même une machine avec ICMP bloqué, TCP filtré, tous les ports fermés, doit répondre à une requête ARP pour rester joignable de sa passerelle. C'est un protocole de couche 2, en dessous de tout ce qu'un pare-feu applicatif peut voir.

C'est pour cela qu'un attaquant sérieux commence toujours par ARP quand il est sur le segment. Un ping sweep (nmap -sn) suffit sur beaucoup de réseaux, mais sur un LAN où les stations sont durcies et refusent ICMP, ARP reste le seul moyen fiable de compter les hôtes vivants. Prendre l'habitude dès la semaine 1 vous évitera de manquer la moitié d'un réseau dans une vraie mission.

Attention : ARP ne fonctionne que sur le même segment que vous. Si votre attaquant est routé vers un autre VLAN, ARP ne remonte plus rien. Dans ce cas, il faut soit pivoter, soit passer aux découvertes réseau (ICMP, TCP SYN sur des ports probables).

---

Étape 3 — Ports TCP (10 min)

Scannez tous les ports TCP sur chaque cible. En Docker, le lien est parfait, on peut monter en cadence :

sudo nmap -sS -Pn -p- --min-rate 4000 $CIBLE_LINUX -oN scans/20-ports.nmap
sudo nmap -sS -Pn -p- --min-rate 4000 $CIBLE_WEB   -oN scans/12-ports.nmap

À vérifier :

• 10.20.30.20 ouvre une vingtaine de ports (21, 22, 23, 25, 53, 80, 111, 139, 445, 512-514, 1099, 1524, 2049, 2121, 3306, 3632, 5432, 5900, 6000, 6667, 8009, 8180…). Le profil d'un serveur historiquement mal maintenu.
• 10.20.30.12 n'ouvre que le port 80. Un serveur récent, bien tenu, un seul rôle. Le profil de la moitié des sites web modernes.

Notez, dans rapport/, le nombre exact de ports ouverts par cible. Une cible avec plus de vingt ports ouverts est presque toujours un lab volontaire ou un serveur oublié en production. C'est un signal fort dès la lecture du rapport exécutif.

---

Étape 4 — Versions (10 min)

Récupérez les listes de ports ouverts et relancez -sV uniquement sur ces ports :

sudo nmap -sV -p 80 $CIBLE_WEB -oN scans/12-versions.nmap

sudo nmap -sV -p 21,22,23,25,53,80,111,139,445,512-514,1099,1524,2049,3306,3632,5432,5900,6000,6667,8009,8180 \
                 $CIBLE_LINUX -oN scans/20-versions.nmap

Regardez ce que Nmap révèle :

grep -E "vsftpd|OpenSSH|Samba|MySQL|Apache|Postgres|distcc" scans/20-versions.nmap
grep -E "nginx|X-Powered" scans/12-versions.nmap

Vous devriez lire :

• vsftpd 2.3.4 (le vieux copain du module 01)
• Samba smbd 3.X - 4.X
• MySQL 5.0.51a
• Apache/2.2.8
• distccd v1
• nginx 1.27.x (Server header non caché)

Livrable : dans rapport/, pour chaque cible, notez les 5 services les plus intéressants avec leur version exacte. C'est votre matériau pour la partie « Résultats » du rapport.

---

Étape 5 — Scripts NSE ciblés (10 min)

Les scripts NSE (Nmap Scripting Engine) transforment Nmap d'un scanner de ports en outil de confirmation de vulnérabilités. On lance uniquement des scripts pertinents pour ce qu'on a trouvé — jamais --script vuln en aveugle, qui peut casser des services.

Sur la cible Linux :

sudo nmap --script "ftp-vsftpd-backdoor,smb-vuln-cve2009-3103,smb-enum-shares,smb-os-discovery,http-vuln-*" \
  -p 21,80,139,445 $CIBLE_LINUX -oN scans/20-nse.nmap

Sur la cible web :

sudo nmap --script "http-headers,http-title,http-methods,http-robots.txt,http-enum" \
  -p 80 $CIBLE_WEB -oN scans/12-nse.nmap

Livrable : dans rapport/, la liste des CVE confirmées par NSE avec l'IP concernée et la référence CVE. Pour la cible Linux, vous devriez retrouver la backdoor vsftpd 2.3.4 (CVE-2011-2523) et probablement Samba usermap (CVE-2007-2447).

Définition — pourquoi jamais nmap --script vuln en balayage large

--script vuln regroupe environ 150 scripts NSE, dont certains sont destructeurs. Certains testent une vulnérabilité en provoquant volontairement le comportement dangereux — un buffer overflow qui crashe le service, une requête SQL qui verrouille une table, un envoi malformé qui met un routeur en boucle.

En laboratoire, aucun problème. En production chez un client, un --script vuln bien placé peut mettre une base de données hors ligne pour trois heures. Vous avez le contrat qui vous autorise à tester, vous n'avez pas le contrat qui vous autorise à casser.

La règle : on lance NSE par catégorie précise, en fonction de ce que le scan de versions a révélé. Vous voyez du SMB ? smb-vuln-* ciblé. Vous voyez du HTTP ? http-headers, http-methods. Vous voyez du FTP ? ftp-anon, ftp-vsftpd-backdoor. Chaque script cité en clair dans votre commande, avec la logique dans le rapport. C'est aussi ce qui permet au client de rejouer vos scans pour vérifier ses correctifs.

---

Étape 6 — UDP et SNMP (10 min)

UDP est plus lent et souvent oublié. C'est précisément pour ça qu'il faut y aller.

sudo nmap -sU --top-ports 25 $CIBLE_LINUX -oN scans/20-udp.nmap

Si SNMP (161/udp) est ouvert :

snmpwalk -v 2c -c public $CIBLE_LINUX sysDescr
snmpwalk -v 2c -c public $CIBLE_LINUX hrSWRunName > scans/20-snmp.txt
snmpwalk -v 2c -c public $CIBLE_LINUX iso.3.6.1.2.1.4.20 >> scans/20-snmp.txt

Testez d'autres communities fréquentes :

onesixtyone -c /usr/share/wordlists/onesixtyone/dict.txt $CIBLE_LINUX -o scans/20-community-strings.txt

Livrable : le nombre de communities SNMP trouvées et un résumé de l'inventaire (OS, processus, interfaces) dans rapport/.

Définition — SNMP, la trésorerie oubliée des réseaux d'entreprise

SNMP (Simple Network Management Protocol) date de 1988. Il sert à monitorer et administrer à distance switches, routeurs, imprimantes, serveurs — n'importe quoi qui tourne un agent. La version 1 utilise une community string, un mot de passe partagé en clair, presque toujours laissée à sa valeur par défaut : public en lecture, private en écriture.

Ce qui rend SNMP fabuleux pour un attaquant : lu en clair, il fournit la totalité de l'inventaire logiciel et matériel de la machine. Version du système, liste des processus, adresses réseau, tables ARP, tables de routage, utilisateurs connectés, partages montés. Sur un vrai réseau, un snmpwalk sur un serveur bien configuré est meilleur qu'un whoami; ip addr; ps aux; ss -tunap combinés.

La version 3 corrige tout — authentification, chiffrement, contrôle d'accès. Mais en 2026, la majorité des switches et des imprimantes tournent encore en SNMPv1/v2c avec public intacte. C'est un indicateur presque parfait de la maturité d'un réseau : un environnement où SNMP n'est jamais joignable en public a été audité. Ailleurs, c'est votre porte d'entrée la plus riche.

---

Étape 7 — Énumération SMB profonde (15 min)

Le port 445 est votre meilleur ami en interne. Sur Metasploitable 2, il est ouvert et fuit à peu près tout ce qu'un domaine peut fuir.

# Bannière + signing
nxc smb $CIBLE_LINUX

# Partages en session nulle (sans identifiant)
nxc smb $CIBLE_LINUX -u '' -p '' --shares > scans/20-shares.txt

# Utilisateurs par RID cycling
enum4linux-ng -R $CIBLE_LINUX -oJ scans/20-rid.json

# Politique de mot de passe
enum4linux-ng -P $CIBLE_LINUX > scans/20-policy.txt

# Tout dans un fichier lisible
enum4linux $CIBLE_LINUX > scans/20-smb.txt 2>&1

Livrable : dans rapport/, notez :

• si signing: False (permet le relais NTLM)
• la liste des partages accessibles en session nulle (typiquement tmp en écriture sur Metasploitable 2)
• le nombre d'utilisateurs énumérés
• la politique de mot de passe (longueur minimale, verrouillage)

---

Étape 8 — Reconnaissance web (15 min)

La cible web ne présente aucune vulnérabilité exploitable. Mais elle fuit énormément dès qu'on gratte. C'est le cas de la moitié des sites web internes que vous scannerez en mission.

# Fingerprint applicatif
whatweb -a 3 http://$CIBLE_WEB > scans/12-web.txt
echo "---" >> scans/12-web.txt

# Headers et status
curl -s -I http://$CIBLE_WEB/ >> scans/12-web.txt
echo "---" >> scans/12-web.txt

# robots.txt et sitemap
curl -s http://$CIBLE_WEB/robots.txt >> scans/12-web.txt
echo "---" >> scans/12-web.txt
curl -s http://$CIBLE_WEB/sitemap.xml >> scans/12-web.txt
echo "---" >> scans/12-web.txt

# Force brute des paths (petite liste ciblée)
gobuster dir -u http://$CIBLE_WEB \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -q -o scans/12-gobuster.txt

# Consulter les paths intéressants trouvés
for p in "/admin/" "/api/v1/" "/backup/" "/.env.example" "/package.json"; do
  echo "=== $p ==="
  curl -s -o /dev/null -w "HTTP %{http_code}\n" http://$CIBLE_WEB$p
done > scans/12-paths.txt

# Récupérer le .env.example et le package.json
curl -s http://$CIBLE_WEB/.env.example  > scans/12-env-example.txt
curl -s http://$CIBLE_WEB/package.json  > scans/12-package.txt

Regardez ce que fuit .env.example :

cat scans/12-env-example.txt

Vous y trouvez : le nom du serveur SMB (dev-server), le port MySQL, un utilisateur en lecture seule (intranet_ro). C'est exactement le genre d'artefact laissé dans les dépôts publics par distraction, et qui donne à un attaquant sa toute première liste de comptes à tester.

Et le package.json :

cat scans/12-package.txt

Il expose une version applicative précise et toutes les dépendances avec leurs versions. Avec ça, vous pouvez chercher les CVE connues de chaque dépendance sur nvd.nist.gov — sans même toucher la cible.

Définition — les « information disclosures » silencieux, ces fuites qui ne cassent rien

L'OWASP ne classe pas la fuite d'information dans le Top 10 comme critique — parce qu'à elle seule, elle ne compromet rien. Pas de shell obtenu, pas de mot de passe exfiltré, pas de donnée client exposée. Un .env.example sur un serveur, ce n'est pas une brèche, c'est un fichier légitime.

Mais dans la vraie vie d'un attaquant, ces fuites sont le carburant de tout le reste. Le nom d'un serveur interne cité dans un exemple de configuration devient une IP à cibler. Une liste de dépendances avec versions devient une liste de CVE candidates. Une adresse mail d'admin laissée dans un commentaire HTML devient une cible de phishing. Un banner Nginx en 1.14.0 devient un ticket de reconnaissance pour tenter les CVE de cette branche.

C'est pour ça qu'un audit sérieux consacre du temps à ces trouvailles, même quand elles ne conduisent nulle part en isolation. Le rapport client les liste sous « exposition d'information », avec la recommandation implicite : retirez ces fichiers ou masquez ces headers, non parce qu'ils sont exploitables directement, mais parce qu'ils font gagner à l'attaquant les vingt heures qu'il aurait passées à deviner.

---

Étape 9 — Capture tcpdump (10 min)

Pas de Wireshark en Docker (pas d'interface graphique). On capture avec tcpdump, on ouvre le PCAP sur son hôte avec Wireshark.

Dans un premier terminal du conteneur attaquant :

sudo tcpdump -i eth0 -w captures/scan-syn.pcap host $CIBLE_LINUX and tcp

Dans un second terminal du conteneur attaquant (docker compose exec attaquant bash depuis votre hôte) :

sudo nmap -sS -p 22,80,445,3389 10.20.30.20

De retour dans le premier terminal, Ctrl+C sur tcpdump.

Vérifiez la capture :

tcpdump -r captures/scan-syn.pcap -c 20
capinfos captures/scan-syn.pcap    # si disponible

Sur votre hôte, le fichier apparaît dans labs/docker/module-04-recon-active/attaquant-home/captures/scan-syn.pcap. Ouvrez-le avec Wireshark local.

Appliquez le filtre :

tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.dst == 10.20.30.20

Comptez les paquets envoyés, vérifiez que la source est bien 10.20.30.5 (l'attaquant).

Livrable : le PCAP + une capture d'écran de Wireshark montrant le filtre.

---

Étape 10 — Scapy en exercice (5 min)

Écrivez scapy_check.py dans ~/labs/ :

#!/usr/bin/env python3
from scapy.all import IP, TCP, sr1

CIBLES = {
    "10.20.30.20": [21, 22, 23, 80, 139, 445, 3306],
    "10.20.30.12": [80, 443, 22],
}

for ip, ports in CIBLES.items():
    print(f"\n=== {ip} ===")
    for p in ports:
        r = sr1(IP(dst=ip) / TCP(dport=p, flags="S"), timeout=2, verbose=0)
        if r is None:
            print(f"  {p}/tcp  filtered")
        elif r.haslayer(TCP):
            flags = int(r[TCP].flags)
            if flags == 0x12:
                print(f"  {p}/tcp  open   (SYN/ACK)")
            elif flags & 0x04:
                print(f"  {p}/tcp  closed (RST)")
            else:
                print(f"  {p}/tcp  ?      (flags={hex(flags)})")

Exécutez :

sudo python3 scapy_check.py | tee scans/scapy-verification.txt

Livrable : la sortie doit correspondre à ce que Nmap a dit à l'étape 3. Un écart = un problème à comprendre — mauvaise interface, filtrage discret, capacité manquante.

---

Étape 11 — Rédiger le rapport (25 min)

Ouvrez rapport/reconnaissance.md. Deux pages. Pas plus.

# Rapport de reconnaissance — Lab semaine 4 (date)

## 1. Résumé exécutif (5 lignes maximum)
Cartographie de deux hôtes dans le segment 10.20.30.0/24. Deux profils
opposés : un serveur Linux historique très bavard, et un intranet nginx
correctement configuré mais qui fuit son inventaire logiciel.
Priorités pour la phase suivante : 1) vsftpd 2.3.4, 2) Samba usermap,
3) énumération des comptes MySQL sans mot de passe.

## 2. Périmètre et méthode
- Réseau : 10.20.30.0/24, réseau Docker bridge, isolé.
- Attaquant : Kali 10.20.30.5 (conteneur inskillsec/kali-lab).
- Méthode : ARP → ping sweep → SYN scan tous ports → -sV ciblé →
  NSE par catégorie → UDP top-25 → énumération SMB → reconnaissance web →
  vérification Scapy.

## 3. Résultats — 10.20.30.20 (cible Linux, "dev-server")
- OS : Ubuntu 8.04 (SNMP + banner Apache).
- Ports TCP notables : 21, 22, 80, 139, 445, 3306, 3632, 5432, 5900, 8180…
- Vulnérabilités confirmées par NSE :
  - CVE-2011-2523 (vsftpd 2.3.4 backdoor)
  - CVE-2007-2447 (Samba usermap script)
- Comptes énumérés par session nulle : root, msfadmin, user, service…
- SNMP community "public" : inventaire complet lisible.
- Partage /tmp accessible en écriture par session nulle.
- Priorité 1 pour exploitation : vsftpd backdoor (facile, silencieuse).

## 4. Résultats — 10.20.30.12 (cible web, "intranet")
- Serveur : nginx 1.27.x, header Server bavard.
- Applicatif : Intranet-App 2.3.1 (Node.js).
- Aucune CVE confirmée directement.
- Expositions d'information :
  - /.env.example — fournit nom du serveur SMB et compte MySQL ro.
  - /package.json — expose 8 dépendances avec versions.
  - /admin/ et /api/v1/ existent mais protégés (401/403).
  - robots.txt liste 17 paths internes qui n'existent pas forcément
    tous, mais montrent l'architecture attendue.
- Priorité pour exploitation : chercher des CVE sur les 8 dépendances
  listées dans package.json.

## 5. Plan pour les modules 5 à 8
1. Exploiter vsftpd 2.3.4 (déjà éprouvé en module 01).
2. Exploiter Samba usermap script (Metasploit).
3. Extraire les hashs de tous les comptes locaux.
4. Réutiliser les identifiants extraits contre l'intranet.

## 6. Artefacts
- scans/12-ports.nmap, scans/20-ports.nmap : scans TCP complets.
- scans/12-versions.nmap, scans/20-versions.nmap : scans de versions.
- scans/12-nse.nmap, scans/20-nse.nmap : NSE ciblés.
- scans/20-udp.nmap, scans/20-snmp.txt : recon UDP.
- scans/20-smb.txt, scans/20-rid.json, scans/20-policy.txt : SMB.
- scans/12-web.txt, scans/12-gobuster.txt, scans/12-env-example.txt : web.
- captures/scan-syn.pcap : capture tcpdump.
- scans/scapy-verification.txt : vérification indépendante Scapy.

---

Grille d'auto-évaluation

• scans/decouverte.txt contient deux IPs cibles.
• Deux fichiers *-ports.nmap — tous ports TCP scannés.
• Deux fichiers *-versions.nmap — détection de versions.
• Scan NSE ciblé par cible (jamais --script vuln en aveugle).
• Scan UDP top-25 sur la cible Linux.
• Sortie snmpwalk sauvegardée si SNMP ouvert.
• Énumération SMB : bannière + partages + utilisateurs + politique.
• Reconnaissance web : whatweb + gobuster + .env.example + package.json.
• Capture tcpdump d'un scan SYN, PCAP ouvrable dans Wireshark hôte.
• Script Scapy exécuté, sortie sauvegardée, cohérente avec Nmap.
• Rapport de 2 pages structuré selon le modèle ci-dessus.
• Aucune commande n'a été lancée en dehors du sous-réseau 10.20.30.0/24.

---

Ce qui bloque en général

Symptôme	Cause probable	Correction
arp-scan : permission denied	Capabilities NET_RAW non ajoutées	Vérifier cap_add: dans le compose, docker compose down puis up -d.
nmap -sS refusé	Idem — pas de socket raw	Idem.
tcpdump ne montre rien	Mauvaise interface	ip -brief address dans le conteneur pour trouver l'interface Docker.
-sV marque unknown partout	Cible pas encore prête	Attendre 30 s, docker compose ps doit afficher healthy pour la cible.
SNMP ne répond pas	Metasploitable 2 pas encore chaud	Attendre 30 s de plus, ou docker compose restart cible-linux.
enum4linux-ng très lent	Normal — beaucoup d'appels RPC	Patienter, ce n'est jamais rapide.
gobuster : connection refused	cible-web en cours de redémarrage	docker compose logs cible-web, vérifier syntaxe nginx.
Wireshark n'ouvre pas le PCAP	Chemin sur l'hôte, pas dans le conteneur	Prendre le fichier dans labs/docker/module-04-recon-active/attaquant-home/captures/.

---

Ce que vous emportez de cet atelier

• Une méthodologie de scan reproductible à la lettre en 90 minutes, valable pour n'importe quel segment interne.
• Un rapport de reconnaissance que vous pouvez, tel quel, glisser en annexe d'un pentest client.
• La compréhension du coût en bruit de chaque option Nmap.
• L'habitude de capturer votre propre trafic — c'est le premier pas vers l'évasion en red team.
• Une liste ordonnée de vulnérabilités à exploiter dans les modules 5, 7, 8, 9.
• Une preuve concrète qu'un site sans vulnérabilité exploitable peut fuir une quantité choquante d'information — leçon à faire retenir à vos clients.

Prochaine étape : le quiz du module. Puis on entre dans la chair du pentest — la recherche et l'exploitation de vulnérabilités.