Qué es Credential Guard y cómo comprobar si está activado

Proteger las credenciales en Windows se ha convertido en una tarea crítica para cualquier empresa que quiera tomarse en serio la ciberseguridad. Cada vez que un usuario inicia sesión, se generan y almacenan secretos de autenticación extremadamente valiosos (hashes, tickets, tokens, etc.) que, si caen en manos de un atacante, le permiten moverse por la red como si fuera un usuario legítimo. Aquí es justo donde entra en juego Credential Guard.

Windows Defender Credential Guard es una función de seguridad que aprovecha la seguridad basada en virtualización (VBS) para aislar esos secretos y evitar que el sistema operativo “normal” o el malware con privilegios elevados puedan acceder a ellos. Aunque no es una bala de plata y no cubre todos los tipos de credenciales ni todos los vectores de ataque, reduce de forma drástica la eficacia de técnicas clásicas como Pass-the-Hash y Pass-the-Ticket, así como de herramientas como Mimikatz en muchos escenarios.

Qué es exactamente Windows Defender Credential Guard

Credential Guard es una característica de Windows diseñada para proteger las credenciales de dominio y otros secretos de autenticación frente a ataques que intentan leerlos directamente de la memoria del sistema. Esta tecnología apareció en Windows 10 Enterprise y Windows Server 2016, y sigue presente en versiones posteriores de Windows 11 y Windows Server.

A grandes rasgos, Credential Guard se apoya en VBS para ejecutar parte del proceso de seguridad en un entorno aislado por el hipervisor, separado del sistema operativo principal. En lugar de que los secretos residan directamente en la memoria del proceso de Autoridad de Seguridad Local (LSA) tradicional (lsass.exe), se almacenan en un proceso protegido e independiente, normalmente gestionado por LsaIso.exe, al que solo puede acceder el código más privilegiado y confiable.

Esta separación tiene como objetivo evitar que el malware que haya conseguido privilegios de administrador pueda simplemente volcar la memoria de LSASS para extraer hashes NTLM, tickets de Kerberos o credenciales almacenadas en el Administrador de credenciales. El enfoque no consiste en cambiar los protocolos de autenticación, sino en blindar dónde y cómo se guardan las credenciales en memoria.

Secretos y servicios que protege Credential Guard

La función protege distintos tipos de credenciales que, tradicionalmente, eran un objetivo muy jugoso para los atacantes. Entre los secretos que Credential Guard mantiene protegidos se incluyen, principalmente, los relacionados con:

• NTLM: hashes de contraseñas NTLM usados para autenticación.
• Kerberos: en concreto, el Ticket Granting Ticket (TGT) que permite solicitar otros tickets de servicio.
• Credential Manager: credenciales de dominio almacenadas por aplicaciones y servicios.
• Inicios de sesión locales y remotos que dependen de credenciales de dominio.

En versiones anteriores de Windows, estos secretos residían en la memoria del proceso LSASS de forma accesible para un atacante con privilegios elevados. Con Credential Guard habilitado, se ejecuta un proceso LSA aislado que no expone directamente esos secretos a herramientas que intenten leer la memoria del sistema operativo estándar.

Cómo funciona la seguridad basada en virtualización (VBS) y el modo seguro virtual (VSM)

La clave de Credential Guard es la VBS, una tecnología que utiliza el hipervisor de Windows para crear entornos de ejecución aislados dentro de la misma máquina física. Dentro de ese entorno, denominado con frecuencia Virtual Secure Mode (VSM), se ejecutan servicios de seguridad que manejan los secretos de autenticación.

Cuando Credential Guard está activo, los secretos se almacenan en memoria dentro de VSM y no en el espacio de memoria del sistema operativo normal. El hipervisor se encarga de que solo el código altamente privilegiado y verificado pueda acceder a ellos. De esta forma, aunque un atacante llegue a comprometer el sistema operativo con privilegios de administrador, sus posibilidades de lectura directa de esos secretos se reducen enormemente.

En hardware moderno que incluye un TPM 2.0 compatible, los datos persistentes de VSM pueden cifrarse con una clave maestra de VSM. Esta clave se almacena y protege mediante el TPM y sus mecanismos de raíz de confianza a nivel de firmware. El resultado es que, incluso si alguien intenta manipular el arranque o clonar un disco, no podrá acceder a los secretos protegidos fuera de un entorno verificado.

Es importante señalar, además, que Credential Guard no suele conservar en disco datos como el hash NTLM o el TGT. Estos se regeneran en cada inicio de sesión y se pierden entre reinicios, por lo que no dependen directamente de la clave maestra de VSM ni del TPM para mantenerse seguros tras un apagado.

