Qué es Virtualization-Based Security (VBS) y cómo funciona en Windows

La seguridad basada en virtualización, o VBS, se ha convertido en una de las piezas clave del ecosistema de seguridad de Windows 10, Windows 11 y Windows Server modernos. Es una de esas funciones que la mayoría de usuarios no ve, pero que puede marcar la diferencia entre un ataque exitoso al kernel y un sistema que aguanta el tipo incluso frente a malware muy sofisticado.

Al mismo tiempo, VBS y HVCI generan dudas por su impacto en el rendimiento, sobre todo en PCs gaming o equipos con hardware más veterano. De ahí que muchos usuarios se planteen qué hace exactamente esta tecnología, para qué sirve, cómo se activa (o desactiva) y qué implicaciones reales tiene tanto en seguridad como en FPS, latencias y uso de CPU.

Qué es Virtualization-Based Security (VBS) en Windows

La Virtualization-Based Security (VBS) es una característica de seguridad de Microsoft que se apoya en la virtualización de hardware y en el hipervisor de Windows para crear un entorno de ejecución aislado dentro del propio sistema. Ese entorno virtual se convierte en una especie de raíz de confianza desde la que se asume el peor escenario: que el kernel de Windows podría estar comprometido y aun así haya que proteger recursos críticos.

En la práctica, VBS monta un pequeño “mini-sistema” protegido usando las capacidades de virtualización de la CPU (Intel VT-x, AMD-V, etc.) y lo utiliza para alojar distintas soluciones de seguridad: integridad de memoria, Credential Guard, protecciones de arranque, entre otras. Al estar separado del kernel normal, este entorno es mucho más difícil de atacar incluso con vulnerabilidades de día cero del sistema operativo.

Este mecanismo permite que recursos muy sensibles del sistema y de seguridad (como credenciales, claves criptográficas o estructuras internas del kernel) queden fuera del alcance del código que se ejecuta en modo kernel “normal”, precisamente el objetivo favorito del malware avanzado.

Otro punto importante es que VBS impone restricciones muy estrictas sobre cómo se gestiona la memoria del kernel. Ciertas regiones solo pueden ser ejecutables una vez han superado comprobaciones de integridad dentro del entorno seguro y, una vez marcadas como ejecutables, no pueden modificarse. Así, un desbordamiento de búfer o una vulnerabilidad de corrupción de memoria puede permitir escribir en memoria, pero no convertir esa memoria en código ejecutable que comprometa todo el sistema.

Cuando VBS se habilita dentro de una máquina virtual, se arranca una variante de Hyper-V en el propio invitado y Windows pasa a ejecutarse en la partición raíz de ese hipervisor interno. Es como si el sistema operativo se encapsulara dentro de su propia capa de virtualización para reforzar sus defensas.

Integridad de memoria e integridad de código en modo kernel (HVCI)

Dentro del paraguas de VBS, una de las piezas más relevantes es la integridad de memoria, también conocida como Hypervisor-Enforced Code Integrity (HVCI) o integridad de código protegida por hipervisor. Esta función se encarga de endurecer el sistema comprobando que todo el código que se ejecuta en modo kernel cumple unas reglas estrictas de firma y confianza.

En términos simples, HVCI valida cada controlador (driver) y binario de modo kernel antes de que se cargue. Si el controlador no está firmado correctamente, está alterado o proviene de una fuente no confiable, se bloquea su carga en memoria. Esto cierra uno de los vectores clásicos de ataque: colar un driver malicioso con privilegios elevados.

Además, la integridad de memoria limita de forma agresiva cómo se pueden hacer asignaciones de memoria del kernel. Las páginas de memoria destinadas a código ejecutable del kernel solo pasan a ser ejecutables después de superar las validaciones de integridad en el entorno VBS y nunca vuelven a ser páginas de escritura. Esto evita técnicas típicas de explotación donde se inyecta código en memoria del kernel y se hace ejecutable al vuelo.

