Con cifrar el 10 % del VMDK le basta: la cuenta que cambia tu plan de recuperación

El cifrador para ESXi de Kyber tiene un parámetro de porcentaje. El binario lo valida entre 0 y 100 y el valor que Rapid7 observó puesto era 10. En un disco virtual de 500 GB eso son unos 50 GB tocados, y con eso la máquina ya no arranca.

Rapid7 recuperó dos binarios en la misma red durante una respuesta a incidente en marzo de 2026 y publicó el análisis el 21 de abril: un ELF de 64 bits en C++ escrito para ESXi y un PE en Rust para servidores Windows. Comparten identificador de campaña e infraestructura en Tor, así que todo apunta al mismo afiliado apuntando a las dos mitades de la misma casa. Conviene decir de entrada que el cifrado parcial no es ninguna novedad: LockFile lo usaba ya a mediados de 2021 —cifraba 16 bytes de cada 32 para burlar el análisis chi-cuadrado con el que algunos productos detectan ficheros cifrados— y desde 2022 lo anuncian como reclamo para afiliados Black Basta, ALPHV/BlackCat, PLAY, Agenda y Qyick. Lo que aporta Rapid7 es el desensamblado con los números delante, y esos números tienen consecuencias concretas para tu plan de recuperación.

Qué hace exactamente con cada fichero

El recorrido es recursivo sobre /vmfs/volumes y no sigue enlaces simbólicos. Para cada fichero, tres tramos:

• Menos de 1 MB: se cifra entero.
• Entre 1 y 4 MB: solo el primer MB.
• Más de 4 MB: una porción proporcional, el porcentaje configurable que Rapid7 observó puesto en 10.

El motivo que da Rapid7: reduce mucho el tiempo de cifrado «mientras sigue dejando inservibles los ficheros grandes (por ejemplo, VMDK)». Ficheros cifrados con extensión .xhsyw; excluye .locksignal, .processing, .cryptdata_backup, .tmp, readme.txt y .sf, los ficheros de sistema de VMware.

El 90 % de los bytes del VMDK sigue siendo tuyo, byte a byte, y da exactamente igual. Rapid7 no publica dónde cae esa porción dentro del fichero, y tampoco hace falta saberlo: un disco virtual con 50 GB de ruido metidos por algún sitio no arranca, y el contenido no se recupera a mano en un plazo que le sirva a nadie. Cuidado con la tentación de convertir esto en un «diez veces más rápido»: nosotros no podemos afirmarlo y Rapid7 tampoco lo dice —habla de reducir mucho el tiempo de cifrado, sin dar factor—, porque el recorrido del datastore, la apertura de cada fichero y las esperas de entrada/salida siguen ahí. Lo que sí se puede decir es que la ventana entre «ha empezado» y «ya da igual» se acorta, y no sabemos cuánto. Si tu detección tarda una hora, el factor exacto es una discusión académica: llegas tarde.

Antes de cifrar, apaga a los testigos

La secuencia en el host es corta. Enumera con esxcli vm process list, mata con esxcli vm process kill type=soft world-id <id> —con lista blanca opcional para respetar alguna máquina— y, antes de cifrar nada, sustituye tres ficheros por la nota de rescate: /etc/motd y los dos index.html del Host Client. Sobre la parte de apagar defensas antes de empezar ya escribimos con detalle a cuenta de DeadLock y su lista de servicios, así que aquí solo apuntamos lo que cambia en un hipervisor: las máquinas que apaga son donde vive tu detección. Lo que quede por ver, lo tiene que ver el host.

En el hipervisor no tienes agente, y no es un descuido tuyo

Lo dice Broadcom en su propio artículo de la base de conocimiento, el 330057: «It is not supported to install 3rd Party Agents or Antivirus Software directly on the VMware vCenter Server Appliance (VCSA) or ESXi hosts». No es que se te olvidara desplegar el agente en los hosts: es que no está soportado, y el día que abras un caso te lo van a recordar. ESXi está más cerca del firmware de un router que de un sistema operativo de propósito general, y no está hecho para correr software pensado para Windows o para Linux; lo que el propio artículo propone son herramientas sin agente, algunas de las cuales entran por SSH, con lo que eso implica.

