KomuraSoft LLC
Contáctenos
Menú

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

· · Windows, Virtualización, Seguridad, VBS, HVCI, Credential Guard

Hubo un tiempo en que los privilegios de administrador eran la «meta» para un atacante en Windows. Cargar un controlador de kernel como administrador, volcar la memoria del proceso LSASS, y ya se tienen hashes de contraseña y tickets de Kerberos. A partir de ahí solo queda caminar hacia otra máquina con los hashes robados.

En el Windows 11 actual con Credential Guard en ejecución —el estado predeterminado a partir de 22H2 en los dispositivos que cumplen los requisitos de licencia como Enterprise y Education, más los requisitos de hardware— ese manual de juego no funciona. Un atacante que ha tomado por completo el kernel puede buscar en la memoria todo lo que quiera, y los hashes reales de las credenciales de dominio protegidas no se encuentran «dentro de ese sistema operativo». Si no está en ejecución, el peligro antiguo permanece, así que lea esto junto con los métodos de confirmación más adelante en el artículo.

¿Dónde están, entonces? La respuesta es «otro mundo, creado dentro del mismo PC». Como vimos en la parte 1, el Windows anfitrión se ejecuta en la partición raíz sobre el hipervisor («¿Dónde se ejecuta realmente su Windows?»). Este artículo continúa desde ahí y sigue una frontera más que el hipervisor traza dentro de la misma partición.

La pregunta que responde la parte 2 es solo una.

¿Dónde pone Windows secretos que ni un administrador ni el kernel pueden leer?

Los lectores previstos son desarrolladores y operadores que han visto palabras como Aislamiento del núcleo, Integridad de la memoria y Credential Guard en una pantalla de configuración o en un caso de resolución de problemas, y quieren entender la cosa real desde el mecanismo. Los requisitos previos son Windows 10/11 x64 o una versión actual de Windows Server (como en la parte 1, el tratamiento de anillos y SLAT asume x64; Arm64 usa un mecanismo distinto, como los niveles de excepción). El conocimiento de fondo exigido son los conceptos de particiones y SLAT cubiertos en la parte 1. La dificultad es intermedia. El objetivo es una explicación de la estructura, no una guía de cómo configurar las funciones de seguridad.

1. Conclusión principal

Windows añadió un eje de privilegio llamado VTL (Virtual Trust Level) y puso los secretos en VTL1. La memoria de VTL1 no se puede leer desde el kernel ordinario que se ejecuta en VTL0. Lo que guarda la frontera no es el propio kernel, sino el hipervisor que tiene 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ñado bajo el supuesto de que el entorno aislado sigue protegido aunque el kernel esté comprometido.1

Los dos mundos que crea VBSVTL0 y VTL1 se sitúan dentro de la misma partición; VTL0 tiene el kernel ordinario y las aplicaciones, VTL1 tiene el Secure Kernel y las funciones de seguridad aisladas, y el hipervisor guarda la fronteraVTL1 (el mundo aislado)VTL0 (el mundo ordinario)No puede leerFunciones de seguridad aisladasSecure KernelAplicaciones (anillo 3)Kernel NT y controladores (anillo 0)Hipervisor (hace cumplir la frontera mediante SLAT)

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

El punto 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. Veremos por turnos cómo se realiza esta división.

2. Los límites del modelo de anillos — El guardián y lo guardado se sientan 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 Windows mismo sino un gran número de controladores de terceros se ejecutan. Si cualquiera de ellos tiene una vulnerabilidad, un atacante obtiene ejecución de código en el anillo 0.
  • Desde el anillo 0, todo es visible. Por mucho que se defienda un proceso de modo usuario como LSASS, su memoria es de libre lectura para un atacante que ha tomado el kernel. Tanto los atributos de protección como las tablas de páginas los gestiona el propio kernel.
El camino del robo de credenciales en el modelo tradicional de anillosUn atacante que toma el anillo 0 a través de un controlador vulnerable puede leer la memoria del proceso LSASS con la autoridad plena del kernel y obtener hashes de contraseñaExplota un controlador vulnerableCódigo del atacanteToma el control del anillo 0Puede leer toda la memoria físicaObtiene hashes de la memoria de LSASSSe abusa para el movimiento lateral a otras máquinas

