Bastionado de VMware ESXi y vCenter contra ransomware: guía técnica 2026 y qué cambia en Proxmox, Hyper-V y Nutanix

El bastionado de ESXi contra ransomware es el conjunto de controles de identidad, host, red, registros y copias que impide a un atacante cifrar desde el hipervisor todas las máquinas virtuales a la vez. Un solo cifrado del almacén de datos deja sin servicio, en minutos, todas las máquinas que dependen de él: controladores de dominio, ERP, correo y, demasiadas veces, la infraestructura de copias. Por eso los grupos de ransomware llevan desde 2022 publicando variantes para VMware ESXi, y por eso la toma de control de vCenter se ha convertido en uno de los peores escenarios que puede vivir una empresa.

Esta guía de bastionado de ESXi y vCenter reúne los controles que más reducen ese riesgo en vSphere 8 y 9, ordenados por fases y con los comandos para aplicarlos y comprobarlos. Incluye también los registros que permiten detectar el ataque a tiempo y lo que cambia para quien ha migrado a Proxmox, Hyper-V o Nutanix. Se basa en las guías publicadas en 2026 por Mandiant, la guía de configuración de seguridad de Broadcom, la STIG (guía técnica de configuración segura) de DISA para ESXi 8 y los avisos de CISA, contrastados con lo que vemos en respuesta a incidentes.

¿Por qué el ransomware apunta al hipervisor?

El ransomware apunta al hipervisor porque un solo cifrado detiene cientos de servidores a la vez y porque ESXi no admite agentes EDR, de modo que el atacante trabaja allí con poca visibilidad. Los datos de los últimos dos años confirman el desplazamiento:

• En julio de 2024, Microsoft informó de que los casos de su equipo de respuesta con ESXi implicado se habían más que duplicado en tres años.
• Huntress observó que el peso de los hipervisores en los cifrados maliciosos pasó del 3 % en el primer semestre de 2025 al 25 % en lo que iba del segundo, sobre todo por Akira.
• El informe M-Trends 2026 de Mandiant describe un ransomware que ya cifra almacenes de datos de hipervisores en lugar de máquinas sueltas, y que busca antes la identidad, la gestión de la virtualización y las copias.

La lista de grupos con cifrador para ESXi es larga: LockBit desde enero de 2022, Black Basta, Royal y BlackSuit, Akira, Qilin, RansomHub, Play y, desde 2025, The Gentlemen. En febrero de 2023, la campaña ESXiArgs comprometió más de 3.800 servidores en todo el mundo, según el aviso conjunto de CISA y el FBI. Akira dio además un paso nuevo en junio de 2025, cuando cifró por primera vez discos de máquinas virtuales en Nutanix AHV, según la actualización del aviso de CISA de noviembre de 2025.

La urgencia de 2026 está en vCenter. Broadcom publicó el 29 de julio el aviso VMSA-2026-0006, que analizamos en los tres fallos críticos de vCenter y ESXi, y la firma alemana QUIRSO detectó actividad maliciosa desde el 1 de agosto. Según The Hacker News, afectó a unas 361 direcciones IP de 47 países y terminó con un cifrador derivado de Babuk que, según QUIRSO, pudo servir también para destruir los registros de ESXi.

Aviso: los comandos y ajustes de esta guía son orientativos y no sustituyen una evaluación de cada entorno. Deben probarse en preproducción, con copia de seguridad y plan de marcha atrás, antes de aplicarlos en producción, y algunos cambios, como el cifrado de la configuración con TPM, no se pueden revertir. Su aplicación es responsabilidad de cada organización. Las referencias normativas tienen carácter informativo y no constituyen asesoramiento jurídico.

¿Cómo es la cadena de ataque contra vSphere?

La cadena de ataque contra vSphere pasa casi siempre por la identidad antes que por el hipervisor, y Mandiant advierte de que, en manos de UNC3944 (Scattered Spider), puede completarse en cuestión de horas. Su análisis de julio de 2025 y los avisos de CISA sobre Akira describen una secuencia que se repite, con su correspondencia en MITRE ATT&CK v20:

