Cazar o ser cazado: los cazadores de HuntIQ se enfrentan al php2shell

¿Qué ocurrió?

En October 20, 2026, los identificadores de dos vulnerabilidades críticas de PHP se filtraron en Internet un día antes de su publicación coordinada, y PHP adelantó la publicación de su corrección a la mañana siguiente. Para entonces, el primer intento de explotación ya había afectado a los honeypots de Amazon en October 17. El parche en sí consiste en una actualización del paquete. Lo más complicado era saber dónde se encontraba cada copia de PHP.

PHP gestiona una gran parte de la web, motivo por el cual SANS elevó el nivel de amenaza de su Internet Storm Center a «amarillo» el día del lanzamiento (SANS ISC (se abre en una nueva pestaña)). Wiz, uno de los equipos que ha informado sobre ello, estima que las vulnerabilidades afectan a aproximadamente el 70 % de Internet (Wiz (se abre en una nueva pestaña)). Los propios avisos de seguridad de PHP señalan que el mayor riesgo lo presenta el módulo PHP integrado en Apache, donde una sola solicitud puede llegar a la vulnerabilidad antes de que se ejecute ningún código de la aplicación, y advierten de que los cambios en la configuración solo suponen una mitigación parcial (Aviso de seguridad de PHP (se abre en una nueva pestaña)).

Cómo transcurrió el primer día

Se informó a los cazadores de HuntIQ la misma tarde en que se filtraron los identificadores, y el equipo de The Guardian abrió un canal de respuesta esa misma noche. PHP publicó las correcciones relacionadas con 14:00 UTC en October 21. En menos de una hora, el contenido de HuntIQ sobre ataques incluía tres casos de explotación posterior: shells y herramientas de descubrimiento iniciadas por un proceso de PHP o de un servidor web, código PHP y ejecutables escritos por dichos procesos, y binarios de PHP más antiguos que las versiones corregidas.

Aquella noche, en un laboratorio aislado, un investigador de HuntIQ reprodujo ambas cadenas de ejecución remota de código contra PHP 8.5.11 y logró ejecutar comandos con los privilegios de la cuenta del servicio web de Apache. En tan solo un día, el equipo fue un paso más allá de lo que habían logrado los exploits públicos: llevó a cabo el ataque únicamente a través de HTTP, sorteando la aleatorización de direcciones mediante una fuga de memoria en banda, contra un servidor del que no disponía de información privilegiada. Al ejecutarlas contra la versión corregida de PHP 8.5.12, las mismas cadenas y sus variaciones fallaron, y el equipo no encontró ninguna forma de eludir la protección. Esto reveló a HuntIQ dos cosas a la vez: que los exploits públicos fallaban, pero que un atacante con los conocimientos necesarios aún podía llegar a ejecutar código, por lo que el fracaso de las pruebas de concepto públicas no era motivo para esperar; y que el parche en sí mismo era sólido. Al final encontrará el enlace al informe completo de la investigación.

Al mismo tiempo, Tanium Guardian ha lanzado un panel de control para las dos vulnerabilidades CVE y un nuevo sensor para instalaciones de PHP en Windows que lee la versión de cada archivo binario de PHP sin ejecutarlo. El contenido llegó a los primeros clientes de Tanium Cloud en 19:38 UTC y se completó su implementación en todos los clientes de Tanium Cloud en 21:59 UTC, unas ocho horas después del lanzamiento de PHP. Los clientes con instalación local disponían de un paquete de importación y un artículo de la base de conocimientos pública de 01:58 UTC , publicado el October 22.

Ningún usuario de esos entornos de Tanium Cloud tuvo que crear una pregunta ni importar un archivo. El panel de control se presentó ordenado por versiones vulnerables en Windows, Linux y macOS, y los especialistas de HuntIQ facilitaron a sus clientes una regla de detección de comportamientos diseñada para Tanium Atlas, de modo que la pregunta de seguimiento —si alguien ya había aprovechado la vulnerabilidad— pudiera plantearse en lenguaje natural a toda la flota.

Por qué lo más difícil fue descubrir el PHP

Los escáneres de versiones presentan dificultades con PHP en dos aspectos. Las distribuciones de Linux lo solucionan adaptando el parche a una cadena de versión anterior: el paquete corregido de Ubuntu 24.04 sigue indicando PHP 8.3.6, por lo que una comprobación de la versión califica de vulnerable a un servidor al que se le ha aplicado el parche. En Windows, PHP suele descomprimirse desde un archivo zip en lugar de instalarse, por lo que nunca aparece en la lista de programas instalados. En la práctica, se han detectado numerosas copias de Windows integradas en aplicaciones de terceros. Los análisis de laboratorio de HuntIQ han revelado una tercera laguna: el inventario de paquetes de un host describe al propio host, no las imágenes de contenedor que ejecuta, y una imagen PHP vulnerable puede encontrarse en un servidor cuyo propio PHP esté actualizado con los parches correspondientes.

Los atacantes ya estaban realizando escaneos antes de que existiera la solución. Las organizaciones que salieron airosas del día del lanzamiento fueron aquellas que pudieron localizar y catalogar todos los servidores que ejecutaban PHP, clasificarlos según su nivel de exposición y aplicar los parches primero a los que estaban expuestos a Internet. Esa es una pregunta que Tanium responde para toda la flota de una sola vez, y HuntIQ se encarga de determinar qué respuestas son relevantes.

• Descubra cómo puede adelantarse al próximo ataque de día cero con Tanium Security Operations y HuntIQ
• Lea el análisis técnico completo: HuntIQ Tradecraft: «Hunting php2shell : post-explotación con Tanium» (se abre en una nueva pestaña)
• Lea más sobre nuestra investigación: «HuntIQ Tradecraft: Por qué el php2shell es real y sigue siendo difícil de explotar» (se abre en una nueva pestaña)