WindowsServer安全之启用CredentialGuard防范凭据窃取

Windows Server 管理员最怕的场景之一，不是服务器宕机，而是服务器还在正常运行，但域控权限已经被偷走了。现代高级持续性威胁（APT）和勒索软件攻击，几乎都绕不开一个核心步骤：凭据窃取。攻击者通过抓取内存中的 NTLM 哈希、Kerberos TGT 票据或明文密码，完成横向移动，最终拿下整个域。微软从 Windows 10 和 Windows Server 2016 开始，提供了一项基于虚拟化的安全功能 Credential Guard，专门用来解决这个问题。它不是一个需要复杂部署的第三方产品，而是系统内置的、可以彻底阻断常见凭据抓取工具的防线。

要理解 Credential Guard 的价值，必须先知道凭据在没保护的情况下存放在哪里。Windows 的本地安全机构子系统服务（LSASS.exe）负责处理用户的身份验证。当用户通过密码或智能卡登录后，LSASS 进程会在内存中缓存凭据的哈希值或票据，以便后续访问网络资源时进行单点登录。Mimikatz 这类工具之所以出名，就是因为它们能直接读取 LSASS 进程的内存空间，从中提取出明文密码、NTLM 哈希和 Kerberos 票据。传统防御手段，比如杀毒软件或 EDR，往往在攻击者加载驱动或注入代码时才能检测，而一旦攻击者使用白名单工具或内核级漏洞，这些检测很容易被绕过。问题的根源在于，LSASS 进程运行在常规操作系统内核之上，一旦内核被攻破，内存数据就毫无秘密可言。

Credential Guard 不依赖特征码检测，而是从架构上把凭据挪走。它利用 Hyper-V 的虚拟机监控程序（Hypervisor）创建一个独立、轻量级的虚拟安全模式（VSM）。在这个模式下，系统内存被物理隔离出一个安全区，普通操作系统内核甚至管理员都无法访问。Credential Guard 将原本存储在 LSASS 中的凭据，交给运行在 VSM 内的一个专用组件——隔离的 LSA 进程（LSAIso.exe）来保管。当系统需要验证凭据时，LSASS 不再直接持有哈希，而是通过 RPC 调用向隔离区发起请求。这样一来，即使攻击者拿到了 SYSTEM 权限，用 Mimikatz 抓取 LSASS 内存，也只能看到加密的票据或空值，拿不到真正的 NTLM 哈希。这种隔离是硬件级的，依赖 CPU 的虚拟化扩展（Intel VT-x 或 AMD-V）和二级地址转换（SLAT），性能开销极低，但对凭据的保护效果是革命性的。

不是所有服务器都能直接开启 Credential Guard。首先，服务器必须支持并开启 CPU 虚拟化技术，包括 Intel VT-x 和 EPT，或者 AMD-V 和 NPT。其次，系统固件需要支持 UEFI 2.3.1 或更高版本，并且开启安全启动。此外，还需要 TPM 2.0 模块，虽然在某些测试场景下可以跳过 TPM 检查，但生产环境强烈建议配备。操作系统方面，Windows Server 2016 及以上版本原生支持，但不同版本的功能完整度有差异。Windows Server 2019 和 2022 对 Credential Guard 的支持更完善，特别是在域控场景下的兼容性更好。还需要注意，如果服务器上运行了与虚拟化技术冲突的第三方虚拟化平台或旧版驱动，可能会导致启动失败或功能降级。

对于物理服务器，推荐通过组策略或直接修改注册表来启用。最稳妥的方式是使用组策略对象（GPO）。在域控上打开组策略管理，找到目标服务器的 OU，创建一个新的 GPO。导航到计算机配置 -> 管理模板 -> 系统 -> Device Guard。双击“打开基于虚拟化的安全性”，选择“已启用”。在“基于虚拟化的安全保护”下拉框中，选择“启用 Credential Guard”。下方的“安全启动配置”和“直接内存访问保护”可以根据硬件情况勾选。策略刷新后重启服务器即可生效。

如果无法使用组策略，也可以直接修改注册表。在目标服务器上以管理员身份运行以下命令：

reg add "HKLM\System\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "LsaCfgFlags" /t REG_DWORD /d 2 /f

LsaCfgFlags 的值设为 2 表示启用 Credential Guard，设为 1 表示启用但禁用 Credential Guard，设为 0 表示关闭。重启后，可以通过在 PowerShell 中运行 Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard 来验证状态，SecurityServicesRunning 字段应包含 1。

对于 Hyper-V 虚拟机，需要在虚拟机设置里先启用嵌套虚拟化。在宿主机的 PowerShell 中运行：

Set-VMProcessor -VMName "你的虚拟机名称" -ExposeVirtualizationExtensions $true

