
Una simulación integral de respuesta a incidentes de un Centro de Operaciones de Seguridad (SOC) que demuestra la detección, triaje, análisis y mitigación de la vulnerabilidad Spring4Shell (CVE-2022-22965).

Una simulación práctica de un Centro de Operaciones de Seguridad (SOC) donde desempeñé el rol de Analista de Seguridad de la Información respondiendo a un intento activo de explotación de Spring4Shell. Este repositorio documenta el ciclo completo de respuesta a incidentes — desde la detección inicial hasta el análisis y la mitigación.
Aviso: Este proyecto se completó como parte de una simulación laboral en ciberseguridad en Forage con fines educativos. Todo el análisis se realizó en un entorno controlado y simulado.
Spring4Shell es una vulnerabilidad crítica de ejecución remota de código en Spring Framework. Permite a los atacantes explotar el mecanismo de enlace de parámetros para obtener acceso no autorizado a las propiedades de clases Java, lo que puede llevar a una ejecución remota de código completa.
Analizar los registros del firewall para identificar la infraestructura comprometida, evaluar la gravedad de la amenaza y notificar al equipo correspondiente.
La revisión de los registros del firewall reveló un patrón de peticiones HTTP/1.1 POST sospechosas dirigidas a /tomcatwar.jsp, todas conteniendo cadenas de parámetros class.module.classLoader — el indicador característico de la explotación de Spring4Shell.

| Campo | Detalle |
|---|---|
| Infraestructura afectada | Servicios críticos de NBN |
| Nivel de prioridad | P1 — Crítico |
| Vector de ataque | CVE-2022-22965 (Spring4Shell) |
| Estado actual | Servicio caído; funcionalidad afectada |
| Marca de tiempo de detección | 2022-03-20T03:21:00Z |
Tras confirmar la amenaza, redacté y envié una notificación de incidente al equipo de NBN con un resumen preciso de la situación, los sistemas afectados y las acciones inmediatas requeridas.

Objetivo: Realizar un análisis más profundo de los patrones de ataque, comprender la mecánica de explotación y desarrollar reglas de firewall para contener la amenaza.
Del análisis de la estructura de las peticiones POST en los registros del firewall:
/tomcatwar.jspclass.module.classLoader.resources.context.parent.pipeline.first.patternSe utilizó un enfoque de múltiples capas para bloquear el ataque en cada etapa:
| Regla | Acción | Justificación |
|---|---|---|
Bloquear peticiones a endpoints *.jsp | DROP | Evita el acceso al webshell |
Bloquear peticiones POST que contengan class.module.classLoader.resources.context.parent.pipeline.first | DROP | Bloquea directamente el mecanismo de explotación |
Bloquear operaciones de escritura en webapps/ROOT/tomcatwar*.jsp | DENY | Detiene la persistencia del webshell |
Después de definir la estrategia de mitigación, comuniqué las reglas de firewall requeridas al equipo de Redes con todo el contexto técnico del ataque en curso.

class.module.classLoader presentes en datos HTTP POST/tomcatwar.jsppipeline.first.pattern