“DNS隧道”盗号木马分析——类似hjack偷密码然后利用dns tunnel直传数据发送出去

Posted 2020-10-10 将者，智、信、仁、勇、严也。

摘自：http://www.freebuf.com/articles/network/38276.html#

运行后不断监控顶端窗口，一旦发现为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的拦截截图是不能少的：