Pass-the-Hash：为什么你的密码没泄露，攻击者照样进了系统
想象这样一个场景：你从未在钓鱼页面输入过密码，密码库也没被拖过，但安全团队发现你的域管账号在一台陌生机器上远程执行了命令。问题出在哪？答案是一种叫 Pass-the-Hash（PtH）的攻击手法。
Windows 认证体系中，NTLM 协议并不要求客户端出示明文密码。验证过程只需要密码的 NTLM Hash——一个 MD4 计算出的 128 位值。当用户登录时，系统把这个 Hash 存在内存里（LSASS 进程），后续访问网络资源时直接用它在挑战-响应流程中计算应答。攻击者只要拿到这个 Hash，就能跳过"输入密码"这个环节，直接冒充该用户向域控发起认证。整个过程，明文密码从头到尾都不需要出现。
获取 Hash 的路径很多：从 lsass.exe 内存中 dump（mimikatz 的 sekurlsa::logonpasswords 是经典操作）、从磁盘上的 SAM 数据库提取、从 NTDS.dit 导出域内所有 Hash、甚至通过 EDH 降级在网络上捕获 NTLM 握手。拿到之后，工具链就很直接了——impacket 的 psexec.py、wmiexec.py、smbexec.py，或者 CrackMapExec，一条命令就能以目标身份执行远程操作。
这也是为什么 PtH 在内网横向移动中几乎成了标配技术。红队用它从普通工作站跳到域控，蓝队则头疼于如何在不破坏业务的前提下堵住它。微软在 2012 R2 之后引入了"Protected Users"安全组和 LSA Protection（RunAsPPL），前者强制成员只能用 Kerberos 认证、禁止 NTLM，后者阻止非 PPL 进程读取 LSASS 内存。但现实是，很多环境里这些防护并没有完全覆盖。
#Security
想象这样一个场景：你从未在钓鱼页面输入过密码，密码库也没被拖过，但安全团队发现你的域管账号在一台陌生机器上远程执行了命令。问题出在哪？答案是一种叫 Pass-the-Hash（PtH）的攻击手法。
Windows 认证体系中，NTLM 协议并不要求客户端出示明文密码。验证过程只需要密码的 NTLM Hash——一个 MD4 计算出的 128 位值。当用户登录时，系统把这个 Hash 存在内存里（LSASS 进程），后续访问网络资源时直接用它在挑战-响应流程中计算应答。攻击者只要拿到这个 Hash，就能跳过"输入密码"这个环节，直接冒充该用户向域控发起认证。整个过程，明文密码从头到尾都不需要出现。
获取 Hash 的路径很多：从 lsass.exe 内存中 dump（mimikatz 的 sekurlsa::logonpasswords 是经典操作）、从磁盘上的 SAM 数据库提取、从 NTDS.dit 导出域内所有 Hash、甚至通过 EDH 降级在网络上捕获 NTLM 握手。拿到之后，工具链就很直接了——impacket 的 psexec.py、wmiexec.py、smbexec.py，或者 CrackMapExec，一条命令就能以目标身份执行远程操作。
这也是为什么 PtH 在内网横向移动中几乎成了标配技术。红队用它从普通工作站跳到域控，蓝队则头疼于如何在不破坏业务的前提下堵住它。微软在 2012 R2 之后引入了"Protected Users"安全组和 LSA Protection（RunAsPPL），前者强制成员只能用 Kerberos 认证、禁止 NTLM，后者阻止非 PPL 进程读取 LSASS 内存。但现实是，很多环境里这些防护并没有完全覆盖。
#Security
