Integridad de memoria HVCI: verificar controladores, ejecución y bloqueo UEFI

¿Qué es la integridad de memoria HVCI?

La integridad de memoria HVCI es una protección de Windows que ejecuta la integridad del código del kernel dentro del entorno aislado proporcionado por la seguridad basada en virtualización (VBS). Su despliegue necesita tres respuestas distintas: qué configuración se pretende aplicar, si la integridad de memoria funciona realmente en cada dispositivo objetivo y si la recuperación sigue siendo posible tras elegir el modo de bloqueo UEFI. Una GPO de dominio solo responde a parte de la primera pregunta. Guía de habilitación de Microsoft

Para un equipo de AD, el resultado útil es un despliegue probado con evidencias por dispositivo. Empiece con una población representativa, resuelva las dependencias de los controladores, mida el servicio después de reiniciar y registre la decisión sobre el bloqueo. Incluya en el informe las máquinas que no pudieron medirse; omitirlas sin indicarlo hace que la cobertura de la directiva parezca una protección verificada.

Esta guía utiliza documentación de Microsoft Learn comprobada el 3 de octubre de 2026 y las dos comprobaciones del collector descritas más adelante. Los comandos de Windows son ejemplos de la documentación o adaptaciones identificadas de solo lectura; no se ejecutaron en un parque de Windows para este artículo. No se afirma ninguna cobertura del parque ni ninguna prueba de compatibilidad satisfactoria.

Nuestra guía de Credential Guard después de actualizar utiliza el mismo método de evidencia WMI para un servicio diferente: el aislamiento de determinados secretos. La integridad de memoria se ocupa de la integridad del código del kernel. Demostrar que un servicio está en ejecución no demuestra que el otro también lo esté.

Diferencias entre directiva, estado de ejecución y bloqueo UEFI

Un mismo número tiene significados diferentes según el ajuste. La referencia de la directiva VirtualizationBasedTechnology de Microsoft documenta el modo de la directiva y su correspondencia con la GPO de Device Guard. La página de habilitación documenta por separado los valores locales Enabled y Locked.

Las rutas locales de la tabla están bajo HKLM\SYSTEM\CurrentControlSet\Control. El valor de la directiva está bajo HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. No escriba Enabled=2 para reproducir el modo sin bloqueo de la directiva. No interprete un identificador de servicio WMI como un modo del registro. Conserve la ruta completa y el nombre del valor en las evidencias para que otro administrador pueda interpretarlas sin reconstruir la recopilación.

Un registro de cambio útil conserva la intención de la directiva, la directiva aplicada, los ajustes locales y la observación de la ejecución en campos separados. Si una GPO especifica un modo mientras un equipo muestra otro, investigue la configuración aplicada antes de dar el cambio por terminado. Si los ajustes coinciden pero la ejecución difiere, investigue el equipo en vez de editar repetidamente la misma GPO.

El bloqueo UEFI también cambia la decisión de recuperación. El procedimiento GPO de Microsoft ofrece un despliegue sin bloqueo y advierte de que seleccionar el modo bloqueado restringe la deshabilitación remota. Decida quién puede acceder al menú del firmware y restaurar la máquina antes de incorporar esa restricción a la administración de producción. Instrucciones GPO de Microsoft

Detección: recopilar evidencias en el dispositivo objetivo

Utilice una sesión de PowerShell con privilegios elevados en el objetivo. Microsoft proporciona este comando en su referencia de Win32_DeviceGuard:

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

La siguiente adaptación de solo lectura selecciona los campos necesarios para esta investigación:

$state = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$state | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

Interprete las matrices de servicios por pertenencia. Un resultado que contenga tanto 1 como 2 incluye la integridad de memoria; 1 identifica Credential Guard. VirtualizationBasedSecurityStatus=2 describe VBS en ejecución, mientras que la presencia de 2 en SecurityServicesRunning identifica la integridad de memoria en ejecución. Definiciones de propiedades WMI de Microsoft

Trate la recopilación como una observación con un host, una hora y un contexto de arranque. Conserve las matrices completas aunque el panel muestre después un booleano. Distinga una consulta satisfactoria que no incluya la integridad de memoria de una consulta que haya fallado. Los fallos de autenticación, los dispositivos inaccesibles y la ausencia de salida deben pertenecer a una categoría de estado desconocido con una acción de seguimiento.

Comparar la directiva y los ajustes locales de bloqueo

