浅析如何让你的Responder更强大之增强篇

一、前言

前几天写过一篇关于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：

67nyAbR.jpg!web 图 1

AZ36nyE.jpg!web 图 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：

qYrAjqy.jpg!web

图 3

将self.ntry == 0 该为self.ntry != 10.这样就可以了，因为没有一个客户端会默认尝试10次。

2.3 我们再来抓包看一下，如图4 图5

UfmiYnV.jpg!web

图4

miqYVr6.jpg!web 图 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

Jn63m2i.jpg!web

如图6

惊不惊喜，意不意外，相同的密码，相同Challenge，竟然产生不同的”Net-NTLMv1 hash”。酸不酸爽。

是不是没有解决的办法了？

答案是：当然不是

填坑的时间到了。其实它上面的hash不叫”Net-NTLMv1 hash”，它是Net-NTLMv1+ESS hash，它是用在不支持NTLMv2认证的环境中的NTLMv1认证的安全增强版本，用于防止“预先计算的字典攻击”。特征是LM Response段的32个0，及16字节的\x00（NULL）。现在大家明白了吧。详细信息如图：

3myERbz.jpg!web 有兴趣的，自己了解。