为什么我会看到中存储的LM散列？

Question

我使用mimikatz从检索用户的密码散列，命令如下：

lsadump::dcsync /user:mimikatz

用户的密码是Pa55w.rd。

输出是

...

Credentials:
  Hash NTLM: 377565f7d41787414481a2832c86696e
    ntlm- 0: 377565f7d41787414481a2832c86696e
    lm  - 0: 3bad9482ff88c8d842970f4174fbebd7

...

我惊讶地看到LM散列(3bad...)的值。我检查了域控制器上的有效组策略设置，实际上，不应该存储LM散列：

我相信LM散列3bad...不是我所相信的LM散列，而是一种不同的散列。但这是什么？

Answer 1

如果没有更多的信息，很难确定。Microsoft表示当用户更改密码时不会存储LM散列。

但是，在迈克·皮尔金顿的一篇无意义文章中应用了适当的缓解设置，但是仍然有一些实例可以在内存中找到LM散列。

转储SAM db之后与预期一样，没有LM散列可用。默认情况下，前两个帐户是禁用的，并且从来没有为它们设置过密码。对于用户帐户MIKE，只有他的NT哈希可用。到目前为止，一切顺利！在内存中转储凭据之后结果表明，Windows计算并将LM哈希存储在内存中，假设密码小于15个字符，而不管用于LM哈希存储和LM质询响应的主机或域设置是什么！

更深一点的

在的NT和LM散列的计算。Pa55w.rd之后，NT的值是377565F7D41787414481A2832C86696E，LM是C321C0EE1F8388924A3B108F3FA6CB6D，两者都不匹配上面的值。所以我在想，也许你抄袭错了哈希？或者，你没有正确地复制密码？

在我曾经使用过的各种戊类中，我注意到遗留环境很难摆脱LM散列，即使它们推出GPO来不存储LM散列并在网络上禁用LM 1/2。正如本文所指出的，这肯定与仍在计算并存储在内存中的散列有关。