Figura 2: Como el guardián (el kernel) y lo guardado (los secretos) se sientan a la misma altura, la debilidad fundamental 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 a un privilegio más alto que el kernel y monopoliza desde el principio el control de los permisos de acceso a memoria de la CPU (SLAT). Una región aislada que guarda el hipervisor está protegida incluso frente al acceso desde software de sistema operativo de anillo 0 (modo supervisor).2

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

3.1. Niveles de confianza virtual (VTL)

La familia de funciones del hipervisor que ofrece este aislamiento se llama VSM (Virtual Secure Mode). VSM es la base de Device Guard, Credential Guard, un TPM virtual y similares.2

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

  • Los VTL son jerárquicos, y cuanto más alto el número, más alto el privilegio. VTL0 es el más bajo; VTL1 es más privilegiado que VTL0.
  • Arquitectónicamente se definen hasta 16 niveles, pero lo que está implementado actualmente son dos: VTL0 y VTL1.
  • Cada VTL tiene protecciones de acceso a memoria independientes. Estas protecciones las gestiona el hipervisor contra 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 un estado de registros y una maquinaria de interrupciones separados por VTL, y un VTL inferior no puede espiar el estado de un VTL superior.
Tres independencias que componen el aislamiento VTLLas protecciones de acceso a memoria, el estado de registros del procesador virtual y la maquinaria de interrupciones son independientes por VTL, y un VTL inferior no puede tocar ninguna de ellas en un VTL superiorIndependiente por VTLProtección de accesoRegistros del procesadorMaquinaria de interrupcionesVTL inferior no toca el superior

Figura 3: Hacer no solo la memoria sino también el estado de la CPU y las interrupciones un mundo separado es el conjunto de tres piezas que no deja mirilla.

Si los anillos (0 y 3) son el eje que separa «sistema operativo y 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.

Cuatro regiones creadas por los dos ejes de anillos y VTLEl eje de anillos separa el modo kernel y el modo usuario, el eje VTL separa el mundo ordinario y el mundo aislado, y la combinación produce cuatro regiones: aplicaciones ordinarias, el kernel NT, trustlets IUM y el Secure KernelVTL1 (mundo aislado)VTL0 (mundo ordinario)Anillo 3: IUM (trustlets)Anillo 0: Secure KernelAnillo 3: aplicaciones ordinariasAnillo 0: kernel NT y controladores

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 de la frontera es SLAT

En la parte 1 dijimos que las tablas de traducción de segundo nivel que mapean una dirección física del invitado (GPA) sobre la RAM real (SPA) —SLAT— las tiene el hipervisor. VSM usa exactamente esta propiedad. El aislamiento VTL se crea usando el hipervisor de Hyper-V y SLAT.3

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, se le niega en la etapa de traducción de direcciones de la CPU. De nada sirve que el kernel reescriba sus propias tablas de páginas como quiera. 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.

El flujo por el que se niega el acceso desde VTL0 a la memoria de VTL1Cuando el kernel de VTL0 intenta leer memoria de VTL1, puede pasar su propia tabla de páginas pero lo niega la protección de acceso SLAT, y el control se transfiere al hipervisorNo permitidoPermitidoEl kernel de VTL0 intenta leer una página de VTL1Pasa la propia tabla de páginas del kernel¿Lo permite la protección de acceso SLAT?El hipervisor interviene y niega el accesoAcceso ordinario a memoriaProtegido en una capa que el kernel no puede cambiar

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

En la parte 1 de la serie de memoria escribimos que «los VAD, las PTE y los atributos de protección deciden si se permite el acceso». En un entorno VBS se puede organizar así: después de haber pasado todos esos, aún espera un puesto de control SLAT.

3.3. El Secure Kernel e 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).3

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

El flujo de las llamadas al sistema de un trustletUn trustlet en VTL1 no gestiona la mayoría de las llamadas al sistema él mismo; las marshalea al kernel NT de VTL0 y recibe solo el resultado, lo que mantiene VTL1 pequeñoEn la mayoría de los casosTrustlet (IUM en VTL1)Hace falta una llamada al sistemaLa petición se marshalea al kernel NT de VTL0Solo vuelve el resultadoVTL1 se mantiene pequeño, reduciendo la superficie de ataque

Figura 6: La caja fuerte no tiene instalaciones propias; externaliza las tareas y sigue guardando solo los secretos.

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

4.1. Qué se está verificando

La primera función representativa que se sienta sobre VBS es Integridad de la memoria: HVCI (hypervisor-protected code integrity). Windows tiene un mecanismo de integridad de código que inspecciona los controladores y binarios de modo kernel antes de que arranquen y no carga los que no están firmados o no son de confianza. HVCI ejecuta esta verificación dentro del entorno aislado de VBS.1

