What Is WDigest habilitado?
WDigest habilitado significa que un sistema vuelve a almacenar material de autenticación reutilizable relacionado con WDigest en LSASS, cuando el objetivo defensivo debería ser reducir la cantidad de secretos aprovechables en memoria. La guía de Microsoft alrededor del Security Advisory 2871997 buscaba precisamente reducir el robo de credenciales en sistemas Windows unidos al dominio. Uno de los endurecimientos más prácticos de esa guía consiste en asegurarse de que UseLogonCredential no reactive el almacenamiento de secretos WDigest en memoria.
El riesgo importa porque WDigest no es solo una nota histórica de protocolo. La documentación técnica de Microsoft explica que supplementalCredentials puede contener Primary:WDigest, descrito como hashes criptográficos de la contraseña en texto claro para el protocolo Digest. Si un equipo vuelve a habilitar el almacenamiento WDigest en un host, aumenta la probabilidad de que una intrusión local exponga credenciales reutilizables que no deberían estar presentes en LSASS.
Por eso WDigest habilitado debe revisarse junto con Seguridad de contraseñas en Active Directory: configuraciones erróneas que sí importan, Contraseñas en campos de descripción de AD: detección y limpieza y Cuentas obsoletas y con privilegios excesivos en Active Directory. En los tres casos, el problema no es solo una configuración débil, sino que material de autenticación reutilizable sea más fácil de robar y volver a usar de lo que la organización cree.
How WDigest habilitado Works
Microsoft documenta UseLogonCredential bajo la ruta WDigest como el control que evita que WDigest guarde credenciales en memoria. Cuando ese ajuste se reactiva, el material de autenticación vuelve a quedar disponible para código que pueda alcanzar LSASS con privilegios suficientes.
La lógica de hardening es sencilla:
- si el almacenamiento WDigest está deshabilitado, un atacante con compromiso local debe encontrar otros secretos reutilizables
- si el almacenamiento WDigest está habilitado, el host ofrece una superficie de robo de credenciales más atractiva de lo necesario
El Advisory 2871997 de Microsoft también destaca el grupo Protected Users. Sus miembros no pueden autenticarse con NTLM, Digest Authentication ni CredSSP, y sus contraseñas no se manejan igual en sistemas compatibles. Esto no sustituye desactivar WDigest, pero persigue el mismo objetivo: reducir la cantidad de material reutilizable disponible tras una intrusión local.
| Estado | Significado operativo | Por qué importa |
|---|---|---|
UseLogonCredential ausente o deshabilitado | WDigest no conserva secretos reutilizables en memoria | Menor superficie LSASS |
UseLogonCredential habilitado | Material relacionado con WDigest vuelve a almacenarse | El robo de credenciales es más fácil |
| Protected Users para admins sensibles | NTLM, Digest y CredSSP quedan restringidos | Se reducen rutas de reutilización para identidades críticas |
The Attack Chain
Paso 1 - Obtener privilegios locales elevados en un host Windows
WDigest habilitado no suele ser el vector inicial. Se vuelve peligroso cuando el atacante ya tiene admin local, SYSTEM o ejecución equivalente en una máquina. A partir de ahí, la diferencia entre un host endurecido y uno débil es cuántos secretos reutilizables siguen viviendo en LSASS.
Paso 2 - Volcar LSASS y recuperar credenciales útiles
Cuando el ajuste está habilitado, el atacante no necesita que todo el entorno esté roto. Le basta con un host donde el compromiso local pueda convertirse en acceso a credenciales.
# Comprobación defensiva del ajuste WDigest
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential
Para un equipo azul, lo importante no es la herramienta concreta de volcado, sino el hecho de que el host almacene más material reutilizable del necesario.
Paso 3 - Reutilizar el secreto en sistemas cercanos
Si la credencial robada pertenece a un admin privilegiado, a un operador de helpdesk o a una cuenta de servicio con mucho alcance, el atacante puede moverse rápidamente hacia más equipos o hacia rutas de escalado AD. Por eso WDigest habilitado rara vez es un hallazgo aislado: amplifica la gravedad de otros errores de control de acceso.
La misma lógica aparece en Rutas de ataque de Active Directory hacia Domain Admin: cualquier ajuste que convierta un host comprometido en una fuente de credenciales reutilizables acorta el camino hacia objetivos más críticos.
Detection
No hace falta intuición para detectar esta exposición. Microsoft ya proporciona el punto de control clave: el valor de registro UseLogonCredential. Una revisión seria también debería verificar si los admins más sensibles siguen fuera de Protected Users y si la telemetría detectaría con rapidez cambios en el registro o accesos sospechosos a LSASS.
| Indicador | Fuente | Qué comprobar |
|---|---|---|
UseLogonCredential habilitado | Revisión de registro | ¿Se está reactivando explícitamente el almacenamiento WDigest? |
| Faltan controles del Advisory 2871997 | Revisión de baseline y parches | ¿Los hosts antiguos se endurecieron realmente? |
| Admins sensibles fuera de Protected Users | Revisión del grupo AD | ¿Las identidades críticas siguen usando rutas más débiles? |
| Alertas de LSASS o del registro | EDR, auditoría de registro, detecciones de credential theft | ¿Se vería rápido una reactivación o un acceso sospechoso? |
# Comprobación rápida de WDigest en un host
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
# Revisar si cuentas sensibles pertenecen a Protected Users
Get-ADGroupMember 'Protected Users'
La comprobación de registro es la validación más rápida, pero no debería ser la única. En una revisión de incidente conviene confirmar si el ajuste aparece en estaciones administrativas, jump servers o servidores donde inician sesión identidades de alto valor.
Por qué este ajuste vuelve una y otra vez
WDigest rara vez vuelve porque un equipo quiera conscientemente menos protección. Más a menudo reaparece por hábitos de troubleshooting: un ingeniero reutiliza un workaround antiguo, una gold image conserva el valor o un script de soporte se ejecuta años después sin revisar si la dependencia original sigue existiendo. Ese patrón cambia la revisión necesaria. La pregunta no es solo “¿está la clave puesta?”, sino “¿qué baseline, qué script o qué owner la sigue reintroduciendo?”.
En entornos maduros, la revisión debe incluir estaciones admin, jump hosts y cualquier tier de servidor donde se conecten cuentas privilegiadas. Si el ajuste está limpio en workstations normales pero sigue activo donde viven las credenciales más valiosas, el riesgo residual continúa siendo alto.
Remediation
💡 Quick Win: si un host no tiene una dependencia justificada de almacenamiento WDigest, desactívelo y confirme que la configuración no reaparece a través de una baseline antigua, una imagen base o un script de soporte.
Una remediación limpia suele ser corta:
- Inventariar dónde
UseLogonCredentialestá habilitado. Empiece por estaciones administrativas, jump hosts y servidores sensibles. - Desactivar el ajuste.
En sistemas compatibles, establezca
UseLogonCredentialen0o vuelva al estado por defecto de la baseline moderna. - Revisar dependencias legacy. Si un equipo afirma necesitar WDigest, exija un flujo de aplicación concreto y un plan de retirada de la excepción.
- Proteger identidades de alto valor. Use Protected Users cuando sea operativo para cuentas privilegiadas.
- Vigilar la deriva. Genere alertas sobre cambios en la ruta de registro WDigest y accesos sospechosos a LSASS.
# Ejemplo de remediación local en un host Windows
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0
Validate Before You Close the Finding
La medida no debería darse por cerrada solo porque el valor se puso a 0 una vez. Valide el estado del registro en sistemas representativos, confirme que un supuesto flujo crítico sigue funcionando si existe una dependencia legítima y asegúrese de que su stack de detección avisaría si UseLogonCredential se reactivara más adelante. Este es exactamente el tipo de control que parece trivial hasta que un incidente demuestra que alguien lo deshizo meses antes.
También conviene revisar el lado identidad. Si los admins privilegiados siguen iniciando sesión en superficies demasiado amplias y no cuentan con protecciones más fuertes, una sola excepción WDigest puede pesar mucho más de lo esperado.
Dónde revisar primero la deriva de WDigest
La revisión de WDigest debería empezar por los sistemas donde realmente inician sesión identidades de alto valor. La documentación de soporte de Microsoft sobre el endurecimiento de credenciales deja claro que el comportamiento por defecto cambia según la generación de Windows. En Windows 7, Windows Server 2008 R2, Windows 8 y Windows Server 2012, UseLogonCredential sigue en 1 por defecto tras la actualización si la organización no lo fuerza a 0. En cambio, en Windows 8.1, Windows Server 2012 R2 y versiones posteriores, el almacenamiento WDigest queda deshabilitado por defecto cuando la entrada de registro no existe. Esa diferencia explica por qué imágenes antiguas, scripts heredados o baselines de soporte siguen reintroduciendo el riesgo.
En la práctica conviene revisar por separado estaciones administrativas, jump hosts y servidores donde se realizan inicios de sesión privilegiados. Si el build moderno está limpio pero una imagen legacy usada para administración vuelve a escribir UseLogonCredential=1, el riesgo real permanece concentrado justo en los hosts con las credenciales más valiosas.
Otro control útil es comparar la baseline documentada, la pipeline de imagen y el estado local real de los equipos en producción. Cuando esas tres fuentes no describen el mismo valor, el problema suele ser organizativo más que técnico. Identificar qué script, qué excepción o qué artefacto de build vuelve a introducir la clave suele ser la parte más importante de la remediación.
La revisión también debe alinearse con la guía de Microsoft sobre Protected Users. Ese grupo no corrige WDigest por sí solo, pero Microsoft sí especifica que sus miembros no pueden autenticarse con NTLM, Digest Authentication ni CredSSP. Revisar WDigest sin analizar dónde se conectan las cuentas privilegiadas y si ya disfrutan de esa protección suele dejar fuera la parte más relevante del riesgo.
How EtcSec Detects This
EtcSec asocia este tema directamente con WDIGEST_ENABLED. La pregunta útil no es solo si la clave existe en algún punto, sino si los hosts que más importan siguen reteniendo material reutilizable en LSASS y si la excepción tiene un propietario claro.
ℹ️ Note: EtcSec detecta automáticamente almacenamiento de credenciales WDigest en revisiones de Active Directory para ayudar a priorizar los sistemas donde una intrusión local expondría identidades de alto valor.
Official References
- Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
- Microsoft Support article for
UseLogonCredentialand WDigest credential storage behavior - Microsoft protocol documentation for
supplementalCredentialsandPrimary:WDigest
Related Reading
Revise este tema junto con Seguridad de contraseñas en Active Directory: configuraciones erróneas que sí importan, Contraseñas en campos de descripción de AD: detección y limpieza, Cuentas obsoletas y con privilegios excesivos en Active Directory, Cómo auditar la seguridad de Active Directory: guía práctica para equipos internos y Monitorización de seguridad de Active Directory: eventos que importan. Estos temas ayudan a conectar una clave de registro local con la cuestión más amplia de qué credenciales reutilizables siguen vivas en el entorno.