同时确保虚拟机使用的是第二代固件，并启用了安全启动模板。VMware vSphere 环境则需要虚拟机硬件版本 11 以上，在虚拟机选项里勾选“向客户机公开硬件辅助的虚拟化”和“启用基于虚拟化的安全”。需要注意的是，嵌套虚拟化会带来一定的性能损耗，在评估时需要纳入考量。

部署完成后，不能只看服务状态，必须实测防护效果。最简单的方法是直接运行 Mimikatz 或类似工具，在未启用 Credential Guard 前，privilege::debug 后 sekurlsa::logonpasswords 可以轻松导出明文密码和 NTLM 哈希。启用后，同样的操作只能看到加密的凭据或显示“null”。另一个验证方法是检查任务管理器，会发现多出一个 LSAIso.exe 进程，这是隔离 LSA 在运行。还可以在事件查看器中导航到“应用程序和服务日志” -> Microsoft -> Windows -> DeviceGuard，查看操作事件，确认虚拟化安全已成功启动。如果发现 SecurityServicesConfigured 和 SecurityServicesRunning 值不一致，通常意味着硬件不支持或策略冲突，需要排查 UEFI 和虚拟化设置。

域控制器是凭据窃取的重灾区，但启用 Credential Guard 需要额外谨慎。Windows Server 2016 域控上，Credential Guard 与某些角色服务存在兼容性问题，特别是与“企业根 CA”或“NDES”服务共存的场景。在 Windows Server 2019 及更高版本，微软已解决大部分冲突。域控启用后，Kerberos 票据的加密和解密都转移到 VSM 中完成，这会导致一些旧版第三方认证软件或自定义凭据提供程序失效。如果环境中存在使用非微软 Kerberos 实现的 Linux 客户端或旧版网络设备，需要先在测试环境验证 NTLM 回退是否正常。另一个常见问题是，域控上的备份软件如果依赖卷影复制服务直接读取系统状态，可能会因为无法访问隔离的凭据而备份失败。建议在启用前，详细阅读微软的“Credential Guard 与域服务”文档，并在维护窗口内操作，保留回滚路径。

客观地说，Credential Guard 不是万能药。它主要防御的是凭据从 LSASS 内存中被窃取，但不能防止攻击者使用窃取到的 Kerberos 票据进行传递票据攻击。如果攻击者已经通过其他方式拿到了有效的 TGT 或服务票据，仍然可以在票据有效期内横向移动。此外，Credential Guard 不保护存储在 SAM 数据库中的本地账户凭据，也不保护缓存在浏览器或 RDP 客户端中的密码。如果管理员在服务器上勾选了“记住密码”，这些凭据仍可能被工具提取。还有一个容易被忽略的点：Credential Guard 依赖虚拟化安全，如果攻击者能够利用 CPU 漏洞绕过虚拟化隔离，理论上可以突破防护，不过这种攻击成本极高，目前仅存在于学术研究领域。理解这些局限，才能更合理地分层部署防御。

远程桌面会话是凭据泄露的重灾区。管理员通过 RDP 连接到服务器时，默认情况下密码哈希和 Kerberos 票据会缓存在目标服务器的内存中，这就是“凭据中继”攻击的温床。Windows Defender Remote Credential Guard 是 Credential Guard 的延伸，它确保在建立 RDP 会话时，凭据不发送到目标主机，而是保持在客户端本地。启用方式很简单，在客户端机器上配置组策略“限制向远程服务器委派凭据”为“需要 Remote Credential Guard”，或者在 RDP 文件里添加一行 enablecredsspsupport:i:0 并配合 remoteguard 参数。两者协同后，即使目标服务器被完全控制，攻击者也无法从内存中抓取到管理员的域凭据。这对于管理特权访问工作站和跳板机环境尤为重要。

在生产环境启用前，务必评估所有运行在服务器上的应用程序和驱动。特别是使用内核模式驱动的安全软件、旧版 VPN 客户端、以及某些系统管理代理。可以通过运行微软提供的 Device Guard 和 Credential Guard 硬件准备工具来检查兼容性。命令行为：

.\DG_Readiness_Tool_v3.6.ps1 -Capable -CG

如果输出报告显示“Capable”但“Not Ready”，需要根据日志排查 UEFI 锁定或 TPM 状态。回滚方案很简单，将组策略或注册表中的 LsaCfgFlags 值改回 0，重启服务器即可。需要注意的是，从启用到关闭的过程中，LSASS 不会重新缓存历史凭据，所有已登录用户的凭据在重启后会正常清理，不存在遗留风险。

Credential Guard 是 Windows Server 安全体系里性价比极高的一项配置。它不需要额外授权费用，不依赖云端服务，不产生明显性能开销，却能从根本上阻断一大类凭据窃取工具。在勒索软件和定向攻击盛行的当下，部署这一功能应该是服务器加固清单里的高优先级事项。与其在入侵发生后紧急响应，不如提前把凭据锁进虚拟化的保险箱里。