La razón de mover la propia lógica de verificación a VTL1 es exactamente la debilidad de la sección 2. Si el código de verificación se sienta 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.

La diferencia que marca dónde vive el código de verificaciónSi el código de verificación se sienta dentro del kernel de VTL0 se puede desactivar tomando el kernel, pero si está en VTL1 ni siquiera un atacante que ha tomado el kernel puede alcanzarlo y la verificación queda protegidaDentro del kernel de VTL0 (clásico)Entorno aislado en VTL1 (HVCI)Atacante que ha tomado el kernel¿Dónde vive la verificación de integridad de código?Se puede sustituir la lógica de verificaciónLa sustitución queda fuera de alcancePuede ejecutarse código sin firmar en el kernelLa verificación sigue funcionando tras comprometer el kernel

Figura 7: No ponga el puesto de control dentro del lado que podría ser vulnerado: 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 arrancar». También restringe la asignación de memoria del kernel.4

  • 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 (el llamado W^X).

Cuando estas dos están en su sitio, aunque una vulnerabilidad como un desbordamiento de búfer permita reescribir memoria del kernel, no se puede poner en ejecución el contenido reescrito. Una página ejecutable no se puede reescribir, y una página que se puede reescribir no se puede ejecutar.4 El respaldo final del permiso de ejecución es el derecho de ejecución del lado SLAT, que el kernel de VTL0 no puede manipular.

Hasta que una página del kernel se vuelve ejecutable en un entorno HVCIUna petición de carga de un controlador recibe verificación de integridad de código en el entorno aislado de VBS; si la supera se permite como página ejecutable no escribible, y si falla se bloquea y se registra en el registro CodeIntegritySuperaFallaPetición de cargar y ejecutar código del kernelVerificación de integridad de código en el entorno aisladoPermitida como página ejecutable (escrituras prohibidas)Se bloquea la cargaRegistrado en CodeIntegrity Operational (evento 3087)Las páginas escribibles siguen sin ser ejecutables

Figura 8: La verificación de la regla que no deja coexistir ejecutar y escribir se hace en el lado VTL1, y el kernel de VTL0 no puede anularla.

Seguir esto desde el punto de vista de un atacante deja claro cómo entra en vigor la regla.

El flujo por el que falla la inyección de código en un entorno HVCIAunque una vulnerabilidad permita reescribir memoria del kernel, una página que se pudo escribir no es ejecutable, y una página ejecutable no se puede reescribir de entrada, así que el código inyectado no se puede poner en ejecuciónUna página escribibleUna página ejecutableIntentar alterar la memoria del kernel mediante una vulnerabilidad¿Qué página es el objetivo?La escritura tiene éxitoLa propia escritura es imposiblePero esa página no es ejecutableEl código inyectado no se puede ejecutar

Figura 9: El significado de no cruzar páginas escribibles con páginas ejecutables es que, por la entrada que se tome, se llega a un callejón sin salida.

4.3. El precio en compatibilidad de controladores

Esta regla choca con los controladores de diseño antiguo. Los que reescriben su propio código en tiempo de ejecución, no tienen firma, o exigen memoria que es a la vez ejecutable y escribible: tales controladores no se pueden cargar en un entorno HVCI. El hecho del bloqueo se puede confirmar en el Visor de eventos bajo Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (el identificador de evento 3087 es representativo).5

«Después de activar Integridad de la memoria, un periférico dejó de funcionar»: en muchos casos, esa es la identidad real del problema. La respuesta adecuada es actualizar a un controlador compatible con HVCI; desactivar Integridad de la memoria debe pensarse como un último recurso que renuncia a la protección de golpe. Si participa en esta verificación desde el punto de vista del desarrollo de controladores, vea también el artículo de controladores de filtro («Controladores minifiltro de Windows»).

Aislar el caso en que un periférico deja de funcionar con Integridad de la memoriaIdentifique el controlador bloqueado en el registro CodeIntegrity Operational; la respuesta adecuada es actualizar a una versión compatible con HVCI, pedir al proveedor si no existe, y tratar la desactivación como un último recurso que no se hace permanenteSíNoUn dispositivo deja de funcionar tras activar Integridad de la memoriaIdentificar el controlador bloqueado en el registro CodeIntegrity¿Hay un controlador compatible con HVCI?Actualizar y resolverlo dejando HVCI activadoPedir al proveedor una versión compatibleDesactivar es un último recurso, no un ajuste 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 quién bloqueó la carga.

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