La defensa del host se reparte en tres decisiones, y ninguna se compra. Quién puede hablar con él: el modo lockdown obliga a operar a través de vCenter, con dos puertas que hay que auditar porque siguen abiertas incluso en lockdown estricto —la lista DCUI.Access y los Exception Users con permisos de administrador, que conservan DCUI, ESXi Shell y SSH—. Qué se le deja ejecutar: execInstalledOnly impide correr binarios que no vengan en un VIB firmado, y desde ESXi 8.0 la opción interna de ejecución viene activada de fábrica; la de arranque, no. Es decir, aquí no toca activar nada: toca comprobar que nadie la apagó para instalar algo, un caso lo bastante frecuente como para que Broadcom tenga artículo propio sobre hosts actualizados a 8.x que aparecen con ella desactivada. Qué manda fuera: syslog remoto, porque si te desfiguran el motd y el Host Client, lo de antes tiene que estar en otra máquina. Nuestro EDR/MDR gestionado hace su trabajo dentro de las máquinas virtuales y en los servidores; en el hipervisor lo que se vigila es el plano de gestión. Cuando una conversación sobre ESXi empieza por «¿qué antivirus le pongo al host?», va mal encaminada desde la primera frase.

La nota de rescate también hace marketing

La nota que deja el cifrador de ESXi presume de «AES-256-CTR, X25519 and Kyber1024». El binario usa ChaCha8 y envoltura de claves con RSA-4096; Rapid7 lo identificó por las constantes de rotación y por la sigma «expand 32-byte k». Ni X25519 ni Kyber por ninguna parte. En la variante de Windows sí está lo que dice —Kyber1024 con clave pública de 1.568 bytes, que es el tamaño que le toca, y AES-256-CTR para el grueso—, así que no es que no sepan hacerlo: es que en el cifrador que va a tu hipervisor no se molestaron. Rapid7 lo resume diciendo que las notas de rescate resultan ser «más aspiracionales que exactas».

Llévate ese detalle al comité cuando toque discutir si se paga. El actor miente en la ficha técnica de su propio producto, donde mentir no le aporta nada; la promesa de devolverte los datos sale de la misma imprenta. Esta mañana escribíamos sobre los que aparecen después ofreciéndose a rescatarte; esto es el otro extremo de la misma cuerda.

Tu copia es un objetivo, no el plan B

La variante de Windows del mismo afiliado detiene los servicios cuyo nombre contenga msexchange, vss, backup, veeam y sql, y ejecuta wbadmin DELETE SYSTEMSTATEBACKUP, también con -deleteOldest. Veeam aparece por su nombre en la lista. Trae además una función experimental para Hyper-V: Get-VM | select VMId, Name | ConvertTo-Json para inventariar y Stop-VM -Force -TurnOff para apagar en seco.

Traducido: la copia que se administra con las mismas credenciales que todo lo demás no es una copia, es otra carpeta. Ya escribimos sobre el caso extremo de esto —el servidor de copias metido en el dominio que tiene que restaurar— y sigue siendo la dependencia circular que más nos encontramos. Lo que sí aguanta: retención que el propio administrador no puede acortar, poda ejecutada en el servidor de copias y no en el cliente, credenciales distintas de las del dominio y, al menos, una copia que ningún proceso de producción puede alcanzar.

«Pues me paso a Proxmox»

Nos lo dicen a menudo, y lo entendemos, pero no. Halcyon documentó la variante Linux de Pay2Key —detectada a finales de agosto de 2025— con lógica escrita a mano para Proxmox: comprueba que exista /etc/pve, inventaria con pvesh get /cluster/resources, para máquinas y contenedores con qm stop --skiplock y pct stop --skiplock, y a las copias les quita primero el pestillo con pvesh set .../content/<backup> --protected 0 para después borrarlas con pvesh delete. De eso ya hablamos con el código de pve-storage delante: el flag protected de Proxmox no es un candado.

