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.
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.
- 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)
Regla para patrones jndi en peticiones + salida LDAP/RMI desde servidores de app + procesos hijo inesperados de la JVM.