Los atacantes habrían recurrido a plataformas de inteligencia artificial agéntica para las tareas posteriores a la explotación de las vulnerabilidades conocidas como PHP2Shell, identificadas como CVE-2026-109618 y CVE-2026-109619. Según Palo Alto Networks Unit 42, en uno de los incidentes el objetivo fue una entidad gubernamental europea: en un plazo de dos horas desde la explotación inicial los intrusos lograron acceso a hashes de contraseñas y a secretos de autenticación multifactor, establecieron un túnel de retransmisión NTLM hacia Active Directory e intentaron escalar privilegios hasta Domain Admin.
La compañía de seguridad de red señaló que el atacante, aún sin identificar, también enumeró el endpoint comprometido con comandos y patrones de comportamiento que apuntan a un actor automatizado por IA. Entre las acciones observadas figuran:
- Reconocimiento de la base de datos de autenticación con credenciales robadas, centrado en hashes de contraseñas y secretos de doble factor (2FA).
- Reconocimiento de Active Directory mediante consultas LDAP anónimas con curl contra el controlador de dominio para localizar la cuenta de administrador.
- Reconocimiento del host para identificar la integración de DNS con AD, hosts internos, grupos privilegiados y usuarios interactivos.
Unit 42 añadió que cada lote de comandos va envuelto en delimitadores de encabezado de sección, como ==SHELLUSER== y ==PASSWD==, que generan una salida interpretable por máquina para que la lea un modelo de IA.
Una campaña atribuida a Corea del Norte sondea PHP2Shell
La revelación coincide con el análisis de CYFIRMA, que afirma haber descubierto una campaña presuntamente vinculada a Corea del Norte que emplea PHP2Shell para sondear activamente infraestructura PHP en todo el mundo desde 21 nodos comprometidos. Kumar Ritesh, consejero delegado y fundador de la firma, explicó a The Hacker News que el escaneo es deliberadamente de bajo volumen y pausado: los nodos rotan y se abandonan ante la primera señal de bloqueo o limitación de tasa, por lo que las alertas basadas en umbrales difícilmente lo detectarán.
Los objetivos son 216 hosts sin parchear o con mitigación parcial distribuidos por Estados Unidos, Japón, Corea del Sur, Tailandia, Indonesia, Australia, Taiwán, India, Singapur, Emiratos Árabes Unidos, Arabia Saudí y la Unión Europea. Abarcan entidades gubernamentales, instituciones financieras, logística, aeropuertos y aviación, manufactura y plataformas de transacciones en línea.
La campaña ha pasado del reconocimiento al escaneo activo, lento y sigiloso de un conjunto filtrado de objetivos. Las organizaciones de los sectores y geografías priorizados deberían asumir que están dentro del alcance de una selección deliberada.
La actividad, coordinada a través de un canal cerrado de I2P, se atribuye con confianza moderada a un operador de habla coreana que se evalúa como afiliado al ecosistema del grupo Lazarus. Según CYFIRMA, los dos alias activos en ese canal (전창혁 2, Jeon Chang-hyuk 2, y 최아린, Choi A-rin) ya habían sido vistos ejecutando operaciones encubiertas para esos actores. Ritesh indicó que los operadores de habla coreana han usado el canal para compartir listas de objetivos, infraestructura de alojamiento de exploits y tareas y prioridades coherentes con los objetivos de la RPDC, y que la conversación capturada emplea vocabulario y ortografía propios del norcoreano (Munhwaŏ) y no del estándar surcoreano.
Otros indicadores principales que vinculan la campaña con el clúster Lazarus son los siguientes:
- Infraestructura de mando y control (C2) que Lazarus ya había utilizado para explotar activos web.
- El historial documentado del grupo Lazarus de comprometer servidores PHP y WordPress para C2 y para implantar webshells PHP y ASP, como se observó en la campaña de watering hole SyncHole.
- La priorización de agencias gubernamentales y bancos, en particular plataformas de transacciones en línea, en línea con la trayectoria de Lazarus de brechar instituciones financieras para robar dinero y criptomonedas.
La explotación es el siguiente paso. Los operadores dijeron que preseleccionarían ese mismo día los objetivos más prometedores y luego elegirían qué exploits públicos adaptar.
Otras iniciativas de explotación y mitigaciones
En una publicación del 25 de octubre de 2026 en X, Defused Cyber afirmó que también observa sondeos de PHP2Shell contra sus honeypots de Palo Alto Networks GlobalProtect, originados en 204.76.203[.]7, una dirección IP conocida por la explotación masiva. Según la empresa de inteligencia de amenazas, las solicitudes incluyen el marcador PHP_SESSION_UPLOAD_PROGRESS ('p2s-rider') y una carga de archivo ficticia sin payload, lo que apunta a alguien que comprueba el comportamiento vulnerable de carga con progreso y probablemente confecciona una lista de dispositivos Palo Alto como objetivos.
Tanto CVE-2026-109618 como CVE-2026-109619 son vulnerabilidades críticas que pueden desembocar en ejecución remota de código en configuraciones PHP por defecto. Cloudflare indicó que detectó millones de intentos de explotación tras la divulgación pública. Datadog explicó que el atacante afronta dos limitaciones principales: debe dimensionar la petición para que falle la asignación de memoria en el momento adecuado y debe sortear ASLR para hallar direcciones de memoria válidas. El exploit necesita un nombre de campo lo bastante pequeño para caber en el cuerpo aceptado de la petición pero lo bastante grande para que copiar su clave supere memory_limit.
ReliaQuest, en una actualización publicada el 22 de octubre de 2026, dijo haber reproducido CVE-2026-109618 en un laboratorio controlado y observado una secuencia de errores que podría ayudar a los defensores a identificar la explotación: una petición POST devuelve un error 500, PHP informa agotamiento de memoria y corrupción del heap, y el worker de Apache que atiende la petición se cae.
Por su parte, la PHP Foundation advirtió de una tercera vulnerabilidad de ejecución remota de código (CVE-2026-115560) que solo puede darse bajo una combinación inusual de configuración y código de aplicación, y que se espera corregir en el ciclo habitual de versiones. La aplicación debe fijar session.serialize_handler en php_binary o php_serialize en su configuración y luego cambiarlo a php en tiempo de ejecución con ini_set() antes de llamar a session_start(); además, el progreso de carga de sesión debe seguir habilitado. Las aplicaciones que nunca modifican el manejador de serialización en tiempo de ejecución pueden mantener la función activada.
Xint ha publicado un escáner para comprobar si un host está expuesto a PHP2Shell, y señala que la ejecución remota de código es posible en cualquier script PHP con independencia de la aplicación, y en aplicaciones donde se produce decodificación, como con session_start() y unserialize(). Los escaneos a escala de Internet de Bitsight muestran casi 37 millones de sistemas accesibles desde Internet que ejecutan PHP o software relacionado, con la mayoría de las exposiciones en Estados Unidos, Alemania, Francia, Países Bajos y Japón.
PHP sostiene una porción enorme de la web, desde gestores de contenido y tiendas en línea hasta herramientas internas a medida. Un fallo en el runtime no se corrige cambiando el código de la aplicación, y una actualización del firewall de aplicaciones web o de un plugin no lo elimina. Solo actualizar PHP en el propio host cierra la brecha.
Deja una respuesta