Un wiper en ESXi cerró la cadena PHP2Shell contra gateways Check Point

Desde el 30 de octubre de 2026, los procesos de Apache y PHP del portal Mobile Access de varios Security Gateway de Check Point en Israel empezaron a caer por cientos de fallos de segmentación, la huella de un exploit de PHP2Shell (CVE-2026-109618 y CVE-2026-109619) lanzado desde la dirección 130.94.19[.]204. Check Point Research reconstruyó el 12 de noviembre lo que vino después, root en el gateway por un fallo local nuevo, CVE-2026-123039, dos implantes emparentados con PhiliKit, un salto por SSH a un host VMware ESXi y el wiper destroy_v6 dejando una nota en hebreo e inglés firmada en nombre de Dream Security.

• Check Point Research confirma intrusiones por PHP2Shell en portales Mobile Access de Security Gateway sin el hotfix del 23 de octubre, entre el 30 de octubre y el 4 de noviembre de 2026.
• La escalada a root usa CVE-2026-123039, un socket 0777 del demonio dynamic_server de Gaia OS, con 7,8 de CVSS y explotación confirmada en un par de docenas de clientes.
• El atacante dejó webshells, el implante TSGA con su proxy TSProxy, saltó por SSH a un ESXi y ejecutó el wiper destroy_v6 con una nota en nombre de Dream Security.
• Los Jumbo Hotfix del 12 de noviembre (R82.20 Take 14, R82.10 Take 52, R82 Take 132 y R81.20 Take 174) corrigen la escalada e incluyen el parche de PHP2Shell.
• Lo urgente es instalarlos, parar dynamic_server si no se puede hoy y revisar dynamicCli.log, el directorio de plantillas del portal y los ESXi alcanzables por SSH.

Es la cuarta noticia que dedicamos a PHP2Shell desde el parche de emergencia de PHP del 21 de octubre, y la segunda en la que un fabricante de firewalls confirma intrusiones por esa vía, después de la de Palo Alto y el informe de Dream. La diferencia es que esta vez la víctima documentada es el propio Check Point, que ha publicado a la vez el informe de Check Point Research, un aviso firmado por Lotem Finkelstein, vicepresidente de investigación, y los Jumbo Hotfix de noviembre con el parche de la escalada.

El diagrama con el que Check Point Research abre su informe resume la cadena completa. A la izquierda, el exploit de PHP2Shell contra el gateway desde 130.94.19[.]204. En el centro, la escalada local con DynamicCLI y los dos artefactos que deja en el equipo, la webshell zz<aleatorio>.tpl y el implante TSGA, del que cuelga el módulo de proxy TSProxy. A la derecha, el salto por SSH al ESXi y el borrado.

Cientos de segfaults en Mobile Access, así entró PHP2Shell en los gateways Check Point

Check Point tenía hotfix desde el 23 de octubre de 2026 a las 18:30 GMT, según recoge su respuesta a PHP2Shell (sk1000302), que lista como afectados los Quantum Force, Spark y Cloud Firewalls que usen el portal Mobile Access, el acceso remoto con SSL Network Extender, la autenticación SAML del Remote Access VPN, el Captive Portal de Identity Awareness, el portal de UserCheck o Zero Phishing. Los servidores de gestión y de logs y el Maestro Orchestrator quedan fuera. Una semana después de ese hotfix, el 30 de octubre, aparecieron los primeros ficheros de sesión de PHP bajo /opt/CPcvpn-R81.20/tmp/ con el marcador upload_progress_pwn, el mismo rastro que deja el exploit público de PHP2Shell, y los trabajadores de Apache y PHP del portal registraron cientos de fallos de segmentación en la misma ventana.

La primera oleada, la del 30 de octubre, fue contra organizaciones israelíes e incluyó borrados en algunas de ellas. La segunda, el 2 de noviembre, volvió sobre parte de esas víctimas y añadió organizaciones de varios países sin fijarse ya en Israel. Check Point Research lo resume en una frase, «Neither wave showed a clear sector preference» (ninguna de las dos oleadas mostró una preferencia clara de sector), y lo lee como intentos oportunistas de acceso inicial más que como una selección por industria.