1. Acceso inicial con una cuenta válida (T1078), obtenida con una llamada al servicio de soporte, una VPN sin parchear o un fallo de vCenter expuesto.
2. Control del Directorio Activo y abuso de su relación con vSphere, por ejemplo con el grupo "ESX Admins" de CVE-2024-37085, que daba administración total sobre los hosts unidos al dominio.
3. Acceso a vCenter Server Appliance y, desde allí, activación de SSH en los hosts ESXi (T1021.004) y desactivación de protecciones como el modo de bloqueo o lockdown mode (T1685).
4. Robo de credenciales sin tocar el sistema operativo invitado: se apaga o se clona la máquina del controlador de dominio y se extrae NTDS.dit de su disco (T1003.003).
5. Borrado de instantáneas, trabajos de copia y repositorios (T1490), a veces tras añadir cuentas al grupo de administradores de Veeam.
6. Apagado masivo de máquinas virtuales (T1529) y cifrado de los VMDK con esxcli y scripts (T1059.012 y T1486).

Existe una variante sin cifrado que también obliga a bastionar. El grupo UNC5221 usó la puerta trasera BRICKSTORM en vCenter con una permanencia media de 393 días, según Google Threat Intelligence. En octubre de 2026, CrowdStrike atribuyó a Warp Panda la explotación como zero-day de CVE-2026-41709, un fallo de baja gravedad que permitía a un administrador actuar sin dejar rastro en los registros de ESXi, según SecurityWeek.

¿Qué controles de bastionado de ESXi reducen más el riesgo de ransomware?

Los controles de bastionado que más reducen el riesgo de ransomware cortan la cadena en la identidad, el host y la red de gestión, y dejan la recuperación fuera del alcance del atacante. La tabla resume la secuencia recomendada; los apartados siguientes explican cómo aplicar cada control y qué puede romper.

Antes de cambiar la configuración, hay que conocer el estado de todos los hosts. Este informe de PowerCLI muestra en una sola tabla qué hosts siguen con SSH o la shell activos, sin lockdown mode, con el grupo "ESX Admins" añadido de forma automática o sin envío de registros:

# Inventario de exposición en todos los hosts conectados a vCenter (PowerCLI).
Get-VMHost | Select Name,
@{N="Lockdown";E={$_.ExtensionData.Config.LockdownMode}},
@{N="SSH";E={($_ | Get-VMHostService | ? Label -eq "SSH").Running}},
@{N="ESXiShell";E={($_ | Get-VMHostService | ? Label -eq "ESXi Shell").Running}},
@{N="AutoAddESXAdmins";E={($_ | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd).Value}},
@{N="ESXAdminsGroup";E={($_ | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup).Value}},
@{N="Syslog";E={($_ | Get-AdvancedSetting -Name Syslog.global.logHost).Value}}

Los comandos esxcli de esta guía pueden ejecutarse a través de vCenter con Get-EsxCli -V2 en PowerCLI, sin abrir SSH en los hosts. Cada cambio debe incorporarse además a la imagen de vLCM, a vSphere Configuration Profiles o al perfil de host, porque la siguiente remediación podría revertirlo.

¿Quién debe poder administrar vSphere?

Solo un grupo pequeño de cuentas nominativas, distintas de las de uso diario, autenticadas con MFA y conectadas desde estaciones de administración dedicadas. El cambio de mayor efecto es romper la dependencia entre el Directorio Activo de producción y los hosts. Mandiant recomienda no unir ESXi al dominio y gestionar todo el acceso a los hosts mediante los roles de vCenter.