Esta adaptación de PowerShell de solo lectura consulta los ajustes indicados; las rutas o los valores que falten deben registrarse como ausentes, sin sustituirlos silenciosamente por cero:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name HypervisorEnforcedCodeIntegrity
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity' -Name Enabled, Locked
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures, Locked

Compare esas observaciones con el modo aprobado y con un informe de directiva resultante para ese host. Un ajuste exportado de una GPO ajena al objetivo no es evidencia suficiente de que este lo haya recibido. Registre las configuraciones en conflicto y los errores de recopilación en lugar de convertirlos en una simple puntuación de protegido/no protegido.

Las propiedades documentadas de Win32_DeviceGuard indicadas arriba no proporcionan una propiedad Locked. Lea por separado los marcadores del registro especificados. Describen la configuración del bloqueo y no deben presentarse como una atestación independiente del firmware. Del mismo modo, un resultado CIM que muestre la integridad de memoria en ejecución no demuestra que se aplique el bloqueo UEFI. Referencia de configuración y validación de Microsoft

Compatibilidad de controladores: diseñar un piloto que pruebe el trabajo real

La guía de compatibilidad de controladores de Microsoft combina comprobaciones de Code Integrity en Driver Verifier, pruebas funcionales con la integridad de memoria habilitada y Windows HLK HyperVisor Code Integrity Readiness Test. Distingue la preparación para la firma de las pruebas funcionales exhaustivas. Un controlador que se carga durante un arranque no ha probado necesariamente todas las rutas de ejecución pertinentes.

Para el responsable de un controlador o un equipo de ingeniería, el comando documentado del verificador es:

verifier.exe /flags 0x02000000 /driver <driver.sys>

Sustituya el marcador por el controlador seleccionado en un entorno de pruebas recuperable. Driver Verifier es una herramienta de prueba, no un comando que deba distribuirse indiscriminadamente a los equipos de producción. Registre el controlador seleccionado, las condiciones de prueba, los hallazgos y la vía de recuperación. Coordine los fallos con el proveedor del controlador en lugar de considerar una deshabilitación permanente como la única solución.

Para el equipo de despliegue, cree una matriz de modelos de dispositivo, revisiones de firmware, compilaciones de Windows, paquetes de controladores y flujos de trabajo empresariales. Incluya las combinaciones realmente presentes en la población objetivo. Elija máquinas piloto que expongan diferencias relevantes; un conjunto cómodo de portátiles idénticos puede dejar otras familias de hardware sin probar.

Pruebe el trabajo que esas máquinas deben realizar: arranque, periféricos, aplicaciones necesarias y sus operaciones dependientes de controladores. Defina los resultados esperados antes de empezar y asocie los fallos a un paquete y a un responsable identificados. Son recomendaciones de despliegue, no una afirmación de que una aplicación o un dispositivo concreto de su entorno sea incompatible.

Asigne a cada excepción un motivo, la población afectada, un responsable, una corrección prevista y una fecha de revisión. Distinga un fallo de compatibilidad demostrado de la suposición de que una excepción antigua sigue siendo necesaria. Pida a los proveedores un paquete actualizado o evidencias de prueba que lo respalden y vuelva a ejecutar el flujo de trabajo pertinente con la integridad de memoria activa. El inventario de excepciones delimita la siguiente oleada de despliegue.

Corrección: desplegar la GPO por etapas y demostrar el resultado tras reiniciar (Remediation)

1. Aprobar la población y el plan de recuperación

Asigne responsables para la revisión del hardware, las pruebas de controladores, los cambios GPO y la recuperación. Registre el modo de bloqueo previsto, el alcance del piloto y las exclusiones antes de editar la directiva. Establezca una regla de aceptación que exija tanto una observación de la ejecución como la superación de los flujos de trabajo necesarios; crear una GPO por sí solo no debe cerrar la tarea.

Para las estaciones de administración, sitúe esta decisión en la arquitectura más amplia descrita por nuestra guía ANSSI Active Directory: rutas de administración, uso dedicado y límites de confianza. Reforzar una función de Windows no demuestra que la arquitectura de administración sea sólida ni establece conformidad con ANSSI.

2. Aplicar una configuración compatible con un alcance definido

Siga el procedimiento GPO de Microsoft en Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Habilite la directiva y seleccione la opción prevista en Virtualization Based Protection of Code Integrity. Vincule y filtre la GPO para la población piloto aprobada; examine la directiva aplicada al objetivo antes de ampliar el alcance. Procedimiento de despliegue de Microsoft