HVCI también protege estructuras críticas como el mapa de bits de Control Flow Guard (CFG) para drivers del kernel y el propio proceso de integridad de código que verifica otros componentes. De esta forma, se reduce drásticamente la capacidad del malware de manipular el flujo de ejecución de procesos privilegiados.

Eso sí, toda esta protección tiene un coste: introduce cierta sobrecarga sobre la CPU, que puede ser mayor o menor dependiendo de si el procesador incluye aceleraciones de hardware como MBEC (Mode-based Execution Control) o equivalentes, y del tipo de carga de trabajo (juegos, render, etc.).

Requisitos de hardware y firmware para usar VBS

Para que la seguridad basada en virtualización pueda activarse de forma completa y estable, Windows exige una serie de requisitos mínimos de hardware y firmware. No basta con tener un sistema operativo moderno; la plataforma debe exponer ciertas capacidades al sistema.

En primer lugar, es obligatorio contar con una CPU de 64 bits con extensiones de virtualización. En el mundo x86, eso significa soporte para Intel VT-x o AMD-V. Sin hipervisor no hay VBS, ya que toda la protección se construye encima de esa capa de virtualización.

También se requiere compatibilidad con traducción de direcciones de segundo nivel (SLAT). En Intel esto se concreta en EPT (Extended Page Tables) y en AMD en RVI o NPT (Rapid Virtualization Indexing). SLAT reduce la penalización de rendimiento típica de la virtualización y permite que VBS funcione con una sobrecarga asumible.

Otro componente clave es disponer de una IOMMU o SMMU (Intel VT-d, AMD-Vi o SMMU en plataformas Arm64). Estas unidades permiten controlar el acceso DMA de los dispositivos de E/S, de forma que no puedan escribir de manera arbitraria en memoria. Todos los dispositivos con capacidad DMA deben estar “detrás” de una IOMMU para que el sistema pueda mitigar ataques de acceso directo a memoria.

Además, VBS se apoya fuertemente en el TPM 2.0 (Trusted Platform Module). Este chip, integrado en placa o implementado de forma firmware, sirve para almacenar de manera segura credenciales, claves de cifrado y mediciones de arranque. VBS puede reutilizar el espacio de memoria protegido por TPM para guardar información muy sensible como credenciales o datos de autenticación.

El firmware también tiene deberes: la UEFI debe cumplir ciertas directrices de asignación y reporte de memoria para que el sistema operativo sepa qué regiones se pueden usar para el entorno aislado. Igualmente, debe implementar protecciones de System Management Mode (SMM), declaradas a través de la tabla ACPI de la Windows SMM Security Mitigations Table (WMST / WSMT), indicando que cumple los requisitos que Windows espera para habilitar las características de VBS.

Relacionado con esto, entra en juego la Memory Overwrite Request (MOR) v2, que mediante una variable segura UEFI protege la configuración de bloqueo de sobrescritura de memoria, ayudando a defenderse de ataques avanzados que intentan reusar contenidos de memoria tras reinicios.

Finalmente, es imprescindible que todos los controladores instalados sean compatibles con la integridad de memoria. Microsoft proporciona en el Windows Driver Kit y en el Comprobador de controladores (Driver Verifier) pruebas específicas para validar que un driver no viola las reglas de HVCI. Lo normal es:

• Ejecutar el Comprobador de controladores con las comprobaciones de compatibilidad de integridad de código activadas.
• Pasar la prueba de preparación de integridad de código de hipervisor en el Windows HLK.
• Probar el controlador en sistemas con VBS e integridad de memoria habilitados en tiempo de ejecución.

En muchos despliegues corporativos se exige además que el sistema arranque en modo Secure Boot, de forma que solo se cargue firmware y bootloaders firmados, completando así la cadena de confianza desde la UEFI hasta el entorno VBS.

VBS, HVCI y su integración en Hyper-V y entornos virtuales

