El 19 de octubre de 2026, Unit 42 actualizó su informe sobre la explotación de CVE-2026-0257 con un párrafo que pasó bastante desapercibido entre los titulares de «ransomware entra por el VPN». Dice que, en uno de los casos, los atacantes saltaron del concentrador comprometido a vCenter, desactivaron una protección de los hosts ESXi y usaron una herramienta propia para volcar credenciales contra el disco virtual del controlador de dominio. El agente que vigilaba esa máquina no tenía nada que contar: dentro de ella no tuvo que pasar nada.
Nos dedicamos a operar infraestructura ajena, así que leemos estos informes buscando la parte que cambia lo que hacemos el lunes. Aquí la parte que cambia no es la vulnerabilidad del cortafuegos —esa se parchea— sino la segunda mitad de la cadena, donde el ataque sale del sistema operativo y se mete en una capa en la que, sencillamente, no hay ningún agente instalado. Y conviene decir una cosa incómoda antes de seguir: lo que desactivaron no lo rompieron. Lo apagaron con un comando que el fabricante documenta en su web.
La cadena, en orden
La puerta de entrada es CVE-2026-0257, que el aviso oficial describe en plural —«authentication bypass vulnerabilities in the GlobalProtect portal and gateway» de PAN-OS— y que permite al atacante «bypass security restrictions and establish an unauthorized VPN connection». Puntuación base 7,8 en CVSS 4.0, severidad alta, urgencia sugerida la máxima. El aviso se publicó el 13 de mayo de 2026 y se actualizó por última vez el 3 de junio. No afecta a cualquier despliegue: hace falta tener activa la función de authentication override cookies con una configuración de certificado concreta, y por eso las soluciones temporales que publicó el fabricante son usar un certificado dedicado para esas cookies o desactivar la opción.
El calendario de después merece leerse de un tirón, porque es el verdadero titular. CISA lo metió en su catálogo de vulnerabilidades explotadas conocidas el 29 de mayo con fecha límite de corrección el 1 de junio: tres días. Unit 42 observó intentos de explotación activa desde el 5 de junio. Arctic Wolf investigó varias intrusiones distintas durante junio que acabaron todas en ransomware Qilin. Y el informe que comentamos aquí es de octubre. Cinco meses con parche disponible, y el agujero seguía siendo rentable.
Lo que hicieron dentro en junio, según Arctic Wolf, es de manual y es ruidoso: sesiones de VPN abiertas desde equipos que se identificaban con el nombre de máquina kali, volcado de LSASS con rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump, extracción de ntds.dit con ntdsutil.exe por el método IFM, movimiento lateral con PsExec sobre recursos administrativos, exfiltración con Rclone hacia MEGA y el cifrador win.exe dejado en C:\PerfLogs\. Cada una de esas líneas es algo que un agente de EDR puede ver, y que un registro guarda. Es el guion que ya contamos cuando DeadLock apaga el antivirus antes de cifrar: hace falta pelearse con lo que hay dentro de la máquina.
El caso de octubre no se pelea con nada de eso. Lo esquiva. Y hay un detalle de honestidad que conviene marcar: el informe de Arctic Wolf de julio no menciona el salto al hipervisor. Eso aparece en la actualización de Unit 42, referido a un caso. No es un patrón consolidado todavía; es una técnica que ya funcionó una vez contra alguien real.
«Desactivaron la protección» es generoso
La protección en cuestión se llama execInstalledOnly y hace una cosa sola: que el VMkernel ejecute únicamente binarios empaquetados y firmados como parte de un VIB válido. Es, literalmente, la casilla anti-ransomware del hipervisor. Y la página que explica cómo quitarla es del fabricante, se titula «Deactivate the execInstalledOnly Internal Runtime Option» y cabe en una línea:
esxcli system settings advanced set -o /User/execInstalledOnly -i 0
La misma página avisa de las dos consecuencias: «When you deactivate the execInstalledOnly internal runtime option, vCenter Server warnings appear for the host» y «Deactivating the execInstalledOnly internal runtime option leaves you more vulnerable to attacks». Nadie rompió criptografía aquí. Alguien que ya mandaba en el host usó el interruptor que viene de serie. Lo que falló fue una capa antes: que llegara a mandar en el host.
Hay dos execInstalledOnly, y el que tienes es el flojo
Esta es la parte que no hemos visto contada en ninguna cobertura de la noticia, y es la que decide si el comando de arriba te habría funcionado a ti. No hay un execInstalledOnly: hay dos, con el mismo nombre y propiedades opuestas. La documentación de vSphere 8.0 los separa así:
| Opción interna de ejecución | Opción de arranque del kernel | |
|---|---|---|
| Qué es | ajuste avanzado /User/execInstalledOnly, añadido en ESXi 8.0 | opción de arranque del VMkernel |
| Por defecto | activada | desactivada |
| Se consulta | solo si la de kernel está desactivada | manda sobre la otra |
| Cambiarla | en caliente, un esxcli | exige reiniciar el host |
| Requisito previo | ninguno | UEFI secure boot |
La frase exacta del fabricante es esta: «The execInstalledOnly boot option continues to be deactivated by default, except a previously enabled execInstalledOnly boot option overwrites the internal runtime option if you set both». Y para activar la de arranque hay un peaje que casi nadie ha pagado: «the secure boot enforcement must be activated before you can enforce the execInstalledOnly boot option in the sealing policy». Traducido a consecuencias: si tu host es un ESXi 8.x de instalación limpia, tienes la primera columna. Y la primera columna vale exactamente lo que valga la contraseña de root de ese host, porque se apaga en caliente y sin reiniciar nada.
Dos comandos para saber en cuál de las dos columnas estás. Ninguno modifica nada:
esxcli system settings advanced list -o /User/execInstalledOnly
esxcli system settings kernel list -o execInstalledOnly
Y activado tampoco detiene un script
Hay un artículo de soporte del propio fabricante, titulado «execInstalledOnly Not Preventing Script Execution on ESXi», que lo deja por escrito: la función «is designed to prevent the execution of unsigned binaries, but it does not prevent the execution of scripts run through interpreters like Python». Y remata: «there is no built-in method in ESXi 7.0 to prevent the execution of unsigned scripts run through interpreters», limitación que el artículo extiende hasta las versiones 8.x incluidas.
Esto no convierte el control en inútil y no vamos a decir que lo sea: sube el coste de la operación, obliga a traer un intérprete o a apañarse con el que haya, y deja rastro. Pero sitúa bien la expectativa. Bloquea el binario, no la herramienta. Un atacante con el host en la mano y un intérprete disponible no necesita tocar ese interruptor para nada —y si lo tocó fue, probablemente, por comodidad—.
El aviso que ya te estaban dando
Cuando esa opción se apaga, el host lo dice con estas palabras exactas: «ExecInstalledOnly has been disabled. This allows the execution of non-installed binaries on the host. Unknown content can cause malware attacks similar to Ransomware.»
O sea: la señal existía. Estaba escrita, en inglés claro, y nombra el ransomware. El problema es el que viene después, y está en el mismo artículo de soporte, que enumera por qué un host puede aparecer así: porque alguien lo desactivó a mano, porque lo desactivó una utilidad de actualización de firmware, o porque se quedó desactivado en la primera inicialización después de una actualización a 8.x.
Ahí está el nudo. Un host que actualizaste en marzo y un host que te tomaron hace una hora producen exactamente la misma línea. Una señal ambigua que nadie clasifica no es una señal: es ruido con formato de aviso. Y resolver esa ambigüedad no lo hace un producto —no hay nada que instalar que sepa quién apagó qué—; lo hace alguien de guardia que pueda responder a dos preguntas, cuándo se apagó y quién estaba conectado entonces. Eso es turno, no licencia.
El mapa de cobertura, capa por capa
Esta tabla es nuestra lectura de la cadena, no una cita. Pone en una columna lo que suele vigilar cada capa y en otra lo que este ataque dejó ahí:
| Capa | Quién la mira | Qué dejó este ataque |
|---|---|---|
| Controlador de dominio | agente EDR, auditoría de AD | nada |
| Concentrador VPN | registros del cortafuegos | sesión VPN sin autenticar |
| vCenter | casi nadie, a las 3 de la mañana | el aviso de execInstalledOnly |
| Host ESXi | nadie: no hay agente que instalar | shell abierta, binario no instalado |
| Almacenamiento | la cabina, si alguien lee sus eventos | un disco virtual leído desde fuera |
La primera fila es la que vende el resto del artículo. Un EDR bien puesto en el controlador de dominio es una pieza seria y no estamos diciendo que sobre: cubre lo que pasa dentro de esa máquina, que es casi todo. Lo que no cubre —porque no puede— es que su disco se lea desde una capa por debajo del sistema operativo donde el agente vive. Es el mismo razonamiento que explicábamos con el cifrador que solo toca el 10 % de cada VMDK: desde el hipervisor, tus máquinas virtuales son ficheros.
Y no, esto no es un problema de VMware. Lo decimos porque la tentación comercial sería esa y sería mentira: en un Proxmox, el root de un nodo lee igual de bien el disco del mismo controlador de dominio, sea un qcow2 o un volumen RBD. La superficie expuesta no es el producto, es el plano de gestión. Cambia la marca y el argumento no se mueve.
Seis preguntas para esta tarde
Todas se responden con un sí, un no o un número. Ninguna necesita comprar nada:
- 1.¿La red de gestión del hipervisor es alcanzable desde el rango que reparte el concentrador VPN? Si la respuesta es sí, la cadena de este post te aplica entera.
- 2.¿Cuántas cuentas pueden entrar en vCenter como administrador, y cuántas de ellas se autentican contra el mismo Active Directory que vive dentro de ese vCenter? El bucle es el riesgo, y está documentado por Mandiant.
- 3.¿Qué devuelve
esxcli system settings kernel list -o execInstalledOnlyen tus hosts? La de kernel, no la de ejecución. Si no la tienes, no tienes la buena. - 4.¿Dónde acaba una alarma de vCenter un domingo a las tres de la madrugada, y cuántos minutos pasan hasta que una persona la abre? Un número, no una intención.
- 5.¿Los eventos de vCenter y de los hosts se guardan fuera del propio clúster? Si viven dentro, quien se queda el clúster se queda también el relato de lo que hizo.
- 6.¿Cuándo se rotó por última vez la contraseña de root de los hosts, y cuántas personas la tienen hoy? Dos fechas y un número, y ya sabes cuánto vale tu primera columna.
La pregunta 4 es la que más veces hemos visto quedar sin respuesta, y es la única que no se arregla con una tarde de trabajo. Las otras cinco sí.
En everyWAN montamos EDR y MDR gestionados, y precisamente por eso decimos lo que no hacen: en la capa del hipervisor no hay agente que instalar, así que ahí lo que cubre es el turno, los eventos sacados fuera del clúster y alguien que se tome en serio un aviso ambiguo a deshora. Lo otro que ayuda de verdad es tratar el plano de gestión con el criterio de Zero Trust: red aparte, cuentas que no dependan de lo que están protegiendo, y root rotado con fecha.
Fuentes (verificadas el 07-11-2026): descripción, CVSS 7.8 (CVSS 4.0), versiones afectadas, fechas de publicación (13-05-2026) y última actualización (03-06-2026), condición previa de authentication override cookies y soluciones temporales — aviso oficial de Palo Alto Networks sobre CVE-2026-0257; salto del concentrador VPN a vCenter, desactivación de execInstalledOnly y volcado de credenciales contra el VMDK del controlador de dominio, además de la cronología de explotación y los grupos implicados — Unit 42, «Active Exploitation of May 2026 PAN-OS CVE-2026-0257» (sección «Update: Oct. 19, 2026»; última actualización del informe, 26-10-2026); intrusiones de junio, nombre de máquina kali, MiniDump de LSASS, ntdsutil, PsExec, Rclone y win.exe en PerfLogs — Arctic Wolf Labs, «Cookie Crumbles»; alta en el catálogo KEV el 29-05-2026 con fecha límite 01-06-2026 — CISA Known Exploited Vulnerabilities Catalog; comando de desactivación, estado por defecto de las dos opciones y avisos en vCenter — Broadcom TechDocs, «Deactivate the execInstalledOnly Internal Runtime Option»; dependencia del arranque seguro para la opción de kernel — Broadcom TechDocs, «Securing the ESXi Configuration»; límite con intérpretes — KB 373898, «execInstalledOnly Not Preventing Script Execution on ESXi»; texto exacto del aviso y sus tres causas — KB 401376; riesgos de integrar vSphere con Active Directory — Google Cloud Threat Intelligence (Mandiant). La tabla de las dos opciones, el mapa de cobertura y las seis preguntas son elaboración nuestra. Fotografía: cabina de almacenamiento HP EVA4400, CC BY-SA 3.0 vía Wikimedia Commons, recortada por nosotros.
¿Sabes qué pasa con una alarma de tu vCenter a las tres de la madrugada?
Revisamos la cobertura capa por capa, decimos dónde no llega tu agente y quién mira lo que queda. Con tus hosts y tus registros, no con una presentación.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN