Las profundidades de la virtualización de Windows (parte 2) — Memoria que ni el kernel puede ver: cómo funcionan VBS, HVCI y Credential Guard

¿Dónde pone Windows los secretos que ni un administrador ni el kernel pueden leer? La parte 2 parte de esta pregunta y sigue cómo funcionan VBS, HVCI y Credential Guard.

En el Windows tradicional, un atacante que cargaba un controlador de kernel como administrador y volcaba la memoria del proceso LSASS podía robar hashes de contraseña y tickets de Kerberos y usarlos para movimiento lateral hacia otras máquinas.

En Windows 11 con Credential Guard en ejecución, los hashes de las credenciales de dominio protegidas no están en ningún sitio donde el kernel ordinario pueda buscar. En los dispositivos que cumplen los requisitos de licencia (Enterprise, Education y similares) y los requisitos de hardware, esta protección está habilitada de forma predeterminada a partir de 22H2.¹ Los requisitos y el estado de ejecución real son dos cosas distintas, así que el peligro no ha desaparecido allí donde no está en ejecución.

La parte 1 mostró la estructura en la que el Windows anfitrión se ejecuta en la partición raíz sobre el hipervisor. Lo que sigue este artículo es una frontera más, trazada dentro de esa misma partición.

«Las profundidades de la virtualización de Windows» — Las 3 partes

Miramos el mismo hipervisor de Windows en el orden base → aislamiento de seguridad → aplicación a máquinas virtuales ligeras.

Requisitos previos de este artículo

Cómo leer este artículo

1. Primero la conclusión

Windows añadió un eje de privilegio llamado VTL (Virtual Trust Level) y puso los secretos en VTL1. El kernel ordinario que se ejecuta en VTL0 no puede leer la memoria de VTL1. Quien guarda el límite no es el kernel mismo, sino el hipervisor, que sostiene las tablas de traducción SLAT.

Ese es el esqueleto de la seguridad basada en virtualización (VBS). VBS usa el hipervisor para crear un entorno aislado y aloja ahí funciones de seguridad. Está diseñada bajo el supuesto de que el entorno aislado sigue protegido incluso si el kernel se ve comprometido.²

flowchart TB
    accTitle: Los dos mundos que crea VBS
    accDescr: VTL0 y VTL1 se sitúan dentro de la misma partición; VTL0 tiene el kernel ordinario y las aplicaciones, VTL1 el Secure Kernel y las funciones de seguridad aisladas, y el hipervisor guarda el límite
    subgraph vtl0 ["VTL0 (el mundo ordinario)"]
        apps["Aplicaciones (anillo 3)"]
        ntk["Kernel NT y controladores (anillo 0)"]
    end
    subgraph vtl1 ["VTL1 (el mundo aislado)"]
        ium["Funciones de seguridad aisladas"]
        sk["Secure Kernel"]
    end
    hv["Hipervisor (impone el límite mediante SLAT)"] --- vtl0
    hv --- vtl1
    ntk -.->|No se puede leer| ium

Figura 1: Hay dos mundos dentro de un mismo Windows, y el kernel de VTL0 no puede acceder a la memoria de VTL1.

