凭据不再直接躺在 LSASS 里
Windows 登录后，口令哈希与 Kerberos 票据等凭据由 LSASS 进程管理，历史上大量攻击工具通过读取 LSASS 内存直接拿走凭据，再用它在内网横向移动。Credential Guard 借助虚拟化安全（VBS）把这类机密放进受隔离的虚拟化环境，普通内核代码无法读取，从而让抓 LSASS 的手法失效。它需要硬件与固件支持（虚拟化扩展、安全启动等），因此部署前要先评估兼容性。
基本信息
| 加固项 | 凭据隔离保护 |
|---|---|
| 适用平台 | Windows 10/11 企业版、Windows Server 2016 及以上（需 VBS 支持） |
| 权限要求 | 本地管理员或域管理员 |
| 达标判据 | 运行状态包含凭据保护服务，即 SecurityServicesRunning 含 1 |
| 依赖条件 | CPU 虚拟化、UEFI 安全启动、与该机虚拟化软件兼容 |
典型使用场景
- 高价值服务器与特权管理终端的横向移动防护
- 等保与内部基线对凭据保护条款的取证
- 红队评估中发现 LSASS 抓取可利用后的整改
- 新建终端标准镜像中固化配置
- 域内分批推广时核查各机型是否真正启用、而非仅配置
核查运行状态
核查运行状态
Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus
# SecurityServicesRunning 包含 1 表示凭据保护正在运行
# 2 表示内存完整性（HVCI）在运行；两者都启用时值为 1 和 2
Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning
msinfo32 # 图形界面中也可在“系统摘要 → 基于虚拟化的安全性”查看启用（注册表方式，需重启）
启用（注册表方式，需重启）
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 1 /f
shutdown /r /t 0 # 必须重启，重启后再用 Win32_DeviceGuard 复核字段与取值读法
| 字段或取值 | 含义 | 判读 |
|---|---|---|
| SecurityServicesConfigured | 策略上配置了哪些服务 | 有值只说明配了，不代表在跑 |
| SecurityServicesRunning | 实际正在运行的服务 | 含 1 才算凭据保护真正生效 |
| 1 | Credential Guard | 本项的达标标志 |
| 2 | 内存完整性（HVCI） | 常与凭据保护一起启用 |
| LsaCfgFlags=1 / =2 | 带 UEFI 锁启用 / 不带锁启用 | 带锁无法远程关闭，按组织策略选择 |
| VirtualizationBasedSecurityStatus | VBS 运行状态 | 未运行说明硬件或固件条件不满足 |
只配置未运行是最常见的情况：SecurityServicesRunning 为空时通常是因为缺少 UEFI 安全启动、虚拟化被其他软件占用或机型不支持。这类机器需要先解决前置条件，而不是反复下发注册表。生产推广应先在测试 OU 验证兼容性，确认业务软件与虚拟化方案不受影响再分批启用。
启用方式有两种语义：带 UEFI 锁的配置无法通过远程注册表关闭，安全性更高但灵活性低；不带锁的配置便于集中管理但也能被本地高权限用户关闭。选择哪种取决于组织对终端管控能力与远程运维需求的权衡，选定后要在基线文档里写明。