emailtry.com 1ucn.com proxychk.com

ReconCobra

今天给大家介绍的是一款名叫ReconCobra的全自动渗透测试框架，该框架可以帮助安全研究人员在研究的信息收集阶段自动化完成绝大部分的任务。本质上来说，ReconCobra是一款指纹识别与收集框架，该框架目前支持在Kali、Parrot OS、Black Arch、Termux和Android Led TV平台上运行。

框架接口

软件框架拥有82个不同的操作选项，并且完全自动化实现了功能强大的信息收集能力：

工具运行

ReconCobra特性

1、ReconCobra对于银行、私人组织和安全研究人员来说非常有价值。

2、ReconCobra可以被视作是一种防御技术，它可以帮助我们尽可能多地找到有价值的信息，以及未经授权的访问和入侵行为。

3、随着新技术的出现，网络犯罪分子也找到了更多入侵目标组织体系的方法和途径，ReconCobra便应运而生。

4、ReconCobra可以审计防火墙行为，并寻找内部以及外部网络中的相关软件，如ERP、邮件防火墙和不安全的服务器等等，以便研究人员能够尽可能多地收集目标的指纹、和相关信息，例如用户名、Web技术架构、文件、终端节点和API接口等等。

5、ReconCobra也是阻止网络犯罪的第一步，它可以有效保护我们的基础设施不会发生信息泄露。除此之外，ReconCobra是无假阳性的。

工具整合

ReconCobra的功能实现还整合了Tigerman Root软件包。

工具安装

Kali安装

广大用户可以使用下列命令在Kali平台下完成工具的安装与构建：

git clone https://github.com/haroonawanofficial/ReconCobra.git

cd Reconcobra

sudo chmod u+x *.sh

./Kali_Installer.sh

安装完成之后，ReconCobra将以系统软件的形式呈现，依赖组件将会自动完成安装，第三方软件即模块同样会自动安装。

Parrot OS安装

广大用户可以使用下列命令在Parrot OS平台下完成工具的安装与构建：

git clone https://github.com/haroonawanofficial/ReconCobra.git

cd Reconcobra

chmod u+x *.sh

Bash ParrotOS_Installer.sh

安装完成之后，ReconCobra将以系统软件的形式呈现，依赖组件将会自动完成安装，第三方软件即模块同样会自动安装。

Termux安装

广大用户可以使用下列命令在Termux平台下完成工具的安装与构建：

git clone https://github.com/haroonawanofficial/ReconCobra.git

cd Reconcobra

chmod u+x *.sh

pkg install proot

type: termux-chroot

./Termux_Installer.sh

./Termux_fixme.sh

安装完成后，重启Termux，然后运行下列命令：

perl ReconCobraTermux.pl

依赖组件将会自动完成安装，第三方软件即模块同样会自动安装。

Black Arch安装

广大用户可以使用下列命令在Black Arch平台下完成工具的安装与构建：

git clone https://github.com/haroonawanofficial/ReconCobra.git

cd Reconcobra

chmod u+x *.sh

./BlackArch_Installer.sh

安装完成之后，ReconCobra将以系统软件的形式呈现，依赖组件将会自动完成安装，第三方软件即模块同样会自动安装。

API接口

1、针对Python模块，可以从censys.io获取我们的API和密钥-censys.py

2、针对Python模块，可以从securitytrails.com获取我们的API和密钥-vasl/vasl.py

项目地址

ReconCobra：【GitHub传送门】

参考资料

1、https://codeby.net/threads/reconcobra.68782

2、https://www.facebook.com/1470285456587684/posts/reconcobra-ultimate-recon-software-for-information-gatheringbrief-introductionre/2351883108427910/

3、https://raidforums.com/Thread-reconcobra-Ultimate-Recon-Software-for-Information-Gathering

4、https://psdrepo.blogspot.com/2019/08/codebynet_14

5、https://vaultdomain.com/reconcobrathe-ultimate-recon-software-for-information-gathering-osint/

* 参考来源：haroonawanofficial，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM

本文来源于互联网:ReconCobra：一款针对信息收集的全自动化渗透测试框架

一、前言

前几天写过一篇关于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 相同用户名不同密码的情况。不多聊，有兴趣自己研究。

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

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，本文属于FreeBuf原创奖励计划，未经许可禁止转载

本文来源于互联网:浅析如何让你的Responder更强大之增强篇

