一个DOS攻击木马的详细分析过程
0×01 起因
网路流量里发现了大量的的1.exe的文件，而且一直在持续，第一感觉就像是一个木马程序，而且每个1.exe的MD5都不一样，对比发现只有几个字节不一样（如下图），按了几下PgDn就到尾了！一看大小，只有5k。一下想到了以前分析的一个老外写的兼容xp,win7,x86,x64系统的非常小的MBR bootkit木马，当时分析的时候真的是忍不住拍手叫绝。喜欢“小而美”的东西，后面分析里有段代码，也可以看出作者写代码的确比较讲究：检查http方法是POST还是GET时，只比较一个首字母。
一时兴起，决定深入分析一下这个样本，于是有了在FreeBuf上的第一篇文章。
0×02 网络流量里为什么有大量1.exe文件 ?
木马加壳加密，反调试，在这个年代已经是基本配置了，此文不是讲脱壳，所以这里省略一万字直接穿越到脱完壳后，样本的确非常小，一共就只有20多个函数。本文叫详细分析，所以把这个样本的所有边边角角都逆向出来了，看着有了名字的函数，一下舒服多了。（为了纪念在FreeBuf上的第一篇文章，特意有了一个函数叫FreeBuf，如果非要问为什么叫这个名字，那我们就点进去看看，因为它真的就只是free buffer）
网络流量里有大量1.exe，而且每个MD5值不一样，先猜测木马是不是一个下载者，运行后就不停的下载其他木马
经过分析，定位到了如下关键函数，找出了原因，和猜想的还不一样。
1）读取自身文件内容
2）修改自身PE文件的时间戳，每次递增1
（这就是为什么每个1.exe的MD5值都不一样）
3）post数据，并上传文件
如下是第2个appendstr附加的数据，从内容以及0x0D, 0x0A的换行，很容易认出是在构建http的协议头。最后一行的64字节的字符串，是提交的apikey，而这个apikey到底是什么呢？继续往下分析。
如下是第4个appendstr附加的数据，也是在构建http协议头，Content-Disposition字段指明了上传文件的文件名叫1.exe
4）木马为什么要循环上传自己，而又把自己上传到哪里去了呢？
先将前面构造的需要POST的IStream流数据转到buffer里，然后提交给了 www.virustotal.com/vtapi/v2/file/scan
VirusTotal是一个全球知名的提供可疑文件分析服务的网站，/vtapi/v2/file/scan 这个是开放给他的会员扫可疑文件的API接口，现在可以来回答前面看到的那个64字节的apikey是什么：会员必须向VirusTotal申请到这个apikey后，才能正常使用这个扫文件的API接口
上面是httpRequest的部分内容，这个函数就是用WinHTTP系列SDK完成http请求的函数，不需要细看，
这里只是提一下框住的那句汇编cmp ecx, 50h，晃眼一看还以为是在比较是不是80端口，原来是在检查函数参数http方法是GET还是POST, ascii 80也是字母”P”，只比较了一个首字母，这就是文章最开始提到的作者写代码比较讲究，还有不少作者编码很讲究的地方，与本文主题关系不大，这里就不细讲了。
我们再回到上面核心函数末尾
木马请求完返回的结果没有使用就直接被正义使者FreeBuf给干掉了，这是什么意思？
FreeBuf后面那句 jmp loc_401451 原来是一个死循环，又跳到上面修改自身时间戳的地方
到这里我们就清楚了原来木马一直在循环上传自身，每个循环会递增PE的TimeDataStamp字段（[PE_Base+0x3c] + 0×8），所以每次提交的1.exe的MD5都不一样，因为VirusTotal对已经有MD5值分析过了的文件，就不会再分析了，直接返回以前分析的结果。所以VirusTotal返回的结果木马也不关心，直接free掉。这个木马是想攻击VirusTotal……？
分析到这里，就像给这个函数取的名字一样“LoopSubmitVirusTotal”，已经很清楚了整个过程，而且已经完全解答了分析这个样本的起因：
到这里文章仿佛也该结束了：《一个木马作者报复安全厂商的故事》
0×03 揭开木马的真实意图
这个故事始终觉得怪怪的，木马作者有什么好处呢？那就继续把剩下几个没逆完的函数，全部看完吧
如上图，又发现一个和前面httpRequest函数几乎一模一样的函数，唯一的区别是，这个函数自己把写了一长串WinHTTP SDK，辛苦获取到的Response返回结果，直接在函数内部就给Free掉了。换句话说就是，这是一个Http请求的函数，完成了所有工作后，却什么也不返回。外部看来和一个空函数有什么区别？
如下图，我们来到了调用这个函数的地方，看完这里基本就清楚了是怎么回事了
上层函数又是一个死循环，接收参数：服务器主机地址和路径后，就一直循环发起GET请求。原来这是在发起应用层的DOS攻击，所以前面的函数也不需要关心请求的返回结果直接就free了。
如上图，再往外层分析，进一步确认这是一个应用层DOS攻击木马。 对目标服务器循环GET的那个函数又被启了100个线程，的确是想把对方搞死的节奏
真相越来越明朗，还剩下最后一个问题，攻击的目标服务器，从哪里获取？
经验猜测是通过C&C获取，继续来证实，果然找到了如下C&C通讯函数，是通过twitter的博客页面，实现的http隐蔽通讯，接收命令
如下，打开twitter.com/pidoras6页面来证实一下（只关心祖国大事的好同志，还花了20元去买了一个VPN）
打开页面，置顶的推文一下就发现了5个反括号，控制命令是被加了密的，其实都不用去逆向解密函数，看长相就挺眼熟，最后末尾有等号，很像base64（base64编码的字符串的长度是以3来对齐，不足的用=来补齐，所以在最后经常能看到一个或两个等号）
并没有对控制命令做加密，只是简单用了base64编码，让别人不要一眼看出是什么就行了。
后面的代码已经不重要，也能猜到，网页的utf8编码转为本地编码，调用WinHttpCrackUrl函数拆解收到的攻击目标URL，然后回写到全局变量里，供那100个攻击线程循环去GET目标
0×04 尾声
回头再来看起因的那些大量提交给VirusTotal的1.exe，仿佛和木马接收命令进行DOS攻击没什么关系，
推测作者的目的可能是：因为VirusTotal是限制会员提交样本的频率的，木马首先去攻击VirusTotal后，VirusTotal可能会把本机的IP拉到黑名单里，而现在一些网络检测设备都可能去调用VirusTotal的接口检查样本（VirusTotal还有个提交样本MD5查询的接口，沙箱等很多安全设备经常会使用）如果本地有类似的安全设备，这样就可以把安全设备的VirusTotal扫描功能给搞废掉。
我尝试去打开攻击目标页面w0rm.in，却为什么总是响应超时？w0rm.in这个关键字仿佛直指一名俄罗斯黑客？攻击VirusTotal的行为真的和猜想一样吗？这一切会不会只是一次例行的压力测试？w0rm如果真的是一名黑客，那w0rm的初恋和木马作者的老婆究竟是不是同一个人？这背后是道德的沦丧还是人性的扭曲……敬请关注今晚25点30分的《走近科学》，让我们一起跟随镜头，揭开you call, i jmp那些鲜为人知的故事。