WDigest habilitado: por qué las credenciales en texto claro reaparecen en LSASS

¿Qué significa 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.

Cómo funciona

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.

La cadena de ataque

Paso 1 - Obtener admin local o SYSTEM 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.

Por eso este problema suele aparecer junto a Kerberoasting: cómo los atacantes crackean contraseñas de cuentas de servicio y AS-REP Roasting: recopilando hashes sin credenciales. Los atacantes encadenan oportunidades de credenciales. Si un host entrega secretos reutilizables, el resto del ataque sale más barato.

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 la credencial robada 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.

Detección

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.

# 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. Una sola excepción en el host equivocado puede echar por tierra buena parte de un trabajo de hardening de credenciales por lo demás sólido.

Remediation

Una remediación limpia suele ser corta:

1. Inventariar dónde UseLogonCredential está habilitado. Empiece por estaciones administrativas, jump hosts y servidores sensibles.
2. Desactivar el ajuste. En sistemas compatibles, establezca UseLogonCredential en 0 o vuelva al estado por defecto de la baseline moderna.
3. 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.
4. Proteger identidades de alto valor. Use Protected Users cuando sea operativo para cuentas privilegiadas.
5. 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

Si su entorno todavía tiene scripts de baseline antiguos o plantillas de hardening posteriores al build, revíselos con cuidado. WDigest a veces vuelve no por diseño, sino por un script olvidado que alguien copió hace años para «arreglar» un problema de aplicación. Por eso el estado del registro, la baseline de build y la dependencia real de producción deben revisarse juntos.

Valide el cambio antes de darlo por cerrado

La secuencia de validación más segura es simple: confirme el estado del registro en sistemas representativos, confirme que el flujo de aplicación de riesgo sigue funcionando si existe una dependencia de negocio real, y confirme que su stack de detección lanzará una señal si alguien reactiva UseLogonCredential más adelante. Este es exactamente el tipo de control que parece trivial hasta que un incidente demuestra que fue deshecho en silencio seis meses antes.

También conviene validar el lado identidad. Si sus 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. Por eso este hallazgo pertenece a una revisión de acceso privilegiado más amplia, no solo a una checklist de hardening de estaciones de trabajo.

Por qué las excepciones de WDigest vuelven a aparecer

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é automatización 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. Por eso también son útiles como lectura complementaria Cómo auditar la seguridad de Active Directory: guía práctica para equipos internos y Supervisión de seguridad de Active Directory: eventos que importan: ayudan a conectar una debilidad de registro local con la pregunta más amplia de dónde viven realmente las credenciales privilegiadas.

Cómo lo detecta EtcSec

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.

Referencias oficiales

• Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
• Microsoft Support article for the UseLogonCredential policy and WDigest credential storage behavior
• Microsoft protocol documentation for supplementalCredentials and Primary:WDigest

Lecturas relacionadas

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 Supervisió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.