VBS, integridad de memoria (HVCI) y Kernel DMA Protection

Cuando un atacante ejecuta código en el kernel de Windows, la mayoría de las demás defensas pasan a ser negociables: puede desactivar herramientas de seguridad, leer LSASS y ocultarse. Tres características respaldadas por hardware le hacen frente:

• La seguridad basada en virtualización (VBS) usa el hipervisor de Windows para crear un entorno aislado (Virtual Trust Level 1) que el kernel normal no puede leer ni modificar.
• La integridad de memoria, también llamada integridad de código protegida por hipervisor o HVCI, ejecuta las comprobaciones de integridad del código del kernel dentro de VBS. Las páginas de memoria del kernel son escribibles o ejecutables, nunca ambas cosas, y solo el código firmado puede volverse ejecutable, aunque el kernel esté comprometido.
• Kernel DMA Protection usa el IOMMU para impedir que los dispositivos externos conectados a puertos Thunderbolt, USB4 o PCIe de conexión en caliente lean o escriban en memoria mediante acceso directo a memoria.

El pilar de endurecimiento de BitLocker menciona la protección DMA como parte de la cadena de arranque, y la guía de Credential Guard cubre el aislamiento de credenciales que funciona sobre VBS. Esta guía despliega VBS y la integridad de memoria en todo el parque y convierte Kernel DMA Protection en parte de su estándar de hardware. El resto de la serie está en el tema BitLocker y seguridad del arranque.

Requisitos

Windows 11 sobre hardware que cumple sus requisitos mínimos admite las tres. Muchos equipos de escritorio y portátiles antiguos carecen de Kernel DMA Protection aunque VBS funcione.

Paso 1: comprobar la preparación

En una muestra de cada modelo de hardware, msinfo32 > System Summary muestra Virtualization-based security, Kernel DMA Protection y la lista de servicios de VBS configurados y en ejecución. Los mismos datos desde PowerShell:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus     # 0 desactivado, 1 habilitado pero no en ejecución, 2 en ejecución
$dg.AvailableSecurityProperties           # 1 hipervisor, 2 Secure Boot, 3 protección DMA, 7 MBEC/GMET, ...
$dg.SecurityServicesConfigured
$dg.SecurityServicesRunning               # 1 Credential Guard, 2 integridad de memoria, 3 System Guard Secure Launch

Para los controladores, la aplicación Seguridad de Windows, en Seguridad del dispositivo > Detalles de aislamiento del núcleo, enumera los controladores incompatibles que impiden la integridad de memoria. A escala de parque, el método más fiable es una fase de auditoría: habilite la integridad de memoria en un anillo piloto por modelo de hardware y revise en el registro Microsoft > Windows > CodeIntegrity > Operational los controladores cuya carga se bloqueó. Actualícelos o sustitúyalos antes del despliegue general. Los culpables habituales son utilidades de hardware antiguas, motores antitrampas, controladores antiguos de VPN y de virtualización, y herramientas de fabricantes sin mantenimiento.

Paso 2: habilitar VBS y la integridad de memoria con directiva de grupo

Ruta de GPO: Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, en Enabled:

El bloqueo UEFI guarda la configuración en una variable del firmware, de modo que no se puede desactivar editando el registro ni la directiva; quitarlo más tarde exige un procedimiento documentado con presencia física. Empiece sin él.

Equivalentes en el registro, para imágenes o dispositivos fuera del dominio:

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
  EnableVirtualizationBasedSecurity   REG_DWORD 1
  RequirePlatformSecurityFeatures     REG_DWORD 1 (Secure Boot) or 3 (Secure Boot and DMA protection)

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
  Enabled                             REG_DWORD 1
  Locked                              REG_DWORD 0 (no UEFI lock) or 1

Hace falta reiniciar. En Windows 11, Kernel-mode Hardware-enforced Stack Protection es una opción adicional de aislamiento del núcleo que se apoya en la integridad de memoria y en la compatibilidad de la CPU con la pila de sombra; evalúela cuando la integridad de memoria sea estable.

Paso 3: el equivalente en Intune

En el catálogo de configuración, las categorías Device Guard y Virtualization Based Technology contienen las mismas opciones:

• Enable Virtualization Based Security y Require Platform Security Features (Policy CSP DeviceGuard/EnableVirtualizationBasedSecurity, DeviceGuard/RequirePlatformSecurityFeatures).
• Hypervisor Enforced Code Integrity: deshabilitada, habilitada con bloqueo UEFI o habilitada sin bloqueo (Policy CSP VirtualizationBasedTechnology/HypervisorEnforcedCodeIntegrity, valores 0, 1 y 2).
• Require UEFI Memory Attributes Table (VirtualizationBasedTechnology/RequireUEFIMemoryAttributesTable).

