Pass-the-Hash：为什么改了密码，黑客还能用旧哈希登录？
想象一个场景：你发现内网有异常登录，立刻让受影响账号改了密码。结果几分钟后，同样的异常登录又出现了——用的还是那个账号。密码明明已经换了，这是怎么做到的？
答案藏在 Windows NTLM 认证的设计里。当用户登录时，系统不会把明文密码直接发给服务器，而是把密码做一次 MD5 运算生成一个 16 字节的哈希值，之后所有认证请求都用这个哈希来证明身份。问题在于，NTLM 协议验证的从来不是"你知道密码"，而是"你拿着正确的哈希"。换句话说，哈希本身就成了密码的等价物。
攻击的流程其实很直白。黑客先用某种方式（比如 Mimikatz 从 LSASS 进程内存中提取，或从 SAM 数据库导出）拿到用户密码的 NTLM 哈希。拿到之后根本不需要破解出明文，直接把这个哈希塞进认证请求里发出去，服务器就会认为认证通过。整个过程中，真正的密码是什么、改没改过，完全不重要——只要哈希没变，攻击就成立。
而"改了密码但哈希没变"听起来矛盾，实际上在旧版 Windows 中，开启 NTLM 后密码改了哈希确实会变，但攻击者往往拿到的是机器账户的哈希或服务账户的哈希，这类账户的密码极少变更。更关键的是，在域环境中 Kerberos 票据和 NTLM 哈希可以互相派生，拿到一个就能横跳出一整条攻击链。这就解释了为什么 PTM（Pass-the-Ticket）和 Overpass-the-Hash 这些变体攻击同样危险。
防御上，微软给出的方案是 Credential Guard——用虚拟化隔离把哈希锁在 VBS 的安全区域内，让 Mimikatz 这类工具读不到。但这要求硬件支持 VBS 且系统版本够新，很多实际环境还没铺开。更现实的缓解手段包括：限制本地管理员权限（减少哈希被提取的机会）、启用 EDR 监控 LSASS 访问行为、以及尽早迁移到 Kerberos Only 策略禁用 NTLM。
#Security
想象一个场景：你发现内网有异常登录，立刻让受影响账号改了密码。结果几分钟后，同样的异常登录又出现了——用的还是那个账号。密码明明已经换了，这是怎么做到的？
答案藏在 Windows NTLM 认证的设计里。当用户登录时，系统不会把明文密码直接发给服务器，而是把密码做一次 MD5 运算生成一个 16 字节的哈希值，之后所有认证请求都用这个哈希来证明身份。问题在于，NTLM 协议验证的从来不是"你知道密码"，而是"你拿着正确的哈希"。换句话说，哈希本身就成了密码的等价物。
攻击的流程其实很直白。黑客先用某种方式（比如 Mimikatz 从 LSASS 进程内存中提取，或从 SAM 数据库导出）拿到用户密码的 NTLM 哈希。拿到之后根本不需要破解出明文，直接把这个哈希塞进认证请求里发出去，服务器就会认为认证通过。整个过程中，真正的密码是什么、改没改过，完全不重要——只要哈希没变，攻击就成立。
而"改了密码但哈希没变"听起来矛盾，实际上在旧版 Windows 中，开启 NTLM 后密码改了哈希确实会变，但攻击者往往拿到的是机器账户的哈希或服务账户的哈希，这类账户的密码极少变更。更关键的是，在域环境中 Kerberos 票据和 NTLM 哈希可以互相派生，拿到一个就能横跳出一整条攻击链。这就解释了为什么 PTM（Pass-the-Ticket）和 Overpass-the-Hash 这些变体攻击同样危险。
防御上，微软给出的方案是 Credential Guard——用虚拟化隔离把哈希锁在 VBS 的安全区域内，让 Mimikatz 这类工具读不到。但这要求硬件支持 VBS 且系统版本够新，很多实际环境还没铺开。更现实的缓解手段包括：限制本地管理员权限（减少哈希被提取的机会）、启用 EDR 监控 LSASS 访问行为、以及尽早迁移到 Kerberos Only 策略禁用 NTLM。
#Security