VBS no es solo cosa de equipos físicos; también se puede aprovechar dentro de máquinas virtuales. Aquí entra en juego tanto Hyper-V como otros hipervisores como VMware ESXi, que ya ofrecen soporte específico para estas funciones de seguridad.

En entornos Hyper-V, se puede habilitar VSM invitado (Guest VSM) para que la máquina virtual de Windows disponga de su propio entorno VBS dentro del invitado. En Azure, por ejemplo, las máquinas virtuales de generación 2 lo traen activado por defecto en muchas de sus series, y también se soporta virtualización anidada en varias familias.

Algunas de las series de Azure con soporte para virtualización anidada y/o VSM invitado incluyen familias como Av2, Dsv2/Dv2/Dv3, Esv3/Edsv3, Fsv2, Lsv2 y generaciones más recientes como Dv4/Dv5, Esv5, entre otras. El detalle concreto varía según generación (1 o 2) y tamaño, pero la idea es que gran parte del catálogo moderno de Azure puede ejecutar VBS dentro de las VMs.

En VMware, desde vSphere 6.7 en adelante con CPUs Intel (y desde vSphere 7 Update 2 para CPUs AMD compatibles) se permite activar VBS en máquinas virtuales Windows invitadas. Es requisito usar versiones de hardware de VM recientes (por ejemplo, hardware 14 o superior en Intel y 18 o superior en AMD) e invitados como Windows 10 de 64 bits, Windows Server 2016 o 2019.

En el cliente de VMware (VMware Host Client), se puede marcar la opción de “Enable Windows Virtualization Based Security” al crear la VM o activarla más tarde en una VM existente. Esto habilita automáticamente:

• Firmware UEFI con Secure Boot.
• Exposición de virtualización asistida por hardware al invitado.
• IOMMU y resto de mecanismos requeridos.

Cuando se activa VBS en una VM existente, hay que asegurarse de que ya usa firmware UEFI. Un cambio posterior de BIOS heredada a EFI puede ser delicado y requerir pasos extra para no dejar al invitado sin arrancar.

Dentro de la VM, el proceso de habilitar VBS suele implicar instalar el rol de Hyper-V (en el caso de Windows Server) y configurar posteriormente las directivas de seguridad (por ejemplo, mediante gpedit.msc en Device Guard > Turn On Virtualization Based Security), seleccionando niveles como Secure Boot and DMA Protection, HVCI activado con bloqueo UEFI y configuración de Credential Guard.

VBS como herramienta de seguridad en máquinas virtuales e infraestructuras

Más allá de la parte puramente técnica, VBS se integra en estrategias de seguridad de entornos virtualizados, donde las VMs manejan información tan valiosa como el propio host físico o incluso más.

En muchas organizaciones, las máquinas virtuales no son solo entornos de pruebas: dan servicio a aplicaciones de producción, bases de datos y sistemas que tratan datos sensibles. Esto las convierte en objetivo prioritario de atacantes, que buscan comprometer tanto la VM como, si es posible, pivotar hacia el host y el resto de la red.

VBS es útil aquí porque aísla la VM del host físico en cuanto a acceso a hardware, interfaces de red y, en determinados escenarios, incluso en la gestión de identidad. Cuando se usa junto con la gestión de identidades de Active Directory, se puede hacer que el acceso a determinadas VMs dependa directamente de las credenciales corporativas en lugar de usuarios/contraseñas locales.

Este enfoque permite revocar rápidamente el acceso a VMs sensibles si un empleado abandona la empresa, se detectan actividades sospechosas o se produce una brecha. En vez de ir máquina por máquina cambiando contraseñas, basta con ajustar permisos en AD y las políticas asociadas a esos recursos virtuales.

Además, VBS contribuye a limitar el impacto de ataques que se originan dentro de la propia VM. Aunque un atacante consiga elevar privilegios dentro del invitado, la capa VBS puede seguir protegiendo las credenciales y el código crítico del kernel, dificultando mucho el robo de secretos o el uso de técnicas de movimiento lateral basadas en drivers maliciosos.

