Check Point bajo ataque: PHP2Shell, un zero-day con root y un wiper en tus ESXi

El cortafuegos es la última pieza que quieres ver comprometida: ve todo el tráfico y, si cae, entrega la red entera. Check Point ha confirmado que eso es lo que ha pasado con sus Security Gateways: un actor desconocido encadenó dos fallos críticos de PHP con un zero-day nuevo en Gaia OS, obtuvo root, instaló una puerta trasera persistente y, en algunas víctimas, saltó a los hipervisores VMware ESXi para borrarlos.

Qué ha pasado

La primera oleada, el 30 de octubre, se dirigió contra organizaciones israelíes a través de sus portales Mobile Access expuestos a internet. La segunda, el 2 de noviembre, se amplió a organizaciones de varios países y sectores. Check Point ha observado explotación activa contra «un par de docenas de clientes».

La entrada fue PHP2Shell, el par de fallos críticos de PHP —CVE-2026-109618 y CVE-2026-109619— que permiten ejecución remota de código sin autenticación. PHP los parcheó de urgencia el 21 de octubre, pero los intentos de explotación empezaron cuatro días antes, según Amazon Threat Intelligence. CISA añadió ambos CVE a su catálogo de explotados conocidos (KEV) el 26 de octubre.

Dentro del portal, el atacante escaló privilegios con un fallo hasta ahora inédito: CVE-2026-123039, una escalada local en el DynamicCLI de Gaia OS (CVSS 7.8). El demonio dynamic_server corre como root y escucha en un socket local (/tmp/dynamic_socket) con permisos de escritura para todo el mundo y sin autenticar a quien se conecta: cualquier usuario local puede ejecutar comandos como root.

Con root, instaló webshells PHP y la puerta trasera TSGA, disfrazada de slot_CPconfigdaemon, con un componente de red embebido llamado TSProxy. TSGA es un implante específico para gateways Check Point: acceso remoto cifrado, robo de configuración, persistencia mediante copias de seguridad y snapshots, inyección de procesos y manipulación de los logs del cortafuegos. TSProxy inyecta su código en procesos del appliance para atender las conexiones del atacante mientras el tráfico normal sigue su curso.

Del gateway al borrado de los ESXi

En las víctimas de la primera oleada, la campaña no se detuvo en el cortafuegos. El atacante desplegó el escáner gogo para descubrir activos internos, se movió por SSH hasta hosts VMware ESXi con la cuenta de servicio vpxuser, y allí ejecutó destroy_v6, un wiper para Linux que borra todos los archivos del directorio objetivo, intentando primero sobrescribirlos con ceros. En cada directorio dejaba una nota llamada DREAM_ANNEXATION.txt con mensajes políticos que rechazan negociar un rescate: el objetivo era causar daño, no cobrar. La segunda oleada no incluyó actividad destructiva, y Check Point reconoce que no está claro qué hicieron después los atacantes en esas víctimas.

Cadena de ataque: portal Mobile Access, gateway Check Point, backdoor TSGA y borrado del servidor ESXi

¿Quién está detrás?

Check Point vincula TSGA y TSProxy con PhiliKit, un framework documentado por ESET en junio de 2026 y asociado al grupo de ciberespionaje con nexos chinos Armory Castle (antes UNC5221). Pero la propia Check Point subraya que no hay evidencia suficiente para atribuir la campaña: el uso de un wiper y el foco en Israel, con referencias al conflicto israelo-palestino en la nota del wiper, no encajan con el perfil habitual de ese grupo. Los escenarios abiertos son un único actor, un broker de acceso inicial, una operación de bandera falsa o que la destrucción fuera una cortina de humo.

A quién afecta y qué hacer

El fallo CVE-2026-123039 afecta a Gaia R81, R81.10, R81.20, R82, R82.10 y R82.20 en Check Point Force Firewalls, Security Gateways, Management y Log Servers, entornos Multi-Domain y orquestadores Maestro. El contexto no ayuda: en septiembre, Check Point ya avisó de otros dos zero-days explotados (CVE-2026-93616 y CVE-2026-85102), y en dos años CISA ha añadido cinco fallos de Check Point a su catálogo de explotados, dos de ellos usados por bandas de ransomware.

Check Point recomienda instalar el Jumbo Hotfix de noviembre en todos los Management Servers y Security Gateways, priorizando los que tengan portales Mobile Access expuestos a internet. El parche cubre tanto PHP2Shell como el fallo de DynamicCLI. Si no puedes parchear de inmediato, la mitigación temporal es detener el proceso dynamic_server e impedir que se reinicie.

Pero parchear no basta si ya hubo compromiso: hay que buscar señales en los gateways que estuvieron expuestos. Check Point señala archivos de sesión que contengan upload_progress_pwn, procesos CPconfigdaemon inesperados, huecos en los logs del cortafuegos y actividad SSH no autorizada desde el gateway hacia hosts ESXi internos. Cualquiera de esas señales exige asumir compromiso y entrar en modo de respuesta a incidentes.

Mirada de analista Blue Team: qué vigilaría un SOC

Esta campaña recuerda que el perímetro también hay que monitorizarlo como si fuera un endpoint más. En un SOC vigilaría: actividad sobre el proceso dynamic_server y el socket /tmp/dynamic_socket, y comandos que no usen el wrapper Clish por defecto o que invoquen el sink system(); procesos CPconfigdaemon fuera de lo esperado y webshells en el portal Mobile Access, porque un backdoor que vive en el cortafuegos y manipula sus logs es invisible para el propio cortafuegos; cualquier sesión SSH que salga del gateway hacia ESXi u otros sistemas internos, especialmente con la cuenta vpxuser; ejecución de binarios desconocidos como destroy_v6 en ESXi y aparición de archivos DREAM_ANNEXATION.txt; y conexiones salientes hacia la IP 130.94.19[.]204, origen de la primera oleada.

La lección es incómoda pero clara: cuando el dispositivo que protege la red es el comprometido, las defensas que dependen de él dejan de ser fiables. Por eso la monitorización del gateway debe hacerse desde fuera, con telemetría independiente, y por eso un parche disponible desde el 23 de octubre no puede esperar dos semanas: los atacantes empezaron a explotarlo incluso antes de que existiera.

Indicadores de compromiso (IOCs)

Publicados por Check Point. Valores defanged, tal como se publicaron:

IP de origen (primera oleada): 130.94.19[.]204
Archivos de sesión: contienen upload_progress_pwn
Backdoor: TSGA ejecutándose como slot_CPconfigdaemon; componente TSProxy
Wiper: destroy_v6 (ELF de Linux)
Nota del wiper: DREAM_ANNEXATION.txt
Cuenta de servicio abusada: vpxuser (acceso SSH a ESXi)
Herramienta de reconocimiento: escáner gogo
Señales en el gateway: procesos o binarios CPconfigdaemon inesperados, huecos en los logs del cortafuegos, SSH no autorizado desde el gateway a hosts ESXi internos