Ataques a Check Point borran servidores VMware ESXi: guía de respuesta

Una campaña contra gateways Check Point empezó el 30 de octubre de 2026: los atacantes entraron por portales Mobile Access vulnerables, escalaron a root y, en algunos casos, saltaron por SSH a servidores VMware ESXi para ejecutar el borrador destroy_v6. Check Point dijo que afectó a «a couple of dozen» clientes; la primera oleada se dirigió a organizaciones israelíes y otra, el 2 de noviembre, alcanzó empresas de varios países y sectores.

Quién debe comprobar sus gateways

La campaña se dirigió a Check Point Security Gateways sin parchear, especialmente los que exponían el portal Mobile Access a internet. Check Point Research describió una primera oleada el 30 de octubre y otra el 2 de noviembre; en la segunda no encontró actividad destructiva. La segunda oleada también alcanzó a algunas organizaciones israelíes ya atacadas en la primera, además de organizaciones de otros países.

La cadena combinó PHP2Shell, los fallos CVE-2026-109618 y CVE-2026-109619, con CVE-2026-123039, una vulnerabilidad local de escalada de privilegios en la interfaz DynamicCLI de Gaia OS. Tras obtener acceso inicial por el portal, los atacantes llegaron a root, instalaron web shells y la puerta trasera TSGA con el componente TSProxy, y desde algunos gateways pasaron a ESXi mediante SSH.

Comprueba si tu entorno incluye Management Servers o Security Gateways y si Mobile Access estaba accesible desde internet durante la campaña. Network World también enumera Firewall, Multi-Domain Security Management Server, Security Management Server y Scalable Platforms entre los productos afectados por CVE-2026-123039. The Hacker News incluye, además, versiones R82.20, R82.10, R82, R81.20, R81.10 y R81 en su relación de versiones afectadas.

Qué hacer, en orden

1. Instala el November Jumbo Hotfix en todos los Management Servers y Security Gateways, dando prioridad a los equipos con Mobile Access expuesto. Check Point indica que la actualización aborda PHP2Shell y el fallo DynamicCLI utilizado en estos ataques. No pospongas los gateways accesibles desde internet mientras revisas los demás equipos.

2. Desactiva Mobile Access si no se utiliza y mantén las interfaces de administración fuera de internet. Si el parche no puede aplicarse de inmediato, Check Point aconseja detener el proceso dynamic_server e impedir que se reinicie. Network World advierte de que esta mitigación puede dejar de estar disponibles algunos comandos de CLI.

3. Revisa los gateways expuestos desde finales de octubre, incluidos los que ya estén actualizados. Busca archivos de sesión PHP con el marcador upload_progress_pwn, procesos o binarios CPconfigdaemon inesperados y huecos sin explicación en los registros del firewall. Check Point Research también observó fallos de segmentación repetidos en los procesos Apache/PHP del portal durante la actividad de explotación.

4. Busca rastros de persistencia en los sistemas que puedas inspeccionar. Check Point Research documenta archivos zz*.tpl en el directorio de plantillas de Mobile Access, además de /tmp/.bd.log, /tmp/.p_sock y /lib/libcpfwcommon.so. También describe TSGA como slot_CPconfigdaemon y señala que puede sobrevivir en copias de seguridad y snapshots. Estos indicios justifican investigar el gateway; no los trates como una lista exhaustiva.

5. Correlaciona los registros del gateway y de ESXi. Busca actividad SSH no autorizada desde el gateway hacia los hosts VMware; los investigadores identificaron el uso de la cuenta de servicio vpxuser. En los equipos afectados por la fase destructiva, el malware destroy_v6 eliminó archivos recursivamente y dejó notas llamadas DREAM_ANNEXATION.txt.

6. Corta la ruta de confianza a ESXi desde cualquier gateway sospechoso. Network World recomienda separar el firewall del hipervisor: un gateway potencialmente comprometido no debe conservar una vía de confianza hacia VMware ESXi. Revisa también la segmentación de red para limitar el movimiento lateral entre ambos entornos.

7. Envía los registros fuera del gateway a un sistema que el propio dispositivo no pueda modificar. TSGA puede alterar los registros binarios del firewall, por lo que un registro local sin huecos aparentes no descarta por sí solo una intrusión. Conserva y compara la telemetría externa con la de ESXi y otros sistemas de la red.

8. Reconstruye los sistemas comprometidos desde imágenes de confianza cuando la investigación confirme o no permita descartar una intrusión. Erik Avakian, de Infotech, advierte que aplicar el parche no expulsa a atacantes que ya hayan establecido persistencia. La recomendación de Network World es investigar y, cuando haga falta, reconstruir los equipos afectados.

Errores que pueden dejar abierta la intrusión

Dar por resuelto el incidente al parchear es el primer error. La actualización corrige las vulnerabilidades, pero no quita una puerta trasera ya instalada ni demuestra que el gateway esté limpio; revisa los equipos previamente expuestos aunque ya tengan el hotfix.

Confiar solo en los registros locales tampoco basta: TSGA puede manipular los registros binarios del firewall. Evita usar la ausencia de alertas locales como prueba de que no hubo acceso, y contrasta la actividad con registros enviados a otro sistema y con los de ESXi.

Por último, no mantengas Mobile Access o SSH innecesariamente expuestos, ni dejes que un gateway sospechoso conserve acceso de confianza al hipervisor. Las señales más concretas para priorizar la revisión son el marcador de sesión, los procesos CPconfigdaemon inesperados y conexiones SSH desde el gateway a ESXi.

Fuentes: Network World, BleepingComputer, The Hacker News, Check Point Research, Secure Blog