Una migración de VMware a Proxmox se decide por coste, por licencias y por arquitectura, y motivos hay de sobra estos dos años. Pero si alguien la está justificando en el comité con el argumento de la seguridad, ese argumento se cae con el análisis de Halcyon encima de la mesa: lo que hoy hay menos es cifradores hechos para Proxmox, y la cuota de mercado del atacante de turno no es una capa de tu defensa.

Lo que cambia el resultado esta semana

• Sacar el plano de gestión de la red plana: vCenter, los hosts, la interfaz del PVE, los iDRAC/iLO. Es lo más aburrido de la lista y lo que más cambia el desenlace.
• Cuentas nominales y MFA en vCenter y en Proxmox. Nada de una contraseña de root que sabe media empresa.
• Modo lockdown, SSH apagado salvo ventana con motivo, y revisar quién hay en DCUI.Access y en la lista de Exception Users: ahí es donde se cuelan los accesos que creías cerrados.
• Los registros del host, fuera del host. Si te desfiguran la interfaz de gestión, lo que pasó antes tiene que estar en otra máquina.
• Una restauración cronometrada de una máquina grande. No «verificar la copia»: arrancarla y mirar el reloj.

Cuándo no haríamos nada de esto

Si tienes tres hosts, una cabina y dos personas de IT, no te pongas a rehacer el arranque seguro de los hosts esta semana. execInstalledOnly ya viene puesto en 8.x, y donde va a chirriar es el día que un fabricante te pida correr su instalador suelto o meter un VIB sin firmar: entonces tocará decidir, y esa decisión merece estar escrita. Empieza por el primer punto de la lista y por el último: la red de gestión y el cronómetro. Tampoco hay nada que comprar hoy —los cuatro primeros son configuración— y si alguien te ofrece un EDR «para el hipervisor», la pregunta educada es dónde se instala exactamente el agente.

Al final, la cifra de este análisis que acaba en tu acta no es el 10 %: son los minutos que pasan entre «esto está cifrado» y «esta máquina vuelve a dar servicio». Nuestro último simulacro de recuperación completa duró 14 minutos, y conviene decir de qué hablamos: un simulacro planificado sobre nuestra propia infraestructura, no un incidente real con análisis forense por medio, que no se parece en nada. Es una prueba nuestra y no un compromiso de servicio; el número de tu empresa solo lo vas a saber cuando lo cronometres. Si no lo has cronometrado nunca, ese RTO que figura en tu plan es una intención, no una medida.

Fuentes: los tres tramos de tamaño, el porcentaje configurable con valor por defecto 10, la frase sobre dejar inservibles los VMDK, la extensión .xhsyw y las exclusiones, la secuencia esxcli vm process list/kill, la desfiguración de /etc/motd y del Host Client, el desajuste entre la nota (AES-256-CTR, X25519, Kyber1024) y el binario (ChaCha8 + RSA-4096), el Kyber1024 real de la variante Windows con clave pública de 1.568 bytes, los servicios detenidos, wbadmin DELETE SYSTEMSTATEBACKUP y la función experimental de Hyper-V — Rapid7, «Kyber Ransomware Double Trouble», 21-abr.-2026; el soporte de agentes de terceros en ESXi y VCSA — Broadcom, artículo 330057; qué conservan los usuarios de DCUI.Access y los Exception Users con permisos de administrador en lockdown normal y estricto (DCUI, ESXi Shell y SSH) — documentación de vSphere 8.0, Broadcom; que la opción interna execInstalledOnly viene activada por defecto desde ESXi 8.0 y la de arranque no — documentación de vSphere 8.0, y los hosts actualizados a 8.x que aparecen con ella desactivada — Broadcom, artículo 401376; el historial del cifrado intermitente (LockFile a mediados de 2021 cifrando 16 bytes de cada 32 contra el análisis chi-cuadrado, y su adopción posterior por Black Basta, ALPHV/BlackCat, PLAY, Agenda y Qyick) — SentinelOne Labs, oct.-2022; la lógica específica para Proxmox de la variante Linux de Pay2Key (/etc/pve, pvesh, qm stop --skiplock, --protected 0) — Halcyon, «Pay2Key Linux». Los 14 minutos del simulacro son un dato interno de everyWAN: es lo que tardamos nosotros la última vez, no un compromiso de servicio.