Ataques de PHP2Shell iniciaron cuatro días antes de la divulgación pública
Amazon Threat Intelligence ha revelado que atacantes intentaron explotar dos vulnerabilidades críticas en PHP antes de que fueran anunciadas oficialmente. El informe destaca la importancia de no asumir que la ventana de riesgo comienza únicamente con la publicación del aviso de seguridad.
Atacantes intentaron explotar dos vulnerabilidades críticas de PHP cuatro días antes de que los fallos se hicieran públicos, según informa Amazon Threat Intelligence.
Detección temprana y actividad sospechosa
«Amazon Threat Intelligence identificó un intento de explotación de PHP2Shell con fecha del 17 de octubre de 2026, en la telemetría de MadPot, cuatro días antes de la divulgación pública de CVE-2026-109618 y CVE-2026-109619», indica el informe publicado por el equipo de Amazon. «El intento de explotación se originó desde una dirección IP asociada a una red de anonimización comercial. Mientras la vulnerabilidad estaba bajo embargo, el objetivo de un honeypot desde una dirección IP anonimizada sugiere que la actividad fue llevada a cabo por un actor de amenazas, aunque no está claro cómo el actor obtuvo información sobre la explotación antes de la divulgación».
La actividad comenzó el 17 de octubre de 2026 y apareció en la telemetría de MadPot, la red de honeypots de AWS diseñada para atraer y estudiar la actividad maliciosa. La empresa señaló que el primer intento tuvo como objetivo un honeypot desde una dirección IP vinculada a una red de anonimización comercial. Las vulnerabilidades, rastreadas como CVE-2026-109618 y CVE-2026-109619, todavía estaban bajo embargo en ese momento.
AWS cree que el uso de infraestructura anonimizada sugiere que un actor de amenazas estaba detrás de la actividad. Sin embargo, la empresa no ha establecido cómo el atacante obtuvo información sobre las vulnerabilidades antes de su divulgación pública, ni ha confirmado si los intentos tempranos habrían tenido éxito en sistemas reales.
El primer intento no fue un evento aislado. AWS detectó múltiples códigos de prueba de concepto (PoC) el 21 de octubre, con los más antiguos apareciendo alrededor de las 02:00 UTC, aproximadamente 12 horas antes del lanzamiento público y parche programado para las 14:00 UTC.\n Entre las 02:00 y las 08:00 UTC de ese día, AWS observó más intentos contra MadPot desde infraestructura anonimizada adicional. Las cargas útiles y los servicios de anonimización variaron, lo que llevó a la empresa a sospechar que varios actores estaban involucrados.
Impacto de la vulnerabilidad y medidas de mitigación
Después de que terminara el embargo y PHP lanzara las correcciones, aparecieron más códigos de prueba de concepto en cuestión de horas. AWS informó que los atacantes los utilizaron contra sus sensores casi de inmediato, describiendo PHP2Shell como una vulnerabilidad siendo explotada activamente.
Los hallazgos muestran por qué la fecha de un aviso de seguridad público no siempre puede servir como el punto de partida para la investigación de un incidente. En este caso, los defensores tuvieron que contabilizar actividades que comenzaron antes de que pudieran identificar públicamente las vulnerabilidades.
«Las cargas útiles reales y las opciones en la infraestructura de anonimización variaron, lo que sugiere que se trataba de múltiples actores», continúa el informe. «El análisis técnico está en curso y no está claro si alguno de estos intentos habría tenido éxito en sistemas reales».
PHP2Shell se refiere a dos fallos críticos en el entorno de ejecución de PHP que pueden permitir la ejecución de código de forma remota sin autenticación. Un atacante podría enviar una solicitud web especialmente elaborada y ejecutar comandos en un servidor vulnerable sin tener que iniciar sesión previamente a la autenticación.
PHP publicó las correcciones el 21 de octubre. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según el aviso oficial de seguridad de PHP.
Las vulnerabilidades afectan al propio PHP, en lugar de a una aplicación web específica. Como resultado, actualizar WordPress, Drupal u otra aplicación no corregirá el problema subyacente si el servidor continúa ejecutando un entorno de ejecución de PHP vulnerable. AWS afirma que no existe una solución alternativa basada únicamente en la configuración que aborde completamente ambos fallos. Las organizaciones deben instalar la versión corregida de PHP lo antes posible y verificar si su proveedor de alojamiento, el fabricante del sistema operativo o la imagen de contenedor han proporcionado la actualización necesaria.
Para los sistemas que no pueden parchearse inmediatamente, AWS sugiere considerar si es práctico bloquear las cargas de archivos multipart. Los administradores deben evaluar el impacto en sus aplicaciones antes de aplicar esa restricción, y no deben tratarla como un sustituto para la instalación de las correcciones.
AWS recomienda revisar los registros del servidor web en busca de solicitudes sospechosas, particularmente solicitudes POST que contengan la cadena PHP_SESSION_UPLOAD_PROGRESS en datos de formulario multipart. Los equipos de seguridad también deben buscar procesos inesperados iniciados por PHP y cambios inexplicables en los archivos de los servidores de aplicaciones web.\n
Estas comprobaciones son importantes porque un ataque puede dejar evidencia más allá de la solicitud HTTP original. Los intérpretes de comandos inesperados, los archivos recién creados o la actividad de procesos inusuales pueden ayudar a los investigadores a determinar si un atacante avanzó más allá de la exploración de un punto final vulnerable.\n
AWS también publicó seis direcciones IP asociadas con la actividad observada. Estas direcciones requieren un manejo cuidadoso. AWS advierte que algunas pertenecen a infraestructura de anonimización compartida y no son exclusivas de la actividad de PHP2Shell, por lo que las organizaciones deben investigar los eventos coincidentes en lugar de bloquear automáticamente cada dirección.\n
El análisis de Cloudflare sobre PHP2Shell proporciona contexto adicional. Cloudflare afirmó que había desplegado protecciones de firewall de aplicaciones web antes de la divulgación pública y ya había observado tráfico de ataque dirigido a sus clientes, incluidos intentos de cambiar las cargas útiles para evadir esas protecciones.\n
Un firewall de aplicaciones web puede ayudar a reducir la exposición, pero no sustituye al parcheo. Los defensores deben combinar el software actualizado con el análisis de registros, el monitoreo de procesos y las comprobaciones de cambios sospechosos en los archivos.\n
Lecciones aprendidas y el papel de la IA
AWS extrae una lección más amplia del incidente: las organizaciones no deben asumir que la explotación comienza solo después de que una vulnerabilidad se haga pública. La actividad del 17 de octubre muestra que los atacantes pueden obtener o desarrollar información sobre la explotación mientras un fallo todavía está bajo una divulgación coordinada.
Los atacantes están utilizando IA para desarrollar exploits más rápido, a veces en cuestión de horas tras la publicación de un parche. Los equipos de seguridad deben parchear sistemas críticos rápidamente e investigar ataques desde la fecha más temprana conocida. Para PHP2Shell, AWS recomienda revisar los registros y la actividad desde el 17 de octubre en adelante, incluyendo comportamientos sospechosos que las herramientas de detección podrían no reconocer todavía.\n
El caso de PHP2Shell subraya la importancia de la vigilancia proactiva y la monitorización de logs para detectar actividades sospechosas que puedan preceder a las alertas oficiales de seguridad.
Contenido traducido al español con fines informativos, cualquier cambio en la publicación original no será reflejada en esta entrada, favor referirse a la fuente para obtener el acceso a cualquier actualización del contenido. Para la traducción se utilizó un LLM, al ser una traducción automática puede contener errores gramaticales o de otro tipo, me pueden enviar un mensaje.
Comentarios
Publicar un comentario