Endpoint security > Account protection también expone Credential Guard. Evite configurar la misma opción en dos perfiles, o en GPO e Intune a la vez en los dispositivos híbridos, porque los conflictos dejan los dispositivos en estado de error.

Añada Require code integrity en Device Health en su directiva de cumplimiento para informar sobre la integridad de código atestiguada o condicionar el acceso a ella.

Paso 4: Kernel DMA Protection

Kernel DMA Protection la activa el firmware, no Windows. Su trabajo es comprar hardware que la tenga, mantenerla habilitada y decidir cómo tratar los dispositivos incompatibles.

1. Estándar de hardware: exija Kernel DMA Protection: On en msinfo32 como criterio de compra para todos los portátiles y para los equipos de escritorio con Thunderbolt o USB4.
2. Configuración del firmware: mantenga habilitados VT-d / AMD-Vi y el IOMMU; se pueden desactivar en la configuración de la BIOS, otro motivo más para una contraseña de firmware.
3. Directiva de enumeración: GPO Computer Configuration > Administrative Templates > System > Kernel DMA Protection > Enumeration policy for external devices incompatible with Kernel DMA Protection. Las opciones son Block all, Only while logged in (comportamiento por defecto) y Allow all. Elija Block all para los dispositivos de alto riesgo, sabiendo que algunas bases de acoplamiento y periféricos antiguos cuyos controladores no admiten la reasignación de DMA dejarán de funcionar. Intune: Policy CSP DmaGuard/DeviceEnumerationPolicy (0 bloquear todo, 1 solo tras iniciar sesión, 2 permitir todo).

En los dispositivos sin Kernel DMA Protection, compénselo:

• BitLocker con TPM y PIN para los usuarios de alto riesgo, para que las claves no estén en memoria antes de la autenticación.
• La opción de BitLocker Disable new DMA devices when this computer is locked en Windows Components > BitLocker Drive Encryption.
• Desactive Thunderbolt o defina su nivel de seguridad en el firmware donde no se usen bases de acoplamiento.

Qué se rompe

• Los controladores de kernel incompatibles no se cargan cuando la integridad de memoria está activada; el hardware que depende de ellos pierde funcionalidad, y un controlador de almacenamiento o de seguridad crítico para el arranque puede impedir que el sistema se inicie. Pruebe siempre en piloto por modelo.
• Los hipervisores y emuladores de terceros deben ejecutarse sobre la Plataforma del hipervisor de Windows una vez activada VBS; las versiones actuales de los principales productos lo hacen, las antiguas no.
• El rendimiento en procesadores sin MBEC/GMET, sobre todo en juegos y cargas gráficas.
• El bloqueo UEFI hace lenta la reversión. Déjelo desactivado hasta que el parque sea estable.
• Las bases de acoplamiento y los periféricos sin controladores capaces de reasignación de DMA dejan de enumerarse con Block all.

La integridad de memoria también dificulta los ataques basados en controladores; combínela con la lista de bloqueo de controladores vulnerables, que se impone automáticamente en los dispositivos con la integridad de memoria activada, y con App Control for Business para el código en modo de usuario.

Comprobarlo

En el dispositivo:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
[pscustomobject]@{
  VBS              = $dg.VirtualizationBasedSecurityStatus -eq 2
  MemoryIntegrity  = $dg.SecurityServicesRunning -contains 2
  CredentialGuard  = $dg.SecurityServicesRunning -contains 1
  DmaAvailable     = $dg.AvailableSecurityProperties -contains 3
}

Confirme Kernel DMA Protection: On en msinfo32 para el modelo de hardware. Recopile los mismos valores en todo el parque y alerte sobre los dispositivos en los que VBS está configurada pero no se ejecuta: suele significar que se desactivó la virtualización en el firmware, que se restableció la BIOS o que se instaló un controlador incompatible.

Lista de comprobación

• Inventario de hardware: compatibilidad con VBS, MBEC/GMET, IOMMU y Kernel DMA Protection por modelo
• Controladores incompatibles identificados en un piloto y actualizados o eliminados
• VBS e integridad de memoria impuestas por GPO o Intune, bloqueo UEFI tras la estabilización
• Nivel de seguridad de plataforma con protección DMA donde todos los dispositivos tienen IOMMU
• Kernel DMA Protection exigida en el estándar de compra de hardware
• Directiva de enumeración definida; controles compensatorios en los dispositivos sin protección DMA
• Informe del parque sobre SecurityServicesRunning; alertas cuando VBS deja de ejecutarse