Credential Guard y protección LSA: proteger LSASS

LSASS (Local Security Authority Subsystem Service) guarda los secretos que hacen posible el inicio de sesión único: hashes NTLM, tickets y claves de Kerberos y, a veces, más. Cualquier proceso capaz de leer la memoria de LSASS puede recolectar esos secretos y reutilizarlos en otro lugar. El volcado de credenciales de LSASS aparece en una proporción muy alta de las intrusiones con operador humano, y por eso Windows incluye ahora dos defensas específicas:

• La protección LSA (RunAsPPL) ejecuta LSASS como proceso protegido ligero (PPL). Solo el código firmado con el nivel de protección adecuado puede abrirlo para leer su memoria o inyectar código, aunque el atacante sea administrador local.
• Credential Guard usa la seguridad basada en virtualización (VBS) para trasladar los hashes NTLM, las claves de sesión de los TGT de Kerberos y las credenciales de dominio almacenadas a un proceso aislado, LsaIso.exe, que se ejecuta en un nivel de confianza virtual separado. LSASS se comunica con él por RPC y nunca guarda los secretos en bruto.

Se complementan y deben activarse juntos.

Requisitos

Qué se rompe

Ambas características eliminan capacidades, por diseño. Prevé lo siguiente:

• Complementos y controladores LSA de terceros que no están firmados para procesos protegidos: middleware de tarjetas inteligentes, algunos filtros de contraseñas, productos de seguridad antiguos. La protección LSA tiene un modo de auditoría para esto; úsalo.
• Con Credential Guard: el inicio de sesión único con NTLMv1, MS-CHAPv2 y Digest deja de funcionar con credenciales guardadas, la delegación sin restricciones de Kerberos y el cifrado DES quedan bloqueados, y CredSSP no puede delegar credenciales guardadas ni predeterminadas. Los perfiles Wi-Fi y VPN que usan MS-CHAPv2 (PEAP-MSCHAPv2) pedirán credenciales o fallarán si dependen de las credenciales de Windows guardadas. Pásalos antes a autenticación basada en certificados (EAP-TLS).

Paso 1: auditar la protección LSA antes de imponerla

Pon LSASS en modo de auditoría en un grupo piloto (Windows 11 22H2 y posteriores ya auditan de forma predeterminada). Así se registra cada módulo que no podría cargarse con la protección activada, sin bloquear nada:

Key:   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe
Value: AuditLevel  (REG_DWORD) = 8

Reinicia y revisa Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational:

• Evento 3065: LSASS intentó cargar un controlador o módulo que no cumple los requisitos de seguridad para secciones compartidas.
• Evento 3066: LSASS intentó cargar un módulo que no cumple los requisitos de nivel de firma de Microsoft, por lo que se bloquearía con la protección activada.

Contacta con el proveedor de cada módulo de la lista. La mayoría de los productos actuales de seguridad y autenticación incluyen componentes LSA correctamente firmados.

Paso 2: activar la protección LSA

Directiva de grupo (ADMX de Windows 11 22H2 y posteriores, y de Server 2025): Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process, establecida en Enabled with UEFI Lock o Enabled without UEFI Lock.

El valor del registro equivalente, que también funciona en compilaciones anteriores:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: RunAsPPL  (REG_DWORD)
       1 = enabled with a UEFI variable (cannot be turned off by registry alone)
       2 = enabled without UEFI lock (Windows 11 22H2 and later)

El bloqueo UEFI es más robusto, porque un atacante con derechos de administrador no puede limitarse a cambiar el registro y reiniciar. También implica que desactivarlo más adelante requiere una herramienta de exclusión documentada y presencia física, así que úsalo cuando tengas confianza en la compatibilidad.

Tras reiniciar, verifícalo en el registro System: el evento 12 del origen Wininit indica que LSASS.exe was started as a protected process with level: 4.

Paso 3: activar Credential Guard

Directiva de grupo: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security:

Equivalentes en el registro, para despliegues por script o fuera del dominio:

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  LsaCfgFlags                         REG_DWORD 1  (with UEFI lock) or 2 (without lock)

En Intune, usa Endpoint security > Account protection o un perfil del catálogo de configuración para Credential Guard.

Paso 4: verificar

En el dispositivo, msinfo32 muestra Virtualization-based security: Running y enumera Credential Guard en Virtualization-based security Services Running. Desde PowerShell:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus   # 2 = en ejecución
$dg.SecurityServicesRunning             # contiene 1 = Credential Guard, 2 = HVCI (integridad de memoria)

Microsoft no recomienda buscar LsaIso.exe en el Administrador de tareas; revisa en su lugar el registro System en busca del evento 13 de WinInit (Credential Guard (LsaIso.exe) was started and will protect LSA credentials). Recoge estos valores en todo el parque con tu herramienta de administración o un script de cumplimiento, porque las actualizaciones de firmware, los restablecimientos de BIOS y los cambios de hardware pueden desactivar VBS sin avisar.

Paso 5: desactivar los restos heredados

Credential Guard y PPL protegen lo que guarda LSASS. Reduce, para empezar, lo que guarda:

Activa también la regla ASR Block credential stealing from the Windows local security authority subsystem (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2), que añade otra barrera en los dispositivos donde Credential Guard no puede ejecutarse. Consulta la guía de reglas ASR.

La detección sigue importando

Ninguna de las dos características protege las credenciales escritas en una máquina comprometida (un keylogger las sigue viendo), los hashes de las cuentas locales en la SAM ni la base de datos NTDS.dit de los controladores de dominio. Sigue detectando:

• Accesos de procesos a lsass.exe con derechos de lectura de memoria (evento 10 de Sysmon, o tu EDR).
• Cambios en RunAsPPL, LsaCfgFlags y UseLogonCredential (auditoría del registro o evento 13 de Sysmon).
• Creación de archivos de volcado de LSASS (evento 11 de Sysmon para *.dmp escritos por procesos inusuales).

Lista de comprobación

• Protección LSA auditada (eventos 3065/3066) y después impuesta con bloqueo UEFI
• El evento 12 confirma el nivel de proceso protegido en cada host
• VBS y Credential Guard en ejecución en todos los clientes y servidores miembro aptos
• Wi-Fi/VPN sin MS-CHAPv2 antes del despliegue de Credential Guard
• WDigest desactivado y supervisado; inicios de sesión en caché reducidos
• Regla ASR de LSASS en modo de bloqueo
• Informe del parque sobre SecurityServicesRunning, revisado de nuevo tras las actualizaciones de firmware

Estas dos configuraciones convierten la técnica de post-explotación más fiable de Windows en una poco fiable. Junto con el modelo por niveles de administración, sencillamente hay menos que merezca la pena robar y menos sitios de donde robarlo.