Inicios de sesión en caché, WDigest y credenciales expuestas

Credential Guard y la protección LSA endurecen cómo protege Windows los secretos que guarda. Esta guía trata de cuántos guarda, para empezar. Un puñado de configuraciones decide si una máquina comprometida entrega una contraseña en texto claro, un hash descifrable de cada usuario de dominio reciente o contraseñas guardadas de recursos compartidos y aplicaciones web. La mayoría se pueden cambiar sin coste y rompen muy poco cuando sabes qué vigilar.

Todo lo que aquí se describe se aplica también a los dispositivos donde Credential Guard no puede ejecutarse: hardware antiguo, VM sin virtualización anidada y controladores de dominio. Es la base de la serie Protección de credenciales.

Qué guarda Windows y dónde

Paso 1: reducir los inicios de sesión en caché

Cuando un usuario de dominio inicia sesión de forma interactiva, Windows guarda un verificador para que ese mismo usuario pueda iniciar sesión más tarde sin un controlador de dominio. El valor predeterminado conserva los 10 últimos usuarios. En un puesto compartido o en un servidor, eso es una lista de todos los técnicos de soporte y administradores recientes, cada uno con un hash que se puede descifrar sin conexión.

La configuración es Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Number of previous logons to cache (in case domain controller is not available). Escribe CachedLogonsCount (un REG_SZ, no un DWORD) en HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

Las líneas base de seguridad de Microsoft no configuran este valor; la propia documentación de Microsoft indica 0 como contramedida y sugiere 2 para los equipos de usuario final y móviles, y los CIS Benchmarks recomiendan 4 o menos. Elige el valor más bajo con el que puedan vivir tus usuarios y prueba un portátil desconectándolo de todas las redes e iniciando sesión.

Dos puntos relacionados:

• Los miembros de Protected Users nunca dejan un verificador en caché, otra razón más para poner a los administradores humanos en ese grupo (consulta modelo por niveles y Protected Users).
• Bajar el valor no borra de inmediato los verificadores existentes. Las entradas se sobrescriben a medida que inician sesión nuevos usuarios. En los servidores donde ya existen verificadores de administradores, el valor 0 detiene el almacenamiento en caché nuevo; planifica la rotación de las contraseñas de las cuentas privilegiadas que quedaron en caché en máquinas de baja confianza.

Paso 2: fijar WDigest como desactivado

WDigest es un antiguo paquete de autenticación HTTP/SASL que necesitaba la contraseña en texto claro del usuario en memoria. Desde Windows 8.1 y Windows Server 2012 R2 ya no guarda el texto claro de forma predeterminada, pero el comportamiento sigue dependiendo de un único valor del registro que un atacante con derechos de administrador puede cambiar:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
Value: UseLogonCredential  (REG_DWORD) = 0

En cuanto vale 1, cada inicio de sesión interactivo posterior coloca la contraseña en texto claro en la memoria de LSASS, lista para que herramientas como Mimikatz la lean. Es un paso de persistencia muy conocido en las intrusiones: cambiar el valor, bloquear la pantalla y esperar a que el usuario la desbloquee.

Establécelo explícitamente en 0 en lugar de fiarte del valor predeterminado. El archivo SecGuide.admx del Security Compliance Toolkit lo expone como WDigest Authentication (disabling may require KB2871997) en Computer Configuration > Policies > Administrative Templates > MS Security Guide; establécelo en Disabled. La referencia a la KB solo importa para Windows 7 y Server 2008 R2. Microsoft retiró esta configuración de la línea base de seguridad de Windows 11 24H2 porque la directiva quedó en desuso con esa versión, así que en las compilaciones actuales también puedes imponer el valor del registro directamente con Group Policy Preferences o Intune, y seguir supervisándolo en cualquier caso.

Credential Guard también impide que Digest use credenciales guardadas, pero un 0 impuesto por directiva protege las máquinas donde no se ejecuta.

Paso 3: borrar las credenciales tras cerrar sesión

Cuando un usuario cierra sesión, LSASS puede conservar sus credenciales en memoria un tiempo si quedan identificadores abiertos a la sesión de inicio. Windows 8.1 y posteriores las borran a los 30 segundos. El valor es:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: TokenLeakDetectDelaySecs  (REG_DWORD) = 30

En las versiones actuales de Windows este es el comportamiento integrado, así que establecerlo sirve sobre todo para evitar que alguien lo aumente. La línea base de seguridad de Microsoft no lo exige; establécelo donde tu estándar de endurecimiento o tu auditoría lo pidan y déjalo en 30 segundos.

Ten en cuenta que solo afecta a las sesiones cerradas. Una cuenta privilegiada que sigue conectada a un servidor por RDP permanece en memoria mientras la sesión exista. Establece límites de tiempo para las sesiones RDP y cierra las sesiones desconectadas, como se explica en endurecimiento de RDP.