前言

渗透圈内，Responder声名远扬。去年在使用中发现了一些异常，脑子抽筋，读了smb协议和Responder源码，进而发现了Responder在实现上存在的一些问题，然后进行了修复和完善，趁着这几天有时间，进行了简单整理和分析，分享出来，希望对大家有所帮助。

原标题：Make your Responder stronger

我们先看两张图片

图1

图2

图1是我从Responder官方（其实是非官方，你懂的）GitHub（https://github.com/lgandx/Responder）上找到的一段话，大致意思：支持抓去NTLMv1，NTLMv2 Hash，并成功的在Windows 95 到Server 2012 RC等机器上测试，而且内建并支持了SMBv2。

图2是我在responder的配置文件截的图，大致是说：开启CaptureMultipleCredentials，可让Responder发送ACCOUNT_DISABLED当客户端想向服务器认证时，然后尝试抓去多个hash值。（这个配置从源码上看只适用于SMB1）

大家看懂了吧，那就先别下，等我说完，然后去我GitHub上https://github.com/wreck1t/Responder下载，因为他在骗你：

1.内建的SMBv2实现存在缺陷，在与某些常用SMB客户端交互时无法正常工作，更别提捕获Hash了。

2.CaptureMultipleCredentials开启，在与某些常用SMB客户端交互时，SMBv1也只能抓到一次Hash。

由于SMB客户端的多样性和不同客户端实现的复杂性，本文以net use客户端为例，对Responder实现的SMBv1和SMBv2存在的问题进行解析，并进行修复。

作为一名医学生——逻辑一般，文采不行，文章难免存在纰漏之处，欢迎大家批评指正。

二.背景知识

1.Responder

由Laurent Gaffie撰写的Responder是迄今为止，在每个渗透测试人员用于窃取不同形式的凭证（包括Net-NTLM hash）的最受欢迎的工具。它通过污染LLMNR和NBT-NS等主机解析请求，从而欺骗目标主机与其实现的恶意服务器通信，从而达到设置恶意浏览器代理，窃取凭证等目的。当网络上的设备尝试用LLMNR和NBT-NS请求来解析目的地机器时，Responder就会伪装成目的地机器。当受害者机器尝试登陆攻击者机器，responder就可以获取受害者机器用户的Net-NTLM哈希值。

2.SMB工作流程

2.1.首先客户端发送一个SMB negotiate protocol request请求数据报，并列出它所支持的所有SMB协议版本，如图3中No 20所示：

2.2.服务器收到请求信息后响应请求SMB2 negotiate protocol response，并列出希望使用的协议版本。如图3中 No 24所示：（明眼的同学发现中间有几个包略过了，别急，咱一会再说）

2.3.协议确定后，客户端进程使用磋商好的版本向服务器发起认证以获得访问权限。

2.4.服务器发送一个Session setup response应答数据包允许或（附带拒绝的原因）拒绝本次连接。

注：2.3和2.4的认证涉4步（NTLM认证的内容），讲起来内容比较多，网上资料也比较多，我的任务是介绍流程，让大家对SMB不太陌生。

图3

3.NTLM认证（挑战响应机制）

三.实验环境：

Windows 7 （默认支持smb1 smb2）  ip：172.20.10.8

Windows XP （默认只支持smb1）      ip：172.20.10.7

kali （默认自带Responder）                ip：172.20.10.6

四.实验详情：

1.先说SMBv1：

1.1. 同时开启Windows XP和Kali，配置Kali中Responder配置文件，路径：/usr/share/responder/Responder.conf。设置CaptureMultipleCredentials=On，这也是responder的默认设置，设置完成后，在终端输入responder -I eth0，开启responder进行Hash捕获，

1.2. 来到XP，在cmd下输入net use \cfca回车（当用户不输入账号密码时，windows会使用当前的用户的账号密码尝试NTLM认证，如果认证失败，客户端会要求用户输入账号密码重新认证—-这是正常流程，按照正常流程，我们是会认证两次，而responder也会捕获两次Hash。）

1.3 windows 提示：账户被禁用，然后终止，kali也只捕获到一次hash。如图4图5所示

图4

图5

说好的捕获多次呢，骗人。我们来看一下WireShake抓包的情况，如图6:

就像配置文件里说的，responder返回了ACCOUNT_DISABLED”x72x00x00xc0″的响应 ，没问题啊。