Límites y credenciales que Credential Guard no protege

Pese a sus ventajas, Credential Guard tiene limitaciones claras que hay que entender para no confiarse de más. Hay credenciales y flujos de autenticación que quedan fuera de su ámbito de protección o que directamente no funcionan igual cuando la característica está activa.

Por un lado, cuando Credential Guard está habilitado, determinados protocolos heredados como NTLMv1, MS-CHAPv2, Digest y CredSSP no pueden usar las credenciales de sesión ya iniciada. Eso implica que el inicio de sesión único (SSO) con estos protocolos deja de funcionar. Las aplicaciones que dependan de ellos pueden llegar a pedir de nuevo usuario y contraseña o tirar de credenciales almacenadas en el almacén de Windows, que en estos casos no quedan protegidas por Credential Guard.

Además, hay métodos de gestión de credenciales que quedan completamente fuera del paraguas de esta función, tales como:

• Software de terceros que almacena contraseñas o tokens fuera de la infraestructura estándar de Windows.
• Cuentas locales y cuentas Microsoft, que no gozan del mismo tipo de aislamiento que las credenciales de dominio.
• Bases de datos de Active Directory alojadas en controladores de dominio Windows Server. Credential Guard no protege directamente la base de datos de AD ni las canalizaciones de entrada de credenciales en servicios como la puerta de enlace de Escritorio remoto.
• Keyloggers y otros capturadores de entrada: si el atacante registra las pulsaciones de teclado, puede robar la contraseña antes de que siquiera se almacene en LSASS o en el entorno aislado.
• Ataques físicos al equipo (por ejemplo, acceso a memoria en caliente o lectura de disco mediante técnicas avanzadas).

También hay que tener en cuenta que Credential Guard no impide que un atacante que ya tenga malware en la máquina utilice los privilegios de las credenciales válidas que se hayan obtenido de formas alternativas. Por ejemplo, si un administrador se loguea en un equipo ya comprometido, el atacante puede aprovechar su sesión activa para realizar acciones con sus permisos, aunque no sea capaz de extraer el hash NTLM del entorno aislado.

Por otro lado, las credenciales de inicio de sesión almacenadas en caché por Windows (lo que se suele llamar “inicios de sesión almacenados en caché”) tampoco entran en la categoría de credenciales reutilizables en otros equipos. Se guardan en el Registro local y sirven solo para validar inicios de sesión cuando el dominio no está disponible. Estas se gestionan mediante la directiva de seguridad “Inicio de sesión interactivo: número de inicios de sesión anteriores que se almacenarán en caché” y no están específicamente protegidas por Credential Guard.

Finalmente, los vales de servicio Kerberos no quedan bajo la protección de Credential Guard, aunque sí lo hace el TGT. Y cuando Credential Guard está activo, Kerberos no permitirá delegación sin restricciones ni cifrado DES, ni para credenciales iniciadas ni para credenciales solicitadas o guardadas.

Beneficios frente a ataques de robo de credenciales

El objetivo principal de Credential Guard es frenar ataques de “robo y reutilización” de credenciales, en particular:

• Pass-the-Hash: reutilización de hashes NTLM robados para autenticarse en otros sistemas.
• Pass-the-Ticket: uso indebido de tickets Kerberos (TGT o de servicio) obtenidos en una máquina comprometida.

Al aislar los secretos en VSM y limitar quién puede acceder a ellos, se bloquean muchas de las técnicas que aprovechan herramientas como Mimikatz para volcar la memoria de LSASS. En un entorno sin Credential Guard, Mimikatz puede extraer hashes NTLM y tickets de Kerberos sin demasiada dificultad una vez que el atacante tiene privilegios de administrador. Con Credential Guard activo, el proceso LSA aislado impide que estos secretos estén disponibles en la memoria accesible desde el sistema operativo estándar.

Aun así, es importante entender que Credential Guard no es invulnerable. Mimikatz y herramientas similares siguen pudiendo, por ejemplo, capturar credenciales mientras se están introduciendo, si el sistema ya está comprometido y el usuario con privilegios inicia sesión después. El propio autor de Mimikatz ha advertido que, si el atacante controla el endpoint antes de que el administrador introduzca sus credenciales, aún hay vías para robarlas. Además, Credential Guard no protege contra el uso malicioso de credenciales por parte de usuarios internos legítimos; si alguien tiene acceso autorizado a un recurso, esta tecnología no evitará que copie datos sensibles.