La STIG de DISA pide integración con el directorio para la trazabilidad individual, pero su regla V-258737 no aplica cuando el host no tiene más cuentas locales que root y las de servicio. Sin unión al dominio, la trazabilidad llega por las cuentas nominativas de vCenter, cuyos eventos registran cada cambio. Quien controla el dominio no debe obtener, por diseño, el control del hipervisor. Donde la unión al dominio se mantenga, hay que aplicar los valores de Broadcom para CVE-2024-37085, corregido en ESXi 8.0 U3 y sin parche previsto para la rama 7.0:

# CVE-2024-37085: valores que Broadcom publica como seguros (KB 369707).
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd | Set-AdvancedSetting -Value $false -Confirm:$false
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.vimsvc.authValidateInterval | Set-AdvancedSetting -Value 90 -Confirm:$false
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup | Set-AdvancedSetting -Value "" -Confirm:$false
# Los permisos ya concedidos se mantienen: se listan y se retira la entrada del grupo.
esxcli system permission list
esxcli system permission unset -i "DOMINIO\ESX Admins" -g

En vCenter, la federación con un proveedor de identidad permite exigir MFA en el inicio de sesión, algo que una fuente LDAP no ofrece. vSphere admite AD FS desde la versión 7.0, Okta desde 8.0 U1, Microsoft Entra ID desde 8.0 U2 y PingFederate desde 8.0 U3, según la documentación de Broadcom. En VCF 9, la federación se configura una sola vez con VCF Identity Broker, que cubre vCenter, NSX y VCF Operations; la interfaz de SDDC Manager mantiene su cuenta local. La cuenta administrator@vsphere.local queda como acceso de emergencia, con la contraseña custodiada y alertas en cada uso.

El procedimiento de emergencia se prueba cada trimestre, incluido el acceso a la consola local desde la tarjeta de gestión del servidor (iDRAC, iLO o XCC), que también debe estar en la red de gestión aislada. Los roles de vCenter deben retirar además los privilegios VirtualMachine.GuestOperations a quien no los necesite, porque permiten ejecutar comandos dentro de las máquinas a través de VMware Tools; UNC3886 los abusó mediante CVE-2023-20867, según Mandiant. Es el mismo principio del modelo de niveles del Directorio Activo: vCenter, ESXi y las copias pertenecen al nivel 0.

¿Qué se cierra en cada host ESXi?

En cada host se cierra todo acceso que no pase por vCenter y toda ejecución de código que no llegue en un paquete firmado. El modo de bloqueo (lockdown mode) normal obliga a administrar el host desde vCenter; la guía de configuración de Broadcom lo recomienda y considera el modo estricto innecesario en la mayoría de los despliegues. La lista de usuarios de excepción debe quedar vacía salvo necesidad documentada, y el ajuste DCUI.Access, que define quién puede usar la consola local del host (DCUI) con el bloqueo activo, debe limitarse a la cuenta prevista.

SSH y la ESXi Shell deben quedar detenidos y con política de arranque desactivada, con tiempos de expiración (UserVars.ESXiShellTimeOut a 600 segundos y UserVars.ESXiShellInteractiveTimeOut a 900, como fija la STIG). La política de contraseñas y bloqueo de la STIG (tres intentos fallidos, desbloqueo a los 900 segundos y quince caracteres mínimos) cierra el ataque por fuerza bruta contra cuentas locales.

El control más eficaz contra el cifrador es execInstalledOnly, que impide ejecutar binarios que no se hayan instalado mediante un VIB (vSphere Installation Bundle, el paquete firmado de software de ESXi). ESXi 8 activa de serie la opción en tiempo de ejecución, aunque Broadcom advierte de que una actualización puede dejarla desactivada (artículo 401376). La opción de arranque, VMkernel.Boot.execInstalledOnly, es un ajuste distinto que exige la STIG.

Con arranque seguro y TPM 2.0 se puede imponer la opción de arranque, y un host iniciado con ella desactivada no arranca. La imposición no impide que root desactive la opción en tiempo de ejecución sin reiniciar, así que ese cambio requiere una alerta inmediata.

