
Une simulation complète de réponse à incident pour centre d'opérations de sécurité (SOC), illustrant la détection des menaces, le triage, l'analyse et l'atténuation de la vulnérabilité Spring4Shell (CVE-2022-22965).

Une simulation pratique de Centre d'opérations de sécurité (SOC) dans laquelle j'ai joué le rôle d'un analyste en sécurité de l'information répondant à une tentative d'exploitation active de Spring4Shell. Ce dépôt documente l'intégralité du cycle de vie de la réponse à incident — de la détection initiale à l'analyse et à l'atténuation.
Avertissement : Ce projet a été réalisé dans le cadre d'une simulation de poste en cybersécurité sur Forage à des fins pédagogiques. Toute l'analyse a été menée dans un environnement contrôlé et simulé.
Spring4Shell est une vulnérabilité critique d'exécution de code à distance dans le framework Spring. Elle permet aux attaquants d'exploiter le mécanisme de liaison de paramètres pour obtenir un accès non autorisé aux propriétés des classes Java, ce qui peut conduire à une exécution de code à distance complète.
Objectif : Analyser les journaux du pare-feu pour identifier l'infrastructure compromise, évaluer la sévérité de la menace et notifier l'équipe appropriée.
L'examen des journaux du pare-feu a révélé un schéma de requêtes HTTP/1.1 POST suspectes ciblant /tomcatwar.jsp, contenant toutes des chaînes de paramètres class.module.classLoader — l'indicateur de signature de l'exploitation de Spring4Shell.

| Champ | Détail |
|---|---|
| Infrastructure concernée | Services critiques NBN |
| Niveau de priorité | P1 — Critique |
| Vecteur d'attaque | CVE-2022-22965 (Spring4Shell) |
| État actuel | Service indisponible ; fonctionnalités dégradées |
| Horodatage de détection | 2022-03-20T03:21:00Z |
Après avoir confirmé la menace, j'ai rédigé et envoyé une notification d'incident à l'équipe NBN avec un résumé précis de la situation, des systèmes concernés et des actions immédiates requises.

Objectif : Mener une analyse plus approfondie des schémas d'attaque, comprendre les mécanismes d'exploitation et élaborer des règles de pare-feu pour contenir la menace.
À partir de l'analyse de la structure des requêtes POST dans les journaux du pare-feu :
/tomcatwar.jspclass.module.classLoader.resources.context.parent.pipeline.first.patternUne approche multicouche a été utilisée pour bloquer l'attaque à chaque étape :
| Règle | Action | Justification |
|---|---|---|
Bloquer les requêtes vers les points de terminaison *.jsp | DROP | Empêche l'accès au webshell |
Bloquer les requêtes POST contenant class.module.classLoader.resources.context.parent.pipeline.first | DROP | Bloque directement le mécanisme d'exploitation |
Bloquer les opérations d'écriture vers webapps/ROOT/tomcatwar*.jsp | DENY | Empêche la persistance du webshell |
Après avoir défini la stratégie d'atténuation, j'ai communiqué les règles de pare-feu requises à l'équipe Réseau avec le contexte technique complet de l'attaque en cours.

class.module.classLoader présentes dans les données HTTP POST/tomcatwar.jsppipeline.first.pattern