Windows Credential Guard防窃

Windows Credential Guard 的本质是利用虚拟化安全（VBS）技术，将操作系统存储的域凭据、NTLM 哈希、Kerberos TGT 票据等核心机密，隔离在一个独立于操作系统内核的微型虚拟机中。这意味着，即便攻击者获得了 SYSTEM 最高权限，只要无法突破 Hyper-V 的隔离层，就拿不到明文密码或哈希值，从而彻底阻断“凭据窃取”这一横向移动的核心攻击路径。

在 Credential Guard 出现之前，Windows 的凭据保护主要依赖 LSASS 进程。本地安全机构子系统服务在内存中处理用户登录，必然要在内存中解密并暂存凭据。这就带来了一个致命问题：Mimikatz 这类工具只需注入 LSASS 进程，就能直接读取内存中的明文密码、哈希和票据。即便微软不断修补 LSASS 的访问权限，攻击者也发展出内存转储、进程克隆、DPAPI 解密等多种绕过手段。根本原因在于 LSASS 和攻击者运行在同一个操作系统层面，一旦内核被攻破，所有保护形同虚设。

启用 Credential Guard 后，系统会创建一个名为“Isolated LSA”的安全子系统，运行在一个独立的轻量级虚拟机中。这个隔离环境只暴露极少数经过严格验证的 RPC 接口给宿主操作系统。当用户登录时，宿主机的 LSASS 进程不再直接接触凭据，而是将认证请求转发给隔离的 LSA 处理。隔离环境内的 LSA 完成 NTLM 或 Kerberos 认证后，只返回认证结果，绝不返回原始凭据。整个过程中，宿主机的内存空间里永远不会出现明文密码或可用的哈希值。

要让 Credential Guard 正常运行，硬件必须支持虚拟化技术并开启相关特性。具体来说，需要 64 位处理器具备 Intel VT-x 或 AMD-V，同时开启 IOMMU 即输入输出内存管理单元，Intel 平台叫 VT-d，AMD 平台叫 AMD-Vi。此外，还需要支持 Second Level Address Translation 即二级地址转换，Intel 的 EPT 或 AMD 的 NPT。TPM 2.0 并非强制要求，但如果有 TPM，系统可以利用它来保护加密密钥，进一步增强安全性。固件必须使用 UEFI 2.3.1 或更高版本，并且关闭传统 BIOS 兼容模式。安全启动 Secure Boot 也必须启用，确保启动链不被篡改。

Credential Guard 从 Windows 10 企业版和教育版 1511 版本开始引入，后续在 Windows Server 2016 及更高版本中也得到支持。Windows 10 和 Windows 11 的专业版从 1709 版本开始也支持该功能，但部分管理工具和配置选项可能有所限制。如果使用的是家庭版，则无法启用此功能。Windows Server 2019 和 2022 默认在某些角色下自动启用，但建议手动验证状态。许可方面，只要操作系统版本支持，无需额外购买授权。

最直接的方法是通过组策略配置。在域环境中，打开组策略管理控制台，定位到目标组织单元，创建或编辑一条组策略对象。依次展开计算机配置、管理模板、系统、Device Guard。找到“打开基于虚拟化的安全”策略，将其设为“已启用”。在“Credential Guard 配置”下拉菜单中选择“使用 UEFI 锁启用”。UEFI 锁意味着配置会被写入固件，即使操作系统重装，只要不重置固件，Credential Guard 依然强制开启。如果只是测试，可以选择“启用但不使用 UEFI 锁”。配置完成后，在客户端执行 gpupdate /force 并重启计算机。

对于独立计算机，可以直接修改注册表。打开注册表编辑器，定位到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard。新建 DWORD 值 EnableVirtualizationBasedSecurity，设置为 1。再新建 DWORD 值 RequirePlatformSecurityFeatures，设置为 1 表示要求安全启动，设置为 3 表示同时要求安全启动和 DMA 保护。接着定位到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa，新建 DWORD 值 LsaCfgFlags。设为 1 表示启用但无 UEFI 锁，设为 2 表示启用并加 UEFI 锁。修改注册表后同样需要重启。

微软提供了一个图形化的配置工具，可以从微软下载中心获取 Windows Defender Application Control Wizard。运行后选择“基于虚拟化的安全”选项卡，勾选“Credential Guard”并选择锁定级别。该向导会自动检查硬件兼容性，生成可部署的配置文件或脚本。对于批量部署，可以将生成的配置导出为 XML，通过 SCCM 或 Intune 推送到终端。

重启后，打开系统信息工具 msinfo32，在“系统摘要”中查找“基于虚拟化的安全”项目。如果显示“正在运行”，且“Credential Guard”状态为“已启用”，说明配置成功。也可以以管理员身份运行 PowerShell，执行 Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard。输出结果中 SecurityServicesRunning 字段应包含 1，表示 Credential Guard 正在运行。还可以查看事件查看器中“应用程序和服务日志\Microsoft\Windows\DeviceGuard\Operational”日志，事件 ID 7000 表示服务已启动，7001 表示配置已应用。