El aviso de Finkelstein acota las fechas, «Exploitation activity dates back to October 30 and was observed as active until November 4» (la actividad de explotación se remonta al 30 de octubre y se observó activa hasta el 4 de noviembre), y el alcance, que cifra en un par de docenas de sistemas sin parchear en una sola región. Sobre las víctimas añade que «Affected customers were notified in real time» (los clientes afectados fueron avisados en tiempo real). El Centro Canadiense de Ciberseguridad publicó el mismo 12 de noviembre su aviso AV26-1154 con una línea que no deja margen, «Check Point indicates that CVE-2026-123039 is being exploited in the wild» (Check Point indica que CVE-2026-123039 se está explotando en ataques reales).

Los dos CVE de PHP2Shell figuran en el catálogo KEV de CISA desde el 26 de octubre, con plazo federal hasta el 29. Quien gestione un gateway Check Point tiene otra fecha que mirar. El exploit llegó a los portales una semana después de que existiera el hotfix y tres días después de que CISA ordenara parchear. La ficha de la cadena completa queda así.

De nobody a root por un socket con permisos 0777, el fallo CVE-2026-123039 de DynamicCLI

PHP2Shell deja al atacante con los permisos de la cuenta de servicio del portal, insuficientes para tocar el sistema. Lo que convirtió ese acceso en root es un fallo del propio Gaia OS que Check Point describe en sk1000362, creado el 8 de noviembre y actualizado el 12. La CLI dinámica de Gaia la sirve el proceso dynamic_server, que corre como root y escucha en el socket local /tmp/dynamic_socket. En los productos afectados ese socket se crea con permisos 0777, el proceso no autentica a quien se conecta y ejecuta como root cualquier cadena de comando que recibe. Cualquier usuario local con capacidad de escribir en el socket obtiene root con una sola petición, y la propia ficha reconoce que «Check Point observed an active exploit of this vulnerability against a couple of dozen customers» (Check Point observó un exploit activo de esta vulnerabilidad contra un par de docenas de clientes).

La captura del aviso sk1000362 muestra la lista de productos afectados, Quantum Force Firewalls, servidores de gestión y de logs, Multi-Domain y Maestro Orchestrator, y las versiones, de R81 a R82.20, con R81 y R81.10 ya fuera de soporte. Los Spark Firewalls y Smart-1 Cloud no están afectados. Check Point puntúa el fallo con 7,8 en CVSS 3.1 (vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) y lo clasifica con las debilidades CWE-732, permisos incorrectos sobre un recurso, y CWE-862, falta de autorización. Su ficha en NVD se publicó el 12 de noviembre a las 14:17 UTC y a la hora de escribir esta noticia seguía en estado de análisis pendiente, sin puntuación propia de NVD. En el catálogo KEV, cuya última versión era del 10 de noviembre cuando lo descargamos, el fallo todavía no aparecía.

El aviso del 12 de noviembre corrige a la vez otros dos fallos sin explotación conocida. CVE-2026-107484, con 7,3 y descrito en sk1000291, permite a un usuario autenticado sin privilegios de administrador ejecutar operaciones reservadas en los manejadores del portal web de Gaia. CVE-2026-120490, con 3,8, permite saltar desde el servidor de gestión al gateway a través de una regla NAT. Los cuatro Jumbo Hotfix Accumulator que cierran todo esto, incluida la corrección de PHP2Shell que hasta ahora iba en un hotfix aparte, se publicaron el 12 de noviembre, como se ve en la lista de problemas resueltos de R82 con los identificadores PRJ-73738 y PRJ-72792 en el Take 132.

TSGA, TSProxy y destroy_v6, lo que el atacante dejó en el gateway y en el ESXi

Con root en la mano, el primer movimiento fue escribir webshells PHP en el directorio de plantillas que Mobile Access usa para construir sus páginas de inicio de sesión. Los ficheros siguen el patrón zz*.tpl, y cada uno recibió primero una shell mínima que después se sustituyó por una versión más capaz. Esa segunda versión exige la clave fija zz2026, acepta comandos en claro o en base64 con ofuscación XOR, ejecuta código PHP con eval y guarda los ficheros subidos en la ruta fija /tmp/.up.tpl, desde donde el atacante los copió al directorio del portal como challenge_render.tpl.

