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

文章目录

  • 一、前言
  • 二、思考
  • 三、Responder 捕获net-ntlmv1 hash的现状:
    • 1.实验环境:
    • 2.实验
  • 四、NTLM认证过程
  • 五、Responder hash捕获增强版
  • 六、总结
  • 七、参考材料

一、前言

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

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

浅析如何让你的Responder更强大之增强篇插图(2)图 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:

浅析如何让你的Responder更强大之增强篇插图(4)

图 3

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

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

浅析如何让你的Responder更强大之增强篇插图(6)

图4

浅析如何让你的Responder更强大之增强篇插图(8)图 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

浅析如何让你的Responder更强大之增强篇插图(10)

如图6

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

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

答案是:当然不是

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

浅析如何让你的Responder更强大之增强篇插图(12)有兴趣的,自己了解。

看明白了吗?不明白也没关系,记住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访问文件共享:获得如图

浅析如何让你的Responder更强大之增强篇插图(14)XP降级成功。

浅析如何让你的Responder更强大之增强篇插图(16)无法与Windows 7 (高与XP的系统交互)

之所以会出现这种情况,是因为Responder 实现了一个单独实现了一个针对降级的SMB服务器SMB1LM(如图),一旦使用–lm,就会启用该服务器,进行交互。而XP以后的操作系统,默认不支持。

浅析如何让你的Responder更强大之增强篇插图(18)

难道没有两全的办法?

当然有。

这次我们降的不是SMB服务器,而是通过在NTLM协商过程,告诉它:我不要你使用Net-NTLM + ESS hash跟我进行认证操作。进而通过NTLM协商将其降为Net-NTLMv1 hash。

如图7,Challenge包会带有一个Negotiate Flags的字段,它代表众多的协商标志位,Negotiate Extended Security标识位对我们的结果产生了巨大影响,我们要做的就是把Set改为Not Set,然后要求客户端使用Net-NTLMv1 Hash来向我们认证。

浅析如何让你的Responder更强大之增强篇插图(20)图7

5.3 现在我们改它一下:vi /usr/share/responder/packets.py 搜索这个Flags,然后将它替换为图8,即禁用Extended Security:

浅析如何让你的Responder更强大之增强篇插图(22)图8

5.3 重新实验:获得如下图9所示:

浅析如何让你的Responder更强大之增强篇插图(24)

图9

开不开心,意不意外,而且在降级的同时,不影响更高版本的系统产生的hash抓取。

不幸运的是:你可能依然分不清Net-NTLMv2 相同用户名不同密码的情况。不多聊,有兴趣自己研究。

关于如何破解,我就不多说了,网上资料太多了。这里点一下而已

1.https://crack.sh/netntlm/

2.hashcat

六、总结

为什么我这么帅,却依然没有女朋友?(真等我给你们总结啊,天真……(^-^))

七、参考材料

1.http://davenport.sourceforge.net/ntlm.html

2.https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/ee3e4254-083b-4230-9289-3ca0f969ac5a

3.https://github.com/lgandx/Responder

4.https://crack.sh/netntlm/

5.https://3gstudent.github.io/3gstudent.github.io/Windows%E4%B8%8B%E7%9A%84%E5%AF%86%E7%A0%81hash-NTLM-hash%E5%92%8CNet-NTLM-hash%E4%BB%8B%E7%BB%8D/

*本文原创作者:Wreck1t,本文属于一一网络博客原创奖励计划,未经许可禁止转载

免责声明:务必仔细阅读

  • 本站为个人博客,博客所转载的一切破解、path、补丁、注册机和注册信息及软件等资源文章仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。

  • 本站为非盈利性站点,打赏作为用户喜欢本站捐赠打赏功能,本站不贩卖软件等资源,所有内容不作为商业行为。

  • 本博客的文章中涉及的任何解锁和解密分析脚本,仅用于测试和学习研究,禁止用于商业用途,不能保证其合法性,准确性,完整性和有效性,请根据情况自行判断.

  • 本博客的任何内容,未经许可禁止任何公众号、自媒体进行任何形式的转载、发布。

  • 博客对任何脚本资源教程问题概不负责,包括但不限于由任何脚本资源教程错误导致的任何损失或损害.

  • 间接使用相关资源或者参照文章的任何用户,包括但不限于建立VPS或在某些行为违反国家/地区法律或相关法规的情况下进行传播, 博客对于由此引起的任何隐私泄漏或其他后果概不负责.

  • 请勿将博客的任何内容用于商业或非法目的,否则后果自负.

  • 如果任何单位或个人认为该博客的任何内容可能涉嫌侵犯其权利,则应及时通知并提供身份证明,所有权证明至admin@proyy.com.我们将在收到认证文件后删除相关内容.

  • 任何以任何方式查看此博客的任何内容的人或直接或间接使用该博客的任何内容的使用者都应仔细阅读此声明。博客保留随时更改或补充此免责声明的权利。一旦使用并复制了博客的任何内容,则视为您已接受此免责声明.

您必须在下载后的24小时内从计算机或手机中完全删除以上内容.

您使用或者复制了本博客的任何内容,则视为已接受此声明,请仔细阅读


更多福利请关注一一网络微信公众号或者小程序

一一网络微信公众号
打个小广告,宝塔服务器面板,我用的也是,很方便,重点是免费的也能用,没钱太难了,穷鬼一个,一键全能部署及管理,送你3188元礼包,点我领取https://www.bt.cn/?invite_code=MV9kY3ZwbXo=


一一网络 » 浅析如何让你的Responder更强大之增强篇

发表评论

发表评论

一一网络-提供最优质的文章集合

立即查看 了解详情