哈希传递攻击（Pass-the-Hash，简称PtH）是内网渗透中最古老、最致命的技术之一。攻击者一旦窃取了高权限账户的NTLM哈希值，根本不需要破解明文密码，就能直接拿着这段哈希值在域内横向移动，拿下域控制器。微软推出Credential Guard，本质上就是要在操作系统内核层面建立一个硬件隔离的安全区域，把凭据锁死，让攻击者连哈希的影子都摸不到。
要理解Credential Guard如何防御哈希传递，得先看清攻击者是怎么拿到哈希的。Windows系统为了减少用户反复输入密码的麻烦，会把凭据缓存在本地安全认证子系统服务（LSASS）的内存中。Mimikatz这类工具之所以横行多年，就是因为它能直接读取LSASS进程的内存，把里面缓存的明文密码、NTLM哈希、Kerberos票据全部拖出来。只要管理员在一台机器上登录过，这台机器的LSASS内存里就存着他的凭据，攻击者拿下一台普通终端，就能提取出域管理员的哈希，然后横行整个域。
传统的防御手段，比如强制管理员使用单独的干净主机、定期修改密码、开启防火墙，都绕不开一个根本问题：LSASS进程本身运行在操作系统内核的同一个信任边界内。一旦内核被攻破，或者攻击者获得了足够的权限，LSASS内存就是一块待宰的肥肉。Credential Guard的破局思路很直接——把凭据从操作系统的信任边界里彻底剥离出去。
Credential Guard的核心架构：虚拟化安全模式Credential Guard依赖Windows的虚拟化安全模式（Virtualization-Based Security，简称VBS）。VBS利用Hyper-V的虚拟机管理程序，在物理内存中划出一块完全独立的区域，称为安全内核（Secure Kernel）。这个安全内核运行在一个比操作系统内核更高的特权级别上，操作系统本身无法直接访问这块内存区域，即使操作系统内核被完全攻破，攻击者也读不到安全内核里的数据。
具体到凭据保护，Credential Guard在VBS的安全内存中创建了一个独立的进程，叫做隔离的LSA进程（Isolated LSA，简称LSAIso）。原本存储在LSASS进程中的NTLM哈希、Kerberos票据授予票据、长期凭据等敏感数据，现在全部被转移到LSAIso进程中。正常的LSASS进程仍然负责处理认证请求，但它不再持有凭据本身，而是通过远程过程调用向LSAIso进程请求签名或解密操作。LSAIso进程相当于一个凭据保险箱，只对外提供有限的操作接口，绝不暴露原始凭据数据。
这套架构带来的安全效果是立竿见影的。攻击者即使拿到了SYSTEM权限，用Mimikatz读取LSASS内存，也只能看到一堆无用的加密指针或者占位符数据，真正的哈希值躲在VBS隔离区里，操作系统内核都碰不到，更别说用户态工具了。这就是Credential Guard防御哈希传递攻击的根本原理：让哈希变得不可提取，攻击者连哈希都拿不到，哈希传递攻击自然无从谈起。
启用Credential Guard的硬件与软件前提Credential Guard不是装个补丁就能开的，它对硬件有明确要求。首先，CPU必须支持虚拟化技术，Intel的VT-x和AMD的AMD-V是基础。其次，CPU还需要支持二级地址转换（SLAT），Intel叫EPT，AMD叫RVI，这是VBS实现内存隔离的硬件基础。第三，系统固件必须是UEFI 2.3.1以上版本，并且开启了安全启动，传统BIOS模式无法使用Credential Guard。第四，TPM不是强制要求，但如果要配合BitLocker使用，TPM 1.2或2.0是必要的。最后，CPU还需要支持I/O内存管理单元（IOMMU），Intel的VT-d或AMD的AMD-Vi，用于防止DMA攻击绕过内存隔离。
操作系统方面，Credential Guard在Windows 10 Enterprise、Education、Pro for Workstation以及Windows 11的对应版本中可用。Windows Server 2016及以后版本也支持。Pro版Windows 10在较新的版本中也逐步开放了Credential Guard功能。需要注意的是，启用Credential Guard后，某些第三方认证方式可能不兼容，比如某些旧的VPN客户端、网络负载均衡服务，以及那些直接与LSASS交互的安全软件。
通过组策略启用Credential Guard在域环境中，最标准的方式是通过组策略批量启用。打开组策略管理控制台，定位到“计算机配置” -> “管理模板” -> “系统” -> “Device Guard”。找到“打开基于虚拟化的安全”策略，将其设置为“已启用”。在“选项”部分，将“基于虚拟化的安全保护级别”设置为“安全启动和DMA保护”。在“凭据保护配置”下拉框中，选择“使用UEFI锁启用”。UEFI锁选项会把Credential Guard的配置写入固件，防止攻击者通过修改注册表或启动配置来绕过保护。配置完成后，需要重启客户端，系统会在启动过程中自动配置VBS和LSAIso进程。
单机环境下的启用方法对于没有加入域的独立主机，可以使用Windows安全中心或者直接修改注册表来启用。打开Windows安全中心，进入“设备安全性” -> “内核隔离详细信息”，开启“内存完整性”和“固件保护”。内存完整性是VBS的一个子功能，开启后会自动启用VBS基础架构。但要完整启用Credential Guard，还需要额外配置。
更直接的方式是使用注册表。以管理员身份打开命令提示符，执行以下命令：
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 3 /f reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "LsaCfgFlags" /t REG_DWORD /d 2 /f
第一条命令启用VBS，第二条要求安全启动和DMA保护，第三条将LsaCfgFlags设置为2表示启用Credential Guard并使用UEFI锁。设置完成后重启系统。重启后，可以打开系统信息工具，在“系统摘要”中查看“基于虚拟化的安全性”状态，如果显示“正在运行”，并且“要求的基于虚拟化的安全性属性”中包含“凭据保护”，就说明Credential Guard已经成功运行。
验证Credential Guard是否真正生效配置完成后，光看系统信息还不够，需要实际验证凭据是否真的被隔离保护。最简单的方法是直接运行Mimikatz，以SYSTEM权限执行经典的sekurlsa::logonpasswords命令。在启用Credential Guard的机器上，这条命令返回的NTLM哈希字段会显示为全零或者完全不可见，只会留下一串无意义的占位符。如果还能看到完整的哈希值，说明Credential Guard没有正常工作。
另一个验证方法是使用PowerShell查看LSAIso进程的运行状态。执行以下命令：
Get-Process -Name "lsaiso"
如果返回一个进程信息，说明隔离的LSA进程正在运行。还可以通过事件查看器检查Credential Guard的启动日志，在“应用程序和服务日志” -> “Microsoft” -> “Windows” -> “DeviceGuard”下，查找事件ID 7000和7001，这些事件记录了VBS和Credential Guard的初始化状态。
Credential Guard的防护边界与局限性任何安全机制都有边界，Credential Guard也不例外。它主要防护的是从LSASS内存中直接提取凭据的攻击方式，但攻击者仍然可以通过其他途径获取凭据。比如，如果攻击者在目标机器上安装了键盘记录器，在用户输入密码时就截获了明文，那Credential Guard也无能为力。另外，Kerberos票据虽然被LSAIso保护，但攻击者仍然可以从网络流量中抓取票据，或者利用委派配置不当进行攻击。
还有一个值得注意的细节：Credential Guard默认不保护域缓存的凭据，也就是所谓的MSV和TSPkg凭据。如果系统配置了允许在无网络连接时使用缓存的域凭据登录，这些缓存凭据仍然可能被提取。要启用对缓存凭据的保护，需要额外配置组策略，在“计算机配置” -> “管理模板” -> “系统” -> “登录”中，启用“在重新启动时清除缓存的凭据”，并结合Credential Guard的完整保护模式。
Credential Guard与虚拟机环境也存在兼容性问题。在VMware Workstation或VirtualBox中运行Windows时，由于这些虚拟化软件本身已经占用了一部分虚拟化特性，再嵌套启用VBS会导致性能严重下降或者根本无法启动。生产环境中，如果要保护虚拟化服务器上的Windows虚拟机，需要宿主机支持嵌套虚拟化，并且在虚拟机配置中暴露硬件虚拟化特性。
Credential Guard与其他安全机制的协同Credential Guard不是孤立的安全方案，它需要与Windows Defender远程凭据保护、LSA保护、攻击面减少规则等机制协同工作。远程凭据保护可以防止凭据在远程桌面会话中被传递到不受信任的客户端。LSA保护通过将LSASS进程标记为受保护进程，防止非微软签名的代码注入。攻击面减少规则可以阻止Mimikatz这类工具的执行。多层防御叠加起来，才能构建起真正难以突破的凭据安全防线。
对于高价值目标，比如域控制器、跳板机、特权访问工作站，Credential Guard应该作为基线安全配置强制执行。结合本地管理员密码解决方案（LAPS）定期轮换本地管理员密码，以及特权访问管理（PAM）实现即时权限授予，可以大幅压缩攻击者在内网横向移动的空间。哈希传递攻击之所以可怕，是因为它利用了认证协议本身的特性，而Credential Guard从操作系统底层切断了凭据泄露的源头，这是目前最有效的技术对抗手段。
部署Credential Guard确实会带来一些兼容性挑战和性能开销，但相比凭据泄露后整个域被拿下的灾难性后果，这些代价是完全值得的。安全团队应该尽快评估当前环境中的硬件支持情况，制定分阶段的部署计划，优先保护暴露面最大的终端和服务器，把哈希传递攻击从威胁清单中彻底划掉。