Paso 4: dejar de guardar contraseñas de red

Credential Manager almacena las contraseñas que los usuarios (o las aplicaciones) deciden guardar: unidades asignadas con "Recordar mis credenciales", conexiones RDP, Outlook, algunas aplicaciones de negocio. Están protegidas por DPAPI con la clave del usuario, lo que significa que cualquier código que se ejecute como el usuario puede descifrarlas.

Comprueba qué hay guardado en un dispositivo para el usuario actual:

cmdkey /list
vaultcmd /listcreds:"Windows Credentials" /all

La directiva Network access: Do not allow storage of passwords and credentials for network authentication (Security Options) establece DisableDomainCreds = 1 en HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Con ella habilitada, Windows deja de guardar en Credential Manager credenciales de dominio para la autenticación de red.

Esta requiere pruebas, y por eso muchas líneas base la dejan para los niveles de alta seguridad:

• Las tareas programadas configuradas con Run whether user is logged on or not y una contraseña almacenada dejan de funcionar. Conviértelas para que se ejecuten como SYSTEM, como gMSA o como una cuenta de servicio administrada en otro lugar.
• Las credenciales guardadas de RDP y de unidades asignadas dejan de persistir. Se vuelve a pedir la contraseña a los usuarios, que suele ser el resultado buscado.

Habilítala primero en los servidores y en las estaciones de trabajo de acceso privilegiado, donde las credenciales de dominio guardadas son más peligrosas y las tareas programadas son más fáciles de inventariar. Para RDP en concreto, habilita también Do not allow passwords to be saved en Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client.

Paso 5: aplicarlo por script y comprobarlo

Para obtener una referencia rápida en una sola máquina o mediante un script de corrección:

$lsa = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
[pscustomobject]@{
  CachedLogonsCount        = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon").CachedLogonsCount
  UseLogonCredential       = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -ErrorAction SilentlyContinue).UseLogonCredential
  TokenLeakDetectDelaySecs = (Get-ItemProperty $lsa).TokenLeakDetectDelaySecs
  DisableDomainCreds       = (Get-ItemProperty $lsa).DisableDomainCreds
  NoLMHash                 = (Get-ItemProperty $lsa).NoLMHash
}

Impón los valores mediante directiva de grupo o Intune en lugar de por script, para que se vuelvan a aplicar si algo los cambia. En Intune, las opciones de Security Options están en el catálogo de configuración en Local Policies Security Options; para los valores sin configuración nativa, sirve un OMA-URI personalizado con un ADMX ingerido o un script de corrección.

Qué se rompe

• El inicio de sesión sin conexión en portátiles si los inicios de sesión en caché se establecen en 0.
• Las tareas programadas con contraseñas almacenadas y las credenciales guardadas una vez habilitado DisableDomainCreds.
• Aplicaciones muy antiguas que usan autenticación HTTP Digest con el inicio de sesión único de Windows. Son raras; pedirán una contraseña.

Verificarlo

1. Inicios de sesión en caché en uso. El evento de seguridad 4624 con Logon Type 11 (CachedInteractive) indica que un usuario inició sesión con un verificador en caché. En los servidores no debería aparecer nunca una vez que el valor sea 0.
2. Manipulación de WDigest. Genera alertas ante escrituras en UseLogonCredential con el evento 13 de Sysmon o con la auditoría del registro (evento de seguridad 4657, que necesita una SACL en la clave). Cualquier cambio a 1 es un indicador de compromiso de alta confianza.
3. Contenido de Credential Manager. Ejecuta la comprobación cmdkey /list en una muestra de servidores y estaciones de administración tras habilitar DisableDomainCreds; las entradas de dominio guardadas deberían desaparecer cuando los usuarios se vuelvan a autenticar.
4. Informe del parque. Recoge de forma centralizada la salida del script del paso 5 y haz seguimiento de los dispositivos fuera de tu estándar.

Lista de comprobación

• Inicios de sesión en caché: 0 en servidores y quioscos, de 1 a 2 en portátiles
• Cuentas de administración humanas en Protected Users para que nunca queden en caché
• UseLogonCredential a 0 de forma explícita por directiva, con alertas ante cambios
• TokenLeakDetectDelaySecs a 30 donde tu estándar lo exija
• DisableDomainCreds habilitado en servidores y PAW, tareas programadas convertidas
• Cliente RDP sin permiso para guardar contraseñas
• Evento 4624 con tipo de inicio de sesión 11 revisado en los servidores

Ninguna de estas configuraciones es espectacular, pero juntas reducen la cantidad de material reutilizable en cada máquina. Combinadas con la supervisión de WDigest y con Credential Guard, dejan a un atacante mucho menos que recoger.