Habilitación predeterminada en Windows 11 y Windows Server

En versiones recientes del sistema, Microsoft ha ido dando un paso más y ha activado por defecto la combinación de VBS y Credential Guard en ciertos dispositivos. A partir de Windows 11, versión 22H2, y de Windows Server 2025, los equipos que cumplan los requisitos mínimos tienen estas características habilitadas automáticamente.

La configuración de fábrica se hace normalmente sin bloqueo UEFI. Esto significa que los administradores pueden desactivar Credential Guard de forma remota si lo consideran imprescindible, por ejemplo, por una incompatibilidad crítica con alguna aplicación heredada. En el momento en que Credential Guard se habilita, VBS se activa también de manera automática.

Es importante saber que si un equipo ya tenía Credential Guard deshabilitado explícitamente antes de actualizar a una versión de Windows en la que la característica pasa a estar habilitada por defecto, ese estado de “desactivado” se respeta tras la actualización. La política explícita siempre tiene prioridad sobre el comportamiento predeterminado después de un reinicio.

Requisitos de hardware, firmware y software

Para que Credential Guard ofrezca una protección efectiva, el dispositivo tiene que cumplir unos requisitos mínimos de hardware, firmware y sistema operativo. Cuanto más moderno y completo sea el hardware, mayor será el nivel de protección alcanzable.

Entre los requisitos clave destacan:

• CPU de 64 bits, con soporte para virtualización por hardware.
• Seguridad basada en virtualización activada (VBS).
• Arranque seguro (Secure Boot) habilitado y configurado.

Además, aunque no siempre es obligatorio, se recomienda encarecidamente contar con:

• TPM (Trusted Platform Module) versión 1.2 o 2.0, ya sea discreto o de firmware, para vincular la protección al hardware y conservar claves maestras de forma segura.
• Bloqueo UEFI, que impide que un atacante deshabilite Credential Guard simplemente modificando entradas del Registro o cambios de configuración a bajo nivel.

Los equipos que superan estos requisitos básicos pueden optar a calificaciones de seguridad adicionales y niveles más altos de protección frente a amenazas que intentan explotar la cadena de arranque o el acceso directo a la memoria.

Uso de Credential Guard en máquinas virtuales Hyper-V

Credential Guard también puede proteger secretos dentro de máquinas virtuales que se ejecutan sobre Hyper-V, de forma muy similar a como lo hace en equipos físicos. Cuando se habilita en una VM, los secretos quedan aislados frente a ataques originados dentro de esa misma máquina virtual.

No obstante, hay matices importantes: Credential Guard no proporciona protección contra ataques con privilegios elevados que se lancen desde el host que ejecuta la VM. Es decir, el administrador del host o un atacante que controle el sistema físico subyacente puede seguir teniendo opciones de manipulación.

Para que Credential Guard funcione en una máquina virtual de Hyper-V, se requieren al menos:

• Un host Hyper-V con IOMMU (unidad de gestión de memoria de entrada/salida) compatible.
• Una máquina virtual de Generación 2, que soporte arranque UEFI seguro y las extensiones necesarias.

Desde el host, es posible incluso deshabilitar Credential Guard para una VM concreta utilizando PowerShell, mediante un comando similar a Set-VMSecurity -VirtualizationBasedSecurityOptOut $true, apuntando al nombre de la máquina virtual.

Licencias y ediciones de Windows compatibles

Credential Guard no está disponible en todas las ediciones de Windows. Microsoft lo ha reservado para las variantes más orientadas a empresa y educación, dejando fuera a ciertas ediciones profesionales estándar.

En cuanto a compatibilidad por edición de Windows, a grandes rasgos se cumple lo siguiente:

• Windows Enterprise: compatible con Credential Guard.
• Windows Education: compatible.
• Windows Pro y Windows Pro Education/SE: no incluyen soporte directo para Credential Guard.

Respecto a derechos de licencia, la funcionalidad viene asociada a suscripciones de nivel empresarial y educativo. Entre las licencias que sí conceden derechos de uso de Credential Guard se encuentran:

• Windows Enterprise E3
• Windows Enterprise E5
• Windows Education A3
• Windows Education A5

Otras licencias como Windows Pro o Pro Education estándar no incluyen por defecto estos derechos. Para profundizar en el detalle de qué incluye cada licencia y qué escenarios cubre, es recomendable revisar la documentación oficial de licenciamiento de Windows.

Impacto en aplicaciones y protocolos de autenticación