El orden importa: primero el arranque seguro en el firmware, después execInstalledOnly y un reinicio, y solo entonces la exigencia, según el artículo 373898 de Broadcom. Los hosts pasan por modo de mantenimiento de uno en uno, y las utilidades de fabricante copiadas como ficheros sueltos dejan de ejecutarse, algo que vmkernel.log registra como "Execution of non-installed file prevented".

# ESXi 8 solo activa de serie la opción en tiempo de ejecución; la de arranque debe fijarse.
# 1. Solo ejecutables instalados mediante VIB (requiere reinicio).
esxcli system settings kernel set -s execInstalledOnly -v TRUE
esxcli system settings kernel list -o execinstalledonly
# Valor en ejecución (1 = activo).
esxcli system settings advanced list -o /User/execInstalledOnly

Con el valor confirmado y tras el reinicio, se activa la exigencia:

# 2. Tras el reinicio, cifrar la configuración con el TPM y exigir arranque seguro.
esxcli system settings encryption set --mode=TPM
esxcli system settings encryption set --require-secure-boot=TRUE
esxcli system settings encryption set --require-exec-installed-only=TRUE
esxcli system settings encryption get
# 3. Guardar el secreto de recuperación fuera del host antes de seguir.
esxcli system settings encryption recovery list
# 4. Modo de mantenimiento y reinicio; el modo TPM no se puede revertir.

El secreto de recuperación que devuelve el último comando debe guardarse en un gestor de secretos fuera de vSphere. Sin ella, un cambio de placa base o de TPM obliga a reinstalar el host.

¿Cómo se aísla la red de gestión?

La red de gestión se aísla en VLAN dedicadas y en VRF (tablas de enrutamiento independientes), sin salida a internet y accesible solo desde la subred de las estaciones de administración. Mandiant propone redes separadas para la gestión de los hosts, vCenter, vMotion, almacenamiento y tráfico de las máquinas, con vMotion y almacenamiento no enrutables. Desde la subred de administración se permiten los puertos 443 y 902, y los puertos 22 y 5480 solo se abren desde esa subred cuando una tarea lo exige. La segmentación de la red interna aplica el mismo criterio al resto de la organización.

El cortafuegos de ESXi ya descarta el tráfico no listado, así que el control consiste en limitar cada servicio a una lista de direcciones permitidas. La de vSphereClient (puertos 443 y 902) debe incluir vCenter, la subred de administración y los proxies de copia, que usan el 902 en modo NBD, además de NSX Manager y SDDC Manager en VCF. Las direcciones se añaden antes de retirar "permitir todo". SLP, el servicio por el que entró ESXiArgs, viene desactivado de serie desde ESXi 7.0 U2c y 8.0, y desde 8.0 U2 su regla de cortafuegos la gestiona el sistema:

# Lista de direcciones permitidas por servicio (ejemplo: vSphereClient).
# Primero se añaden todas las direcciones: vCenter, subred de administración, proxies de copia (y NSX Manager y SDDC Manager en VCF).
esxcli network firewall ruleset allowedip add -r vSphereClient -i 10.10.50.0/24
esxcli network firewall ruleset allowedip add -r vSphereClient -i 10.10.60.10
esxcli network firewall ruleset allowedip list -r vSphereClient
# Solo después se retira "permitir todo"; una lista sin vCenter desconecta el host.
esxcli network firewall ruleset set -r vSphereClient --allowed-all false

En SLP, la comprobación consiste en confirmar que sigue desactivado:

# SLP: mantenerlo desactivado (en builds 7.0 anteriores a U2c, artículo 76372 de Broadcom; no aplica en ESX 9.0, que eliminó CIM y la regla CIMSLP).
esxcli system slp set -e 0
esxcli network firewall ruleset list | grep -i cimslp
# La regla CIMSLP debe aparecer como false.

¿Hasta dónde debe llegar el bastionado de vCenter?

