Los atacantes que buscan explotar Text4Shell suelen seguir una ruta clara. La técnica principal es una forma de inyección de plantillas del lado del servidor (SSTI). Un atacante identifica un campo de entrada en una aplicación web que pasa datos a la librería vulnerable.

Los TTPs comunes incluyen:

• Inyección de payload: Elaborar una cadena maliciosa con los prefijos script, dns, o url e inyectarla en encabezados HTTP, campos de formulario o parámetros de URL.

• Ejecución remota de código: Usar el prefijo script para ejecutar comandos, lo que podría establecer una shell inversa, descargar malware o empezar a exfiltrar datos.

• Recolección de información: Aprovechar los prefijos dns y url para forzar al servidor a hacer solicitudes salientes a un dominio controlado por el atacante. Esto puede confirmar la vulnerabilidad y filtrar detalles del entorno interno.

Indicadores de compromiso

Detectar un ataque de Text4Shell implica buscar patrones específicos y comportamiento anómalo. Ten cuidado con estos IoCs:

• Cadenas sospechosas como ${script:...}, ${dns:...}, o ${url:...} en los registros de la aplicación y del servidor web.

• Consultas DNS salientes o solicitudes HTTP de tus servidores de aplicaciones hacia dominios inusuales o desconocidos.

• La ejecución de procesos inesperados, especialmente shells (sh, bash, powershell) generados por tu proceso de aplicación Java.

• Creación de archivos extraños en directorios temporales como /tmp/ o C:\Windows\Temp\.

Pruebas de concepto y exploits conocidos

Poco después de su divulgación, surgieron varias PoC para CVE-2022-42889. Los investigadores de seguridad demostraron rápidamente cómo una sola cadena maliciosa enviada a una aplicación vulnerable podía llevar a RCE. Por ejemplo, un simple comando curl dirigido al parámetro de búsqueda de una aplicación web podía ser suficiente:

curl http://vulnerable-app.com/search?query=$\{script:javascript:java.lang.Runtime.getRuntime().exec('id')}

Si el servidor responde con la salida del comando id, es vulnerable. Se liberaron exploits públicos y escáneres, y aunque la fiebre de explotación no fue tan caótica como con Log4Shell, los atacantes definitivamente agregaron Text4Shell a sus kits de escaneo automatizado.