Activar Credential Guard tiene consecuencias directas en algunos protocolos de autenticación heredados y en ciertas funcionalidades de Kerberos y NTLM que muchas aplicaciones antiguas aún utilizan. Antes de un despliegue masivo, es fundamental identificar requisitos y probar la compatibilidad.

Las aplicaciones dejarán de funcionar correctamente si necesitan alguna de las siguientes capacidades:

• Soporte para cifrado DES en Kerberos.
• Delegación Kerberos sin restricciones.
• Extracción de TGT de Kerberos desde el sistema.
• Uso de NTLMv1 como protocolo de autenticación.

Otros escenarios no rompen necesariamente la aplicación, pero sí aumentan el riesgo de exposición de credenciales si se siguen utilizando:

• Autenticación implícita que capture o reutilice credenciales en claro.
• Delegación de credenciales sin las protecciones adecuadas.
• Protocolos como MS-CHAPv2 y CredSSP, que pueden forzar al usuario a introducir credenciales que luego se almacenan de forma menos protegida.

Algunos servicios o aplicaciones que intenten enlazar directamente el proceso aislado LSAIso.exe pueden causar problemas de rendimiento o malfuncionamientos si no están diseñados para trabajar con este nuevo modelo. Por el contrario, servicios que se apoyan en Kerberos de forma estándar, como recursos compartidos SMB o conexiones de Escritorio remoto bien configuradas, deberían seguir funcionando con normalidad cuando Credential Guard está habilitado.

Cómo habilitar Credential Guard en entornos corporativos

La recomendación de seguridad es que Credential Guard se habilite antes de unir un dispositivo al dominio o antes de que un usuario de dominio inicie sesión por primera vez, de forma que los secretos no se hayan almacenado nunca sin protección reforzada. Si se activa después de que la máquina lleve tiempo en uso, es posible que algunas credenciales ya se hayan visto comprometidas con anterioridad.

Existen varios métodos principales para habilitar Credential Guard en un parque de dispositivos Windows:

• Microsoft Intune / MDM.
• Directiva de grupo (GPO).
• Configuración directa del Registro.

Configuración mediante Microsoft Intune y políticas MDM

En un entorno gestionado con Intune, se puede desplegar la configuración a través de perfiles de seguridad o políticas personalizadas. El flujo típico consiste en crear una política de protección de cuenta o equivalente, y establecer los parámetros para activar VBS y definir la configuración de Credential Guard.

Cuando se usa un CSP (Configuration Service Provider) como DeviceGuard, las claves relevantes incluyen:

• Nombre de configuración: “activar la seguridad basada en virtualización”. OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity. Tipo de datos: entero. Valor: 1 para habilitar.
• Nombre de configuración: “Configuración de Credential Guard”. OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags. Tipo de datos: entero. Valores típicos:
  • 1: habilitado con bloqueo UEFI.
  • 2: habilitado sin bloqueo.

Una vez aplicada la política al grupo de dispositivos o usuarios deseado, es necesario reiniciar el equipo para que el hipervisor y el entorno VSM se inicialicen correctamente y Credential Guard entre en funcionamiento.

Habilitación usando Directiva de grupo (GPO)

En dominios basados en Active Directory, la forma clásica de configurar Credential Guard es a través del Editor de directivas de grupo. Se puede configurar tanto en el Editor de directiva local de cada equipo como en GPOs vinculadas a OU o al dominio entero.

La ruta de configuración estándar es:

Configuración del equipo → Plantillas administrativas → Sistema → Device Guard

Dentro de esa ruta, hay que editar la directiva “Activar la seguridad basada en virtualización” y establecer su estado en Habilitado. En el desplegable de “Configuración de Credential Guard” se puede elegir entre “Habilitado con bloqueo UEFI” o “Habilitado sin bloqueo”, dependiendo del nivel de restricción deseado. Tras la actualización de políticas y un reinicio, la protección queda activa.

Configuración avanzada mediante el Registro

Para escenarios puntuales o automatizaciones específicas, también es posible configurar Credential Guard manipulando directamente el Registro de Windows. Las claves más relevantes son:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Clave: EnableVirtualizationBasedSecurity (REG_DWORD). Valor: 1 para activar VBS.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Clave: RequirePlatformSecurityFeatures (REG_DWORD). Valores típicos:
  • 1 para usar solo arranque seguro.
  • 3 para usar arranque seguro y protección DMA.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  Clave: LsaCfgFlags (REG_DWORD). Valores:
  • 1: habilitar Credential Guard con bloqueo UEFI.
  • 2: habilitar Credential Guard sin bloqueo.

