Las vulnerabilidades de ejecución remota de código pueden permitir que un atacante pase de una aplicación vulnerable al sistema operativo que la aloja. Aunque la vulnerabilidad inicial puede diferir de un producto a otro, la actividad de postexplotación suele producir relaciones entre procesos similares que los defensores pueden supervisar.

Una señal especialmente útil es un proceso de aplicación o de servidor web que lanza inesperadamente un shell de comandos, un motor de scripts o una utilidad del sistema. En Windows, esto puede dar visibilidad del punto en el que la explotación de la aplicación se convierte en ejecución en el equipo.

De la explotación de aplicaciones web a los comandos del sistema

La detección se centra en procesos del lado del servidor como IIS, WSUS, Tomcat, Java, Apache, Nginx, PHP y Node.js. Estos procesos normalmente tienen patrones de ejecución predecibles. Cuando empiezan a crear procesos secundarios como cmd.exe, powershell.exe, pwsh.exe, wscript.exe, mshta.exe, rundll32.exe, certutil.exe, bitsadmin.exe o curl.exe, la actividad merece ser investigada.

La fuente asocia este comportamiento con RCE que afecta a SharePoint, WSUS, aplicaciones alojadas en IIS, SAP en Windows, consolas de administración web y vulnerabilidades relacionadas con deserialización o carga de archivos.

Una cadena de procesos sospechosa puede tener este aspecto:

w3wp.exe → powershell.exe

o:

java.exe → cmd.exe

La relación entre procesos no es en sí misma una prueba de compromiso, pero puede indicar que una aplicación del lado del servidor ha empezado a ejecutar comandos fuera de su flujo normal.

Consulta de detección

data.win.system.eventID:1 and data.win.eventdata.parentImage:(*\w3wp.exe or *\wsusservice.exe or *\tomcat*.exe or *\java.exe or *\httpd.exe or *\nginx.exe or *\php-cgi.exe or *\php.exe or *\node.exe) and data.win.eventdata.image:(*\cmd.exe or *\powershell.exe or *\pwsh.exe or *\wscript.exe or *\cscript.exe or *\mshta.exe or *\rundll32.exe or *\regsvr32.exe or *\certutil.exe or *\bitsadmin.exe or *\curl.exe)

La fuente registró 15,523 coincidencias durante los 30 días anteriores.

Por qué importa el número de resultados

Un número elevado de coincidencias no significa automáticamente que se hayan producido miles de ataques. Los servidores de aplicaciones a veces ejecutan scripts o utilidades de línea de comandos por motivos operativos legítimos. Las aplicaciones Java pueden llamar a comandos de shell, las aplicaciones Node.js pueden invocar intérpretes de comandos y los sistemas alojados en IIS pueden ejecutar scripts administrativos.

Por esa razón, esta consulta funciona bien como punto de partida para la búsqueda proactiva de amenazas. El primer objetivo debe ser comprender qué combinaciones de proceso principal y secundario generan el volumen.

Algunas agrupaciones útiles son:

• proceso padre;

• proceso secundario;

• nombre de host;

• cuenta de servicio o usuario;

• línea de comandos;

• ruta de ejecución;

• frecuencia.

Si la mayoría de los eventos provienen de un servidor de aplicaciones conocido que lanza repetidamente el mismo script aprobado, ese comportamiento puede documentarse. Sin embargo, un evento poco frecuente de w3wp.exe → powershell.exe en un servidor expuesto a Internet puede merecer una investigación inmediata.

Investigar eventos sospechosos

La línea de comandos es uno de los campos más importantes que revisar. Un script administrativo conocido tiene un perfil de riesgo muy distinto al de un comando de PowerShell codificado inesperado, una URL de descarga externa o un comando que realiza descubrimiento.

Los analistas también deben revisar la actividad inmediatamente anterior y posterior al evento de creación del proceso. Algunas preguntas útiles son:

• ¿Recibió la aplicación solicitudes inusuales antes de que se iniciara el proceso?

• ¿Creó el proceso secundario procesos adicionales?

• ¿Escribió archivos en directorios temporales o de aplicaciones?

• ¿Realizó conexiones de red salientes?

• ¿Modificó la configuración de seguridad o mecanismos de persistencia?

• ¿Se produjo actividad similar en otros sistemas?

Cuanto más sólida sea la evidencia circundante, mayor confianza podrá depositar el SOC en la detección.

Ajuste de la detección

La detección debe ajustarse con cuidado. Exclusiones amplias, como ignorar todos los eventos java.exe → cmd.exe o w3wp.exe → powershell.exe, podrían eliminar una valiosa visibilidad de seguridad.

Un mejor enfoque es crear excepciones acotadas mediante combinaciones como:

equipo conocido + ruta de proceso conocida + línea de comandos conocida + cuenta de servicio conocida

Esto conserva la detección basada en comportamiento y reduce el ruido operativo esperado.

De regla de búsqueda a regla de detección

Una vez comprendida la actividad normal del entorno, la misma consulta puede convertirse en una alerta más precisa. Las variantes de alto valor pueden centrarse en relaciones poco frecuentes entre proceso principal y secundario, equipos inesperados, líneas de comandos inusuales, descargas externas o ejecución desde ubicaciones con permiso de escritura para el usuario.

El principio clave es sencillo: los servicios web y de aplicaciones no deberían comportarse inesperadamente como usuarios interactivos. Supervisar el momento en que empiezan a lanzar shells o utilidades del sistema puede proporcionar una señal valiosa para detectar RCE y actividad de postexplotación.