El bastionado de vCenter Server Appliance debe llegar al mismo nivel que el de un controlador de dominio, porque quien controla vCenter gobierna todos los hosts. Las medidas básicas son desactivar SSH desde la consola de administración (VAMI, puerto 5480), limitar el grupo SystemConfiguration.BashShellAdministrators y aplicar los parches críticos en días, no en ventanas trimestrales. La rama 7.0 terminó su soporte general el 2 de octubre de 2025, y el aviso VMSA-2026-0006 remite a sus usuarios al soporte de Broadcom.

Desde abril de 2025, las descargas de parches exigen un token asociado al contrato de soporte, de modo que ese acceso debe comprobarse antes de necesitarlo (el cambio se detalla en el blog de VMware). Para priorizar, el catálogo KEV de CISA es la referencia: incluye los tres fallos de escape de máquina virtual del aviso VMSA-2025-0004, explotados como zero-day en marzo de 2025, y CISA ya asocia CVE-2025-22225 a campañas de ransomware. El criterio está desarrollado en KEV, EPSS y SSVC.

En abril de 2026, junto con su guía sobre vSphere y BRICKSTORM, Mandiant publicó una herramienta de código abierto que configura en el appliance un cortafuegos de denegación por defecto y el envío de cada comando de la shell al syslog. El repositorio de la herramienta avisa de que una configuración errónea aísla vCenter de inmediato y de que puede afectar al contrato de soporte, así que solo debe usarse tras probarla en preproducción.

¿Dónde deben vivir las copias de seguridad?

Las copias deben vivir fuera de la plataforma que protegen y fuera del dominio que el atacante busca controlar. Mandiant lo formula de forma directa: no alojar el Directorio Activo, las copias ni la gestión de accesos privilegiados en la plataforma de virtualización que esos sistemas protegen. El servidor de copias necesita un dominio de identidad separado o credenciales locales con MFA, y el almacenamiento debe ser inmutable durante el periodo de retención.

Veeam se conecta a vCenter con una cuenta dedicada y limitada a los privilegios que necesita, nunca con administrator@vsphere.local, y su autorización a cuatro ojos, disponible desde la versión 12.1, exige que un segundo administrador apruebe el borrado de copias o repositorios.

Las instantáneas de VMware no son copias: viven en el mismo almacén de datos y desaparecen con él. El repositorio reforzado de Veeam, por ejemplo, impide mover, modificar o borrar los ficheros durante el periodo de inmutabilidad, según su documentación. Hay que vigilar también los cambios en el grupo de administradores de Veeam (evento 4728 de Windows), porque UNC3944 lo usa para borrar trabajos y repositorios antes de cifrar.

La restauración tiene que probarse con tiempos medidos. En el informe de Veeam de 2026, solo el 28 % de las organizaciones afectadas recuperó todos sus datos. La regla 3-2-1-1-0 resume los requisitos.

¿Qué registros y alertas detectan el ataque a tiempo?

Los registros que detectan el ataque a tiempo son los de hostd, vpxa, shell, auth, vobd, vmkernel y esxupdate de cada host. A ellos se suman los eventos de vCenter y el registro de auditoría de su inicio de sesión único (SSO). vCenter conserva de serie solo 30 días de eventos, así que también deben salir al colector. Deben enviarse por TLS a un colector externo y conservarse al menos 400 días, el plazo que Mandiant recomienda tras medir permanencias de más de un año.

Los registros que solo viven en el host desaparecen con el cifrado, como mostró el caso de VMSA-2026-0006. Los registros de auditoría de ESXi vienen desactivados de serie y deben activarse. En hosts que arrancan desde SD o USB, Syslog.global.logDir debe apuntar a un almacén persistente distinto de vSAN, porque el disco en memoria pierde los registros al reiniciar.

