360技术博客：“DNS隧道”盗号木马分析

admin

360技术博客：“DNS隧道”盗号木马分
盗号木马相信大家都不陌生。随着网络越来越普及，网上的账号密码越来越重要，盗号木马的生命力也就越发的顽强了。
随着与杀毒软件的对抗，盗号木马也在不断的更新换代。QQ粘虫就是一个很典型的例子，这类木马的特点可以参考我们之前写过的博文《“神奇”的qq粘虫之旅》。而最近我们又监控到了QQ粘虫中的一例新变种，其主要的突破在于将盗取的信息通过网络发送出去的方法，思路颇为新颖，分享出来与大家共同把玩。
预热
从行为上来看，这其实就是个普通的QQ粘虫木马而已：
伪装成一个文件夹，诱导用户点击

运行后不断监控顶端窗口，一旦发现为QQ，就弹出一个自己伪造的QQ登陆窗口，诱导用户输入密码


编码与发送
如果你不幸输入了密码并点击了登陆，那么请节哀——你中招了。你的QQ号和密码这些隐私数据正在木马指令的授意下，被你自己不惜高价买下的高性能CPU和内存飞速的进行着编码，并最终由你所钟爱的那块网卡发送到盗号者的服务器上……这绝对会是一个忧伤的故事……
但木马的编码过程却颇费周章：
首先，是将一个固定字符串“aaaaaa”与你的QQ号和密码这三组字符串，以制表符(’\t’)相连，拼成一个新的字符串，并将其转为UTF-16编码

然后，将上面的拼出的字符串的字符数(非字节数，实际上由于是UTF-16编码，字符数是字节数的1/2)，保存为大端的WORD形式

接着，再将之前得到的账号信息字符串取Hex字符串后再次进行UTF-16编码……
我自己说着都乱……举个例子，字符’a'，也就是’\x61′，UTF-16编码后就是’\x61\x00′，取Hex字符串就变成了’6100′,也就是’\x36\x31\x30\x30′，再UTF-16后则是’\x36\x00\x31\x00\x30\x00\x30\x00′
好吧，我猜大部分人还是晕……直接给大家看看最终结果吧，你的账号信息已经变的面目全非了：

同时，前面获取到的字符数也做同样的处理，并拼到上面这个字符串的前面，如下：

最后，以16字符为一批进行循环加密，并将加密后数据转成UTF-16编码的Hex字符串，最终结果如下：

这么麻烦，当然是为了绕过各种检测和分析系统，但同时还有一个目的——盗号者需要加密后的结果依然保持所有字符必须只有字母和数字组成(理论上还可以有连字符)。
这是为了给这个木马最关键的一步做好铺垫——以DNS查询的形式将账号信息发送出去!
木马在内存中将加密后的字符串，前面拼上”www.”，后面拼上”.cn”，得到了一个根本不存在的域名。再填上必须的结构，精心构造出了一个DNS查询数据包。

再将这个数据包用UDP协议发送到了自己的服务器的53端口——一切看起来都如此的天衣无缝。
一个DNS查询而已，没有额外的非法数据，只是查询了一个不存在的域名，伪装的够深了吧!
百密一疏
但其实，通过Wireshark抓包还是可以看到一个很讽刺的事实——这个数据包依然是畸形的!根本不是正常的DNS查询。

根据Wireshark的报错信息，可以看到问题出在Queries这一段上，那具体是哪里异常了呢?QNAME部分的每个Label和前面的字节数都能对应上，QType是0×0001——A类请求，QClass是0×0001——IN。看着好像都没错啊?
其实问题还就是出在了木马作者精心拼凑的这个加密字符串上，这一段Label的字节数为0×80——即128字节。而DNS请求的数据结构中队Label的长度可是有严格的规定的：
Labels must be 63 characters or less.(参考RFC882 [Page30])
也就是说Label被允许的最大长度只有63字节——即0x3f，只要超过了这个值，即为畸形!
最后
360的拦截截图是不能少的：

同时也再次提醒大家——不要随意执行网上下载下来的程序，发现涉及到账号密码的异常状况，更要慎之又慎。在这个信息的时代，你的任何一些看起来无关紧要的数据的泄露，都可能成为黑客手中的重要社工数据——信息安全无小事。




来源：网络转载

---