PHP2Shell en Check Point: puertas de enlace borradas

PHP2Shell en Check Point dejó de ser un aviso más. La empresa confirmó el 12 de noviembre que un atacante entró por el portal Mobile Access de sus puertas de enlace de seguridad, tomó el control total del equipo y, en un número reducido de casos, cruzó hasta servidores VMware ESXi para borrar archivos. La corrección llevaba una semana publicada cuando arrancó la primera oleada.

El dato que ordena la historia es ese retraso de siete días. Las correcciones para las puertas de enlace y los servidores de administración salieron el 23 de octubre. La explotación arrancó el 30 de octubre y se observó hasta el 4 de noviembre. Check Point habla de un par de docenas de sistemas sin parchear comprometidos, todos en una misma región, y de clientes avisados el mismo día en que empezó la investigación.

PHP2Shell reúne dos fallos de ejecución remota de código sin autenticación, CVE-2026-109618 y CVE-2026-109619, con nota de 9,2 sobre 10. El blanco son las interfaces web de los cortafuegos: en los equipos de Check Point, la puerta de entrada fue el portal Mobile Access, el mismo que usa el personal para conectarse desde fuera. Las versiones expuestas van de R80 a R82.20, y la lista suma los cortafuegos Spark en las ramas R81.10.x, R82.00.x, R77.20.x y R80.20.x.

Entrar era solo la mitad del trabajo. El informe técnico que Check Point Research publicó junto al aviso describe el segundo eslabón: CVE-2026-123039, un fallo de escalada local de privilegios con nota de 7,8 en el servicio Dynamic CLI de Gaia, el sistema operativo de la casa, expuesto en las versiones R81.20, R82, R82.10 y R82.20. Con ese fallo, el atacante pasaba de la cuenta del portal a root, el nivel máximo dentro del equipo, y ya podía plantar herramientas propias y quedarse.

Dos oleadas y una nota en hebreo

La primera oleada, el 30 de octubre, apuntó a organizaciones de Israel y dejó actividad destructiva en parte de los casos. La segunda llegó el 2 de noviembre, alcanzó organizaciones de varios países y sectores y no mostró destrucción. Ninguna escogió un sector concreto: escaneo oportunista con selección posterior de víctimas. Las primeras huellas quedaron en archivos de sesión de PHP en la carpeta temporal del portal, con una marca inconfundible: upload_progress_pwn.

Ya con root, el trabajo fino quedó documentado por Check Point Research en el mismo informe. El atacante plantó puertas traseras web con nombres que empiezan por zz y terminan en .tpl; una versión posterior, challenge_render.tpl, pedía una clave fija y permitía ejecutar comandos y subir archivos. Después instaló TSGA, una puerta trasera hecha a la medida de estos equipos, lanzada desde un archivo disfrazado de componente legítimo con el nombre CPconfigdaemon. TSGA ofrece acceso remoto cifrado, robo de la configuración y alteración de los registros del cortafuegos. Su compañera, TSProxy, se aloja dentro de procesos del equipo y vigila conexiones escogidas sin tocar el tráfico normal.

Del equipo perimetral, el atacante pasó hacia adentro. Barrió la red interna con el escáner gogo, entró por SSH a un servidor VMware ESXi con la cuenta vpxuser y ejecutó destroy_v6, un programa de borrado que elimina archivos de la carpeta elegida sin mirar la extensión y los sobrescribe con ceros. En cada carpeta procesada dejó una nota, DREAM_ANNEXATION.txt, escrita en hebreo, con referencias al conflicto entre Israel y Palestina y sin ninguna demanda de pago. Borrar sin pedir rescate cambia la lectura del caso: el objetivo era el daño, o tapar otra cosa.

Una herramienta conocida y una autoría sin cerrar

TSGA y TSProxy son variantes modificadas de PhiliKit, un marco de puerta trasera visto antes en ataques contra equipos de Ivanti y que ESET vinculó con UNC5221, un grupo con nexo en China. Las coincidencias son concretas: código, ajustes y material de cifrado compartidos, el puerto TCP 11072 y el mismo certificado TLS con su clave privada en un componente llamado libdssafe.so. El escaneo se concentró entre las 00:00 y las 09:00 UTC, el horario laboral de China.

Hasta ahí llegan las coincidencias. Check Point Research cierra su informe sin atribuir la campaña con confianza alta y deja tres escenarios abiertos: el actor identificado ejecutó la operación completa, actuó solo como vendedor del acceso inicial para otro grupo, o participó en una operación de bandera falsa. La destrucción, el foco en organizaciones israelíes y la nota en hebreo no encajan con el patrón conocido de UNC5221. Presentarlo como autor cerrado sería ir más lejos que la evidencia publicada.

El fallo ya tenía historia en el vecindario. PHP2Shell en Palo Alto Networks sumó explotación activa en octubre, y el 12 de noviembre CISA volvió a publicar avisos de Siemens que confirman la llegada del mismo fallo a productos de automatización de edificios y de energía, entre ellos Spectrum Power y el RUGGEDCOM APE1808. De los productos de Siemens no consta explotación; la campaña destructiva documentada es la de Check Point.

La salida está publicada y tiene nombre: November Jumbo Hotfix, para todos los servidores de administración y todas las puertas de enlace, con prioridad para los portales Mobile Access expuestos a internet. Quien no pueda instalarlo hoy tiene una lista corta de revisión: archivos de sesión con la marca upload_progress_pwn, procesos que se presenten como CPconfigdaemon y huecos en los registros de tráfico. El parche salió el 23 de octubre y la oleada destructiva llegó siete días después.

Fuente: Check Point