Projet 5 — Sécurité offensive et émulation d'adversaire

Fait partie d'un parcours SOC de laboratoire maison de 5 projets : construire → détecter et enrichir → enquêter → surveiller et chasser → attaquer et recouper.

Ce projet ajoute la moitié manquante du tableau des projets 1 à 4 : tout ce qui précède était l'équipe bleue (construction de détections, investigation d'incidents, chasse dans les données réseau). Celui-ci me place du côté de l'attaquant — reconnaissance, exploitation et post-exploitation contre une vulnérabilité réelle et documentée — puis revient vers le SOC existant pour mesurer ce qu'il a réellement détecté.

Résumé

Chaîne d'attaque en un coup d'œil

Recon (Nmap)  →  Exploit (Metasploit: vsftpd backdoor)  →  Root shell (Meterpreter)
     →  Dump /etc/shadow  →  Crack hash (John)  →  Verify via SSH login
     →  Cross-check against Wazuh / Suricata / Zeek

Principales conclusions

1. Une CVE de 2011 fournit encore aujourd'hui une chaîne d'attaque complète et réaliste — de la reconnaissance initiale à l'accès root en passant par l'exposition d'identifiants, sans aucun durcissement moderne pour faire obstacle sur un hôte non corrigé.
2. L'accès root ne termine pas l'histoire — il en commence une nouvelle. Root m'a permis d'extraire les hachages de mots de passe, d'en casser un instantanément (msfadmin:msfadmin), et de prouver que cela fonctionnait comme un second, indépendant, moyen d'accès au système via SSH simple — ce qui signifie que corriger le bug FTP seul ne sécuriserait pas complètement cet hôte.
3. La cible n'avait aucune visibilité SOC basée sur l'hôte. Aucun agent Wazuh n'était installé sur Metasploitable, donc l'exploit, le shell root et l'accès aux identifiants étaient totalement invisibles pour la surveillance basée sur l'hôte — une illustration directe de « on ne peut pas détecter ce que l'on ne surveille pas. »
4. La surveillance réseau (Zeek) était la seule couche de visibilité disponible — et son fonctionnement a révélé une véritable chaîne de 4 à 5 bogues distincts et séparés, d'une mauvaise interface réseau à un chemin de configuration obsolète en passant par un agent nécessitant un redémarrage complet plutôt qu'un redémarrage en douceur. Détail complet dans docs/04-blue-team-cross-check.md.
5. Suricata (basé sur des signatures) est resté correctement silencieux face à une connexion SSH avec des identifiants valides — une conclusion légitime sur les limites de la détection basée sur les signatures, et non une lacune.

Documentation

• docs/01-reconnaissance.md — Scan Nmap, identification de la vulnérabilité
• docs/02-exploitation.md — Sélection du module Metasploit et exploitation
• docs/03-post-exploitation.md — extraction d'identifiants, cassage, vérification
• docs/04-blue-team-cross-check.md — analyse des lacunes de détection du SOC et la véritable chaîne de débogage derrière tout cela

Environnement de laboratoire

• Kali — hôte physique et machine d'attaque (Nmap, Metasploit, John the Ripper, Suricata, Zeek)
• Metasploitable2 — machine virtuelle cible volontairement vulnérable
• Réseau — adaptateur hôte uniquement VirtualBox (192.168.56.x), le même réseau introduit dans le projet 4 afin que Kali (l'hôte) puisse directement atteindre et surveiller le trafic vers/depuis la cible
• SOC existant (projets 1 à 4) — SIEM Wazuh, IDS Suricata, NSM Zeek, utilisé ici purement comme côté « équipe bleue » de cet engagement

Captures d'écran

Voir screenshots/, organisées par phase.