LAPS, Credential Guard y Protected Users:

cerrar el robo de credenciales en Windows

Serie Blue Team / Windows  |  unfantasmaenelsistema.com

La mayoría de los movimientos laterales en un dominio Windows no empiezan con un exploit, sino con una credencial reutilizada. Un atacante que consigue administrador local en un puesto vuelca los secretos que Windows guarda en memoria para dar inicio de sesión único (SSO) y, con ellos, salta al siguiente equipo sin necesidad de conocer ninguna contraseña en texto claro. Si además esa contraseña de administrador local es la misma en cien máquinas, el salto es inmediato.

Windows trae desde hace años un conjunto de controles pensados exactamente para cortar esa cadena: Windows LAPS para que cada equipo tenga una contraseña local única y rotada, Credential Guard para que los secretos de LSASS no se puedan volcar, y Protected Users, Authentication Policies y Silos para limitar dónde y cómo se autentican las cuentas privilegiadas. Este artículo explica qué hace cada uno, qué NO cubre y cómo comprobar que está activo de verdad.

1. Por qué se roba tan fácil una credencial en Windows

El proceso LSASS (Local Security Authority Subsystem Service) mantiene en memoria los secretos necesarios para que no tengas que reescribir la contraseña cada vez que abres un recurso de red. Según la configuración y la antigüedad del sistema, ahí puede haber hashes NTLM, tickets y claves Kerberos (TGT incluido), secretos de cuentas de servicio y, en equipos mal configurados, incluso la contraseña en texto claro a través del proveedor heredado WDigest.

Quien tiene privilegios de administrador local en la máquina puede leer esa memoria y quedarse con esos secretos. A partir de ahí no necesita descifrar nada: reutiliza el hash (pass-the-hash) o el ticket (pass-the-ticket) contra otros equipos. El daño se multiplica con dos malas costumbres clásicas: una contraseña de administrador local idéntica en todo el parque, y el hábito de iniciar sesión interactiva con cuentas de dominio muy privilegiadas en puestos de trabajo normales.

2. Windows LAPS: matar la contraseña local compartida

LAPS (Local Administrator Password Solution) asigna a la cuenta de administrador local de cada equipo una contraseña distinta, larga y aleatoria, la guarda en un almacén central y la rota de forma automática cada cierto tiempo y, opcionalmente, después de cada uso. Así, comprometer un equipo ya no regala acceso a los demás.

El LAPS antiguo era un complemento con una DLL de extensión de directiva de grupo (GPO). Desde abril de 2023, Windows LAPS viene integrado en el sistema (Windows 10/11 y Windows Server actualizados) y en Microsoft Entra. Es el que hay que usar en despliegues nuevos.

# --- Consultar y auditar LAPS (todo lectura) ---
Import-Module LAPS
 
# Recuperar la contrasena actual de un equipo (queda registrado en el log)
Get-LapsADPassword -Identity 'PC-CONTABILIDAD-07' -AsPlainText
 
# Ver tambien el historial y la fecha de expiracion prevista
Get-LapsADPassword -Identity 'PC-CONTABILIDAD-07' -IncludeHistory
 
# Diagnostico local: por que este equipo no esta rotando la contrasena
Get-LapsDiagnostics
 
# Eventos de LAPS en el propio equipo
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20

3. Credential Guard: aislar los secretos de LSASS

Credential Guard usa la seguridad basada en virtualización (VBS): el hipervisor de Windows crea un entorno aislado (modo seguro virtual, VTL1) donde se ejecuta una versión reducida de LSA llamada LSAIso. Los secretos sensibles viven ahí dentro, y el LSASS normal —el que un atacante puede volcar— solo maneja referencias, no los secretos en claro. Volcar la memoria de LSASS deja de servir para hacer pass-the-hash o pass-the-ticket.

3.1 Qué protege y qué no

En resumen: Credential Guard sube mucho el coste de robar credenciales ya presentes en un equipo, pero no impide que un atacante capture nuevas credenciales que se usen mientras él está dentro, ni sustituye a la segmentación ni al modelo de niveles (tiering) de Active Directory.

3.2 Requisitos e incompatibilidades

• Requisitos: CPU de 64 bits con virtualización y SLAT, arranque UEFI con Secure Boot, y edición Enterprise/Education (o Server). En Windows 11 Enterprise 22H2 y posteriores viene activado por defecto en hardware compatible; TPM 2.0 es muy recomendable para anclar las claves
• Incompatibilidades: controladores de kernel antiguos que no cumplen los requisitos de VBS, algunos clientes VPN y suplicantes Wi-Fi heredados que dependen de NTLMv1 o de CredSSP sin restringir, y software de virtualización anidada mal soportado
• Antes de desplegar: pasa la herramienta DG Readiness de Microsoft y prueba en una OU piloto con equipos representativos; algunos fallos de SSO solo aparecen con aplicaciones concretas