El código que reproduce Check Point Research, con la clave redactada, cabe en una pantalla. Comprueba el parámetro key, descifra el campo xb con XOR contra la clave, pasa x directamente a system, c a eval y f a move_uploaded_file. Es la misma lógica de tres entradas que vimos en el backdoor CWPdoor de Control Web Panel, aquí metida en una plantilla del portal.

De la webshell pasaron a un backdoor pasivo independiente. TSGA se lanzó como /tmp/CPconfigdaemon con la salida redirigida a un log oculto y, al ejecutarse como root, se recoloca y se relanza con el nombre slot_CPconfigdaemon en el directorio de persistencia de arranque. El binario lleva embebido un segundo componente, TSProxy, una biblioteca compartida que escribe en /lib/libcpfwcommon.so y que inyecta en procesos del appliance para interceptar sus funciones de red y atender conexiones marcadas por el atacante mientras el tráfico normal sigue pasando. Check Point Research describe TSGA como un implante específico para sus gateways, con acceso remoto cifrado, robo de configuración, persistencia en backups y snapshots, inyección en procesos y manipulación de los logs binarios del firewall. Escucha en el puerto TCP 11072 en todas las interfaces IPv4 y en el socket Unix /tmp/.p_sock.

Desde el gateway, el atacante desplegó el escáner gogo para inventariar la red interna y saltó por SSH a un host VMware ESXi con la cuenta de servicio vpxuser. Allí dejó el wiper destroy_v6 en /tmp/des wiper y lo ejecutó. El binario recibe un directorio objetivo, admite el modificador -f para borrar sin sobrescribir y -w con una lista de directorios a excluir separados por barras verticales, recorre el árbol borrando ficheros de cualquier extensión y, por defecto, los rellena con ceros antes de eliminarlos. En cada directorio procesado escribe DREAM_ANNEXATION.txt.

La nota, que Check Point Research reproduce en su informe, declara anexada la red interna de la víctima, se firma como Dream Security Ltd y rechaza de forma explícita cualquier negociación. Lleva marca de tiempo y alterna inglés y hebreo. Dream es una empresa israelí que el 26 de octubre publicó el informe sobre PHP2Shell y Fragnesia contra firewalls de Palo Alto que ya contamos. Esta vez el wiper borra en su nombre. Al aviso de Finkelstein le queda otro indicador que conviene no pasar por alto, los huecos sin explicar en los logs del firewall después de un fallo del demonio de registro, coherente con la capacidad de manipulación de logs de TSGA.

Los dos ficheros de la familia PhiliKit, philistine y libdssafe.so, no se vieron en los gateways. Check Point Research los incluye en su lista porque son los que comparan con TSGA y TSProxy, y ayudan a quien tenga que buscar parientes en otros appliances.

PhiliKit, LightNode y una nota en hebreo, por qué Check Point no cierra la atribución

TSGA y TSProxy no salieron de la nada. Check Point Research los emparenta con PhiliKit, un backdoor pasivo con instalador para appliances VPN de Ivanti que se conoció tras la subida a VirusTotal, el 25 de febrero de 2026, de una muestra llamada philistine. ESET lo atribuyó en su informe de actividad APT del 28 de mayo al conjunto SPAWN de UNC5221, el grupo de nexo chino que ha explotado un zero-day tras otro en Ivanti. Los dos implantes de Check Point descienden de Tiny SHell, usan el mismo puerto 11072 y el mismo socket /tmp/.p_sock, y TSProxy comparte con libdssafe.so las credenciales de operador, los secretos de transporte, tres digests de activación y el mismo certificado TLS con su clave privada. Para el laboratorio eso es un linaje común de herramientas, no una firma de autor.

A favor de un operador chino juegan también la infraestructura, alojada en el proveedor de VPS LightNode, y el reloj. El gráfico de Check Point Research reparte los escaneos por hora UTC y concentra 18.778 de los 18.849 eventos entre las 00:00 y las 09:00 UTC, de 08:00 a 17:00 en China, con picos a medianoche y a las 08:00 y un valle entre las 02:00 y las 05:00. Lo que no encaja con UNC5221 es el resto. Un grupo de espionaje no suele borrar discos ni centrarse en Israel. Tampoco deja notas en hebreo sobre el conflicto con Palestina. El propio nombre PhiliKit sale de philistine, el nombre interno del malware.

