明文凭据为什么留得住
WDigest 是 Windows 上的 HTTP 摘要式认证凭据提供者。当 UseLogonCredential 为 1 时，交互登录的明文口令会被缓存在 LSASS 进程内存中，攻击者只要拿到本地管理员权限，用常见的凭据抓取工具就能直接读出明文口令。Windows Server 2012 R2 及之后的版本在安装相应更新后默认不再缓存，但历史上被优化工具改动过的机器仍需显式确认并写回 0。
基本信息
| 适用平台 | Windows Server 2012 R2 及以后、Windows 8.1 及以后 |
|---|---|
| 注册表路径 | HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest |
| 值名与类型 | UseLogonCredential（DWORD） |
| 风险等级 | 高 |
| 基线 | UseLogonCredential = 0（缺失表示未设置，应显式写入） |
典型使用场景
- 存量服务器核查：确认是否仍有机器缓存明文口令
- 域内统一加固：通过组策略一次性下发到所有成员机
- 应急响应：怀疑凭据泄漏时，先确认内存中是否存在明文
- 基线固化：把该值与 LSA 保护、Credential Guard 一起纳入清单
- 应用兼容评估：旧版 Exchange 或 IIS 集成认证可能依赖 WDigest
核查与显式关闭
核查与显式关闭
$k='HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
Get-ItemProperty $k -Name UseLogonCredential -ErrorAction SilentlyContinue # 无输出=未设置
Set-ItemProperty $k -Name UseLogonCredential -Value 0 -Type DWord
reg query $k /v UseLogonCredential # 复核写入结果
Get-CimInstance Win32_DeviceGuard | Select-Object SecurityServicesRunning # 1=Credential Guard 运行中
# 域内建议用 GPO 下发：计算机配置 → 管理模板 → 系统 → 凭据分配取值读法
| 状态 | 含义 | 正常与异常 |
|---|---|---|
| 值不存在 | 依赖系统默认行为 | 新版默认不缓存，但不等于已显式加固 |
| UseLogonCredential=1 | 明文口令缓存在 LSASS | 高危，必须改为 0 |
| UseLogonCredential=0 | 不再缓存明文口令 | 基线要求值 |
| 生效时机 | 下一次登录会话 | 改完需重新登录才生效 |
| SecurityServicesRunning 含 1 | Credential Guard 已运行 | 现代系统的主防线之一 |
依赖 WDigest 的老应用（部分旧版本 Exchange、IIS 集成认证）在关闭后可能认证失败：升级前核对应用清单，先在测试环境验证。
落地要点
- 未设置不等于 0：防御性基线要显式写入值，避免默认行为在版本升级中变化
- 域内优先用 GPO 下发，本地逐台改容易漏掉新入域机器
- 与 LSA 保护、Credential Guard 配套：单靠这一项不足以解决凭据窃取
- 变更后重新登录并复核注册表值，确认未被其它策略改回
- 把该核查写进主机基线报告，作为凭据保护项的证据
即使关闭了明文缓存，凭据哈希仍可能驻留内存：Credential Guard 与限制本地管理员登录范围才是更根本的缓解。