# --- Verificar Credential Guard (lectura) ---
$dg = Get-CimInstance -ClassName Win32_DeviceGuard `
        -Namespace 'root\Microsoft\Windows\DeviceGuard'
 
# SecurityServicesConfigured: lo que pide la politica (1 = Credential Guard)
# SecurityServicesRunning:    lo que esta activo de verdad ahora mismo
$dg.SecurityServicesConfigured
$dg.SecurityServicesRunning
$dg.VirtualizationBasedSecurityStatus   # 2 = habilitada y en ejecucion
 
# Alternativa rapida: msinfo32 -> 'Seguridad basada en virtualizacion'
#   y el campo 'Servicios configurados / en ejecucion'

4. Protected Users, Authentication Policies y Silos

Estos controles no aíslan memoria: cambian las reglas de autenticación de las cuentas con poder para que dejen rastro corto y no se puedan reutilizar lejos de donde deben usarse.

4.1 El grupo Protected Users

Meter una cuenta en el grupo de seguridad Protected Users (dominio en nivel funcional 2012 R2 o superior) le impone, sin configurar nada más:

• No puede autenticar con NTLM, solo Kerberos
• Kerberos no usa cifrado DES ni RC4, solo AES
• No se le aplica la delegación Kerberos (ni restringida ni sin restringir)
• No se cachea su verificador de credenciales en el equipo: si el controlador de dominio no está accesible, no hay inicio de sesión offline
• Su TGT dura como máximo 4 horas en lugar de 10, así que una credencial robada caduca antes

4.2 Authentication Policies y Authentication Silos

Una Authentication Policy define condiciones sobre la emisión del TGT de una cuenta: duración máxima y, sobre todo, desde qué equipos se le permite autenticar (mediante notificaciones de control de acceso dinámico). Un Authentication Silo agrupa usuarios, equipos y cuentas de servicio de confianza y les aplica una política común.

Combinados, consiguen que la credencial de un administrador de dominio robada en un portátil cualquiera no sirva para nada: el controlador de dominio se niega a emitirle un TGT si la petición no viene de un equipo autorizado del silo.

5. RDP sin dejar credenciales en el equipo remoto

Una conexión de Escritorio remoto interactiva normal envía tus credenciales al equipo de destino y las deja en su memoria mientras dura la sesión. Si te conectas por RDP a un servidor comprometido con una cuenta privilegiada, acabas de entregar esa cuenta. Hay dos modos que lo evitan:

Remote Credential Guard es la opción preferente para administración interactiva dentro del dominio. Restricted Admin encaja en flujos concretos y automatizados, sabiendo que traslada el riesgo en lugar de eliminarlo. Ambos se activan por directiva en cliente y servidor, y en el cliente se invoca con `mstsc /remoteGuard` o `mstsc /restrictedAdmin`.

6. Higiene complementaria

• Deshabilitar WDigest: `UseLogonCredential = 0` en `HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest`. Desde 2014 ya viene así por defecto, pero conviene comprobarlo y forzarlo por GPO
• Reducir credenciales en caché: `CachedLogonsCount` a un valor bajo (p. ej. 2) en equipos que casi siempre tienen línea con el dominio; en portátiles de teletrabajo hay que equilibrarlo con el inicio de sesión offline
• LSASS como proceso protegido (`RunAsPPL = 1`): impide que procesos sin la firma adecuada abran LSASS; combínalo con la regla ASR «Bloquear el robo de credenciales del subsistema de autoridad de seguridad local»
• Restricción de NTLM: auditar primero el tráfico NTLM entrante y saliente y luego bloquear por excepciones, para empujar todo hacia Kerberos
• Modelo de niveles (tiering): no iniciar sesión nunca con cuentas de Tier 0 en equipos de Tier 1 o Tier 2; es la medida que hace que todo lo anterior tenga sentido

# --- Comprobaciones de higiene de credenciales (lectura) ---
 
# WDigest: UseLogonCredential debe ser 0 o no existir
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' `
    -Name UseLogonCredential -ErrorAction SilentlyContinue
 
# LSASS protegido: RunAsPPL debe ser 1 (o 2)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL
 
# Numero de inicios de sesion en cache
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' `
    -Name CachedLogonsCount
 
# Pertenencia al grupo Protected Users
Get-ADGroupMember 'Protected Users' | Select-Object name, objectClass

7. Verificar que está activo de verdad

Configurar un control por GPO no garantiza que esté funcionando en el equipo: puede faltar un requisito de hardware, un reinicio o la aplicación efectiva de la directiva. Comprueba siempre el estado en ejecución, no solo el configurado.

Conclusión

El robo de credenciales en Windows se ataca por capas. Windows LAPS elimina la contrasena local compartida que convierte un equipo comprometido en cien. Credential Guard encierra los secretos de LSASS donde un volcado de memoria ya no los alcanza. Protected Users, las Authentication Policies y los Silos hacen que una credencial privilegiada robada caduque pronto y no sirva fuera de los equipos donde debe usarse. Y Remote Credential Guard evita sembrar credenciales cada vez que alguien administra un servidor por RDP.

Ninguno de estos controles es completo por si solo, y ninguno sustituye al modelo de niveles de Active Directory: son las piezas que hacen que ese modelo aguante cuando un puesto cae. Despliegalos por anillos, con cuentas de emergencia, y verifica siempre el estado en ejecucion — configurado no es lo mismo que activo.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)