Check Point Research deja abiertas cuatro lecturas, que el actor identificado ejecutara la campaña entera, que solo vendiera el acceso a otro, que participara en una operación de bandera falsa o que el borrado fuese una cortina, y lo escribe así, «It is also possible that the destructive activity served as a smoke screen» (también es posible que la actividad destructiva sirviera de cortina de humo). Sobre Dream, apunta que la firma acababa de documentar explotación de PHP2Shell contra equipos de Palo Alto por actores de nexo chino y que eso abre la puerta a una represalia, sin que las pruebas sostengan un motivo. Es más prudencia de la que mostró Unit 42 cuando en octubre retiró una atribución a PHP2Shell a los dos días, y la misma que exigimos en este blog para cualquier campaña, como la del zero-day de BeyondTrust que también acabó señalando a UNC5221.

Lo que Check Point cuantifica, lo que no cuenta y el silencio de INCIBE-CERT

Lo confirmado por el fabricante cabe en tres datos. Un par de docenas de sistemas comprometidos, todos sin parchear y en una sola región, actividad entre el 30 de octubre y el 4 de noviembre y borrados en un número limitado de casos. Lo que ninguno de los dos documentos dice es cuántos hosts ESXi se borraron, si alguna víctima de la segunda oleada, la de fuera de Israel, llegó a quedar comprometida, si TSGA se ha visto en más gateways que el de la intrusión investigada y cuántos portales Mobile Access siguen expuestos sin el hotfix. A la hora de escribir esta noticia no había recuento público de Shodan, Censys ni Shadowserver para esos portales, y no vamos a reutilizar las cifras de fallos anteriores de Check Point para rellenar el hueco.

En España, INCIBE-CERT no había publicado aviso sobre CVE-2026-123039 ni sobre el impacto de PHP2Shell en Check Point a las 07:30 UTC del 13 de noviembre. Sí lo hizo el 9 de junio con el anterior fallo explotado del fabricante, CVE-2026-50751, el salto de autenticación del Remote Access VPN por IKEv1 que catalogó como crítico. Check Point acumula este año cuatro entradas en el KEV de CISA, CVE-2026-50751 el 8 de junio, CVE-2026-16232 de SmartConsole el 22 de julio y CVE-2026-93616 y CVE-2026-85102 de los servidores de gestión el 22 de septiembre, a las que se suma la de 2024 por la fuga de información de los Quantum Gateway. Quien administre un gateway en España con Mobile Access publicado ha tenido cuatro avisos de explotación activa en cinco meses y ahora un quinto fallo que, salvo cambio de criterio, acabará también en ese catálogo.

Nuestra lectura es que la cadena que describe Check Point Research es la que lleva meses repitiéndose en appliances perimetrales, una consola web con PHP publicada en internet que da una cuenta sin privilegios y un fallo local olvidado que la convierte en root. En Palo Alto fue Fragnesia en el kernel. En Check Point ha sido un socket con permisos de escritura para todos en un demonio que corre como root, un fallo de configuración de manual que el fabricante ha tenido que convertir en CVE. La parte nueva es el destino. Un implante que manipula los logs binarios del firewall y un wiper en el ESXi que había detrás describen a alguien que no quería quedarse, o que quería que pareciera que no.

Instalar el Jumbo de noviembre, parar dynamic_server y leer dynamicCli.log antes de dar el gateway por limpio

Para un equipo que cumpla las condiciones de sk1000302, un gateway con Mobile Access, SSL Network Extender, SAML, Captive Portal, UserCheck o Zero Phishing publicados, el orden lo marca la propia cadena del ataque. Antes de la lista, estas dos comprobaciones de sk1000362 dicen si el equipo sigue vulnerable y si alguien ya intentó la escalada después del parche. Un socket con srwxrwxrwx sigue abierto, y un UID 99, el de nobody, en una conexión rechazada apunta a un exploit lanzado desde el portal.

ls -l /tmp/dynamic_socket
grep "Rejected connection from unauthorized uid" /var/log/dynamicCli.log

