LMHash 是 Windows 操作系统中一种极其过时的密码哈希存储机制，它的存在本身就是现代企业内网最危险的横向移动突破口。攻击者只要抓取到网络中的 NTLM 认证数据包，或者从 SAM 数据库导出哈希，就能在几秒钟内破解 LMHash，因为它的算法设计根本不区分大小写，还会把超过 7 位的密码自动切成两段分别破解。这意味着一条 14 位的复杂密码，在 LMHash 面前等同于两个独立的 7 位全大写字符串，暴力破解的难度断崖式下降。更致命的是，很多早期系统或配置不当的服务器，即便你设置了强密码，系统依然会在后台偷偷存储一份 LMHash，等于把钥匙直接挂在门把手上。
NTLMv2 则是目前 Windows 认证体系中最值得强化的防线。它引入了客户端挑战、服务器挑战和时间戳，配合 HMAC-MD5 算法，让每次认证会话的哈希值都完全不同，彻底杜绝了重放攻击。相比之下，NTLMv1 虽然比 LM 强，但依然使用固定的服务器挑战，无法抵御彩虹表碰撞。所以现在做 Windows Server 安全加固，核心思路就是两条：彻底铲除 LMHash 的存储，强制网络认证只走 NTLMv2。
LMHash 为什么必须禁用LMHash 的加密流程本身就带着原罪。它先把用户密码全部转成大写，不足 14 位就用空字符补齐，然后切成两组 7 字节分别作为 DES 密钥，去加密一个固定字符串。DES 密钥只有 56 位有效长度，而 7 字节的 ASCII 字符集空间极小，现代 GPU 每秒能尝试数百亿次组合，这种哈希在算力面前就是裸奔。即便你的密码是“P@ssw0rd123456”，LMHash 也会先把它变成“P@SSW0R”和“D123456”两段，大写转换直接把复杂度砍掉一大半。很多安全审计工具扫出 LMHash 存储，直接就会被判定为严重漏洞，因为它确实能让攻击者在拿到哈希后不用任何高级技巧就能还原明文。
还有一个容易被忽略的点：Windows 默认行为里，某些版本在密码长度不足 15 位时，会同时存储 LMHash 和 NTLMHash。也就是说，你自认为启用了强密码策略，但只要密码不到 15 位，系统就给你留了个后门。这就是为什么禁用 LMHash 不能只靠组策略里勾一个选项，还得配合密码长度策略一起调整。
通过组策略禁用 LMHash 存储最直接的入口是本地安全策略或域组策略。路径在“计算机配置\Windows 设置\安全设置\本地策略\安全选项”下面，找到“网络安全: 不存储 LAN Manager 哈希值，下次更改密码时”。把这个策略设为“已启用”，系统就不会再为新变更的密码生成 LMHash。但这里有个关键细节：这个策略只影响策略生效之后修改的密码，已经存在的账户密码如果没改过，LMHash 依然残留在 SAM 数据库里。所以部署完策略后，必须强制所有用户执行一次密码变更，或者直接勾选“下次登录时须更改密码”，才能真正清除历史残留。
对于域环境，这个策略需要在默认域策略或专门的安全策略 GPO 里配置，然后强制刷新。验证是否生效可以用 secpol.msc 查看本地安全策略的生效状态，或者用命令行工具导出哈希后检查。注意，这个策略从 Windows Server 2008 开始就默认启用，但在很多升级迁移的环境中，老策略可能被覆盖或未同步，必须手动确认。
用注册表彻底阻断 LMHash 生成组策略本质上也是在改注册表，但直接控制注册表可以多一层保险。对应键值在 HKLM\SYSTEM\CurrentControlSet\Control\Lsa 下，新建或修改 DWORD 值 NoLMHash，设置为 1。这个键值的作用和组策略完全一致，但有些恶意软件或错误配置可能会回退组策略，注册表硬编码能防止这类意外。修改后需要重启服务器或至少重启 LSASS 进程才能生效。生产环境里建议两者都配，组策略做统一管理，注册表做兜底。
还有一个容易被漏掉的地方：如果服务器上运行着旧版 SQL Server 或某些使用 NTLM 认证的中间件，它们可能会在内存中缓存旧格式的凭据。禁用 LMHash 后，这些应用如果还试图用 LM 响应认证，就会直接失败。所以变更前要全面盘点依赖 NTLM 的服务，避免业务中断。
强制网络认证使用 NTLMv2存储层面的 LMHash 清干净了，接下来要管住网络传输中的认证协议。攻击者在内网抓包时，如果捕获的是 NTLMv1 或 LM 响应，依然能离线破解。控制这个行为的安全策略是“网络安全: LAN Manager 身份验证级别”，同样在安全选项里。它有多个级别可选，最严格的是“仅发送 NTLMv2 响应，拒绝 LM 和 NTLM”。这个级别下，服务器只接受客户端用 NTLMv2 做认证，任何试图用 LM 或 NTLMv1 的请求都会被拒绝。
但实际落地时要谨慎。如果内网还有 Windows XP、Windows Server 2003 或某些老旧的网络存储设备，它们可能根本不支持 NTLMv2。比较折中的设置是“仅发送 NTLMv2 响应”，这样服务器自己会用 NTLMv2 去认证别人，但还能接受别人用 NTLMv1 来认证它，兼容性更好。等到所有老旧系统淘汰后，再切到最严格级别。这个策略同样要配合域控下发，并且要在所有成员服务器和工作站上生效。
通过 PowerShell 和命令行验证配置状态策略推下去之后，不能只看 GPO 报告，得用工具实际抓一下系统的认证行为。用 PowerShell 检查 LMHash 存储状态，可以查询注册表：
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "NoLMHash"
如果返回值为 1，说明注册表层面已经禁用。但更彻底的验证方法是导出本地 SAM 哈希，直接用 pwdump 或 mimikatz 的 lsadump::sam 看一下是否还有 LM 哈希。LM 哈希的特征很明显，后半段固定是 AAD3B435B51404EE，因为那是空密码的 LM 哈希值。如果所有账户的 LM 部分都是这个值，就说明 LMHash 已经被清除干净。
验证 NTLMv2 配置，可以用 Wireshark 抓取 SMB 或 HTTP 认证流量，看 NTLMSSP 协商中的 NTLM 版本标志位。也可以用 PowerShell 命令查看安全策略的注册表映射：
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel"
LmCompatibilityLevel 的值对应不同的认证级别：0 是发送 LM 和 NTLM，3 是仅发送 NTLMv2，5 是仅发送 NTLMv2 并拒绝 LM 和 NTLM。一般建议至少设为 3，最终目标设为 5。
配合密码策略和账户锁定策略形成纵深防御禁用 LMHash 和启用 NTLMv2 只是认证安全的一个环节，如果不配合强密码策略，NTLMv2 的哈希依然可能被离线破解。NTLMv2 虽然比 LM 强得多，但它的核心仍然是 MD5 哈希，攻击者拿到哈希后可以用字典或暴力破解。所以密码长度必须至少 15 位，因为 Windows 在密码达到 15 位时根本不会生成 LMHash，这是底层逻辑决定的，比任何策略都可靠。同时启用密码复杂度要求，配合账户锁定阈值，比如 5 次错误尝试后锁定 30 分钟，能极大拖慢在线暴力破解。
还有一个纵深点是 SMB 签名。即使认证用了 NTLMv2，如果 SMB 会话没有签名，攻击者依然可以实施 NTLM 中继攻击。应该启用“Microsoft 网络服务器: 对通信进行数字签名(始终)”和对应的客户端策略，这样即使哈希被中继，也无法在签名校验下完成会话建立。
处理 RDP 和 WinRM 等远程管理协议的 NTLM 行为很多管理员只关注 SMB 和 Netlogon，却忘了 RDP 和 WinRM 同样会用到 NTLM 认证。RDP 在未加入域或证书认证失败时，会回退到 NTLM，这时候如果服务器允许 LM 或 NTLMv1，就会暴露弱点。可以通过“远程桌面会话主机”的安全层设置，强制使用 SSL 或协商到 NTLMv2。WinRM 默认用 Kerberos，但在工作组环境或跨域信任不足时也会降级到 NTLM，需要在 WinRM 客户端和服务端配置中指定认证机制，避免降级到弱协议。
PowerShell Remoting 底层依赖 WinRM，所以同样受这些配置影响。可以用 winrm get winrm/config/service 查看服务端认证配置，确保 Negotiate 和 Kerberos 排在前面，并且没有开启 AllowUnencrypted 这类危险选项。
审计和持续监控安全配置不是一次性工作，必须建立持续的审计机制。启用高级审核策略，在“计算机配置\Windows 设置\安全设置\高级审核策略配置\审核策略”里，打开“审核登录事件”和“审核凭据验证”。当有客户端尝试用 LM 或 NTLMv1 认证时，事件日志里会记录 4625 登录失败事件，状态码和子状态码能明确指示认证协议版本。集中收集这些日志到 SIEM 系统，设置告警规则，一旦发现内网还有设备在使用旧协议，立刻定位并修复。
另外可以用 Microsoft 的免费工具 Local Administrator Password Solution 管理本地管理员密码，配合 ESAE 红林架构或 Privileged Access Workstation，把高权限账户的认证流量完全隔离在加固过的管理网段里。这样即使普通业务网段还有残留的弱协议，攻击者也很难跳到核心服务器。
常见踩坑和排错思路强制 NTLMv2 后最常见的故障是老旧 NAS 设备或 Linux Samba 挂载失败。这类设备通常只支持 NTLMv1，需要升级固件或调整 Samba 配置里的 client max protocol 和 ntlm auth 参数。如果短期无法升级，可以在域控上针对这些设备的机器账户做例外，但一定要限制例外范围，并设定明确的淘汰时间表。
另一个坑是某些第三方备份软件或监控代理，它们会用自己的服务账户做远程认证，如果这些账户密码长期不变，禁用 LMHash 后可能触发认证失败。排查方法是先看事件日志里的审计失败记录，定位到源 IP 和账户名，然后更新这些服务账户的密码，让新密码的哈希不带 LM。
还有一种情况是域信任关系。如果和林间信任或外部信任的对方域没有同步禁用 LMHash 和强制 NTLMv2，信任链路上的认证仍然可能降级。需要和信任域的管理员协调，统一安全基线，或者在信任筛选里限制可用的认证协议。