5.1. LSASS y LSAIso

La segunda función representativa que se sienta sobre VBS es la respuesta al misterio de la apertura: Credential Guard.

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

  • lsass.exe (VTL0) sigue ejecutándose como la recepción del procesamiento de autenticación, como hasta ahora.
  • Los secretos reales los tiene LSAIso.exe (VTL1) y no se puede acceder a ellos desde VTL0.
  • Los dos se comunican mediante RPC (Remote Procedure Call).
  • LSAIso no aloja ningún controlador de dispositivo, y aloja solo el mínimo de binarios firmados. Las firmas se verifican con un certificado en el que VBS confía.6
Dónde se sitúan las credenciales cuando Credential Guard está habilitadolsass en VTL0 se comunica con LSAIso en VTL1 mediante RPC como recepción de autenticación; los hashes y TGT reales de las credenciales de dominio protegidas los tiene LSAIso, así que un atacante que obtiene privilegios de administrador en VTL0 y vuelca lsass sigue sin obtener la sustancia protegidaVTL1VTL0RPCVolcado de memoriaNo llegaLSAIso.exe (caja fuerte de secretos)lsass.exe (recepción de autenticación)Atacante (privilegios de administrador)

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

A partir de Windows 11 versión 22H2, en los dispositivos que cumplen los requisitos de licencia (Enterprise E3/E5, Education A3/A5) y los requisitos de hardware, VBS y Credential Guard están habilitados de forma predeterminada. En ediciones como Pro, Credential Guard no se habilita automáticamente (hay excepciones, como cuando una máquina que estaba habilitada bajo una licencia cualificada se degrada después).7 «El manual de juego ya no funciona» de la apertura no es una historia sobre un producto adicional especial; es el estado estándar del Windows actual en las ediciones objetivo.

El flujo de las credenciales desde el inicio de sesión hasta la autenticaciónTras 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 solo el resultado del procesamiento de autenticación vuelve a VTL0 sin que se devuelvan los propios secretos de larga duración protegidosPedir el cálculo mediante RPCDevuelve el resultado (no el secreto)El usuario inicia sesiónlsass lo gestiona como recepciónLos secretos reales se almacenan en LSAIsoPeticiones de autenticación posteriores

Figura 12: Los propios secretos de larga duración protegidos nunca salen de la caja fuerte; lo que vuelve a VTL0 es el resultado del procesamiento de autenticación, como un ticket.

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

Credential Guard no es un escudo para todo. Lo que está protegido son los hashes NTLM de las credenciales de dominio, los TGT de Kerberos (Ticket Granting Tickets) y lo almacenado como credenciales de dominio. Lo siguiente queda fuera de alcance.8

  • 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 caminos que usan NTLMv1, MS-CHAPv2, Digest o CredSSP
  • El interior de software de terceros que gestiona las credenciales por su cuenta

Además, cuando Credential Guard está habilitado, NTLMv1, la delegación Kerberos sin restricciones y similares dejan de poder usarse, así que los sistemas empresariales que dependen de autenticación heredada necesitan una comprobación de compatibilidad.8 No «actívelo y ya está», sino comprender qué está dentro y fuera del alcance defensivo y rellenar el resto con otros controles: esa es la forma correcta de usarlo en la práctica.

El alcance defensivo de Credential GuardLos hashes NTLM de dominio y los TGT, 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 en privado quedan fuera de alcance¿De qué lado de la frontera de protección está este secreto?Hashes NTLM de dominio y TGTTickets de servicio y cuentas localesProtegido en LSAIsoNo protegido (hacen falta otros controles)Pulsaciones, ataques físicos y almacenes privados de la app también quedan fuera

Figura 13: El alcance defensivo se traza con una línea clara, y el exterior de la línea se rellena con autenticación multifactor y diseño del lado de la aplicación.

6. Compruébelo usted mismo

Puede confirmar el estado de ejecución de VBS y de cada función en su propia máquina.

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

Cómo leerlo es lo siguiente.9

  • 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.

