在 Windows 11 24H2 中提取操作系统账户哈希

【翻译】Dump Hashes in Windows 11 24H2 

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

在这篇博客文章中，我将描述如何在 Windows 11 24H2 中从 lsass.exe 进程内存中读取密码哈希值。由于在撰写本文时，该版本仍然非常新，一些问题的出现是由于工具支持的缺乏，这些问题应该会在未来得到解决。然而，这篇文章也可能有助于为后续的 Windows 版本调整工具。

目录

• 绕过 LSA 保护
• 读取哈希值
• 凭证保护 (Credential Guard)
• 总结

我正在准备一个黑客演示。我想展示在渗透测试中通常会执行的几个标准任务。其中之一就是读取 lsass.exe 进程内存，即提取密码哈希值。我之前可能已经做过上百次了。但这次，它就是不工作。我花了几个晚上来隔离、调试和修复问题。这篇博客文章描述了我的方法。

所有问题的根源都在于 Windows 11 24H2。在撰写本文时，该版本仍然相对较新，工具对其支持并不完善。

此外，Windows 11 默认启用了几个安全措施：

• LSA 保护 (PPL 保护)
• 漏洞驱动程序阻止列表 (Vulnerable Driver Blocklist)（有趣的是，这并不是一个问题，这可能也是由于禁用了 Windows Defender）
• 凭证保护 (Credential Guard)（放在括号中是因为在我的虚拟机中由于缺乏硬件支持而未激活）

总的来说，这意味着我们需要绕过 LSA 保护。然而，漏洞驱动程序阻止列表应该会使这变得更加复杂（理论上）。

绕过 LSA 保护

简单来说，LSA 保护只是在 lsass.exe 进程上设置了一个标志，即使拥有 Local System 权限，也会阻止访问该进程的内存。经典的绕过方法是加载一个允许这种访问的漏洞内核驱动程序。它需要存在漏洞，因为这是唯一可以在其上下文中执行我自己的代码的方法。由于内核驱动程序需要签名，我不能直接编写自己的驱动程序。

这里有很多选择（另见 https://www.loldrivers.io/），但漏洞驱动程序阻止列表 (Vulnerable Driver Blocklist) 使我们的工作更加困难。它会阻止已知的漏洞驱动程序。

已经有一些现成的工具可以执行此攻击，例如 dellicious。这不是拼写错误；该工具之所以这样命名，是因为它利用了存在漏洞的 Dell 驱动程序。

现在我们遇到了一个问题。该工具不支持 Windows 11 24H2。幸运的是，这很容易修复。我们只需要找到我们 Windows 版本的内核偏移量并在代码中调整它们。

这可以通过 WinDBG 完成。打开 文件 > 附加到内核 > 本地，然后使用以下命令加载符号：

.symfix.reload

然后显示 EPROCESS 结构体（EPROCESS structure）：

dt nt!_EPROCESS

从输出中提取 UniqueProcessId、ActiveProcessLinks 和 SignatureLevel 的值：

+0x1d0 UniqueProcessId  : Ptr64 Void+0x1d8 ActiveProcessLinks : _LIST_ENTRY+0x5f8 SignatureLevel   : UChar

现在将这些偏移量插入到 dellicious 工具中。我在这个提交中完成了这个操作：https://github.com/VidraSec/dellicious/commit/56c82bb7a2901baafeb8056deb6f13d8ad24da91

完整的代码仓库可以在这里找到：https://github.com/VidraSec/dellicious/

目前还缺少存在漏洞的 Dell 驱动程序。这些驱动程序可以通过互联网搜索找到。重要提示： 在使用前应该先验证其哈希值。

PS> .dellicious.exe -p 856 -e 0 -d .driver[+] User provided pid: 856[+] User provided driver directory: .driver[+] Windows version found: 26100[+] Using offsets:        UniqueProcessIdOffset = 0x1d0        ActiveProcessLinkOffset = 0x1d8        SignatureLevelOffset = 0x5f8[+] Attempting driver install...[+] Driver installed![+] Device handle has been obtained @ \.DBUtil_2_5[+] Ntoskrnl base address: fffff805b9c00000[+] PsInitialSystemProcess address: ffffc102b46a0040[+] Target process address: ffffc102bbf61080[+] Current SignatureLevel, SectionSignatureLevel, Type, Audit, and Signer bits (plus 5 bytes): 40c00000000000[+] Writing flags back as: 40c00000000000[+] Done![+] Removing device[!] Clean exit! o7

很好，现在我们已成功绕过 PPL（Protected Process Light）保护，获得了对 lsass.exe 进程的访问权限。这意味着我们可以使用任务管理器（Task Manager）来创建内存转储文件。

读取哈希值

现在我们遇到了另一个问题。无论是 Mimikatz 还是 pypykatz 都无法解析该文件。这是由于解析机制的工作原理导致的。

1. 程序会搜索特定的字节序列，即"签名"（signature）
2. 从该内存位置，程序会找到指向 LogonSessionList 和 LogonSessionListCount 的指针
3. 这些指针告诉程序登录数据在文件中的位置

我是如何知道这些的？这要归功于这篇优秀的博客文章：https://www.praetorian.com/blog/inside-mimikatz-part2/

这些值都是硬编码的，并且在 Windows 11 24H2 中已经发生了变化。此外，逻辑也略有改变。要找到新的值，必须对 lsasrv.dll 进行反汇编（例如使用 Ghidra）。

因此，所有内容都需要针对 Windows 11 24H2 进行调整。由于我对这个主题的了解不够深入，我需要帮助并在 pypykatz 仓库中提交了一个 Issue。非常感谢 SkelSec 快速实现了新的逻辑！

使用当前版本的 pypykatz，我们现在可以从转储文件中提取凭证了。

pypykatz lsa minidump ./dump.DMP== LogonSession ==authentication_id 278102 (43e56)session_id 1username highprivdomainname WIN11logon_server WIN11logon_time 2025-02-27T11:44:50.975151+00:00sid S-1-5-21-800810350-130866625-3627431900-1001...

Credential Guard（凭据保护）

在我的案例中，Credential Guard 并未启用。然而，如果它处于激活状态，我将收到一个加密的 blob 而不是 NT 哈希值。要绕过 Credential Guard，还需要额外的一个步骤。我推荐阅读这篇博客文章以获取更多信息：https://research.ifcr.dk/pass-the-challenge-defeating-windows-defender-credential-guard-31a892eee22

总结

很容易说所有这些安全功能都是无用的，因为它们可以被绕过。但在我看来，这种观点过于简单化了。

如果没有这些额外的安全措施，读取哈希值将变得极其容易。我花费了数小时，并且需要大量的专业知识才能完成。

因此：是的，所有安全功能都应该启用。但没有系统是 100% 安全的。我们只能尽可能提高攻击者的攻击难度。