Credential Guard 会与某些软件产生冲突。最典型的是第三方远程桌面工具和密码管理软件中依赖 WDigest 或 CredSSP 组件的部分功能。启用后，WDigest 协议被强制禁用，某些旧版应用程序的 SSO 单点登录可能失效。虚拟机软件如 VMware Workstation 或 VirtualBox 在启用 VBS 后可能无法运行 64 位客户机，因为它们自身需要硬件虚拟化资源。部分指纹识别器和智能卡驱动如果试图直接访问 LSASS 内存，也会出现兼容性问题。建议在部署前建立完整的应用兼容性测试清单。

Credential Guard 并非万能。如果攻击者能够物理接触设备，并且固件未锁定，理论上可以通过修改 UEFI 变量关闭 VBS。这就是为什么必须启用 UEFI 锁的原因。另外，Credential Guard 保护的是存储在设备上的凭据，如果攻击者在认证过程中拦截网络流量，例如通过 ARP 欺骗配合 NTLM 中继，依然可以横向移动。它也无法防御键盘记录器直接捕获用户输入的密码。更高级的攻击者可能尝试挖掘 Hyper-V 的零日漏洞来逃逸隔离环境，但这种攻击成本极高，一般仅见于针对高价值目标的 APT 行动。

域控制器上的情况更为复杂。传统域控制器必须存储所有域用户的凭据哈希以便进行 NTLM 认证，因此 Credential Guard 在域控制器上的行为与工作站不同。在 Windows Server 2016 及以后版本中，域控制器可以启用 Credential Guard，但隔离的 LSA 仍然需要访问凭据数据库。微软的设计是让隔离 LSA 持有加密密钥，而加密后的凭据数据存储在宿主机的数据库中。这样即使攻击者转储了数据库文件，没有隔离环境中的密钥也无法解密。不过这种保护强度略低于工作站场景，因为域控制器的服务特性决定了它必须能够访问凭据。

单靠 Credential Guard 不足以构建完整的安全体系。应当配合以下措施：启用 Windows Defender Firewall 并限制入站 SMB 和 RDP 访问，减少横向移动通道。部署 LAPS 本地管理员密码解决方案，确保每台计算机的本地管理员密码唯一且定期轮换。实施严格的域管理员分层管理，禁止域管理员账户登录普通工作站。启用攻击面减少规则，特别是阻止从 Office 应用创建子进程和阻止从电子邮件客户端创建可疑进程。配置 Windows Defender for Endpoint 的 EDR 功能，实时监测内存注入和凭据转储行为。这些措施与 Credential Guard 配合，能显著提高攻击者的突破成本。

Credential Guard 运行时会占用额外的系统资源。隔离的 LSA 虚拟机需要分配物理内存，通常占用约 128MB 到 256MB。CPU 开销主要来自认证过程中的上下文切换，但在日常使用中几乎无法察觉。真正需要注意的是，启用 VBS 后，部分设备的电池续航可能缩短约 5% 到 10%，因为处理器无法进入最深度的节能状态。对于服务器环境，建议在部署前进行基准性能测试，确保数据库或高并发应用不会受到明显影响。实测表明，绝大多数企业应用的性能损耗在 3% 以内。

如果配置后 Credential Guard 未能启动，首先检查安全启动状态。以管理员身份运行 PowerShell，执行 Confirm-SecureBootUEFI，返回 True 表示安全启动已启用。其次检查 Hyper-V 虚拟机监控程序是否正常运行，执行 Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor，状态应为 Enabled。如果系统是虚拟机，需要确认虚拟化嵌套已开启，并且虚拟机配置中已暴露虚拟化扩展。部分戴尔和惠普的商用机型需要在 BIOS 中手动开启“Virtualization Technology for Direct I/O”和“Trusted Execution”选项。如果问题依旧，尝试删除注册表中 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard 下的内容，然后重新应用配置。

微软正在将 Credential Guard 的保护理念扩展到云端。Azure AD 加入的 Windows 设备已经可以结合 Windows Hello 企业版，使用基于 TPM 绑定的密钥替代传统密码。在混合环境中，Kerberos 云信任和 FIDO2 安全密钥的普及，正在逐步减少对可窃取凭据的依赖。Windows 11 24H2 版本进一步强化了 VBS 的默认启用策略，符合硬件要求的设备会自动开启部分 VBS 功能。可以预见，凭据隔离将不再是可选项，而是操作系统的安全基线。企业现在部署 Credential Guard，不仅是为了防御当前威胁，更是在为未来的无密码架构打下基础。