Para confirmar el estado de ejecución en la interfaz gráfica, mire el campo «Seguridad basada en virtualización» en msinfo32 (se enumeran los servicios que están en ejecución, como «Hypervisor enforced Code Integrity»). 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 ajustes; puede parecer activado incluso mientras HVCI no está realmente en ejecución —esperando un reinicio justo después de la activación, o un problema de compatibilidad al arrancar—, así que juzgue si está en ejecución a partir de msinfo32 o de SecurityServicesRunning de Win32_DeviceGuard.5

Hay también 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 Isolated LSA se aloja en VTL1, y normalmente no aparece en una configuración donde solo está habilitado HVCI. La presencia o ausencia de un proceso es solo un rastro, sin embargo, así que juzgue si Credential Guard está en ejecución a partir de SecurityServicesRunning (si contiene 1), como arriba. Ambos son ventanas visibles desde VTL0 que corresponden al mundo del lado VTL1.

Cómo comprobar que las funciones relacionadas con VBS están en ejecuciónConfirme que VBS está en ejecución consultando Win32_DeviceGuard, juzgue Credential Guard y HVCI a partir de los valores de SecurityServicesRunning, y mire el registro CodeIntegrity para problemas de controladoresNoSí12Win32_DeviceGuard¿Estado VBS 2?VBS no está en ejecución¿Contiene 1 o 2?Credential Guard activadoHVCI activadoCodeIntegrity 3087

Figura 14: La confirmación de estado avanza en tres etapas: VBS en sí, 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 una historia del lado servidor»

Lo que Credential Guard impide es que el daño se extienda después de que se hayan tomado los privilegios de administrador (exfiltración de hashes y movimiento lateral). Dicho de otro modo, VBS es una capa de defensa en profundidad que asume el compromiso, y es en los PC cliente donde es eficaz. En Windows 11 que cumple los requisitos, habilitado de forma predeterminada es el estándar, así que la postura correcta no es «esto no tiene nada que ver con nosotros» sino «gestionar la compatibilidad bajo el supuesto de que ya está en ejecución».

Etapas del compromiso y dónde entra en vigor VBSEl acceso inicial lo cubren otros controles como la autenticación multifactor y la formación; HVCI bloquea la inyección de código en el kernel tras la escalada de privilegios; Credential Guard bloquea el robo de secretos de dominio protegidos y el movimiento lateral, pero no llega a los secretos fuera de su alcanceAcceso inicial (phishing y similares)Escalada de privilegiosInyección de código en el kernelRobo de secretos de dominio protegidos y movimiento lateralMFA, formación y EDR cubren estoHVCI bloquea este pasoCredential Guard bloquea esto (solo secretos protegidos)

Figura 15: VBS no es una tecnología de «que no entren»; es una tecnología de «que no ganen después de entrar», y la etapa que guarda es distinta.

7.2. «Si Integridad de la memoria causa un problema, solo hay que apagarla»

Apagarla hará que las cosas funcionen por el momento, pero tumba de golpe la barrera contra la inyección de código en el kernel. La respuesta adecuada es primero identificar el controlador bloqueado en el registro CodeIntegrity y aplicar la versión actualizada del proveedor. Aunque se desactive temporalmente para una validación, recomendamos una operación que no convierta eso en un ajuste permanente.

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

Eso es exceso de confianza por mezclar el alcance defensivo. Los tickets de servicio, las cuentas locales, las propias pulsaciones y las credenciales que una aplicación almacena en privado quedan fuera de alcance.8 El phishing y los registradores de teclas necesitan otros controles (autenticación multifactor, Windows Hello y una revisión de la gestión de credenciales en el lado de la aplicación).

8. Resumen

  • VBS usa el hipervisor para crear un entorno aislado y protege las funciones de seguridad bajo el supuesto de que el kernel puede estar comprometido.1
  • La unidad de aislamiento es el VTL; actualmente se implementan dos niveles, VTL0 (el mundo ordinario) y VTL1 (el Secure Kernel e IUM).2
  • La sustancia de la frontera es la protección de acceso a memoria SLAT, que el software dentro de la partición —incluido el kernel— no puede cambiar.2
  • HVCI ejecuta la verificación de integridad de código en el entorno aislado y hace cumplir «no ejecutable hasta que la verificación se supere» y «una página ejecutable no es escribible».4 El precio es que hay que gestionar la compatibilidad de controladores.5
  • Credential Guard aísla los hashes NTLM de las credenciales de dominio y los TGT 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 (use esto junto con una comprobación del estado de ejecución).67
  • Se puede confirmar el estado de ejecución a partir de SecurityServicesRunning de Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).9

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, el de la «ligereza», y sigue dónde recortan las máquinas virtuales ligeras que descartaron el peso de una máquina virtual completa.

