攻防视角分析Kerberos票据窃取与横向移动

微软近期公布了一项分阶段计划，将在Windows环境中默认禁用NTLM身份验证。这并非突如其来的决定。长期以来，NTLM因其结构性设计缺陷，一直容易遭受中继攻击、凭据拦截，尤其是哈希传递攻击。它依赖于静态的密码哈希，攻击者无需知晓原始密码即可重放哈希，使得NTLM一旦失守，便成为攻击者理想的跳板。

随着微软计划在2026年前逐步推出更新，他们正全面转向使用Kerberos作为主要身份验证机制。Kerberos在设计上更为健壮，它依赖基于时间的票据、双向验证和更强的加密原语。然而，任何复杂的协议都难以避免自身弱点，Kerberos也不例外。今天，我们将从攻与防的双重视角来探讨这一转变。

传统上，攻击者主要依赖NTLM哈希传递在域内进行横向移动。一旦某个加域系统被攻陷，例如遭受ProxyShell攻击的Exchange服务器，攻击者通常能获得SYSTEM权限。随后，提取凭据就变得相当容易，在许多情况下，攻击者甚至能获取到域管理员账户的NTLM哈希。至此，攻击实质上已接近成功，因为哈希本身即可用于身份验证，无需去破解冗长或复杂的明文密码。

只有当账户被置于“受保护用户”组时，这种方法才会失效，因为该组会阻止凭据材料被缓存到内存中。随着NTLM的逐步淘汰以及LSASS安全性的加强，情况正在发生变化。攻击者正在适应，而防御者则需要了解他们如何应对。本文的目标是探讨攻击者如何转向基于Kerberos的技术，以及同样重要的——防御者如何阻止横向移动或在攻击早期就将其阻断。

将NTLM哈希转换为Kerberos票据（哈希传递/密钥传递）

当NTLM身份验证在加固域中被禁用或严格限制时，攻击者通常会尝试利用NTLM衍生材料转向Kerberos身份验证。其中一种经典攻击手法是哈希传递（Pass-the-Hash，也称为密钥传递 Pass-the-Key）。在此场景下，攻击者获取NTLM哈希，并使用该哈希直接从域控制器请求有效的Kerberos票据授予票据。

诸如Impacket的getTGT.py或Rubeus之类的工具常被用于此目的。NTLM哈希，尤其是其中的NT部分，可用作Kerberos预认证中使用的RC4-HMAC密钥。攻击者通过构造Kerberos AS-REQ请求并使用此密钥加密时间戳，有时能诱使密钥分发中心（KDC）颁发有效的TGT。随后，该票据可存储在.ccache或.kirbi文件中，并加载到环境中，重复用于针对CIFS、HOST或HTTP等服务的票据传递攻击，整个过程无需知晓明文密码。

getTGT.py DOMAIN/username@DOMAIN.FQDN -hashes F6C8F436E90DE59B6B93809D36CFA80C:F6C8F436E90DE59B6B93809D36CFA80C -dc-ip

然而，有一项重要限制改变了这种攻击的可行性。微软已于2026年1月13日开始发布Kerberos RC4加固更新，并分阶段实施强制模式（启用强制模式的更新计划于2026年4月开始，审核移除强制模式则于2026年7月开始实施）。在此变更下，域控制器将为未显式设置msDS-SupportedEncryptionTypes的账户默认使用AES-SHA1作为加密类型。这将阻止为这些账户颁发RC4密钥，除非服务账户明确允许RC4。简而言之，当KDC或账户拒绝RC4密钥时，依赖使用NT哈希作为RC4密钥的哈希传递（密钥传递）攻击将难以实施。

像Rubeus和Impacket这样的工具虽然可以从哈希请求TGT，但仅当KDC接受请求的加密类型（RC4）或攻击者已拥有账户的AES密钥时，请求才会成功。仅凭NTLM哈希无法生成AES TGT。因此，攻击者更可能转向其他技术（例如从内存中窃取票据、使用银票/金票、滥用S4U等），或者寻找特定账户上未修复的明确RC4授权。

从防御角度看，通过域控制器事件日志审核Kerberos加密类型、重置高权限账户密码以重新生成AES密钥，以及在GPO和账户属性中强制执行仅使用AES的策略，可以显著缩小攻击面。监控异常的TGT请求，特别是使用已弃用加密类型的请求，有助于及早发现入侵迹象。AdminDroid和Microsoft Defender for Identity等工具能有效突出显示攻击者可能依赖的旧式身份验证模式。

内存转储与凭证提取

转储LSASS进程已成为最广为人知的凭证窃取技术之一。多年来，这非常简单：攻击者只需在任务管理器中对LSASS进程右键单击并选择“创建转储文件”，或使用Procdump等工具提取凭证。但这已成为过去式。

现代的Defender和EDR解决方案会积极监控对LSASS的访问。即使是合法的进程转储尝试也会被标记和阻止。任何直接针对LSASS的操作通常默认被视为恶意，攻击者深知这一点。因此，除非系统完全未被监控，否则针对单个进程的转储操作会产生大量噪音，且往往失败。

攻击者正越来越多地转向获取完整内存。通过捕获系统的全部物理内存，他们避免了以可疑方式直接与LSASS交互。这种方法更耗时费力，因为转储文件大小约等于系统安装的RAM容量。传输转储文件可能需要相当长时间，具体取决于网络状况，但对于有耐心的攻击者来说，这往往是值得的。

一旦获取内存镜像，像Volatility这样的工具便可发挥作用。较新的Volatility插件专门针对Kerberos工件，允许攻击者列出会话、从内存中提取票据并将其导出为.kirbi格式。这些插件通常底层依赖于Impacket，并且在Credential Guard未启用时有效。