为什么会出现这种情况呢？

这要归咎于SMB客户端的复杂性，不同的SMB客户端可能是由不同的团队实现。ACCOUNT_DISABLED”x72x00x00xc0″对于某些SMB客户端会导致客户端重新认证，而net use实现SMB客户端收到ACCOUNT_DISABLED”x72x00x00xc0″的数据包，会将认证状态打印到屏幕上，然后中断正常的再次认证流程。

经过查阅资料和实验，我们可以将它改为PASSWORD_EXPIRED “x71x00x00xc0″，因为它有更好的兼容性（其实能改的值很多，比如LOGON_FAILURE “x6dx00x00xc0″，我们这里用PASSWORD_EXPIRED “x71x00x00xc0″），客户端会进行再次认证。

1.4 回到kali，打开终端，输入vi /usr/share/responder/servers/SMB.py.作如下图7更改

图7

1.5 删掉Responder.db，重启Responder.回到windows xp重新认证。你会发现，哈哈哈，成功了！如图8图9

图8

图9

2.再来SMBv2:

2.1 同时开启Windows 7和Kali，启动Responder，然后windows 7 系统cmd下net use \cfca.你会发现什么也抓不到，只进行了对LLMNR解析的响应。又要如图，，，如图10 图11

图10

图11

来，我们分析一下WireShark抓到的包。

图12

如图12所示，客户端正常进行了认证（No 2945，No 2946，No 2947），只是responder未对客户端进行响应，所以造成了客户端出现“system error 64 ”错误，但理论上，net-ntlm hash已经到达服务器了，最少也要解析一次吧，不然多浪费。

本着不浪费的与原则，我迅速在代码中定位到了该数据包（No 2947）的代码，如图13，而包含hash的包的MessageID抓包结果是3.如图14

图13

图14

是不是以为改为3，就完了？

那你就单纯了

我们应该做的是把’ and GrabMessageID(data)[0:1] == “x02″删掉。

为什么这么做呢？来来来，协议的东西，还是让微软大大告诉你吧，如图15

图15

大致意思是说，SMB2支持两种Negotiate：Multi-Protocol Negotiate和SMB2-only Negotiate。他们的不同是：Multi-Protocol Negotiate支持多版本SMB，而SMB2-only Negotiate只支持SMB2。

当使用Multi-Protocol Negotiate时，包含hash的数据包ID为3；使用MB2-only Negotiate时，包含hash的数据包ID为2.

微软在实现在支持多版本的SMB客户端时，首先会用Multi-Protocol Negotiate进行协商，一旦确定服务器和客户端共同支持的SMB版本（假设是SMB2）后，后续认证才会用SMB2-only Negotiate。为什么这样做？兼容性  兼容性 兼容性，重要的事情说三遍，愣头青才会上来就用SMB2-only Negotiate。想想我微软大大也不会这么干。

所以无论是等于2还是等于3，都会有问题产生。删掉便成为我能想到的最好的策略。

我们来看看改后SMBv2的效果，该图16图17：

图16

图17

2.2 洗洗睡吧，我去睡了，再见

五.参考材料

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

2.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/

3.https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-WINPROTLP/e36c976a-6263-42a8-b119-7a3cc41ddd2a

4.https://support.microsoft.com/zh-cn/help/2696547/detect-enable-disable-smbv1-smbv2-smbv3-in-windows-and-windows-server

5.https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/a9d8e20e-00d0-45ec-bf8b-ad2c1ac2d805

*本文原创作者：Wreck1t，本文属于FreeBuf原创奖励计划，未经许可禁止转载

本文来源于互联网:浅析如何让你的Responder更强大之修复篇

前言

Fuzzing一直以来是漏洞挖掘非常有效的方式，我最喜欢的工具仍然是经久不衰的AFL，你可以基于AFL来打造各种fuzz工具，当然这得益于AFL中最具有魔性的遗传算法corpus变异，还记得吗，仅凭“hello”几个字符就能产生无数个有效的input输入，鹅妹子嘤！但现在有个问题，AFL基于LLVM、GCC等编译器的辅助一直发挥的不错，可如果遇到java这类基于VM的语言开发的软件还能派上用场吗？答案是肯定的，下面就祭出今天的主角大杀器 —— kelinci 。