Artículos relacionados

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos 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.

Referencias

  1. Microsoft Learn, Virtualization-based Security (VBS). Sobre que VBS usa la virtualización de hardware y el hipervisor de Windows para crear un entorno aislado y tratarlo como la raíz de confianza del sistema operativo bajo el supuesto de que el kernel puede estar comprometido; que Integridad de la memoria ejecuta la verificación de integridad de código de modo kernel dentro de ese entorno aislado; y que SLAT es un requisito duro para VBS. ↩ ↩2 ↩3

  2. Microsoft Learn, Virtual Secure Mode. Sobre que VSM es la base de Device Guard, Credential Guard, un TPM virtual y similares; que el acceso a las regiones aisladas se controla solo a través del hipervisor y está protegido incluso frente a software de sistema operativo de anillo 0; que los VTL son jerárquicos con 2 de un máximo de 16 niveles implementados; y que las protecciones de acceso a memoria por VTL no las puede cambiar el software de sistema dentro de la partición. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, Isolated User Mode (IUM) Processes. Sobre que VSM crea VTL usando el hipervisor de Hyper-V y SLAT; que el Secure Kernel e IUM se ejecutan en VTL1; que los trustlets marshalean las llamadas al sistema al kernel de VTL0; y que LSAIso se ejecuta en VTL1 y se comunica con lsass mediante RPC. ↩ ↩2 ↩3

  4. Microsoft Learn, Memory integrity and virtualization-based security. Sobre que Integridad de la memoria (HVCI) ejecuta la verificación de integridad de código en un entorno aislado, y sobre que las páginas de memoria del kernel se vuelven ejecutables solo después de superar la verificación y las páginas ejecutables no se vuelven escribibles. ↩ ↩2 ↩3

  5. Microsoft Learn, Memory integrity and VBS enablement. Sobre que Integridad de la memoria está habilitada de forma predeterminada en una instalación limpia de Windows 11 si el hardware es compatible; la confirmación de estado en msinfo32 y la aplicación Seguridad de Windows; y la confirmación de un controlador bloqueado mediante el identificador de evento 3087 en el registro CodeIntegrity Operational. ↩ ↩2 ↩3

  6. Microsoft Learn, How Credential Guard works. Sobre que el LSA se comunica con un proceso Isolated LSA (LSAIso.exe) para almacenar secretos cuando Credential Guard está habilitado; que los datos almacenados los protege VBS y son inaccesibles desde el resto del sistema operativo; y que el proceso Isolated LSA no aloja controladores de dispositivo y aloja solo un mínimo de binarios con firma verificada. ↩ ↩2 ↩3

  7. Microsoft Learn, Credential Guard overview. Sobre que Credential Guard está habilitado de forma predeterminada a partir de Windows 11 versión 22H2 en los dispositivos que cumplen los requisitos de licencia, hardware y software y no se han deshabilitado de forma explícita; que las ediciones/licencias cualificadas son Enterprise (E3/E5) y Education (A3/A5), quedando Pro fuera de alcance; y que una máquina Pro que estaba habilitada antes bajo una licencia cualificada sigue siendo un objetivo habilitado de forma predeterminada tras una degradación. ↩ ↩2

  8. Microsoft Learn, Credential Guard protection limits. Sobre que los tickets de servicio, las cuentas locales, los registradores de teclas, los ataques físicos y similares quedan fuera del alcance de protección de Credential Guard; que los TGT están protegidos mientras que los tickets de servicio no; y que NTLMv1 y la delegación sin restricciones dejan de poder usarse cuando está habilitado. ↩ ↩2 ↩3

  9. Microsoft Learn, Enable virtualization-based protection of code integrity. Sobre cómo confirmar el estado de VBS e Integridad de la memoria mediante la clase Win32_DeviceGuard, y sobre el significado de los valores de SecurityServicesRunning (1 es Credential Guard, 2 es Integridad de la memoria). ↩ ↩2

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) e 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, e «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 (hypervisor-protected code integrity). Confirme el estado de ejecución de cada servicio 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 contra 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. Se puede confirmar el bloqueo en el registro CodeIntegrity Operational (identificador de evento 3087 y similares).
¿Qué protege Credential Guard, y qué no protege?
Protege 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, en un entorno aislado. 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.

Contactar
Volver al blog