这种方法还依赖于合法的取证工具，因此更加危险。Belkasoft、FTK Imager和DumpIt等受信任产品被允许执行完整的内存采集，这模糊了取证调查与凭证窃取之间的界限，使得检测更为困难。

提取这些票据的过程如下：

vol -p /home/kali/volatility-kerberos -s /home/kali/volatility-kerberos -f data.lime kerberos.Dump --address 0x2af64e5b930 --output /tmp

提取后，.kirbi文件可以转换为与Hashcat兼容的格式以尝试恢复明文密码，或者可以直接注入用于横向移动。即使不进行破解，有效的票据通常也足以提供必要的访问权限，从而扩大对域的控制。

从防御角度，目标不仅是阻止内存获取，还要使任何提取的痕迹变得无用。启用Windows凭据保护是目前最有效的保护措施之一。但请注意，凭据保护无法阻止键盘记录器捕获凭据、管理员安装的新SSP，或从其他可访问的凭据存储中提取凭据。

对LSASS强制执行受保护的轻量级进程（PPL）并启用Defender攻击面缩减规则，可进一步限制未经授权的内存访问。缩短Kerberos票据的有效期可降低被盗票据的价值，而将高权限账户置于“受保护用户”组则可强制执行更强的加密并禁止委派。当这些措施到位时，攻击者往往被迫采用更加复杂且风险更高的攻击手段。

PsMapExec与Kerberos票据滥用

我们在之前的文章中介绍过PsMapExec，因此不再赘述其基础。本文的重点在于，即使检测技术不断进步，攻击者仍然依赖基于PowerShell的工具。PsMapExec是一个PowerShell脚本，与大多数公开可用的攻击工具一样，一旦以原始形式加载就容易被标记。经验丰富的攻击者很少直接从GitHub使用工具，而是会修改和混淆它们，在保留功能的同时规避基于特征码的检测。许多攻击脚本严重依赖原生Windows API，由于这些底层调用是合法的，检测通常依赖于静态签名、关键字或已知的入侵指标，导致了持续的猫鼠游戏。

在大规模环境中，找到一台未启用防病毒或EDR的机器虽然不容易，但几乎总是可能的。遗留系统、配置错误的服务器和被忽视的基础设施组件仍然存在。在实际攻击中，有时甚至到了2025年，你仍会发现像Windows Server 2003这样的系统在运行。这些系统本身可能价值有限，但它们常常成为攻击的跳板。一旦攻击者获得对未监控机器的GUI访问权限，他们的选择将大大增加。PsMapExec允许攻击者根据具体场景，在本地或远程提取Kerberos票据，无论是否需要凭据。

关于PsMapExec的完整使用指南已在其他文章中介绍。本文旨在说明攻击者还可以提取Kerberos票据并有效地利用它们进行横向移动。加载脚本后，他们通常会使用以下选项。

要从当前主机获取Kerberos票据：

PS > PsMapExec -Method smb -Targets localhost -Module “KerbDump” -ShowOutput

如何从远程主机获取Kerberos票据（无需在当前会话中使用凭据）：

PS > PsMapExec -Method smb -Targets DC -Module “KerbDump” -ShowOutput

要使用凭据从远程主机获取Kerberos票据：

PS > PsMapExec -Method smb -Targets DC -Username “user” -Password “password” -Module “KerbDump” -ShowOutput

加载完成后，脚本会解析结果，分配变量，并方便地重复使用提取的材料来执行命令和进行横向移动。

以下是一个使用先前提取的Kerberos票据，以最高权限在域控制器上执行命令的示例：

PS > PsMapExec -Target DC -Method smb -Ticket $variable -Command “whoami; hostname”

脚本会将票据存储在单独的文件夹中。

防御者可以通过启用AMSI和完整的PowerShell脚本块日志记录来应对，这可以暴露可疑模块、编码载荷和内存执行。通过受限语言模式、AppLocker或WDAC来限制PowerShell的使用，可以显著提高攻击难度。最重要的是，积极修补和隔离遗留系统可以消除攻击者可能依赖的立足点。

其他工具与防御考量

像AutoPt这样的工具展示了攻击者在EDR因驱动程序漏洞而被禁用后，能够多么迅速地进行调整。它能枚举Kerberos票据并执行票据传递攻击，是Rubeus或Mimikatz的轻量级替代方案。

在渗透测试中，发现未受保护的Windows服务器远比发现未受保护的用户工作站更为常见。这更加危险，因为服务器通常由高价值用户访问，并且经常托管具有提升权限的服务账户。虽然将账户添加到“受保护用户”组可以降低风险，但许多服务账户和应用程序身份在代表用户访问资源（例如连接到数据库或文件服务器的后端服务）时，必须合法地模拟用户身份。过度保护这些账户可能会破坏身份验证工作流，但放任不管则会使它们成为Kerberos滥用的主要目标。由于服务账户通常拥有广泛权限，因此降低其暴露程度并严格限制其Kerberos票据的使用范围至关重要。

总结

弃用NTLM协议并不会终结横向移动，但它改变了攻击的性质。随着微软移除弱默认设置和旧版回退方案，攻击者将无法再依赖快速、可重用的哈希，而必须深入了解Kerberos协议。现代攻击越来越依赖于票据行为和配置漏洞，而非简单的凭据重用。

对防御者而言，这种转变是一个机遇。基于Kerberos的攻击更难实施，并且在防护完善的环境中会留下更多痕迹。强大的默认设置、持续的安全加固以及对凭证材料的保护将有效限制攻击者的选择。

如果你对这类数字取证与攻防技术感兴趣，欢迎来云栈社区交流讨论，这里聚集了许多安全研究与实践者。