1. Instala el Jumbo Hotfix Accumulator de noviembre en gateways y servidores de gestión, R82.20 Take 14, R82.10 Take 52, R82 Take 132 o R81.20 Take 174, empezando por los gateways con Mobile Access publicado. Si en octubre aplicaste la mitigación manual del fichero cp-httpd.conf, borra antes el bloque multipart que añadiste, porque el hotfix no lo retira. En Spark, las versiones corregidas son R82.00.11 desde la build 998002843 y R81.10.17 desde la 996005005. Tras instalar, comprueba que el socket aparece como srw-rw---- root config.
2. Si no puedes instalar hoy, para el demonio con los dos comandos de dbset del bloque siguiente. Deja de funcionar la CLI dinámica que documenta sk144112, y el equipo sigue expuesto al acceso inicial por PHP2Shell, así que esta medida solo gana tiempo.
3. Busca en /var/log/dynamicCli.log cualquier comando recibido que no use el envoltorio de Clish, con los tres grep que publica Check Point en sk1000362 y que reproducimos más abajo. Un id, un whoami o un curl en ese log son un exploit, no un administrador.
4. Revisa el directorio de plantillas del portal en busca de ficheros zz*.tpl y challenge_render.tpl, los ficheros de sesión bajo /opt/CPcvpn-*/tmp/ con el marcador upload_progress_pwn, el proceso CPconfigdaemon o slot_CPconfigdaemon, la biblioteca /lib/libcpfwcommon.so, el socket /tmp/.p_sock y cualquier binario en /tmp o /temp. Contrasta los hashes con la tabla de indicadores.
5. Si aparece cualquiera de esos artefactos, da el gateway por comprometido. Sácalo de producción, conserva una imagen antes de reinstalar, rota las credenciales que guarda, incluidas las cuentas de servicio LDAP y RADIUS, los certificados y las claves de VPN, y revisa los hosts ESXi y vCenter alcanzables por SSH desde el gateway, empezando por los accesos de vpxuser desde el 30 de octubre.
6. Busca en el SIEM los huecos en los logs del firewall y las caídas del demonio de registro desde el 30 de octubre, porque TSGA manipula los logs binarios en el propio equipo y las copias locales no sirven como prueba.
7. Da parte del incidente al CERT que te corresponda, INCIBE-CERT en el sector privado y CCN-CERT en el público, y bloquea en el perímetro 130.94.19.204 y 130.94.19.168.

La mitigación temporal de Check Point para el fallo de DynamicCLI se aplica en modo experto y se revierte sustituyendo la línea vacía por el valor t.

dbset process:dynamic_server
dbset :save

Check Point publica en sk1000362 estos tres filtros sobre el log del demonio. El primero devuelve las peticiones que no pasaron por el envoltorio legítimo de Clish, el segundo busca el sumidero system, raro en tráfico normal, y el tercero, los comandos típicos de un exploit.

grep "Received =" /var/log/dynamicCli.log | grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;"
grep -F "Received = #return_value#" /var/log/dynamicCli.log
grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" /var/log/dynamicCli.log

Para los artefactos del informe, estas comprobaciones propias buscan en el gateway los nombres y rutas que describe Check Point Research y calculan el SHA-256 de lo que encuentren para cotejarlo con la tabla.

ps auxw | grep -E 'CPconfigdaemon|dynamic_server' | grep -v grep
ls -la /lib/libcpfwcommon.so /tmp/.p_sock /tmp/.up.tpl /tmp/.bd.log 2>/dev/null
grep -rl upload_progress_pwn /opt/CPcvpn-*/tmp/ 2>/dev/null
find / -xdev \( -name 'zz*.tpl' -o -name 'challenge_render.tpl' -o -name 'CPconfigdaemon' -o -name 'slot_CPconfigdaemon' \) -newermt 2026-10-23 -exec sha256sum {} \; 2>/dev/null

Quien haya montado un laboratorio de VSX de Check Point sabe que el contexto 0 es donde vive el portal, y por eso sk1000302 pide aplicar la mitigación ahí en los despliegues VSX. El hotfix de PHP2Shell lleva en el repositorio de Check Point desde el 23 de octubre y el de la escalada desde el 12 de noviembre. Entre una fecha y otra, un par de docenas de gateways sin parchear bastaron para que un wiper llegara al ESXi de detrás.