# CA del colector en el almacén del host (fichero subido a un almacén de datos) y comprobación de certificados.
esxcli system security certificatestore add --filename=/vmfs/volumes/ds-admin/ca-siem.pem
esxcli system syslog config set --check-ssl-certs=true
esxcli system syslog config set --loghost=ssl://siem.ejemplo.local:6514
# La regla syslog cubre 514 y 1514; desde 8.0 U2b vmsyslogd abre otros puertos por sí mismo.
esxcli network firewall ruleset set -r syslog -e true
# Registros de auditoría en local (100 MB) y reenviados al colector.
esxcli system auditrecords local set --size=100
esxcli system auditrecords local enable
esxcli system auditrecords remote enable
esxcli system syslog reload

Estas son las señales que justifican una alerta inmediata, porque casi nunca forman parte de la operación normal:

Las reglas no tienen que escribirse desde cero. Splunk publica la colección "ESXi Post Compromise", con 24 detecciones, Elastic mantiene un conjunto equivalente para su integración de vSphere y SigmaHQ incluye reglas para esxcli. Elegir qué registros enviar al SIEM y probar cada regla con ingeniería de detección evita que la alerta llegue tarde. Un SOC gestionado que vigile estas fuentes cubre el hueco que deja un hipervisor sin EDR, el mismo que analizamos en los puntos ciegos del EDR.

¿Cuáles son los errores habituales al bastionar ESXi?

Los errores habituales son aplicar controles sin probar su efecto operativo y dar por cerrado el riesgo con un solo control. Los que más vemos son estos:

• Lockdown mode estricto activado sin cuentas de excepción preparadas: si vCenter cae, el host puede quedar inaccesible y obligar a reinstalarlo.
• Herramientas de terceros o de VMware que dejan de funcionar con el lockdown mode. En VCF 9, SDDC Manager no puede validar ni rotar contraseñas de hosts en lockdown mode, según el artículo 426417 de Broadcom.
• Confianza exclusiva en execInstalledOnly. Broadcom recuerda que no impide ejecutar scripts mediante intérpretes como Python, así que no sustituye al control de acceso ni al registro.
• Cifrado de configuración con TPM activado sin el secreto de recuperación a salvo.
• Un grupo "ESX Admins" renombrado con la suposición de que eso retira los permisos del grupo anterior, cuando la STIG advierte de que no lo hace.
• La STIG y la guía de Broadcom aplicadas sin decidir dónde discrepan: unión al dominio, cuenta de DCUI.Access, valor de esxAdminsGroup y nivel de registro.

Cada cambio debe pasar por preproducción, quedar documentado como excepción cuando no se aplique y verificarse después con el informe de PowerCLI anterior.

¿Cambia algo en Proxmox, Hyper-V o Nutanix?

Cambian las herramientas, pero el plano de gestión del hipervisor sigue siendo nivel 0 y los atacantes ya lo buscan fuera de VMware. Tras los cambios de licencias de Broadcom, Gartner estima que más de un tercio de las cargas que hoy corren en VMware estarán en otra plataforma en 2028, según Techzine. El caso de Akira en Nutanix AHV demuestra que una migración sin bastionado traslada el riesgo a la nueva plataforma.

En las tres plataformas valen las mismas reglas de las fases anteriores: identidad de administración separada del dominio de producción y con MFA, red de gestión aislada, registros fuera del host y copias en otra plataforma con almacenamiento inmutable.

¿Cómo encaja este bastionado en el ENS y NIS2?

Bastionar ESXi y vCenter aporta evidencia directa de medidas del ENS como op.acc.6, op.exp.8, mp.com.4 y mp.info.6, y de las letras c), i) y j) del artículo 21.2 de NIS2. En el ENS, el CCN publica la guía CCN-STIC 442, "Implementación de seguridad en VMware vSphere 8.x", actualizada en julio de 2025, y los controles de esta guía se corresponden con medidas del Real Decreto 311/2022:

• Identidad y MFA de administración: op.acc.3 y op.acc.4 (segregación de funciones y derechos de acceso) y op.acc.6 con los refuerzos R2 y R8 (segundo factor).
• Configuración y parches: op.exp.2, op.exp.3 y op.exp.4.
• Registros fuera del host y alertas: op.exp.8 (registro de la actividad) y op.mon.3 (vigilancia).
• Separación de la red de gestión: mp.com.4 (separación de flujos de información en la red).
• Copias inmutables y probadas: mp.info.6 (copias de seguridad).