Lo importante es que esto no es «levantar otra máquina virtual». VTL0 y VTL1 están dentro de la misma partición, dentro del mismo Windows. A continuación vemos cómo se consigue esta división.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (22 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Los límites del modelo de anillos — El guardián y lo guardado están a la misma altura

La seguridad tradicional de Windows se construyó sobre la escalera de anillos (niveles de privilegio). El modo usuario (anillo 3) lo guarda el modo kernel (anillo 0). Entonces, ¿quién guarda el anillo 0? Nadie puede. El anillo 0 es el privilegio más alto.

Esta estructura tiene dos debilidades estructurales.

• El kernel no es un monolito. En el anillo 0 no solo se ejecuta Windows, sino un gran número de controladores de terceros. Si uno de ellos tiene una vulnerabilidad, el atacante obtiene ejecución de código en el anillo 0.
• Desde el anillo 0, todo es visible. Por más que un proceso en modo usuario como LSASS se defienda, un atacante que ha tomado el kernel puede leer su memoria a voluntad. Los atributos de protección y las tablas de páginas los gestiona el propio kernel.

flowchart TB
    accTitle: La ruta de robo de credenciales en el modelo de anillos tradicional
    accDescr: Un atacante que toma el anillo 0 a través de un controlador vulnerable puede leer la memoria del proceso LSASS con toda la autoridad del kernel y obtener hashes de contraseña
    mal["Código del atacante"] -->|Explota un controlador vulnerable| r0["Toma el anillo 0"]
    r0 --> readall["Puede leer toda la memoria física"]
    readall --> lsass["Obtiene hashes de la memoria de LSASS"]
    lsass --> lateral["Se abusa para movimiento lateral hacia otras máquinas"]

Figura 2: Como el guardián (el kernel) y lo guardado (los secretos) están a la misma altura, la debilidad de fondo es que si cae el anillo 0, cae todo.

Lo que hace falta, entonces, es «un lugar más alto que el anillo 0». Ese lugar ya apareció en la parte 1. El hipervisor se ejecuta con un privilegio más alto que el kernel y se apropia pronto del control de los permisos de acceso a memoria de la CPU (SLAT). Una región aislada que guarda el hipervisor queda protegida incluso frente al acceso desde el software de sistema operativo del anillo 0 (modo supervisor).³

3. VSM y VTL — Añadir un eje más al privilegio

Esta sección procede en el orden el conjunto de funciones que ofrece el aislamiento (VSM) → los niveles de aislamiento (VTL) → el mecanismo que impone el límite (SLAT) → el código que se ejecuta dentro. Los nombres se parecen, pero no son lo mismo.

3.1. Niveles de confianza virtuales (VTL)

El conjunto de funciones del hipervisor que ofrece este aislamiento se llama VSM (Virtual Secure Mode). VSM es la base de Device Guard, Credential Guard, el TPM virtual y similares.³

El concepto central de VSM es el VTL (Virtual Trust Level). Los puntos clave son los siguientes.³

• Los VTL son jerárquicos, y cuanto mayor es el número, mayor es el privilegio. VTL0 es el más bajo; VTL1 es más privilegiado que VTL0.
• En la arquitectura se definen hasta 16 niveles, pero lo que está implementado actualmente son dos: VTL0 y VTL1.
• Cada VTL tiene sus propias protecciones de acceso a memoria independientes. El hipervisor gestiona estas protecciones sobre el espacio de direcciones físicas de la partición, así que el software de sistema dentro de la partición no puede cambiarlas.
• Un procesador virtual tiene estado de registros y mecanismo de interrupciones distintos por VTL, y un VTL inferior no puede mirar el estado de un VTL superior.

flowchart TB
    accTitle: Las tres independencias que constituyen el aislamiento VTL
    accDescr: Las protecciones de acceso a memoria, el estado de registros del procesador virtual y el mecanismo de interrupciones son independientes por VTL, y un VTL inferior no puede tocar ninguno de ellos en un VTL superior
    vtl["Lo que es independiente por VTL"] --> m1["Protecciones de acceso a memoria"]
    vtl --> m2["Estado de registros del procesador virtual"]
    vtl --> m3["Mecanismo de interrupciones"]
    m1 -.-> rule["Un VTL inferior no puede tocar un VTL superior"]
    m2 -.-> rule
    m3 -.-> rule

Figura 3: Hacer un mundo aparte no solo de la memoria, sino también del estado de la CPU y de las interrupciones, es el trío que no deja mirilla.

Si los anillos (0 y 3) son el eje que separa «el sistema operativo y las aplicaciones», los VTL son un segundo eje que separa «el mundo ordinario y el mundo aislado». Los dos ejes son ortogonales, y dentro de VTL1 también hay modo kernel y modo usuario.

flowchart TB
    accTitle: Las cuatro regiones que crean los dos ejes de anillos y VTL
    accDescr: El eje de anillos separa el modo kernel del modo usuario, el eje de VTL separa el mundo ordinario del mundo aislado, y la combinación produce cuatro regiones: aplicaciones ordinarias, kernel NT, trustlets de IUM y Secure Kernel
    subgraph ax0 ["VTL0 (mundo ordinario)"]
        a0["Anillo 3: aplicaciones ordinarias"]
        k0["Anillo 0: kernel NT y controladores"]
    end
    subgraph ax1 ["VTL1 (mundo aislado)"]
        a1["Anillo 3: IUM (trustlets)"]
        k1["Anillo 0: Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

Figura 4: Ahora hay dos ejes de privilegio, y «¿es el kernel?» y «¿es el mundo aislado?» se convirtieron en preguntas distintas.

3.2. La sustancia del límite es SLAT

La parte 1 dijo que las tablas de traducción de segundo nivel que hacen corresponder las direcciones físicas del invitado (GPA) con la RAM real (SPA) —SLAT— las sostiene el hipervisor. VSM usa precisamente esa propiedad. El aislamiento de VTL se construye usando el hipervisor Hyper-V y SLAT.⁴

Cuando VTL1 declara «esta memoria no se debe mostrar a VTL0», el hipervisor quita el permiso de acceso a esa página de las tablas de traducción de VTL0. A partir de entonces, aunque el kernel de VTL0 intente tocar esa dirección, el acceso se niega en la etapa de traducción de direcciones de la CPU. Da igual cómo reescriba el kernel sus propias tablas de páginas.

Las tablas de páginas (GVA→GPA) pueden pertenecer al kernel, pero la traducción más allá (GPA→SPA) y el permiso de acceso final pertenecen al hipervisor.

flowchart TB
    accTitle: Cómo se niega un acceso de VTL0 a la memoria de VTL1
    accDescr: Cuando el kernel de VTL0 intenta leer memoria de VTL1, puede pasar sus propias tablas de páginas pero lo rechaza la protección de acceso de SLAT, y el control pasa al hipervisor
    try["El kernel de VTL0 intenta leer una página de VTL1"] --> pt["Pasa las tablas de páginas del propio kernel"]
    pt --> slat{"¿La protección de acceso de SLAT lo permite?"}
    slat -->|Sin permiso| deny["El hipervisor interviene y niega el acceso"]
    slat -->|Con permiso| ok["Acceso a memoria ordinario"]
    deny -.-> point["Protegido en una capa que el kernel no puede cambiar"]

Figura 5: La barrera se sitúa fuera del kernel, y la protección de SLAT no la puede cambiar el software dentro de la partición.

La parte 1 de la serie de memoria escribió que «el VAD, el PTE y los atributos de protección deciden si un acceso está permitido». En un entorno VBS se puede ordenar así: después de haber superado todo eso, aún espera un control de SLAT.

3.3. El Secure Kernel y IUM

Lo que se ejecuta dentro de VTL1 no es el kernel NT ordinario, sino un kernel pequeño llamado Secure Kernel. El modo usuario de VTL1 se llama IUM (Isolated User Mode), y los programas que se ejecutan ahí se llaman trustlets (procesos de confianza).⁴

Un trustlet no puede hacer cualquier cosa como un proceso ordinario. La mayoría de sus llamadas al sistema se marshalan al kernel NT del lado VTL0, al que se pide que haga el trabajo.⁴ VTL1 no es un «mundo superior que puede todo»; se construye deliberadamente pequeño, como una caja fuerte que guarda secretos. Cuanto menos código se pueda meter en la caja, más pequeña es la superficie de ataque.

flowchart TB
    accTitle: El flujo de las llamadas al sistema de un trustlet
    accDescr: Un trustlet en VTL1 no trata por sí mismo la mayoría de las llamadas al sistema; las marshala al kernel NT de VTL0 y recibe solo el resultado, lo que mantiene VTL1 pequeño
    tl["Trustlet (IUM en VTL1)"] --> sc{"Se necesita una llamada al sistema"}
    sc -->|En la mayoría de los casos| mar["Pide al kernel NT de VTL0"]
    mar --> res["Recibe solo el resultado"]
    res -.-> small["VTL1 se mantiene pequeño y la superficie de ataque se reduce"]

Figura 6: La caja fuerte no tiene instalaciones propias; envía las tareas rutinarias afuera y sigue guardando solo los secretos.

4. HVCI — Verificar la integridad de código del kernel en la caja fuerte

En HVCI hay que retener dos puntos: dónde se realiza la verificación y qué se permite en la memoria después de la verificación. Vemos esa protección y, a continuación, su efecto en la compatibilidad de controladores.

4.1. Qué se verifica

La primera función representativa que se asienta sobre VBS es Integridad de la memoria: HVCI (integridad de código protegida por hipervisor). Windows tiene un mecanismo de integridad de código que inspecciona controladores y binarios en modo kernel antes de que arranquen y se niega a cargar los que no están firmados o no son de confianza. HVCI ejecuta esta verificación dentro del entorno aislado de VBS.²

La razón de trasladar la lógica de verificación misma a VTL1 es exactamente la debilidad de la sección 2. Si el código de verificación está dentro del kernel de VTL0, un atacante que ha tomado el kernel puede sustituir la verificación. Si está en VTL1, la mano que sustituye no llega.

flowchart TB
    accTitle: La diferencia según dónde vive el código de verificación
    accDescr: Si el código de verificación está dentro del kernel de VTL0, se desactiva una vez tomado el kernel; si está en VTL1, ni un atacante que ha tomado el kernel llega a él y la verificación sigue protegida
    atk["Atacante que ha tomado el kernel"] --> q{"¿Dónde está la verificación de integridad de código?"}
    q -->|"Dentro del kernel de VTL0 (tradicional)"| bad["La lógica de verificación se puede sustituir"]
    q -->|"Entorno aislado en VTL1 (HVCI)"| good["La sustitución queda fuera de alcance"]
    bad --> res1["Puede ejecutarse código sin firmar en el kernel"]
    good --> res2["La verificación sigue funcionando tras el compromiso del kernel"]

Figura 7: No poner el puesto de control dentro del lado que podría perforarse: ese traslado de la lógica de verificación es la esencia de HVCI.

4.2. Las reglas de las páginas ejecutables

El efecto de HVCI no se limita a la «inspección al arranque». También restringe la asignación de memoria del kernel.⁵

• Una página del kernel se vuelve ejecutable solo después de haber superado la verificación de integridad de código.
• Una página ejecutable no se vuelve escribible (lo que se llama W^X).

Con estas dos juntas, aunque una vulnerabilidad como un desbordamiento de búfer permita reescribir memoria del kernel, no se puede llevar a ejecución el contenido reescrito. Las páginas ejecutables no se pueden reescribir, y las páginas que se pueden reescribir no son ejecutables.⁵ El respaldo final del permiso de ejecución está en el derecho de ejecución del lado SLAT, que el kernel de VTL0 no puede manipular.

flowchart TB
    accTitle: Hasta que una página del kernel se vuelve ejecutable en un entorno HVCI
    accDescr: Una petición de carga de controlador recibe la verificación de integridad de código en el entorno aislado de VBS; si pasa, se permite como página ejecutable y no escribible; si falla, se bloquea y se registra en el registro CodeIntegrity
    load["Petición de cargar y ejecutar código de kernel"] --> verify{"Verificación de integridad de código en el entorno aislado"}
    verify -->|Supera| exec["Permitida como página ejecutable (escrituras prohibidas)"]
    verify -->|No supera| block["Carga bloqueada"]
    block --> log["Registrado en el registro CodeIntegrity Operational (identificador de evento 3087)"]
    exec -.-> wx["Las páginas escribibles siguen sin ser ejecutables"]

Figura 8: La regla que no deja coexistir ejecución y escritura se verifica del lado VTL1, y el kernel de VTL0 no puede volcarla.

Seguirlo desde el punto de vista del atacante muestra con claridad cómo actúa la regla.

flowchart TB
    accTitle: Cómo falla la inyección de código en un entorno HVCI
    accDescr: Aunque una vulnerabilidad permita reescribir memoria del kernel, una página en la que se pudo escribir no es ejecutable, y una página ejecutable no se puede reescribir de entrada, así que el código inyectado nunca llega a ejecutarse
    inj["Intentar manipular memoria del kernel mediante una vulnerabilidad"] --> which{"¿Cuál es la página objetivo?"}
    which -->|Una página escribible| wok["La reescritura tiene éxito"]
    which -->|Una página ejecutable| xfail["La reescritura misma es imposible"]
    wok --> nx["Pero esa página no es ejecutable"]
    nx --> dead["El código inyectado no se puede ejecutar"]
    xfail --> dead

Figura 9: Por la entrada que se tome, se llega a un callejón sin salida; ahí está el sentido de no dejar que se solapen páginas escribibles y páginas ejecutables.

4.3. El precio: la compatibilidad de controladores

Esta regla choca con controladores de diseño antiguo. Un controlador que reescribe su propio código en tiempo de ejecución, que no tiene firma o que exige memoria a la vez ejecutable y escribible no se puede cargar en un entorno HVCI.

El hecho del bloqueo se confirma en el Visor de eventos bajo Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (el identificador de evento 3087 es el representativo).⁶

En muchos casos, esa es la verdadera identidad del problema «después de activar Integridad de la memoria, un periférico dejó de funcionar». El camino principal es actualizar a una versión de controlador compatible con HVCI; desactivar Integridad de la memoria debe considerarse un último recurso que entrega la protección entera.

Si participa en esta verificación desde el desarrollo de controladores, consulte también el artículo de controladores de filtro («Controladores minifiltro de Windows»).

flowchart TB
    accTitle: Acotación cuando un periférico deja de funcionar con Integridad de la memoria
    accDescr: Identifique el controlador bloqueado en el registro CodeIntegrity Operational; el camino principal es actualizar a una versión compatible con HVCI, si no hay pedirla al proveedor, y desactivar es un último recurso que nunca se convierte en configuración permanente
    sym["Un dispositivo deja de funcionar tras activar Integridad de la memoria"] --> log2["Identificar el controlador bloqueado en el registro CodeIntegrity"]
    log2 --> upd{"¿Hay un controlador compatible con HVCI?"}
    upd -->|Sí| fix2["Actualizar y resolverlo dejando la función activa"]
    upd -->|No| ask2["Pedir al proveedor una versión compatible"]
    ask2 -.-> temp["Desactivar es un último recurso, nunca una configuración permanente"]

Figura 10: Lo primero que hay que mirar no es la pantalla de configuración, sino el registro, y el identificador de evento 3087 sabe qué controlador se bloqueó.

5. Credential Guard — Los hashes están dentro de LSAIso

Donde HVCI protege la integridad de código del kernel, Credential Guard protege las credenciales. Si se separan la ventanilla que acepta la autenticación y el lugar donde se guardan los secretos, la estructura y el alcance de protección encajan.

5.1. LSASS y LSAIso

La segunda función representativa que se asienta sobre VBS es la respuesta al enigma inicial: Credential Guard.

El Windows tradicional guardaba hashes NTLM y tickets de Kerberos en la memoria del proceso LSA (lsass.exe). Cuando Credential Guard está habilitado, el almacenamiento de los secretos protegidos de entre ellos —los hashes NTLM de las credenciales de dominio y los TGT de Kerberos (Ticket Granting Tickets)— pasa a LSAIso.exe, un trustlet que se ejecuta en IUM en VTL1.⁷

• lsass.exe (VTL0) sigue ejecutándose como ventanilla del procesamiento de autenticación, como hasta ahora.
• Los secretos mismos los sostiene LSAIso.exe (VTL1) y no se puede acceder a ellos desde VTL0.
• Ambos se comunican mediante RPC (Remote Procedure Call).
• LSAIso no aloja ningún controlador de dispositivo y solo admite el conjunto mínimo de binarios firmados. Las firmas se verifican frente a un certificado en el que VBS confía.⁷

flowchart TB
    accTitle: Dónde se sitúan las credenciales cuando Credential Guard está habilitado
    accDescr: lsass en VTL0, como ventanilla de autenticación, se comunica con LSAIso en VTL1 mediante RPC; los hashes y TGT reales de las credenciales de dominio protegidas los sostiene LSAIso, así que un atacante que obtiene privilegios de administrador en VTL0 y vuelca lsass sigue sin obtener los secretos protegidos mismos
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe (ventanilla de autenticación)"]
        att["Atacante (privilegios de administrador)"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe (caja fuerte de los secretos)"]
    end
    lsassP <-->|RPC| iso
    att -->|Volcado de memoria| lsassP
    att -.->|No llega| iso

Figura 11: Como se separaron la ventanilla y la caja fuerte, volcar lsass ya no entrega los hashes reales de las credenciales de dominio protegidas.

Condiciones para habilitarse de forma predeterminada

A partir de Windows 11 versión 22H2, VBS y Credential Guard están habilitados de forma predeterminada en los dispositivos que cumplen los requisitos de licencia (Enterprise E3/E5, Education A3/A5) y los requisitos de hardware. En ediciones como Pro, Credential Guard no se habilita automáticamente (hay excepciones, por ejemplo una máquina que estuvo habilitada bajo una licencia que cumplía los requisitos y luego se degradó).¹

Esta protección de credenciales no es asunto de un producto adicional especial; es el estado estándar de Windows actual en las ediciones que cumplen los requisitos.

flowchart TB
    accTitle: El flujo de credenciales desde el inicio de sesión hasta la autenticación
    accDescr: Tras el inicio de sesión, los secretos reales se almacenan en LSAIso en VTL1; cada vez que hace falta autenticación, lsass en VTL0 pide el cálculo mediante RPC, y a VTL0 solo vuelve el resultado del procesamiento de autenticación, sin que se devuelvan nunca los secretos de largo plazo protegidos mismos
    signin["El usuario inicia sesión"] --> front["lsass lo trata como ventanilla"]
    front --> store["Los secretos reales se almacenan en LSAIso"]
    auth["Peticiones de autenticación posteriores"] --> front
    front -->|Pide el cálculo mediante RPC| store
    store -->|"Devuelve el resultado (nunca el secreto)"| front

Figura 12: Los secretos de largo plazo protegidos mismos no salen de la caja fuerte; lo que vuelve a VTL0 es el resultado del procesamiento de autenticación, por ejemplo un ticket.

5.2. Saber con precisión qué no está protegido

Credenciales que sí están protegidas

Credential Guard no es un escudo para todo. Lo que protege son los hashes NTLM de las credenciales de dominio, los TGT de Kerberos (Ticket Granting Tickets) y lo almacenado como credenciales de dominio.

Fuera de alcance

Lo siguiente queda fuera de alcance.⁸

• Los tickets de servicio de Kerberos (los TGT sí están protegidos)
• Las credenciales de cuentas locales y de cuentas Microsoft
• El robo de entrada por un registrador de teclas, y los ataques físicos
• Las credenciales en rutas que usan NTLMv1, MS-CHAPv2, Digest o CredSSP
• El interior de software de terceros que gestiona las credenciales por su cuenta

Independientemente del alcance de protección, comprobar también la compatibilidad de autenticación

Además, cuando Credential Guard está habilitado ya no se pueden usar NTLMv1, la delegación Kerberos sin restricciones y similares, así que los sistemas de negocio que dependen de autenticación heredada necesitan una comprobación de compatibilidad.⁸ No es «habilitarlo y listo»; conocer el interior y el exterior del alcance de protección y cubrir el resto con otras medidas: ese es el uso correcto en la práctica.

flowchart TB
    accTitle: El alcance de protección de Credential Guard
    accDescr: Los hashes NTLM y TGT de dominio y las credenciales de dominio almacenadas están protegidos, mientras que los tickets de servicio, las cuentas locales, los registradores de teclas, los ataques físicos y las credenciales que una aplicación almacena por su cuenta quedan fuera de alcance
    scope{"¿De qué lado del alcance de protección está este secreto?"} --> inA["Hashes NTLM y TGT de dominio"]
    scope --> outA["Tickets de servicio y cuentas locales"]
    inA --> prot["Protegido en LSAIso"]
    outA --> unprot["No protegido (hacen falta otras medidas)"]
    unprot -.-> outB["Pulsaciones, ataques físicos y almacenes propios de la aplicación también quedan fuera"]

Figura 13: El alcance de protección está trazado con una línea clara, y el exterior de la línea se cubre con autenticación multifactor y diseño del lado de la aplicación.

6. Comprobarlo con sus propios ojos

Puede comprobar el estado de ejecución de VBS y de cada función en su propia máquina. Lea el estado de VBS, la base, por separado del estado de los servicios que se ejecutan encima.

6.1. Comprobar VBS y los servicios en ejecución en PowerShell

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

Lea la salida de este modo.⁹

• Si VirtualizationBasedSecurityStatus es 2, VBS está habilitada y en ejecución.
• Si SecurityServicesRunning contiene 1, Credential Guard está en ejecución; si contiene 2, Integridad de la memoria (HVCI) está en ejecución.

6.2. Leer msinfo32 y la pantalla de configuración de formas distintas

Para comprobar el estado de ejecución en una interfaz gráfica, mire el campo «Seguridad basada en virtualización» en msinfo32 (ahí se enumeran los servicios en ejecución, por ejemplo «Integridad de código impuesta por hipervisor»).

El conmutador «Integridad de la memoria» bajo «Seguridad del dispositivo > Aislamiento del núcleo» en la aplicación Seguridad de Windows es una pantalla que refleja la configuración. Puede verse activado incluso mientras HVCI no está realmente en ejecución, por ejemplo mientras se espera un reinicio justo después de habilitarlo o cuando hay un problema de compatibilidad al arrancar. Juzgue si está en ejecución a partir de msinfo32 o de SecurityServicesRunning en Win32_DeviceGuard.⁶

6.3. No juzgar «en ejecución» solo por la presencia de un proceso

También hay un rastro en la pestaña Detalles del Administrador de tareas. En una máquina donde VBS está en ejecución verá un proceso llamado «Secure System». LsaIso.exe es el proceso que aparece cuando el servicio LSA aislado está hospedado en VTL1, y normalmente no aparece en una configuración donde solo HVCI está habilitado.

La presencia o ausencia de un proceso es solo un rastro, así que juzgue si Credential Guard está en ejecución a partir de SecurityServicesRunning (si contiene 1), como se describió más arriba. Ambos son ventanas, visibles desde VTL0, hacia el mundo del lado VTL1.

flowchart TB
    accTitle: El procedimiento para comprobar que las funciones relacionadas con VBS están en ejecución
    accDescr: Confirme que VBS está en ejecución consultando Win32_DeviceGuard, juzgue si Credential Guard y HVCI están en ejecución a partir de los valores de SecurityServicesRunning, y mire el registro CodeIntegrity para problemas de controladores
    q0["Consultar Win32_DeviceGuard"] --> q1{"¿El estado de VBS es 2?"}
    q1 -->|No| off["VBS no está en ejecución (comprobar requisitos y configuración)"]
    q1 -->|Sí| q2{"¿Qué contiene SecurityServicesRunning?"}
    q2 -->|Contiene 1| cg["Credential Guard en ejecución"]
    q2 -->|Contiene 2| hvciR["Integridad de la memoria (HVCI) en ejecución"]
    hvciR -.-> ev["Para problemas de controladores, consultar el registro CodeIntegrity (3087)"]

Figura 14: La comprobación de estado avanza en tres etapas: VBS misma, cada servicio encima y el registro cuando ocurre un problema.

7. Tres lecturas erróneas que conviene evitar en la práctica

7.1. «Proteger los privilegios de administrador basta. VBS es un asunto de servidores»

Lo que impide Credential Guard es la ampliación del daño después de que se hayan tomado los privilegios de administrador (extracción de hashes y movimiento lateral). En otras palabras, VBS es una capa de defensa en profundidad que asume el compromiso, y es en los PC cliente donde rinde. En Windows 11 que cumple los requisitos, la habilitación predeterminada es la norma, así que la postura correcta no es «esto no va con nosotros», sino «gestionar la compatibilidad bajo el supuesto de que ya está en ejecución».

flowchart TB
    accTitle: Las etapas del compromiso y dónde actúa VBS
    accDescr: El acceso inicial lo cubren otras medidas como la autenticación multifactor y la formación; HVCI bloquea la inyección de código en el kernel que sigue a la elevación de privilegios; Credential Guard bloquea el robo de secretos de dominio protegidos y el movimiento lateral, pero no alcanza a secretos fuera de su alcance
    s1["Acceso inicial (phishing y similares)"] --> s2["Elevación de privilegios"]
    s2 --> s3["Inyección de código en el kernel"]
    s3 --> s4["Robo de secretos de dominio protegidos y movimiento lateral"]
    s1 -.-> d1["MFA, formación y EDR cubren esto"]
    s3 -.-> d2["HVCI bloquea este paso"]
    s4 -.-> d3["Credential Guard lo bloquea (solo secretos protegidos)"]

Figura 15: VBS no es una técnica de «no dejarlos entrar»; es una técnica de «no dejarlos ganar una vez dentro», y la etapa que guarda es distinta.

7.2. «Si Integridad de la memoria da problemas, basta con desactivarla»

Desactivarla hará que las cosas funcionen de momento, pero quita de golpe la barrera contra la inyección de código en el kernel. El camino principal es identificar primero el controlador bloqueado en el registro CodeIntegrity y luego aplicar la versión actualizada del proveedor. Incluso cuando la desactive temporalmente para validación, recomendamos una práctica de operación que nunca la convierta en configuración permanente.

7.3. «Con Credential Guard las contraseñas no se pueden robar»

Eso es exceso de confianza nacido de confundir el alcance de protección. Los tickets de servicio, las cuentas locales, las pulsaciones mismas y las credenciales que una aplicación almacena por su cuenta quedan fuera.⁸ El phishing y los registradores de teclas necesitan otras medidas (autenticación multifactor, Windows Hello y una revisión de cómo gestiona las credenciales la propia aplicación).

8. Resumen

• VBS usa el hipervisor para crear un entorno aislado y protege funciones de seguridad bajo el supuesto de que el kernel se verá comprometido.²
• La unidad de aislamiento es el VTL; actualmente están implementados dos niveles, VTL0 (el mundo ordinario) y VTL1 (el Secure Kernel e IUM).³
• La sustancia del límite es la protección de acceso a memoria de SLAT, que el software dentro de la partición, el kernel incluido, no puede cambiar.³
• HVCI ejecuta la verificación de integridad de código en el entorno aislado y impone «no ejecutable hasta que la verificación se supere» y «las páginas ejecutables no son escribibles».⁵ El precio es que hay que gestionar la compatibilidad de controladores.⁶
• Credential Guard aísla los hashes NTLM y los TGT de las credenciales de dominio en LSAIso en VTL1. A partir de Windows 11 22H2 está habilitado de forma predeterminada en los dispositivos que cumplen los requisitos de licencia (Enterprise, Education) y los requisitos de hardware (úselo junto con una comprobación del estado de ejecución).⁷¹
• El estado de ejecución se comprueba a partir de SecurityServicesRunning en Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).⁹

Continúa en la parte 3, «Máquinas virtuales que arrancan en segundos — WSL2, Windows Sandbox y contenedores».

Hasta aquí hemos mirado la virtualización desde el lado de la «fuerza del aislamiento». La entrega final mira desde el lado opuesto, la «ligereza», y sigue dónde recortan las máquinas virtuales ligeras que se desprendieron del peso de una máquina virtual completa.

Artículos relacionados

• Las profundidades de la virtualización de Windows (parte 1) — ¿Dónde se ejecuta realmente su Windows? El hipervisor y las particiones
• Interioridades de la memoria de Windows (1.ª parte) — El instante en que una dirección virtual se convierte en RAM física: el ciclo completo de un fallo de página
• Controladores minifiltro de Windows
• Los códigos de error de Windows — Win32, HRESULT y NTSTATUS

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de las investigaciones de compatibilidad entre aplicaciones Windows y funciones de seguridad, del análisis de fallos causados por controladores y de la validación técnica de entornos de PC internos.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Aprovechamiento de activos existentes y soporte de migración
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿VBS (seguridad basada en virtualización) y Aislamiento del núcleo son lo mismo?

En sentido estricto, son cosas distintas. VBS es la tecnología de base que crea un entorno aislado con el hipervisor, y «Aislamiento del núcleo» en la aplicación Seguridad de Windows es el nombre de una pantalla que agrupa varias protecciones construidas sobre VBS. La representativa es «Integridad de la memoria», que se refiere a HVCI (integridad de código protegida por hipervisor). El estado de ejecución de cada servicio se confirma consultando Win32_DeviceGuard, no a partir de lo que muestra la pantalla.

¿La memoria de VTL1 realmente no se puede leer, ni siquiera con privilegios de administrador o desde un controlador de kernel?

No se puede. Las protecciones de acceso a memoria por VTL las gestiona el hipervisor sobre el espacio de direcciones físicas de la partición, y el software que se ejecuta dentro de la partición no puede cambiarlas. Incluso el código que se ejecuta en el kernel (anillo 0) no tiene permiso para acceder a la memoria de VTL1 desde VTL0.

¿Por qué activar Integridad de la memoria (HVCI) puede hacer que un controlador deje de funcionar?

En un entorno HVCI, una página del kernel se vuelve ejecutable solo después de haber superado la verificación de integridad, y no se permiten escrituras en páginas ejecutables. Un controlador sin firmar, o un controlador de diseño antiguo que reescribe memoria ejecutable, no puede satisfacer esta restricción, y se bloquea su carga. El bloqueo se confirma en el registro CodeIntegrity Operational (identificador de evento 3087 y similares).

¿Qué protege Credential Guard, y qué no protege?

Protege, en un entorno aislado, los hashes de contraseña NTLM de las credenciales de dominio, los TGT de Kerberos y lo que una aplicación almacenó como credenciales de dominio. Los tickets de servicio de Kerberos, las credenciales de cuentas locales y de cuentas Microsoft, el robo de entrada por un registrador de teclas y los ataques físicos quedan fuera de alcance.

¿Dónde puedo comprobar si VBS está en ejecución?

Mire el campo «Seguridad basada en virtualización» en msinfo32, o consulte la clase Win32_DeviceGuard del espacio de nombres root/Microsoft/Windows/DeviceGuard desde PowerShell. Si SecurityServicesRunning contiene 1, Credential Guard está en ejecución; si contiene 2, Integridad de la memoria (HVCI) está en ejecución.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.