Tras aplicar estos cambios, hay que reiniciar la máquina para que la nueva configuración tenga efecto y se inicie el entorno protegido.

Cómo comprobar si Credential Guard está realmente en ejecución

Un error frecuente es fijarse únicamente en si el proceso LsaIso.exe aparece en el Administrador de tareas para concluir que Credential Guard está activo. Microsoft no recomienda este método como comprobación definitiva, ya que puede no reflejar con precisión el estado real de la protección.

En su lugar, hay tres métodos más fiables para verificar el estado de Credential Guard:

• Herramienta Información del sistema (msinfo32.exe).
• Comandos de PowerShell.
• Revisión de eventos en el Visor de eventos.

Con Información del sistema, basta con ejecutar msinfo32.exe, seleccionar “Resumen del sistema” y comprobar el campo “Servicios de seguridad basados en virtualización en ejecución”. Si aparece “Credential Guard” listado entre los servicios activos, significa que la función está realmente operativa.

Vía PowerShell, se puede ejecutar el comando:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

El valor devuelto indicará el estado de ejecución:

• 0: Credential Guard deshabilitado (no se está ejecutando).
• 1: Credential Guard habilitado y en funcionamiento.

Además, se pueden revisar eventos relacionados en el Visor de eventos, filtrando en Windows Logs\System por el origen de eventos WinInit. Un análisis periódico de estos eventos, combinado con consultas WMI o auditorías de seguridad, ayuda a confirmar la salud y el estado de la implementación en toda la flota.

Opciones para deshabilitar Credential Guard

Aunque desde el punto de vista de seguridad no es lo ideal, en ocasiones es necesario desactivar Credential Guard por problemas de compatibilidad con aplicaciones críticas o protocolos heredados que no se pueden sustituir a corto plazo.

El procedimiento para desactivar la función varía según cómo se haya habilitado inicialmente. En términos generales, se debe:

• Revertir la configuración aplicada por Intune, GPO o Registro, devolviendo los valores de VBS y LsaCfgFlags a su estado deshabilitado.
• Reiniciar el dispositivo para que dejen de cargarse los componentes de seguridad basados en virtualización.

Si Credential Guard se configuró con bloqueo UEFI, la cosa se complica un poco más, porque parte del estado se guarda en variables EFI dentro del firmware. En este caso, además de deshacer la configuración en Windows, es necesario ejecutar una serie de comandos con bcdedit desde un símbolo del sistema con privilegios elevados para cargar una herramienta especial de configuración (SecConfig.efi) durante el arranque.

El flujo suele ser algo similar a:

• Montar una partición EFI temporal usando mountvol y copiar en ella SecConfig.efi.
• Crear una entrada de cargador de sistema con bcdedit /create, apuntando a SecConfig.efi.
• Configurar una secuencia de arranque temporal para ejecutar esa entrada en el siguiente reinicio y pasarle la opción DISABLE-LSA-ISO.
• Reiniciar la máquina y, cuando aparezca el mensaje previo al arranque del sistema operativo, confirmar el cambio de configuración de UEFI para que la desactivación persista.

Sin esta confirmación, el firmware no grabará el cambio y Credential Guard seguirá estando bloqueado a nivel de UEFI, aunque se haya modificado la configuración dentro del sistema operativo.

En máquinas virtuales, por su parte, el host de Hyper-V puede deshabilitar el uso de VBS y Credential Guard para una VM concreta utilizando el comando de PowerShell Set-VMSecurity con la opción de exclusión correspondiente.

En algunos entornos, se ha observado que tras ciertas actualizaciones de Windows, equipos que usaban autenticación de Escritorio remoto con SSO o métodos heredados empiezan a mostrar mensajes de que las credenciales ya no son válidas. En muchos de esos casos, la solución temporal que se ha aplicado ha sido desactivar Credential Guard desde la política de grupo local (GPEDIT.msc), navegando a Configuración del equipo → Plantillas administrativas → Sistema → Device Guard → “Activar seguridad basada en virtualización” y marcando la opción de configuración de Credential Guard como “Deshabilitado”.

Credential Guard se ha consolidado como una de las piezas clave de la estrategia de protección de identidades en Windows, especialmente en entornos con Active Directory amplio y cuentas privilegiadas muy sensibles. Aprovechando VBS, TPM y aislamiento de memoria, esta tecnología dificulta enormemente la vida a los atacantes que intentan moverse lateralmente robando credenciales de la memoria de los endpoints y servidores, siempre que se complemente con buenas prácticas, herramientas de monitorización y una gestión razonable de aplicaciones y protocolos heredados.