一、前言
前几天写过一篇关于Responder的文章《浅析如何让你的Responder更强大》。在那篇文章中，我们修复了Responder 实现的SMBv1&SMBv2的问题：使其能够兼容net use客户端的多次Hash捕获，并修复了SMBv2实现存在的bug。
今天的主角依然是Responder，不过讨论的主题变成了NTLM 认证。这次我们要谈不是bug，而是功能的Enhancement。容我一点一点的跟各位大佬慢慢道来。
还是那句话：作为一名医学生——逻辑一般，文采不行，文章难免存在纰漏之处，欢迎大家批评指正。
二、思考
为了防止混淆，我们先把文章中出现的几个术语限定一下：
hash：没有特别指出，那就是用来代指Net-NTLM hash
凭证：没有特别指出，那就是代指用户密码或NTLM hash
现在我们先来思考几个问题：
1.Responder为什么要支持多次hash捕获？同样我们为什么要尽可能多的收集用户hash？
2.当用户多次输入密码进行认证时，处于暗处收集用户hash的我们，如何去区分那些hash是不同凭证产生的，那些是同一凭证产生的？以及区分它的意义在哪？
3.思考2分钟，然后再继续阅读。
我依次正对以上问题谈谈我的看法：
1.因为无论是个人还是企业都存在一个密码设置的套路：如办公区A区部分设置成ABC123，B区设置成ABC345，C区设置成ABC567.当A区一个用户想要访问B区的一个文件共享时，首先会在explorer下输入\\abc-001(位于B区的一台文件共享服务器)，然后默认会用该用户的密码去认证，此时如果Responder响应的相对于abc-001更快或用户输入错误，我们就有机会捕获第一次（其实explorer实现的客户端默认用该账户和密码认证好多次），然后Responder返回PASSWORED_EXPIRED，要求用户重新输入密码，此时用户可能会陷入自我怀疑，然后尝试用C区或A区的密码进行认证（想想你忘记爱奇艺密码是的场景，你是不是会翻出自己所有的密码进行尝试），这样我们就有机会尽可能多的收集到该公司的凭证。用于后续渗透。
2.如何区分hash是由不同的凭证产生的？这是我们今天讨论的话题。我们先说一下成功区分的意义吧：节约破解的时间成本
三、Responder 捕获net-ntlmv1 hash的现状：
这里姑且先叫做net-ntlmv1 hash，但是它不是。在我遇见的好多做渗透的小伙子们都傻傻分不清什么是net-ntlmv1 hash和net-ntlmv1+ess hash，一会儿一边实验一边解释，好伐！
1.实验环境：
windows xp
kali
2.实验
2.1 同时开启Windows XP 和Kali ，在Kali 控制台下输入Responder -I eth0 -v，启动Responder。然后回到windows xp，打开我的电脑，在explorer.exe下地址栏里输入\\cfca访问文件共享。我们看到，如图1，图2：
图 1
图 2
2.2 我们看到xp 返回不可访问错误，Responder 捕获了两次hash，是不是看似很完美，好像真的实现了多次hash捕获。
先冷静一下，这其实是同一个账户密码产生的Net-NTLMv1 hash，只是看起来好像两次不同的密码认证而已（是不是傻傻分不清）。先普及一下，当在explorer下输入\\cfca进行SMB访问时，客户端默认会用当前用户名密码进行4次认证尝试，如果都不成功，客户端会断开或不中断连接，然后返回一个用户密码认证框，要求用户输入新的账号密码进行认证（为什么和net use 不同，我只能说：可能是两中SMB客户端是由不同的团队实现的吧，毕竟我也没在微软）—–到这一步以后的操作，才能称得上是真正意义上的多次捕获。
现在我们来说说为什么会有一个现在这样的畸形的情况呢？因为Responder 在实现SMBv1时添加了一个很恶心的计数器ntry（为什么说恶心，因为net use 的SMB客户端默认尝试一次，认证失败后，要求用户输入用户名密码进行重新认证，共计2次，但是是两个不同连接，所以ntry会失效。而explorer默认尝试4次，然后才要求用户重新认证，天了个撸，他竟然生效了。该生效时不生效，不该生效时瞎JB捣乱），我们干脆然他永远不生效：
回到kali ，在控制台下输入vi /usr/share/responder/servers/SMB.py,定位到如下代码，如图3：
图 3
将self.ntry == 0 该为self.ntry != 10.这样就可以了，因为没有一个客户端会默认尝试10次。
2.3 我们再来抓包看一下，如图4 图5
图4
图 5
终于回归正常了，经过4次的默认认证后，客户端弹出了要求用户输入账号密码的框框。这也算工能正常了。
到这儿，把上一篇文章的坑也算填了。
不过很可惜，上面的都不是重点：重点要来了——–我们这这篇文章的目的是说，在暗处收集hash的我们如何区分捕获的hash是由不同的用户凭证产生的。
单单从上面看，同一个用户名和密码产生的”Net-NTLMv1 hash”都区分不出来。用户哪怕重新认证了我也不知道啊，怎么办？我先帮大家回忆一下NTLM认证。
四、NTLM认证过程
Net-NTLMv1的加密流程如下：
1.客户端向服务器发送一个请求
2.服务器接收到请求后，生成一个8字节的Challenge，发送回客户端
3.客户端接收到Challenge后，使用登录用户的密码hash对Challenge加密，作为response发送给服务器
4.服务器校验response
对，就是这样子的。看完这些，我想应该有小哥哥要跳出来说了：“你去配置里面固定Challenge啊，SB，这都不懂，还写文章，咋不去死”，奥，我们来试一下。
五、Responder hash捕获增强版
5.1 同时打开xp 和kali ，vi /usr/share/responder/Responder.conf. 将Challenge设为1111111111111111（只是一个16进制数）。然后开启Responder。用xp进行文件访问\\cfca：得到如图6
如图6
惊不惊喜，意不意外，相同的密码，相同Challenge，竟然产生不同的”Net-NTLMv1 hash”。酸不酸爽。
是不是没有解决的办法了？
答案是：当然不是
填坑的时间到了。其实它上面的hash不叫”Net-NTLMv1 hash”，它是Net-NTLMv1+ESS hash，它是用在不支持NTLMv2认证的环境中的NTLMv1认证的安全增强版本，用于防止“预先计算的字典攻击”。特征是LM Response段的32个0，及16字节的\x00（NULL）。现在大家明白了吧。详细信息如图：
有兴趣的，自己了解。
看明白了吗？不明白也没关系，记住32个0就行，它叫Net-NTLMv1+ESS hash。它就是相同凭证产生不同hash，令我们傻傻分不清的元凶。
可能又有同学跳出了说：“我知道Responder有一个参数，可将Net-NTLMv1+ESS hash降级为Net-NTLMv1 hash”。但它只适用于XP以前的机器。一旦开启，就预示着你要放弃捕获同一网络环境中XP以后机器产生的Hash，这个参数成本高到只适用于演示和做实验。我们一起看一下
5.2 同时打开window 7和xp以及Kali，开启responder。使用命令：responder -I eth0 -v –lm:强制其降级，然后分别用在win7 和XP上使用\\hello1 和\\hello2访问文件共享：获得如图
XP降级成功。
无法与Windows 7 （高与XP的系统交互）
之所以会出现这种情况，是因为Responder 实现了一个单独实现了一个针对降级的SMB服务器SMB1LM（如图），一旦使用–lm，就会启用该服务器，进行交互。而XP以后的操作系统，默认不支持。
难道没有两全的办法？
当然有。
这次我们降的不是SMB服务器，而是通过在NTLM协商过程，告诉它：我不要你使用Net-NTLM + ESS hash跟我进行认证操作。进而通过NTLM协商将其降为Net-NTLMv1 hash。
如图7，Challenge包会带有一个Negotiate Flags的字段，它代表众多的协商标志位，Negotiate Extended Security标识位对我们的结果产生了巨大影响，我们要做的就是把Set改为Not Set，然后要求客户端使用Net-NTLMv1 Hash来向我们认证。
图7
5.3 现在我们改它一下：vi /usr/share/responder/packets.py 搜索这个Flags，然后将它替换为图8，即禁用Extended Security：
图8
5.3 重新实验：获得如下图9所示：
图9
开不开心，意不意外，而且在降级的同时，不影响更高版本的系统产生的hash抓取。
不幸运的是：你可能依然分不清Net-NTLMv2 相同用户名不同密码的情况。不多聊，有兴趣自己研究。
关于如何破解，我就不多说了，网上资料太多了。这里点一下而已
2.hashcat
六、总结
为什么我这么帅，却依然没有女朋友？（真等我给你们总结啊，天真……(^-^)）
七、参考材料
1.http://davenport.sourceforge.net/ntlm.html
*本文原创作者：Wreck1t，本文属于FreeBuf原创奖励计划，未经许可禁止转载
来源：freebuf.com 2020-01-22 09:00:44 by: Wreck1t
请登录后发表评论
注册