SOC Maison : Laboratoire de Détection des Menaces avec Wazuh + Suricata

Un laboratoire de Security Operations Center auto-hébergé conçu pour détecter des techniques d'attaque réelles contre une cible délibérément vulnérable, en utilisant Wazuh comme SIEM et Suricata comme capteur IDS basé sur le réseau. Conçu pour démontrer des compétences en ingénierie de détection — pas seulement le déploiement d'outils.

Aperçu

Le travail moderne dans un SOC ne se résume pas à « installer un SIEM et regarder le tableau de bord ». Il s'agit de comprendre pourquoi un écart de détection existe, et savoir comment le combler. Ce laboratoire simule un petit environnement réaliste : une machine attaquante, une cible legacy/vulnérable sans support de journalisation natif, et une pile SIEM qui doit contourner cette contrainte en utilisant la visibilité au niveau réseau plutôt que des agents hôtes.

Décision architecturale clé : la cible (Metasploitable 2) exécute un OS trop ancien pour supporter un agent Wazuh moderne, voire un transmetteur syslog avec accès Internet. Plutôt que de considérer cela comme un obstacle, le projet se tourne vers la détection entièrement basée sur le réseau via Suricata — un modèle réaliste pour les actifs legacy, IoT ou OT qui ne peuvent pas être instrumentés directement.

Architecture