En NIS2, el artículo 21.2 incluye la gestión de copias y la recuperación en su letra c), el control de acceso en la i) y la autenticación multifactor en la j). España sigue sin ley de transposición; lo que eso implica para las empresas está explicado en NIS2 sin ley en España. El servicio de bastionado de sistemas detalla cómo se documenta cada control para una auditoría.

¿Por dónde empezar?

El orden que más riesgo reduce en menos días empieza por los parches y termina por la arquitectura:

1. Revisión de que vCenter y ESXi están en versiones corregidas para VMSA-2026-0006 y para cada vulnerabilidad de VMware incluida en el catálogo KEV.
2. Informe de PowerCLI y cierre de SSH, la shell y el grupo "ESX Admins" en todos los hosts.
3. Envío de los registros de ESXi y vCenter a un colector externo y activación de las alertas de la tabla.
4. Verificación de que las copias y su consola están fuera de vSphere y del dominio de producción, con una restauración completa de prueba.
5. Plan de execInstalledOnly con exigencia por arranque seguro, empezando por un clúster de prueba.
6. Diseño de la separación de la red de gestión y de la federación de vCenter con MFA.

¿Cambia el orden si el cifrado ya está en marcha?

Sí: si hay indicios de compromiso, primero se contiene y se preservan evidencias, y después se bastiona. Esta es la secuencia que seguimos en incidentes de ESXi:

1. Aislamiento de la red de gestión y de vCenter en el conmutador o el cortafuegos, con una sola vía desde un puesto de respuesta, sin apagar ni reiniciar los hosts, cuyos registros pueden estar en un disco en memoria.
2. Registro de procesos y conexiones de cada host (esxcli system process list, esxcli network ip connection list) antes de detener un posible cifrador, porque el aislamiento no frena un proceso ya en marcha.
3. Máquinas encendidas sin apagar, porque el apagado destruye la memoria del invitado, aunque muchos cifradores detienen antes sus procesos. Si la memoria interesa, una instantánea con memoria o una suspensión genera ficheros .vmsn o .vmss y .vmem, que se copian de inmediato fuera del almacén.
4. Copia de /var/run/log de cada host antes del paquete vm-support, que ejecuta comandos en el host y escribe en él, junto con el paquete de soporte de vCenter. Cada fichero se resume con SHA-256 y se anota en un registro de cadena de custodia.
5. Revisión de persistencia antes de reconstruir: /etc/rc.local.d/local.sh, el crontab de root, cuentas locales nuevas y VIB que no superan "esxcli software vib signature verify".
6. Almacenes cifrados conservados intactos. La herramienta ESXiArgs-Recover de CISA reconstruyó máquinas a partir de ficheros que el malware no había cifrado.
7. Hosts reconstruidos desde una imagen verificada en un entorno aislado, con rotación de las credenciales de root, vCenter y copias.

Los plazos legales corren en paralelo: 72 horas ante la AEPD según el RGPD si hay datos personales, 24 horas para la alerta temprana de NIS2 donde aplique y notificación al CCN-CERT en sistemas del ENS. Un retainer de respuesta a incidentes contratado de antemano acorta esas primeras horas.

Fuentes y metodología: esta guía se basa en las publicaciones de Mandiant y Google Threat Intelligence, la documentación de Broadcom, la STIG de DISA para vSphere 8 y los avisos de CISA. También usa la guía CCN-STIC 442 y los informes de Microsoft, Huntress, CrowdStrike y QUIRSO, con la información disponible a 8 de noviembre de 2026. Las cifras se citan con su fuente y su fecha. La mención de VMware, Broadcom, Microsoft, Proxmox, Nutanix, Veeam y otros fabricantes es descriptiva, no presupone fallos en sus productos más allá de los avisos publicados y no constituye una recomendación comercial.