El comando documentado de actualización de la directiva, ejecutado desde una Command Prompt con privilegios elevados, es:

gpupdate /force

Programe un reinicio para la recopilación de evidencias del piloto. Tras el arranque, repita la observación CIM y la comparación de ajustes locales. Registre las matrices y el modo observados junto con la solicitud de cambio. No deduzca un resultado para todo el parque a partir de una máquina satisfactoria; cada objetivo sin medir conserva su propio estado sin resolver.

3. Documentar la recuperación antes de seleccionar el bloqueo UEFI

Ante una inestabilidad posterior a la habilitación, el procedimiento de solución de problemas de Microsoft empieza deshabilitando las directivas que habilitan la función, y después utiliza Windows Recovery Environment (Windows RE) para establecer el valor Enabled del escenario en 0 y reiniciar. El comando documentado es:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

Construya el procedimiento de recuperación específico de la máquina en torno a ese proceso. Valide el acceso a Windows RE y al registro de la instalación afectada, identifique al operador y pruebe cómo se retirará la directiva de habilitación. No suponga que un cambio ordinario del registro remoto puede recuperar una máquina que no arranca.

Con bloqueo UEFI, Microsoft exige además deshabilitar Secure Boot para completar esos pasos de recuperación. Esa exigencia incorpora el acceso al firmware al plan. Seleccione el bloqueo solo cuando estén documentados la vía física de recuperación, el operador autorizado y el procedimiento de reversión. Incluya en el procedimiento la restauración de la configuración de firmware aprobada y una nueva validación. Guía de recuperación de Microsoft

4. Ampliar utilizando las evidencias conservadas

Revise las observaciones y los fallos del piloto antes de la siguiente oleada. Conserve las excepciones y los dispositivos de estado desconocido en el mismo inventario que las mediciones satisfactorias. Vuelva a comprobar tras cambios relevantes de controladores o plataforma. Un registro de cierre útil contiene la directiva aprobada, el alcance objetivo, el contexto de arranque, la evidencia del servicio en ejecución, el resultado de la prueba funcional y el responsable de la recuperación.

Cómo detecta EtcSec esta configuración

El etc-collector de EtcSec expone dos comprobaciones de configuración GPO para este tema. El siguiente comportamiento procede de sus ramas reales de Detect(), no de una prueba de equipo:

gpoSetsAtLeast y gpoMaxValue recorren las GPO recopiladas, omiten los objetos de directiva/ajustes ausentes e ignoran los valores no establecidos. El máximo comienza en -1. El analizador de Registry.pol asigna un DWORD llamado HypervisorEnforcedCodeIntegrity en una clave que contiene deviceguard a HVCIEnabled. No obtiene las mediciones separadas Enabled y Locked del escenario de ejecución.

El máximo es un agregado numérico, no una clasificación de seguridad ni un cálculo de precedencia GPO. Si una directiva tiene 1 y otra 2, el máximo es 2 y se activa la comprobación Low. Los valores superiores a 2 también entran en esa misma rama de hallazgo, porque el código no valida la enumeración. No son modos de bloqueo válidos documentados y deben investigarse como datos inesperados.

Count 1 es el número de hallazgos del detector, no un recuento de equipos expuestos. Ninguna comprobación calcula el Resultant Set of Policy (RSoP) por máquina, evalúa los vínculos/filtros GPO ni consulta la ejecución mediante WMI. Un ajuste positivo en cualquier lugar puede suprimir la comprobación OFF aunque la cobertura objetivo sea incompleta. Un valor GPO ausente puede coexistir con la habilitación por otro mecanismo; no demuestra que la integridad de memoria esté deshabilitada en ejecución.

Utilice estas comprobaciones para iniciar la investigación de las directivas y después añada evidencias independientes de los dispositivos. Los nombres y comentarios de los detectores no demuestran por sí solos conformidad con ANSSI, bloqueo real del firmware, compatibilidad de controladores ni protección satisfactoria en todo el parque. Esas conclusiones necesitan sus propias evidencias y revisión.

Fuentes

• Microsoft Learn: habilitar la integridad de memoria, GPO, registro, WMI y recuperación
• Microsoft Learn: compatibilidad de controladores con la integridad de memoria y VBS
• Microsoft Learn: valores de la directiva VirtualizationBasedTechnology y correspondencia GPO