┌─────────────┐         attaques          ┌──────────────────────┐
│   Kali VM   │ ────────────────────────▶│   Metasploitable 2   │
│ (attaquant +│                           │  (victime non       │
│  Suricata   │                           │   surveillée, sans  │
│  capteur +  │                           │   agent, sans       │
│  agent Wazuh│                           │   accès Internet)   │
└──────┬──────┘                           └──────────────────────┘
       │ eve.json (alertes/événements Suricata)
       │ transmis via l'agent Wazuh
       ▼
┌─────────────────────┐
│ Gestionnaire Wazuh   │
│ (Amazon Linux 2023)  │
│ Indexeur + Tableau   │
│ de bord              │
└─────────────────────┘

Les trois VMs s'exécutent sur VirtualBox, en réseau NAT sur 192.168.0.0/24.

Pourquoi Suricata s'exécute sur la machine de l'attaquant

Suricata a besoin de visibilité sur le trafic entre l'attaquant et la cible. Deux options existent : une VM dédiée avec une interface en mode promiscuous/miroir, ou exécuter le capteur sur l'un des deux hôtes déjà dans le chemin du trafic. Comme le gestionnaire Wazuh (Amazon Linux 2023) ne prend pas en charge EPEL et a rendu l'installation de Suricata peu pratique, et que la cible ne peut exécuter aucun agent, Suricata s'exécute directement sur la machine Kali. Cela signifie qu'il voit 100 % du trafic d'attaque sur sa propre interface sans nécessiter de mode promiscuous ni de port span, et transmet ses événements au gestionnaire via l'agent Wazuh déjà enrôlé sur Kali.

Détections

1. Reconnaissance — Détection de scan Nmap

Attaque :

nmap -sV -A 192.168.0.138

Détection : Le jeu de règles Emerging Threats de Suricata a signalé plusieurs signatures liées aux scans et anomalies de protocole en temps réel alors que le scan touchait chaque port ouvert, y compris le trafic sur le service UnrealIRCd exposé de Metasploitable (ET CHAT IRC USER command).

Résultat : 132+ événements IDS générés et correctement classés sous les groupes de règles ids, suricata dans la vue Threat Hunting de Wazuh en quelques secondes après la fin du scan.

2. Exploitation — Backdoor vsftpd 2.3.4 (CVE-2011-2523)

Attaque :

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 > set RHOSTS 192.168.0.138
msf6 > set LHOST 192.168.0.200
msf6 > run

Le vsftpd 2.3.4 de Metasploitable contient une backdoor déclenchée par une chaîne de connexion FTP malformée, qui génère un shell root sur le port TCP 6200. L'exploit a atterri proprement et a renvoyé une session Meterpreter en tant que root.

Détection : La signature GPL ATTACK_RESPONSE id check returned root de Suricata (SID 2100498) a déclenché 11 secondes après que le shell ait été généré, correspondant à la chaîne en clair uid=0(root) dans la sortie de commande du shell alors qu'elle traversait le fil sur le port 6200.

"signature": "GPL ATTACK_RESPONSE id check returned root",
"signature_id": 2100498,
"src_ip": "192.168.0.138",
"src_port": 6200,
"dest_ip": "192.168.0.200",
"direction": "to_client"

Pourquoi c'est important : c'est la confirmation au niveau réseau d'une compromission root réussie sur un actif avec zéro journalisation basée sur l'hôte — exactement le scénario pour lequel l'architecture a été conçue.

3. Attaque par identifiants — Force brute FTP (MITRE ATT&CK T1110)

Attaque :

hydra -l msfadmin -P /tmp/quicklist.txt -t 4 ftp://192.168.0.138

Hydra a tenté plusieurs connexions FTP en succession rapide, identifiant correctement la paire d'identifiants valide msfadmin:msfadmin après plusieurs tentatives échouées.

Statut de détection : Le parseur de protocole FTP de Suricata a capturé chaque commande USER/PASS individuelle et code de réponse serveur dans eve.json (event_type: ftp), confirmé présent dans l'archive brute d'événements du gestionnaire :

{"event_type":"ftp","src_ip":"192.168.0.200","dest_ip":"192.168.0.138",
 "dest_port":21,"ftp":{"command":"PASS","command_data":"root",
 "completion_code":["530"],"reply":["Login incorrect."]}}

Le jeu de règles par défaut de Suricata n'a pas de signature dédiée pour la force brute FTP, car c'est un motif de protocole plutôt qu'une chaîne malveillante connue. Une règle de corrélation Wazuh personnalisée a été conçue pour combler cette lacune :

<group name="suricata,ftp,brute_force,">
  <rule id="100100" level="5">
    <if_sid>86600</if_sid>
    <field name="event_type">^ftp$</field>
    <field name="data.ftp.command">^PASS$</field>
    <description>Suricata: FTP password attempt detected on $(data.dest_ip)</description>
  </rule>

  <rule id="100101" level="10" frequency="4" timeframe="60">
    <if_matched_sid>100100</if_matched_sid>
    <description>Suricata: Possible FTP brute force attack detected - multiple password attempts within 60 seconds</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Statut : en cours — les données d'événement sous-jacentes sont confirmées comme arrivant au gestionnaire, et la syntaxe de la règle est validée via wazuh-logtest, mais la règle de corrélation (100101) ne se déclenche pas encore de manière fiable de bout en bout. La prochaine étape de débogage consiste à confirmer le chemin du champ du décodeur attribué aux champs FTP imbriqués de Suricata lors de l'analyse via wazuh-logtest sur un échantillon en direct. Suivi comme travail futur ci-dessous.

Leçons apprises

• Les cibles héritées changent votre architecture, pas seulement vos commandes. La chaîne d'outils obsolète de Metasploitable 2 a exclu un agent Wazuh moderne et même un transfert syslog de base (pas de rsyslog, pas d'accès Internet). Plutôt que de forcer une approche basée sur l'hôte, le projet s'est tourné vers la détection basée sur le réseau — sans doute un modèle plus réaliste pour les actifs hérités/IoT du monde réel.
• Les écosystèmes de paquets ne sont pas interchangeables. La base Amazon Linux 2023 du gestionnaire Wazuh ne prend pas en charge le classique EPEL, ce qui a bloqué une installation directe de Suricata. Déplacer le capteur vers la machine Kali basée sur Debian, qui se trouvait déjà dans le chemin du trafic, a contourné complètement le problème.
• Les jeux de règles IDS par défaut sont basés sur des signatures, pas comportementaux. Suricata a attrapé l'exploit vsftpd instantanément car une signature connue existait pour cela, mais n'avait rien pour la force brute FTP car c'est un motif, pas une chaîne statique. C'est la véritable justification pour écrire des règles de corrélation personnalisées dans un SIEM plutôt que de se fier uniquement au contenu IDS prêt à l'emploi.
• archives.log/archives.json ne sont pas activés par défaut (logall/logall_json sont no par défaut) et sont essentiels pour déboguer ce qu'un SIEM a réellement reçu par rapport à ce sur quoi il a choisi d'alerter.

Travail futur

• Terminer le débogage de la règle de corrélation de force brute FTP (100100/100101) de bout en bout
• Ajouter l'exploitation de la backdoor UnrealIRCd (CVE-2010-2075) comme quatrième détection, puisque Suricata signale déjà le trafic IRC sur la cible
• Ajouter RCE Samba usermap_script (CVE-2007-2447) pour une cinquième technique
• Acheminer les alertes de haute sévérité vers TheHive ou Shuffle pour la création automatisée de cas
• Ajouter une réponse active pour bloquer automatiquement l'IP de l'attaquant lors de détections répétées de force brute

Outils utilisés

• Wazuh 4.14.6 — SIEM (gestionnaire, indexeur, tableau de bord)
• Suricata 8.0.5 — IDS réseau
• Metasploit Framework / Hydra / Nmap — simulation d'attaque
• VirtualBox — virtualisation de laboratoire

Cartographie MITRE ATT&CK