你改了密码，但攻击者根本不需要它
Windows 环境下有一个让人头疼的老问题：Pass-the-Hash（PtH）攻击。它的核心思路简单到离谱——攻击者拿到一台机器的内存 dump 后，从中提取出 NTLM hash，然后直接用这个 hash 向其他机器发起认证，整个过程不需要知道明文密码是什么。
这件事能成立，归根到底是 NTLM 认证协议的设计决定的。在 NTLM 的 challenge-response 流程中，客户端用密码的 NTLM hash 加密 server 发来的 challenge，server 端也用存储的 hash 做同样运算然后比对。既然运算只依赖 hash 值，那拿到 hash 的人自然可以跳过"还原明文"这一步，直接拿 hash 当凭据用。相当于锁匠不需要你的钥匙长什么样，只要能把锁芯的形状复制一份就够了。
真正让 PtH 威力倍增的是 Windows 的"单点登录"机制。域环境里用户登录后，lsass.exe 进程会长期缓存凭据 hash。攻击者只要用 Mimikatz 或类似工具从 lsass 里一把抓出 hash，就能在域内横向移动——从一台工作站跳到域控，权限一路升上去。整个攻击链里最讽刺的环节是：管理员改了密码，但旧 session 的 hash 依然在内存里有效，直到机器重启或用户重新登录。所以"赶紧改密码"这个应急动作，对 PtH 来说基本是慢半拍。
防御方向上，微软后来推出了一些补丁和策略：Restricted Admin Mode 限制 RDP 场景下的 PtH，Credential Guard 用虚拟化保护 lsass 里的 hash 不被随意读取。另外 Kerberos 认证本身对 PtH 有一定抵抗力——但攻击者又发展出了 Overpass-the-Hash，把 NTLM hash 伪造为 Kerberos TGT 请求的密钥，等于绕了一圈又回来了。这个攻防拉锯说明，只要认证协议里 hash 可以替代明文完成认证流程，PtH 类攻击就永远有变种空间。
如果你是域管理员，登录到一台普通工作站上排查问题，攻击者恰好在这台机器上等着抓 hash——拿到的是域管权限还是本地用户权限？从这里出发想想为什么"永远不要用域管账号登录普通机器"是一条铁律。
#Security
Windows 环境下有一个让人头疼的老问题：Pass-the-Hash（PtH）攻击。它的核心思路简单到离谱——攻击者拿到一台机器的内存 dump 后，从中提取出 NTLM hash，然后直接用这个 hash 向其他机器发起认证，整个过程不需要知道明文密码是什么。
这件事能成立，归根到底是 NTLM 认证协议的设计决定的。在 NTLM 的 challenge-response 流程中，客户端用密码的 NTLM hash 加密 server 发来的 challenge，server 端也用存储的 hash 做同样运算然后比对。既然运算只依赖 hash 值，那拿到 hash 的人自然可以跳过"还原明文"这一步，直接拿 hash 当凭据用。相当于锁匠不需要你的钥匙长什么样，只要能把锁芯的形状复制一份就够了。
真正让 PtH 威力倍增的是 Windows 的"单点登录"机制。域环境里用户登录后，lsass.exe 进程会长期缓存凭据 hash。攻击者只要用 Mimikatz 或类似工具从 lsass 里一把抓出 hash，就能在域内横向移动——从一台工作站跳到域控，权限一路升上去。整个攻击链里最讽刺的环节是：管理员改了密码，但旧 session 的 hash 依然在内存里有效，直到机器重启或用户重新登录。所以"赶紧改密码"这个应急动作，对 PtH 来说基本是慢半拍。
防御方向上，微软后来推出了一些补丁和策略：Restricted Admin Mode 限制 RDP 场景下的 PtH，Credential Guard 用虚拟化保护 lsass 里的 hash 不被随意读取。另外 Kerberos 认证本身对 PtH 有一定抵抗力——但攻击者又发展出了 Overpass-the-Hash，把 NTLM hash 伪造为 Kerberos TGT 请求的密钥，等于绕了一圈又回来了。这个攻防拉锯说明，只要认证协议里 hash 可以替代明文完成认证流程，PtH 类攻击就永远有变种空间。
如果你是域管理员，登录到一台普通工作站上排查问题，攻击者恰好在这台机器上等着抓 hash——拿到的是域管权限还是本地用户权限？从这里出发想想为什么"永远不要用域管账号登录普通机器"是一条铁律。
#Security