进入主题之前先讨论个话题，java程序使用fuzz的方式去挖漏洞有效吗？其实个人认为，java语言开发的程序并不会fuzz出什么特别严重的漏洞，比如CC++如果产生了数组越界读写等问题，那很有可能会给你一个舒服的abitrary memory R&W，接下来能干啥就看你的造化了。但是java的程序fuzz出这类问题，可能仅仅就是抛个IndexOutOfBoundsException，最多导致个拒绝服务啥的，危害程度要小得多。所以说如果你想直接在java语言层面fuzz出个什么高危漏洞，不能说不可能，只是概率非常的低。但是这不意味着java程序就不需要fuzz，fuzz仍然能够发现很多有价值的问题，例如资源泄露、RuntimeExceptions 、反序列化漏洞、XXE、逻辑bug、甚至jvm逃逸等等，每一类问题放在系统的业务逻辑中去仔细分析，都有可能是个大问题，千万不要忽视。

OK，下面我们言归正传，开始正式介绍kelinci。（友情提示，搞kelinci之前你最好是折腾过AFL，不然这个kelinci可能有很多地方你可能不会理解） 

原理

英文好的直接看这两篇文档：

https://github.com/isstac/kelinci/blob/master/docs/ccs17-kersten.pdf

https://github.com/isstac/kelinci/blob/master/docs/ccs2017-poster-small.pdf

我通俗的说一下kelinci实现的大概思路，首先对于AFL来说，它并不知道自己在fuzz java程序，这是因为kelinci做了一个java程序的C版interface ，这个interface程序负责从AFL中接收变异数据，然后通过TCP传给java侧，java侧的程序叫做instrumentor，它负责把从interface传过来的变异数据真正的传递给java原始目标程序，然后再把java的运行结果反馈给interface，如此形成了一个fuzz数据流闭环。

安装

首先来个例行的

git clone https://github.com/isstac/kelincicd

Kelinci有两个组件，一个是C程序interface，它作为AFL的测试目标。你可以在fuzzerside目录里找到它。进入fuzzerside目录后执行make就可以编译生成interface可执行程序了。第二个组件是java侧的instrumentor，它是java侧的目标程序被工具化后的产物，负责和interface进行TCP通信，instrumentor运行后会起一个TCP server接收变异数据，每次接收到一个请求，instrumentor就会单独起一个线程来去运行java侧的目标程序，并且将变异数据传递进去。然后再把这个请求的运行结果发送回去，例如是success、timeout还是queue full等，注意任何可以跳出main的异常都会被认定是一个crash。你可以使用gradle来构建instrumentor，进入instrumentor目录，执行gradle build顺利的话，在./build/libs目录里会编译出一个kelinci.jar。

使用

假定你的AFL和上面两个组件都已经编译好了，就可以按照下面的步骤来跑fuzz了。

1，创建一个driver：这个一个步骤是可选的，主要是因为AFL/Kelinci的输入预期是本地文件，但如果你的程序接受的参数不是文件，那就需要自己去把corpus文件和你程序的接口去做个适配了。这说的有点抽象，我举个栗子，比如你要fuzz的目标程序是从数据库中读取数据并做分析处理，那么AFL是无法直接对数据库中的某个字段数据做变异的，这时候就需要你自己去写个driver，把数据从数据库中读取出来组织成本地corpus文件，然后AFL就可以对这个本地的corpus文件进行变异了，变异完成后还需要你的driver程序把变异后的corpus文件的数据读出来，写回数据库让你的测试目标去读取。这些工作AFL无法自动化完成，因为它无法预先知道你要fuzz的程序接受什么样的输入，所以这个driver的工作你要自己去做，当然如果你要fuzz的程序本来就是接受文件的输入，那恭喜你这个步骤可以省了嘿嘿~

2，目标程序工具化：我们假定目标程序和driver你都已经构建好了，并且输出到了目录”bin”中。下面我们要将目标程序工具化，只有工具化以后的目标程序才可以使用AFL来进行fuzz。kelinci提供了一个工具类edu.cmu.sv.kelinci.instrumentor.Instrumentor来干这事。它使用-i选项来指定输入目录，在这里就是”bin”，使用-o选项指定输出目录，这里是“bin-instrumented”。我们需要确保kelinci.jar在classpath中，然后假定目标程序所依赖的jar包都在 /path/to/libs/中，那么执行命令示例如下：

