Étude de cas — Projet de groupe, EPITA
Plateforme SOC & observabilité : ce que les seuils standards laissent passer
Un lab Red Team vs. Blue Team à six personnes : déployer un attaquant et une cible sur AWS, relier la cible à un SIEM Wazuh, puis exécuter quatre scénarios d’attaque réels contre elle — de la reconnaissance silencieuse à une compromission complète par force brute — et prouver que chacun est détecté, corrélé et expliqué.
4
Scénarios d'attaque, 4 détections personnalisées
Wazuh
Plateforme SIEM / XDR cloud
Niv. 10
Alerte personnalisée la plus critique
1 tentative
Reconnaissance détectée avant la force brute
L’environnement du lab
Un unique VPC AWS héberge deux instances EC2 dans le même sous-réseau — une cible Ubuntu 22.04 et un attaquant Kali Linux — avec un accès sortant vers un environnement Wazuh Cloudmanagé servant de SIEM. L’agent Wazuh sur la cible transmet les journaux système (journald, auth.log), les journaux du gestionnaire de paquets et les journaux de pare-feu vers le manager cloud, où des règles et décodeurs corrèlent les événements bruts en alertes sur le tableau de bord. Rien n’est simulé ici — chaque alerte de cette étude de cas provient d’une attaque réellement exécutée contre la machine réelle.
Quatre scénarios, quatre détections
1. Installation de paquet suspecte Règle 100300 · Niveau 8
Les attaquants installent couramment des outils supplémentaires (netcat, nmap) juste après avoir compromis un hôte, pour élargir leur emprise. Une règle personnalisée surveille /var/log/dpkg.log précisément pour cela, en capturant le nom du paquet et l’horodatage afin qu’un analyste puisse distinguer une mise à jour planifiée d’un changement non autorisé en un coup d’œil.
2. Accès SSH non autorisé, utilisateur inexistant Règle 100501 · Niveau 8
La détection de force brute standard se déclenche sur un seuil — cinq tentatives échouées ou plus contre un compte réel. Cela laisse passer une attaque plus discrète : tester si un nom d’utilisateur lui-mêmeest valide, ce qui se traduit par une seule connexion échouée contre un compte qui n’a jamais existé. Une règle personnalisée se base sur la signature sous-jacente « mot de passe échoué pour utilisateur invalide » et se déclenche dès la toute première tentative — une visibilité que les règles standards ne donnent pas.
3. Modification critique de fichier (FIM + élévation de privilèges)
Une fois l’accès shell obtenu, l’attaquant exécute sudo nano /etc/passwd pour implanter un compte backdoor. Deux règles se déclenchent simultanément : le module de surveillance d’intégrité des fichiers de Wazuh détecte le changement de somme de contrôle sur /etc/passwd (Règle 550), tandis qu’une règle distincte signale le sudo réussi vers root (Règle 5402). Aucune des deux alertes ne raconte l’histoire complète à elle seule — le tableau de bord Threat Hunting permet à un analyste de rassembler les deux sur une même chronologie et de voir la commande exacte qui en est à l’origine.
4. Accès initial par force brute SSH Règle 100002 · Niveau 10 (Critique)
Une attaque par dictionnaire Hydra contre la cible — six tentatives de mot de passe, une réussite. L’alerte qui compte n’est pas « connexion échouée », c’est le schéma : une série d’échecs suivie immédiatement d’une réussite sur le même compte. Une règle dédiée de niveau critique distingue cette séquence du bruit de connexion habituel et fait remonter, dans la même alerte, le nom d’utilisateur compromis et l’IP source de l’attaquant.
Pourquoi la règle personnalisée du scénario 2 comptait
Ce fut le scénario le plus instructif, pas le plus spectaculaire. La détection de force brute standard est, par conception, basée sur un seuil — elle attend le volume. C’est précisément le mauvais modèle pour l’énumération de noms d’utilisateur, où un attaquant n’a besoin que d’une seule tentative par hypothèse et ne répète jamais le même nom deux fois. Construire une règle autour de la signature d’échec sous-jacente, plutôt que d’un comptage, est ce qui a permis de détecter la phase de reconnaissance tout court.
<!-- Règle personnalisée : se déclenche dès une seule tentative, pas un seuil -->
<rule id="100501" level="8">
<if_matched_sid>5710</if_matched_sid>
<description>Unauthorized SSH access attempt (non-existing user)</description>
</rule>La corrélation, c’est ça le vrai produit
La leçon la plus claire de ce lab : une connexion échouée isolée ou un changement de fichier isolé paraît bénin en soi. Ce n’est que lorsque le SIEM relie un événement sudoau changement exact d’intégrité de fichier qu’il a provoqué — même hôte, même seconde, même session — que cela devient un récit forensique exploitable, plutôt que deux lignes de journal sans rapport apparent qu’un analyste devrait relier à la main.