La integridad de memoria, en particular, refuerza este modelo, ya que impide que controladores poco fiables se carguen y bloquea varios vectores habituales de escalada de privilegios dentro de sistemas Windows virtualizados.

VBS y HVCI en Windows gaming: impacto en rendimiento y cuándo desactivarlos

Donde la película cambia bastante es en el ámbito del PC gaming. Microsoft ha ido activando VBS e integridad de memoria por defecto en determinadas instalaciones limpias de Windows 10 y, sobre todo, Windows 11, lo que ha despertado mucho debate por la posible pérdida de rendimiento en juegos.

La realidad es que el impacto depende muchísimo del hardware y del tipo de carga. En procesadores relativamente modernos, con soporte para MBEC u otras mitigaciones de hardware, la sobrecarga puede rondar cifras como el 3-5 % en muchas tareas generales. En escenarios concretos o con CPUs sin MBEC (por ejemplo, plataformas AMD Zen+), la penalización al activar HVCI puede escalar hasta alrededor del 10-12 % en benchmarks sintéticos.

En equipos más antiguos o con ciertas generaciones de Intel y AMD, se han visto casos extremos de pérdidas cercanas al 25-28 % en algunos juegos concretos o pruebas sintéticas, especialmente cuando se combinan VBS, HVCI y otras capas de protección, y cuando los títulos dependen mucho del rendimiento monohilo de la CPU.

Varios creadores de contenido y expertos en rendimiento han demostrado que, en determinados PCs, desactivar la integridad de memoria y el hipervisor puede devolver una cantidad apreciable de FPS. Esto se nota sobre todo en títulos muy CPU-dependientes (estrategia con muchos cálculos, simuladores complejos, juegos mal optimizados, etc.).

Dicho esto, la pérdida del “28 % fijo” que algunos titulares han popularizado no es una verdad universal. En muchos portátiles y sobremesas recientes, las pruebas muestran una caída mucho más modesta, alrededor del 3 % si solo está activo VBS sin HVCI, y algo más notable cuando se fuerza la integridad de memoria en CPUs no optimizadas para ello.

Entonces, ¿tiene sentido desactivarlo? En un PC que se usa casi exclusivamente para jugar y que no maneja datos ultrasensibles, puede ser razonable deshabilitar HVCI o incluso VBS si se quiere exprimir hasta el último frame, siempre que el usuario mantenga buenas prácticas de seguridad: sistema al día, antivirus activo, nada de software pirata ni ejecutables “sospechosos”.

Sin embargo, en entornos profesionales, en equipos de trabajo que tratan información de clientes o en puestos donde la seguridad es prioritaria, no es buena idea sacrificar VBS a cambio de unos cuantos FPS. Aquí pesa mucho más la protección contra malware avanzado y ataques al kernel que la ganancia de rendimiento en juegos que quizá ni se ejecutan en esos equipos.

Cómo saber si VBS está activo y cómo se gestiona desde Windows

Para comprobar si la seguridad basada en virtualización está funcionando en un equipo con Windows 10 u 11, se puede recurrir a varias herramientas que ofrece el propio sistema. De este modo, es posible ver el estado de VBS, HVCI y otras características relacionadas.

Una de las formas más directas es abrir msinfo32.exe (Información del sistema) y, en el resumen del sistema, desplazarse hasta la línea de “Seguridad basada en virtualización”. Ahí se indica claramente si está desactivada, habilitada pero no en ejecución, o en funcionamiento.

Otra opción más avanzada es utilizar PowerShell con privilegios de administrador y consultar la clase WMI Win32_DeviceGuard con el comando:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

La salida de esta consulta ofrece un desglose muy detallado: propiedades de seguridad de hardware disponibles (hipervisor, Secure Boot, DMA protection, MBEC, etc.), servicios configurados y en ejecución (Credential Guard, integridad de memoria), estado de VBS, nivel de aislamiento SMM, entre otros parámetros.

