
Una simulazione completa di risposta agli incidenti per un Security Operations Centre (SOC) che dimostra il rilevamento, il triage, l'analisi e la mitigazione delle minacce legate alla vulnerabilità Spring4Shell (CVE-2022-22965).

Una simulazione pratica di Security Operations Centre (SOC) in cui ho ricoperto il ruolo di analista della sicurezza informatica rispondendo a un tentativo attivo di sfruttamento di Spring4Shell. Questo repository documenta l'intero ciclo di vita della risposta all'incidente — dalla rilevazione iniziale fino all'analisi e alla mitigazione.
Disclaimer: Questo progetto è stato completato come parte di una simulazione lavorativa nel campo della cybersecurity su Forage per scopi educativi. Tutte le analisi sono state condotte in un ambiente controllato e simulato.
Spring4Shell è una vulnerabilità critica di esecuzione remota di codice nel framework Spring. Consente agli attaccanti di sfruttare il meccanismo di binding dei parametri per ottenere accesso non autorizzato alle proprietà delle classi Java, il che può portare alla piena esecuzione remota di codice.
Obiettivo: analizzare i log del firewall per identificare le infrastrutture compromesse, valutare la gravità della minaccia e notificare il team appropriato.
L'esame dei log del firewall ha rivelato uno schema di richieste HTTP/1.1 POST sospette verso /tomcatwar.jsp, tutte contenenti catene di parametri class.module.classLoader — l'indicatore distintivo dello sfruttamento di Spring4Shell.

| Campo | Dettaglio |
|---|---|
| Infrastruttura interessata | Servizi critici NBN |
| Livello di priorità | P1 — Critica |
| Vettore d'attacco | CVE-2022-22965 (Spring4Shell) |
| Stato attuale | Servizio fuori uso; funzionalità compromesse |
| Timestamp di rilevazione | 2022-03-20T03:21:00Z |
Dopo aver confermato la minaccia, ho redatto e inviato una notifica di incidente al team NBN con un riepilogo preciso della situazione, dei sistemi interessati e delle azioni immediate richieste.

Obiettivo: condurre un'analisi più approfondita dei modelli d'attacco, comprendere i meccanismi di sfruttamento e sviluppare regole firewall per contenere la minaccia.
Dall'analisi della struttura delle richieste POST nei log del firewall:
/tomcatwar.jspclass.module.classLoader.resources.context.parent.pipeline.first.patternÈ stato utilizzato un approccio a più livelli per bloccare l'attacco in ogni fase:
| Regola | Azione | Motivazione |
|---|---|---|
Bloccare le richieste verso gli endpoint *.jsp | DROP | Impedisce l'accesso alla webshell |
Bloccare le richieste POST contenenti class.module.classLoader.resources.context.parent.pipeline.first | DROP | Blocca direttamente il meccanismo di sfruttamento |
Bloccare le operazioni di scrittura verso webapps/ROOT/tomcatwar*.jsp | DENY | Interrompe la persistenza della webshell |
Dopo aver definito la strategia di mitigazione, ho comunicato le regole firewall richieste al team di rete con il pieno contesto tecnico dell'attacco in corso.

class.module.classLoader presenti nei dati delle richieste HTTP POST/tomcatwar.jsppipeline.first.pattern