java -cp /path/to/kelinci/instrumentor/build/libs/kelinci.jar:/path/to/libs/* edu.cmu.sv.kelinci.instrumentor.Instrumentor -i bin -o bin-instrumented

注意如果目标程序所依赖的库和Kelinci Instrumentor所依赖的相同，这时候如果他们之间的版本不同就会出现版本冲突问题。目前来说Kelinci所使用的版本如下：args4j version 2.32， ASM 5.2， Apache Commons IO 2.4。大多数情况下，如果出现这种问题，你可以不要去使用打包好的kelinci.jar，而是把Kelinci构建出来的classes目录放到classpath上，然后他们共同依赖的那些jar包你就只放一个版本到/path/to/libs/里就OK了。

3，创建输入样例：要对工具化后的目标程序进行fuzz还需要创建一个输入文件的目录”in_dir”。

mkdir in_dir

AFL会从这个in_dir里获取输入样本进行变异，注意这里的文件是变异最初的原始版本，要用心的构造。构造好输入样本后可以使用如下命令去测试一下：

java -cp bin-instrumented:/path/to/libs/* in_dir/

4，启动Kelinci server：现在我们可以启动Kelinci的server了。Kelinci需要目标java程序的main类作为第一个参数，然后使用@@来代替之前建立的”in_dir”中的输入文件，运行时Kelinci会使用每一个具体的输入文件来替换@@。运行的命令可以写成这个形式：

java -cp bin-instrumented:/path/to/libs/* edu.cmu.sv.kelinci.Kelinci @@

你也可以自己指定一个端口号，默认是7007，比如 

java -cp bin-instrumented:/path/to/libs/* edu.cmu.sv.kelinci.Kelinci -port 6666 @@

5，通信测试：开始正式fuzz之前，可以运行interface程序来确认一下与java侧程序的联通性，命令如下：

/path/to/kelinci/fuzzerside/interface in_dir/

你还可以使用-s选项来指定一个远端server,（默认是连接localhost），

/path/to/kelinci/fuzzerside/interface -s yourdomain.com in_dir/

甚至提供一个server的列表server.txt

/path/to/kelinci/fuzzerside/interface-s servers.txt in_dir/

6， 开始正式fuzzing：如果之前做的都没啥毛病，现在可以启动AFL了，就像之前说过的interface就是AFL的测试目标，@@作为interface的输入文件，运行时从”in_dir”里取每一个文件代替@@，然后再指定个fuzz结果输出目录”out_dir”，那么AFL的运行命令可以组成如下：

/path/to/afl/afl-fuzz -i in_dir -o out_dir /path/to/kelinci/fuzzerside/interface [-s servers.txt] @@

不出意外的话，AFL interface过一会就会启动了，如果在AFL的展示窗口发现有了新的path，那么恭喜你，Kelinci运行成功了！

*本文作者：成王败寇，转载请注明来自FreeBuf.COM

本文来源于互联网:基于AFL的Java程序Fuzz工具：Kelinci

免责声明：本文作者竭力保证文章内容可靠，但对于任何错误、疏漏或不准确的内容，作者不负任何责任。文章部分内容来源于网络是出于传递更多信息的目的，对此不负任何法律责任。本文仅用于技术分享与讨论，严禁用于其他用途。

一、前言

在基于DNS的数据窃取开源工具篇(一)和基于DNS的数据窃取开源工具篇(二)中，已经讨论DET和PyExfil两个开源项目关于利用DNS完成数据窃取的部分。本文将继续讨论如图1中所示的第三个开源工具DNSExfiltrator。

图1  DET、PyExfil、DNSExfiltrator、Egress-Assess的首页展示

二、DNSExfiltrator简介

DNSExfitrator开源项目[1]是一个数据泄露测试工具，它利用DNS协议进行隐蔽的数据泄露。DNSExfiltrator采用C/S模式，其服务端使用python实现(dnsexfiltrator.py)，客户端提供C#源码，可通过csc.exe编译为Windows可执行文件；同时，也可以通过作者用JavaScript、Powershell包装后的脚本文件来启用客户端。DNSExfiltrator项目源码结构梳理如图2。

图2 DNSExfiltrator项目组成概况

总结DNSExfiltrator的特色主要有：

1)   默认使用系统定义的DNS服务器，可以通过-s 指定特定DNS服务端。

2)   支持DoH，通过-h参数启用。

3)   默认使用base64URL编码，但也可以通过-b32指定使用Base32编码。

4)   支持基础R**加密对数据进行加解密。

5)   提供一些可选功能用来逃避检测，主要有：

a)     请求限制——每个DNS请求间隔时间大小，实现更隐蔽的数据窃取。

b)     减小DNS请求大小，默认使用每个DNS请求最大剩余可用字节。

c)     减小DNS标签大小，默认使用最大支持的标签长度63字符。

三、基于DNS的数据窃取的源码简要分析

DNSExfiltrator工具采用C/S模式，服务端为DNSExfiltrator.py文件，客户端使用C#实现，可通过csc.exe编译为Windows可执行程序。同时，为了便于使用，作者还提供了包装了DNSExfiltrator客户端二进制文件的Powershell脚本和JavaScript脚本。

DNSExfiltrator准备条件：

1）拥有一个域名，并将其DNS记录指向运行DNSExfiltrator.py的服务端；

2）服务端依赖python的dnslib库。

（一）服务端源码分析

对服务端源码文件dnsexfiltrator.py进行梳理、分析，将其源码概况和服务端工作的主要流程整理如图3。

图3 服务端源码概况及服务端的主要流程

通过对服务端源码dnsexfiltrator.py的梳理、分析，整理服务端接收、恢复窃密数据的主要流程为：

1)  监听53端口并接收请求数据。当DNS请求包的请求类型为TXT记录，则进入第（2）步。

2)  提取请求的子域名，即使用dnslib库提取数据包的qname，DNSExfiltrator中qname的拼接组成主要有如图4所示的两种。

图4 DNSExfiltrator服务端提取的qname组成结构

3)  判断包类型，若qname以”init.”开始，则为初始化请求包执行步骤（4），否则进入步骤（5）。

4)  ”init.”标识该包为初始化包，则首先进行Base32解码，然后提取窃取文件的“filename：文件名”、“nbchunks：数据块总数”、“BASE32：是否使用BASE32编码”，并初始化接收准备。

5)  此类包传输实际窃密文件数据，窃取的数据加密、编码后拼接组成的查询子域名如图5。

图5 用于传输文件数据的子域名拼接组成示例

6)  当某一个查询请求中的包序号等于块总数时，标志着窃取的文件数据已传输完毕，开始执行写入、恢复为本地文件的操作。

注：服务端处理初始化包后会回复客户端请求的TXT记录为“OK”，处理真实窃密数据包后，则会回复TXT记录为对应“包序号”。

（二）客户端源码简要分析

DNSExfiltrator客户端采用C#语言编写，可以编译为独立的可执行文件或一个DLL。编译方法：

1)  编译为Windows可执行程序编译：

C:WindowsMicrosoft.NETFramework64v4.0.30319csc.exe /unsafe/reference:System.IO.Compression.dll /out:dnsExfiltrator.exe dnsExfiltrator.cs

2)  编译为DLL：

C:WindowsMicrosoft.NETFramework64v4.0.30319csc.exe/unsafe /target:library /reference:System.IO.Compression.dll/out:dnsExfiltrator.dll dnsExfiltrator.cs

图6 DNSExfiltrator客户端源码结构及主要流程

通过对DNSExfiltrator.cs的梳理和分析，其源码结构和客户端工作主要流程如图6。参照图6，整理DNSExfiltrator发送窃密文件数据的主要流程如下：

1)  预处理工作，主要是通过指定的标签最大值、域名最大长度，计算拼接子域名时的相关参数值。

2)  读取文件数据到内存中，完成压缩、加密、编码。

3)  发送初始化DNS包，包括将要传输的文件信息包括：文件名、数据块总数、编码方式等，各信息拼接的结构如图7。

图7 DNSExfiltrator初始化包的组成结构

4)  通过服务端响应的TXT记录“ok”，确认初始包发送成功。

5)  按步骤（1）计算所得参数值，将文件数据切分为数据块，然后按图8所示的组成结构拼接成子域名。

图8 DNSExfiltrator窃密数据包的组成结构

6)  逐个发送构建好的DNS TXT请求包。其中，客户端会根据服务端对每个DNS TXT记录响应的包序号来确认数据发送成功后，才发送下一个携带窃密文件数据的DNS TXT请求包。

四、小结

（一）DNSExfiltrator的优势分析：

1）支持使用DoH形式的DNS解析，且可以自行指定DoH服务提供商。

2）客户端使用C3语言编写，便于编译为Windows可执行文件或DLL，且作者还提供了使用DNSExfiltrator的JS、Powershell脚本。

3）客户端、服务端依赖较少，环境搭建简单。

（二）DNSExfiltrator的不足之处：

1）包序号在工具的窃密和文件恢复过程中尤为重要，在实际使用时不稳定。

2）未提供文件校验，窃取的数据完整、真实不能保证。

3）每个包按包序号逐个发送、确认，在实际DNS请求情况下效率低、易出错。

参考链接：

[1] DNSExfiltrator项目地址

*本文作者：GZHU/asUwIll，转载请注明来自FreeBuf.COM

本文来源于互联网:基于DNS的数据泄露开源测试工具篇（三）

一、概述

在系统被入侵后，要想了解下系统被入侵的过程，最好的途径大概就是通过查看日志，对日志进行分析，来还原整个过程的来龙去脉。每次对几百兆的日志进行查看时确实头疼，尤其是对关键字进行搜索时还会出现编辑器卡顿的情况。所以就想着能不能利用脚本去完成一些常规的排查过程，来辅助完成日志分析工作。

二、功能简述

2.1、根据关键字进行搜索

（1）目的：尝试通过在日志中搜索后门名称、时间等关键字，更快找到有用信息。

（2）使用方法：将需要查询的日志放到当前路径/log/目录下，运行日志find.py,该模块最多支持两个关键字搜索，关键字之间以逗号隔开；

当最后一个关键字为1时，表示对关键字1和关键字2同时进行搜索；当最后一个关键字为2时，表示搜索满足关键字1或关键字2的日志；当最后一个关键字为空时，表示只是对关键字1进行搜索；

（3）结果保存：搜索结果会保存在当前result目录下的find_result.txt文档中。

搜索test.php，输入格式test.php, 输出如下：

搜索10月6号访问test.php的日志，输入格式test.php, 06/Oct/,1 输出如下：

搜索10月6号或访问test.php的日志，输入格式test.php, 06/Oct/,2 输出如下：

（4）ip地址查询：

对搜索到结果进行ip地址提取，查看攻击者的ip还做过哪些操作，并将搜索结果保存在log.txt中

2.2、Ip、url分析

（1）目的：提取日志中所有的ip地址，并对ip归属地进行查询，并对出现次数做统计；根据日志 分析url访问情况，记录访问路径、访问次数，并将结果保存到tongji.xsl表格中

（2）使用方法：将需要查询的日志放到当前路径/log/目录下，运行python rizhifenxi.py

（3）结果保存：会在result目录下生成tongji.xls，url地址统计如下

URl统计表

IP地址统计表

三、有待改进

1、脚本思路多数来自平常的项目积累，所以想法过于单一，在今后遇到不同的情况会在继续完善；

2、很多时候即使是筛选出来后还是更多的靠人为去分析，脚本只是辅助工具，所以存在不够通用的问题；

3、ip地址在查询中由于查询接口原因，会存在查询失败情况；

4、当日志格式为自定义情况下，需要根据定义格式在自行修改脚本中分割日志的格式；

四、最后

现成的日志分析工具，网上大牛已经分享了很多，如elk、web-log-parser、360星图等，也有大牛们自己编写的一些工具。这里只是根据自己的需求重点做了搜索、异常地址访问列表提取、ip地址归属地查询、url汇总功能，还是有很多功能可以添加完善的，写的水平比较水，可根据自己的需求做修改完善处理，有好的意见也可以多多指出。

相关代码已经上传github，查看地址如下：

https://github.com/tide-emergency/yingji/tree/master/%E5%BA%94%E6%80%A5%E5%93%8D%E5%BA%94%E4%B9%8B%E5%B7%A5%E5%85%B7%E7%AF%87/%E6%97%A5%E5%BF%97%E5%88%86%E6%9E%90%E8%84%9A%E6%9C%AC

*本文作者：菜鸟的菜，转载请注明来自FreeBuf.COM

本文来源于互联网:应急响应日志分析小脚本

0×01 简介

NoXss是一个供web安全工程师批量检测xss隐患的脚本工具。其主要用于批量检测，比如甲方内部安全巡检，人工分析千万级的url资产是不现实的，NoXss使用多进程+协程的方式，支持高并发，可以出色的完成这一任务。NoXss从实用主义出发，小巧精致，不如其他扫描器拥有各式各样的高级功能（比如绕过waf、存储型xss等），深入挖掘xss这里首推XSStrike，但在批量检测方面，NoXss是一个不错的选择。

项目地址：https://github.com/lwzSoviet/NoXss

0×02 工作原理

NoXss主要是通过“符号闭合”来检测xss隐患，使用基于“反射位置”的payload进行探测（目前一共8个），相比fuzz减少了很多盲目性。比如当请求参数的值出现在response的javascript代码段中，并且是以双引号的形式进行闭合，那么NoXss将使用xssjs”;这个payload；如果是以单引号的形式进行闭合，则会使用xssjs’;进行测试。更多的位置分类以及payload请参考https://github.com/lwzSoviet/NoXss/blob/master/README.md

0×03 优势

1.支持DOM类型的xss

NoXss支持使用Chrome(推荐)和Phantomjs（默认）两种浏览器来对抗DOM类型的xss，同样支持多进程，即可以多个浏览器同时工作，但浏览器的资源占用通常是较高的，使用–browser选项意味着更慢的扫描速度、更高的CPU&内存占用。

2.多进程+协程支持高并发

#指定进程数 
python start.py --url url --process 8 
#指定协程并发数 
python start.py --url url --coroutine/-c 300

漏扫的时间消耗主要集中在网络IO，NoXss支持用户自己配置进程数与协程数，需要注意的是协程并发数需要结合网络情况而定，如果配置的过高，可能出现过多的网络阻塞，导致无法检出xss。

3.使用基于位置的payload

Fuzz技术通常带有很大的盲目性，对于批量检测并不适合。NoXss目前确定使用的payload一共只有8个，全部基于参数反射的位置，更少的payload意味着更少的测试用例、更快的扫描速度。

4.接口维度的去重

对于批量检测而言，去重是一项重要的工作。除了去除各种静态资源，NoXss还会以接口为维度对url进行去重，接口由域名、端口、路径、参数键值对等多个因素共同决定。在这个过程中，对于一些相似的属性，NoXss还会对其进行泛化。

5.与Burpsuite协同工作

NoXss支持将Burpsuite的流量导出进行扫描：

对于渗透测试人员来说，这是一个较为友好的功能。但请不要对NoXss抱有太多的期望，它对较为复杂的xss（比如存储型）无能为力。

6.支持配置Cookie、Referer等请求头

在批量检测的过程中通常需要维持登录态，一些应用的后端还会校验Referer甚至其他的一些自定义的HTTP请求头部，NoXss支持用户对此进行配置：

python start.py --url url --cookie cookie

默认情况下，NoXss会根据当前扫描的url自动添加Referer头部。

7.辅助人工分析

NoXss会将扫描过程中的流量保存到traffic目录下，除此之外还有参数反射结果（.reflect）、跳转请求（.redirect）、网络等错误（.error）都将保存在traffic目录下。在扫描结束后，安全工作者可以很方便地利用这些“中间文件”进行分析。

0×04 安装及使用

NoXss基于python2，主要用于批量检测，Centos安装如下：

yum install flex bison phantomjs 
pip install -r requirements.txt

Ubuntu:

apt-get install flex bison phantomjs 
pip install -r requirements.txt

其它平台安装参考：https://github.com/lwzSoviet/NoXss/tree/master#install

如果你希望使用Chrome作为检测使用的浏览器，还需手动安装Chrome、下载对应的驱动并设置环境变量，可以使用

python start.py --check

来检查浏览器是否安装正确。

批量检测：

python start.py --file ./url.txt --save

检测单个url：

python start.py --url url

使用浏览器：

python start.py --url url --browser=chrome

扫描Burpsuite流量：

python start.py --burp ./test.xml

更多使用方式参考：https://github.com/lwzSoviet/NoXss/tree/master#usage

0×05 总结

就漏洞本身而言，适合扫描的漏洞种类并不多，安全问题更多地还是需要人工去挖。但对于一些简单的漏洞，借助工具可以节省人力成本，如果每天有数千万的url需要你测试，交给NoXss定时任务或许是个不错的选择，最后由衷地感谢工具作者。

*本文作者：帕克飞走了，转载请注明来自FreeBuf.COM

本文来源于互联网:一款优秀的XSS批量检测工具