// Incidente de la semana
Severidad: Crítica #5 · 2026-09-07

Un ${jndi:ldap://…} en el User-Agent contra una app Java

Señales

  • El WAF registra «${jndi:ldap://…}» en la cabecera User-Agent contra una app Java
  • El servidor hace una conexión LDAP saliente a una IP externa justo después
  • El proceso java lanza un /bin/sh hijo
  • Miles de peticiones similares desde IPs distintas

¿Qué haces primero?

▸ Ver la resolución (razonamiento, evidencia, MITRE, detección)
  • A) Se escanea en masa desde miles de IPs: bloquear una es inútil.
  • B) ✅ Correcto. El callback LDAP saliente + el java que lanza una shell confirman explotación CON ÉXITO, no un simple intento. Confirma el alcance (¿qué se descargó/ejecutó?) y mitiga el componente vulnerable.
  • C) Reiniciar puede borrar la evidencia en memoria y no elimina la vulnerabilidad.
  • D) La firma del WAF ayuda como capa extra, pero se puede ofuscar; no confirma ni remedia el compromiso.
Por qué

La diferencia clave: un intento («${jndi…}» en un log) no es un compromiso; el CALLBACK saliente y el proceso hijo sí lo confirman. Prioriza: (1) confirmar explotación con éxito por la telemetría de salida y de procesos, (2) mitigar el componente vulnerable (parche o mitigación temporal), (3) buscar persistencia y movimiento lateral. Bloquear IPs o firmas del WAF son parches de tiempo, no la cura.

Evidencia dónde mirar
  • Access/WAF logs: patrones jndi:ldap/rmi/dns en headers, URI o body
  • Conexiones salientes LDAP/RMI desde el servidor de aplicación
  • La JVM lanza procesos hijo inesperados (cmd/sh) y descargas posteriores (T1105)
Cómo detectarlo

Regla para patrones jndi en peticiones + salida LDAP/RMI desde servidores de app + procesos hijo inesperados de la JVM.

Compártelo como reto y publica luego la resolución.