Windows 域里的幽灵钥匙：Pass-the-Hash 攻击
你可能以为密码泄露后改掉密码就万事大吉，但在 Windows 域环境中，事情没那么简单。NTLM 认证协议的核心流程是：客户端把密码算一遍 NTLM Hash，再结合服务器发来的随机 Challenge 做运算，最后发回 Response 供服务器验证。问题出在这里——整个认证链路上，明文密码从来没出现过。服务器存的是 Hash，客户端用来证明身份的也只是 Hash 派生出来的值。换句话说，如果你拿到了一台机器上的 NTLM Hash（比如从 LSASS 内存里 dump 出来，或者从 SAM 数据库提取），你根本不需要还原明文密码，直接拿着这个 Hash 就能伪装成对应用户，去认证域内其他机器。这就是 Pass-the-Hash，一种在域渗透中被广泛使用的横向移动手法，Mimikatz 一行命令就能做到。
这种攻击之所以有效，根源在于 NTLM 协议把 Hash 当作了"等同于密码"的凭证。Kerberos 在一定程度上缓解了这个问题——TGT 的颁发需要密码的密钥派生值，窃取 Hash 后还需要额外步骤才能拿到 TGT（这就衍生出了 Overpass-the-Hash / Pass-the-Key 等变体）。但只要域内还有服务接受 NTLM 认证，Hash 就是通行证。防御思路很直接：启用 Credential Guard 把密钥隔离到 VBS 安全容器、限制本地管理员权限减少 Hash 暴露面、用 Restricted Admin Mode 阻止 RDP 场景下的 Hash 传递。不过最根本的策略始终是尽可能关掉 NTLM，全面转向 Kerberos。
#Security
你可能以为密码泄露后改掉密码就万事大吉，但在 Windows 域环境中，事情没那么简单。NTLM 认证协议的核心流程是：客户端把密码算一遍 NTLM Hash，再结合服务器发来的随机 Challenge 做运算，最后发回 Response 供服务器验证。问题出在这里——整个认证链路上，明文密码从来没出现过。服务器存的是 Hash，客户端用来证明身份的也只是 Hash 派生出来的值。换句话说，如果你拿到了一台机器上的 NTLM Hash（比如从 LSASS 内存里 dump 出来，或者从 SAM 数据库提取），你根本不需要还原明文密码，直接拿着这个 Hash 就能伪装成对应用户，去认证域内其他机器。这就是 Pass-the-Hash，一种在域渗透中被广泛使用的横向移动手法，Mimikatz 一行命令就能做到。
这种攻击之所以有效，根源在于 NTLM 协议把 Hash 当作了"等同于密码"的凭证。Kerberos 在一定程度上缓解了这个问题——TGT 的颁发需要密码的密钥派生值，窃取 Hash 后还需要额外步骤才能拿到 TGT（这就衍生出了 Overpass-the-Hash / Pass-the-Key 等变体）。但只要域内还有服务接受 NTLM 认证，Hash 就是通行证。防御思路很直接：启用 Credential Guard 把密钥隔离到 VBS 安全容器、限制本地管理员权限减少 Hash 暴露面、用 Restricted Admin Mode 阻止 RDP 场景下的 Hash 传递。不过最根本的策略始终是尽可能关掉 NTLM，全面转向 Kerberos。
#Security