Para gestionar VBS e integridad de memoria a nivel de empresa, Microsoft recomienda el uso de directivas de grupo, plantillas de Device Guard o scripts de registro que establecen claves como:

• EnableVirtualizationBasedSecurity para activar/desactivar VBS.
• RequirePlatformSecurityFeatures para exigir solo Secure Boot o Secure Boot + protección DMA.
• Mandatory para que el arranque falle si no puede cargarse el hipervisor o el kernel seguro.
• Claves bajo Scenarios\HypervisorEnforcedCodeIntegrity para habilitar HVCI y decidir si se bloquea por UEFI.

También se puede controlar la visibilidad de la opción de integridad de memoria en la interfaz de Windows Defender, atenuándola y mostrando mensajes del tipo “This setting is managed by your administrator” para impedir que el usuario la cambie por su cuenta.

En el caso de tener problemas de estabilidad graves tras activar HVCI (pantallas azules al arrancar, drivers que fallan, etc.), se puede recurrir al Entorno de recuperación de Windows (Windows RE) para arrancar en modo de recuperación, deshabilitar las políticas pertinentes y ajustar las claves de registro para dejar integridad de memoria en estado desactivado antes de reiniciar.

Buenas prácticas de seguridad para VMs y PCs con o sin VBS

VBS ayuda, pero no sustituye a una higiene básica de seguridad, tanto en máquinas físicas como en entornos virtualizados. De hecho, muchas prácticas recomendables son independientes de que tengamos esta capa activada o no.

Uno de los pilares es utilizar contraseñas fuertes y únicas para cada máquina virtual y cuenta sensible. Un gestor de contraseñas (o funciones integradas en soluciones VPN o de directorio) simplifica mucho mantener contraseñas robustas y no reutilizadas.

Otra medida fundamental es proteger los puertos de red. Bloquear puertos innecesarios y limitar el acceso solo a IP o segmentos de red autorizados reduce muchísimo la superficie de exposición de las VMs, evitando que servicios internos queden a tiro desde cualquier lugar.

En determinados escenarios, algunas organizaciones optan por técnicas como la “envoltura” o aislamiento reforzado de máquinas virtuales, donde se crea un perímetro de seguridad alrededor de la VM y su host para que el resto de la red no pueda interactuar directamente. Esto permite, por ejemplo, poner en cuarentena una VM sospechosa sin arriesgar la infraestructura completa.

Mantener todo el software actualizado es igualmente crítico. El software antiguo sin parches es caldo de cultivo para exploits ya conocidos, por lo que, si hay que utilizar aplicaciones heredadas, es recomendable confinarlas en VMs muy aisladas y con el mínimo acceso posible al resto de la red.

Por supuesto, no hay que olvidarse de instalar soluciones de prevención de malware integradas en el entorno virtual, que controlen tráfico, procesos y accesos remotos a las VMs. Es preferible prevenir e interceptar un ataque antes de que alcance al núcleo del sistema, incluso aunque VBS pueda amortiguar su impacto.

Finalmente, cualquier estrategia seria debería incluir un plan sólido de copias de seguridad y snapshots de máquinas virtuales. Si una VM se ve comprometida, es mucho más rápido y seguro restaurar una instantánea conocida que tratar de limpiar un sistema en producción comprometido, lo que además evita que el atacante siga moviéndose dentro de la red.

A la hora de equilibrar seguridad y rendimiento, especialmente en equipos domésticos, gaming o mixtos, tiene sentido valorar qué nivel de riesgo se está dispuesto a asumir, qué tipo de tareas se realizan y si compensa mantener VBS e HVCI activados todo el tiempo o únicamente en equipos y perfiles donde la protección del kernel y de las credenciales sea prioritaria frente a cualquier impacto en FPS o recursos de CPU.