在企业内网攻防中，攻击者拿到一台机器后往往会尝试从 LSASS 进程内存里抓取明文密码或哈希，进而横向渗透。Windows 提供的 Credential Guard 与 Remote Credential Guard 正是为了切断这条攻击链而设计的。前者在本地把凭据锁进虚拟化安全边界，后者让远程桌面连接不再把凭据暴露给远端系统。理解它们的启用方式，是终端安全加固的基本功。
一、Credential Guard 与 Remote Credential Guard 的核心原理
Credential Guard 依赖 Windows 的基于虚拟化的安全（VBS）机制。系统在支持 UEFI 安全启动且开启 Hyper-V 特性的硬件上，会创建一个独立的安全内核与隔离环境，称为虚拟安全模式（VSM）。LSASS 进程中原本保存的明文凭据、NTLM 哈希与 Kerberos 密钥，会被转移到这个隔离环境中由 LSAIso 进程托管。普通操作系统层面的恶意代码即使以管理员权限运行，也无法读取 VSM 保护的内存区域，从而阻断了常见的 Mimikatz 式导出。
Remote Credential Guard 并不是在远端机器上单独跑一套隔离，而是复用本地已启用的 Credential Guard 能力。当你使用远程桌面连接开启该功能的远程主机时，本地的凭据并不会被发送到对端，而是将对端的身份验证请求重定向回本地 VSM 完成。这意味着即便远程主机被攻陷，攻击者也拿不到你的域凭据，因为凭据自始至终没有离开过本地受保护边界。
从依赖条件看，两者都要求设备支持并开启 VBS、UEFI 安全启动、以及 IOMMU（如 Intel VT-d 或 AMD-Vi）以防止 DMA 攻击。Remote Credential Guard 额外要求远程桌面客户端与服务器均为 Windows 10 或 Windows Server 2016 以上版本，且网络层面能建立回连通道。弄清楚这些前置条件，可以避免在老旧设备上反复折腾策略却始终不生效。
二、本地启用 Credential Guard 的几种实操路径
最直观的方式是通过组策略。在 gpedit.msc 中依次展开“计算机配置—管理模板—系统—基于虚拟化的安全”，将“基于虚拟化的安全”设为已启用，并在下方选项里勾选“凭据保护”下的“启用基于虚拟化的安全”。该方式适合域环境批量下发，重启后系统会自动配置 VBS 与隔离环境。需要注意的是，组策略生效前必须确认 BIOS 中已开启相关虚拟化与安全启动选项，否则策略会静默失败。
如果更偏好脚本化部署，可以使用 PowerShell 的 Device Guard 与 Hyper-V cmdlet。例如通过 Enable-WindowsOptionalFeature 开启 Hyper-V 与 VBS 相关功能，再借助注册表或 WMI 桥接器写入配置。下面是一段典型的启用脚本示例，它先确认硬件支持，再配置注册表键值并重启：
# 检查 VBS 与 Credential Guard 支持情况 Get-CimInstance -ClassName Win32_DeviceGuard -Namespace rootMicrosoftWindowsDeviceGuard | Select-Object AvailableSecurityProperties, SecurityProperties # 通过注册表启用 Credential Guard（需管理员权限） New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlDeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlDeviceGuardScenariosCredentialGuard" -Name "Enabled" -Value 1 -PropertyType DWORD -Force # 重启使配置生效 Restart-Computer -Force
与组策略相比，脚本方式更灵活，可嵌入到配置管理工具（如 SCCM、Ansible 的 Windows 模块）中做差异化下发。但脚本直接写注册表容易因键值遗漏导致部分功能未激活，因此生产环境建议仍以组策略为主，脚本仅用于排障或单机快速验证。启用完成后，可在系统信息（msinfo32）的“基于虚拟化的安全”一项中看到“正在运行”及“凭据保护”状态。
三、Remote Credential Guard 的启用与远程连接验证
Remote Credential Guard 的启用同样依赖本地 Credential Guard 已跑起来。在客户端上，除了前述本地保护开启外，还需在远程桌面客户端显式指定使用该模式。最常用的是命令行启动 mstsc 时附加参数，或通过 RDP 文件配置。下面示例展示了如何用 PowerShell 调用远程桌面并开启远程凭据保护：
# 使用 mstsc 指定远程凭据保护 # /remoteGuard 参数即开启 Remote Credential Guard Start-Process -FilePath "mstsc.exe" -ArgumentList "/v:192.168.0.1 /remoteGuard"
在组策略层面，也可通过“计算机配置—管理模板—Windows 组件—远程桌面服务—远程桌面连接客户端—远程桌面会话环境中”配置“使用远程凭据保护”为已启用，这样所有出站 RDP 都会默认携带该保护。远端服务器无需额外安装组件，只要系统版本达标便会接受这种重定向式认证。连接建立后，即便在远端用管理员权限执行凭据导出工具，也只能看到指向本地 VSM 的引用，而无法提取实际密钥。
验证是否真正生效，可在远端主机打开任务管理器或事件查看器，观察是否有凭据缓存落地。更严谨的做法是在本地运行 Get-CimInstance 查询 DeviceGuard 状态，并配合 RDP 会话日志确认协商的防护等级。如果远端系统版本过低或本地 VBS 未运行，客户端会回退到普通 RDP 并弹出提示，这时绝不能忽略警告强行连接，否则凭据保护预期将落空。
四、启用过程中的常见误区与排错思路
一个高频误区是认为只要打了补丁就能直接用 Credential Guard。实际上老旧 CPU 缺少必要的指令集或主板未开 IOMMU，会导致 VBS 无法初始化，此时策略看似生效，系统信息里却显示“未运行”。遇到这类情况，应先跑硬件兼容性检查，而不是反复重推组策略。另一个误区是在虚拟机里随意开启，却忘了宿主机也要暴露虚拟化扩展，否则嵌套虚拟化不支持 VSM。
排错时建议分层定位：先用 msinfo32 看大状态，再用 Get-CimInstance 拿明细，最后查事件日志里 Microsoft-Windows-DeviceGuard 的报错。Remote Credential Guard 连不上时，重点看两端系统版本与网络回连是否被防火墙阻断。很多企业因为禁止客户端主动出网，导致重定向验证失败，误以为功能损坏，其实是通道被拦。理清依赖链，才能把凭据保护稳稳落地。
综合来看，Credential Guard 与 Remote Credential Guard 是一套从本地到远程的凭据隔离方案。启用并不复杂，难在前期硬件准备与策略落地的一致性。把 VBS 地基打牢，选对批量配置通道，并在远程场景强制使用保护模式，就能有效缩小凭据泄露面，让横向移动攻击失去最关键的支点。
Credential_GuardRemote_Credential_GuardWindows安全修改时间：2026-08-14 04:42:33