React2Shell: Análisis Forense Completo de un Ataque Real a Next.js/React mediante CVE-2025-55182

React2Shell: Análisis Forense Completo de un Ataque Real a Next.js/React mediante CVE-2025-55182

La Amenaza Silenciosa en Dependencias Críticas
En los últimos días, se detectó un incidente de seguridad crítico asociado a una aplicación Next.js/React que ejecutaba versiones vulnerables. El vector de ataque fue la explotación conocida como React2Shell, derivada del CVE-2025-55182, que permite la Ejecución Remota de Comandos (RCE) a través de una vulnerabilidad de deserialización maliciosa.
La alerta inicial se activó por un simple consumo anómalo de CPU en el host que contenía el servicio. Sin embargo, la investigación posterior, basada en una revisión exhaustiva de los logs, reveló un escenario mucho más complejo: una explotación activa, la descarga de binarios maliciosos, la instalación de mecanismos de persistencia interna y la ejecución de un minero de Monero.
A continuación, se presenta la reconstrucción completa y el análisis forense minuto a minuto del incidente.

🔍 1. Detección y Confirmación: Del Consumo Anómalo a la Intrusión
Síntomas Iniciales en el Host
La investigación comenzó con el monitoreo de recursos. Paralelamente, la revisión de los logs del servidor (host) mostraba actividad de reconocimiento por parte del atacante:
• Intentos reiterados de inicio de sesión SSH.
• Fuzzing web buscando rutas y endpoints vulnerables relacionados con React/Next.
• Tráfico sospechoso proveniente de la misma IP de origen, que coincidía con intentos de explotación del CVE-2025-55182 (React2Shell).
La Confirmación en el Contenedor
Los logs internos del contenedor fueron la prueba definitiva para confirmar la explotación:
• Se registraron comandos ejecutados de forma no autorizada.
• Evidencia de la descarga de binarios y scripts desde una infraestructura de Comando y Control (C2).
• Trazas de ejecución de un shell inyectado mediante la explotación React2Shell.

🧵 2. Descarte de Compromiso en el Host: La Importancia de la Correlación
Durante el análisis del host, se detectaron dos procesos anómalos en memoria con nombres aleatorios y sin un archivo de origen en el disco. Esto sugería, en un primer momento, un posible container breakout con escalada completa al sistema operativo del host.
No obstante, la correlación de logs fue fundamental para refinar el alcance:
• Se determinó que eran procesos huérfanos originados por el contenedor comprometido.
• El host no mostró evidencia de escalada de privilegios ni mecanismos de persistencia.
• No se encontraron binarios persistentes, cron jobs alterados o claves SSH modificadas en el host.
Conclusión clave: El host no fue directamente comprometido con persistencia, lo que limitó el daño y simplificó la contención.

🔬 3. Ingeniería Inversa de Artefactos Maliciosos
La evidencia crucial se recuperó de la revisión manual del contenedor y sus snapshots internos (gestionados por containerd). Se encontró un set completo de artefactos maliciosos en el path /tmp/runnv/. Junto a scripts descargados (setup2.sh).
El análisis de estos archivos reveló la sofisticada operación del atacante:
Ruta Tipo Descripción
…/tmp/runnv/kamd64 ELF 64-bit Binario minero/dropper con alto consumo de recursos
…/tmp/runnv/alive.sh Script Bash Watchdog o Killer de procesos competidores: Monitorea y elimina cualquier proceso que supere aproximadamente el 45% de CPU o procesos «sospechosos» (Python, otros mineros)
…/tmp/runnv/lived.sh Script Bash Auto-arranque del minero; también intentaba bind-mounts en /proc para evadir detección
…/tmp/runnv/runnv.tar.gz Archivo TAR Contenedor del binario minero y su configuración, listo para un posible redeploy
…/tmp/runnv/config.json JSON Configuración del minero (pools Monero y wallet del atacante)

📸 4. Cronología del Ataque (Línea Temporal Reconstruida)
La reconstrucción completa fue posible gracias a la unión de los logs del host y del contenedor.
1. Escaneo y Probing Previo: Antes del ataque final, la IP del atacante (45.61.157.12), asociada a infraestructura de amenazas, ya estaba escaneando los puertos 3000/3010 del servidor, buscando activamente aplicaciones Next.js vulnerables.
2. Explotación React2Shell: A las 21:36 UTC del 8 de diciembre, el atacante aprovechó el CVE-2025-55182 para inyectar un comando y lograr un shell remoto dentro del contenedor.
3. Descarga y Ejecución del Dropper: El comando inyectado ejecutó un dropper binario (ELF) que inició la cadena de ataque.
4. Container Escape (Breach del Contenedor): En segundos, el binario activó un container escape, aprovechando que el contenedor corría con privilegios de root y acceso directo al filesystem del host.
o Resultado: El atacante logró ejecutar código fuera del contenedor, accediendo al host real.
5. Ejecución del Minero y Scripts de Persistencia:
o Se instaló un minero de Monero funcional directamente en el host.
o El consumo de CPU se disparó de inmediato (400%–500%).
o El minero estaba altamente optimizado (RandomX) y diseñado para: autoajustarse, evitar eliminarse a sí mismo y minar de forma agresiva.
6. Persistencia Interna del Contenedor: Aunque el atacante no logró persistencia en el host, sí desplegó una estructura persistente en el contenedor comprometido, bajo el path de containerd.
7. Procesos Fantasma: El payload lanzado post-breakout generó dos procesos maliciosos en el host:
o Un binario con nombre falso (fghgf).
o Ejecutándose como root y consumiendo hasta 500% de CPU.
o Estos procesos no tenían un archivo asociado en el filesystem del host (eran binarios cargados desde memoria o el contenedor), razón por la cual parecían «fantasma».
8. Contención: La eliminación inmediata del contenedor comprometido detuvo instantáneamente toda actividad maliciosa, confirmando la dependencia de los procesos fantasma y del minero en la fuente de origen (el contenedor).

🧭 5. Conclusión: Dos Aprendizajes Críticos de un Incidente Real
1. Las Dependencias Desactualizadas son la Mayor Superficie de Ataque
Es posible tener un código de aplicación impecable, sin endpoints expuestos y con buenas prácticas. Sin embargo, si el framework, las librerías o el runtime están desactualizados, la aplicación sigue siendo vulnerable.
Este incidente ocurrió únicamente porque la aplicación ejecutaba versiones de React/Next afectadas por la vulnerabilidad React2Shell (CVE-2025-55182).
Acción Inmediata: Mantener las dependencias actualizadas no es opcional, es una medida de seguridad fundamental en el ciclo de vida del desarrollo.
2. Los Logs, la Herramienta Forense Definitiva
Registrar logs no es suficiente. La capacidad de revisarlos, correlacionarlos y analizarlos es lo que permite resolver un caso de intrusión.
Este análisis forense fue exitoso gracias a la triple capa de logs:
• Logs del Host: Para detectar el reconocimiento inicial (fuzzing, SSH brute force, probing).
• Logs del Contenedor: Para capturar el punto de compromiso (comandos ejecutados, shells inyectados).
• Logs del Runtime/Snapshots: Para recuperar la evidencia persistente (artefactos maliciosos, binarios).
Sin este nivel de detalle forense, habría sido imposible determinar el alcance exacto (descartar el compromiso del host) y reconstruir la línea temporal del ataque.