0day星期三——新型恶意软件遭遇战

发表评论
650 次浏览

A+

所属分类：网络安全

原文：http://www.gironsec.com/blog/2013/12/0day-wednesday-newish-malware-that-came-across-my-desk/

翻译：徐文博

可能有人会说这标题很疯狂，但我把它称之为“星期三”。

这款较为新颖的恶意软件是我昨天遇到的，今天就被我搞定了。它是一个老的2012 CVE的java攻击包（可能针对SecurityManager）的负载。压缩与解压缩的在VirusTotal/Malwr上都没有查到，所以这又是一个0day啊。

利用IDA进行初步检测，报出一个错误：

估计制作这家伙的兄弟也知道, 迟早某一天它会被像我这样的人拿来瞅瞅的。确实有许多的修改可以用来搅乱反汇编结果，而丝毫不影响Windows上的运行。

用CFF Explorer来看看，发现NT头部的一个错误在“Data Directories”的“Delay Import Directory RVA”项中。CFF很好的为我们指出0×00000040值是错的。将其清零就可以解决此问题。

保存修改的exe,在IDA中重新打开，之前的错误提示就消失了，一切正常。

在IDA里简单的过一眼就可以知道这是一个MFC程序。我咋知道的呢？在导入表的Library字段很清晰的表明了。

当然了，该程序被压缩了。没有节表修改，典型的内存压缩。

这就意味着静态的分析不再有效，我们需要动态分析来获得更多的信息。来吧，操起Immunity。

在开始immunity和虚拟机之前，exe文件里有些有趣的东西，没有很明显的在IDA里出现，但在CFF explorer里我们可以看到。首先，有几个隐藏在资源目录的文件凸显出来。

第一个是PNG文件。

然后是一个html文件。

在IfranView（最好的图像查看器）里浏览下该PNG文件，仅显示了一个很小的黑图片，这显然不足55kb大小。所以，里面肯定隐藏了点啥。呆会再来收拾它。

来吧，到你了,html文件。用notepad++加载清理，可以看到一些浏览器检测代码：

为啥这里仅是简单的放在了资源节表里，而不同其他代码一起压缩处理？真是个谜啊。先在脑海中记着这些资源节表，稍后处理。现在回头来解压这家伙。

首先开启Immunity调试器和VirtualBox，加载我们的anti-anti-debug python插件。

现在将这货运行起来，待其完全运行之后检测内存。

可以看到有些内存区间被标记为可读可写可执行（RWE)，分别在00910000，00930000，00940000和00970000。检测一番，发现4个当中仅有3个包含着代码。该程序仍然有3个隐藏的代码？太酷了吧。

现在我们要从内存中导出程序到文件里，便于后续的分析。使出OllyDumpEx，填入0090区间，可看到00910000和00970000的程序同原始的程序在大小、节表和属性上都匹配。而00950000处的内存与其他的不同：有不同的节表，不同的大小。一定是隐藏着彩蛋啊。

利用‘Binary(Raw)’模式而不是重新构建模式导出exe文件，这样可以保证导出的数据的完整性。

2个无用的节表表明程序被UPX进行压缩了。运行upx工具确认了这一点。意味着我们可以砸出彩蛋了。

新的exe文件正确的解压后多出了40KB，现在我们终于可以在IDA里瞅瞅了。看下strings，有些有趣的信息：

这是啥？HTTP请求信息。看起来这货使用POST请求回传数据啊。

你可能会问C&C服务器在哪呢？似乎不在程序的明文里。还记得前面提到的资源节表吗？再来看看彩蛋的资源节表吧。

瞧，http://31.207.6.161。作者就这样将其放在明文里，让我们捡了个大便宜。想通过隐匿来获取安全，没门。

我知道你在想啥，主程序运行起来是啥样呢？就让我们来看看吧：

一运行起来，就自动的关闭了我的process explorer，我要运行任务管理器都会被一闪而过的消息窗提醒“任务管理器已经被管理员禁用”。我也很想展示下截屏，但我动作实在没它那么迅速。动用Immunity打开，发现原始的“golden_egg.exe”不再运行。另一个名为“zpNvNKSi.exe”的程序从临时文件夹运行起来了。根据hash比较，其实是同一个程序：

喜欢我的哈希程序吗？到这下载吧。

广告时间结束了。现在很清楚该程序做啥了——禁用任务管理器，终止不受欢迎的程序，从临时文件夹运行。检查msconfig发现添加了2个自启动文件。

我对它们都进行了检查，确认正是原始程序的完全拷贝。

将程序附加到immunity，检测程序内存和线程数目(“t”键），显示出该程序是多线程的。我数了下，12个线程。

我猜测这些线程互相监控对方，以防被终止。然而将主程序挂起，用Process Explorer打开它，观察内存，通过检测，发现了一些IDA strings未看到的内容：

大胆猜测一下，我认为这货会检查这些程序，如果发现它们运行就强制结束它们。这就解释了当该程序运行时，process explorer为啥就被终止了。要运行这些工具就有点难了，有regedit，LordPE，wireshark，regmon，filemon，procmon，tcpview，taskmgr以及Windows Defender。吼吼，我没看到Process Explorer的小伙伴Process Hacker啊。

再来说内存，上面表明程序要么是混淆了那些字符串，要么就是进行了再次的压缩。不管哪个，把它揪出来。

对那些我们在Process Explorer中看到的字符串进行unicode格式的搜索，可以看到‘taskmgr’在.data节中。关于这些字符串，难道IDA骗了我们？完全不是这样的。再看一遍，慢慢的利用二分法搜索一遍，的确可以看到这些字符串。我猜IDA进行搜索时，默认的不显示unicode字符串。你可以在IDA中通过’alt+A’ 快捷键，选择6选项来更改。

检查这些新的unicode字符串，似乎该恶意软件还有更多的功能。

这才有趣啊。因为这货阻止了Wireshark的运行，我们需要定位到负责终止功能的地方，并进行修复。咋做呢？对TerminateProcess() API调用进行定位。这在IDA里很容易就能做到。在导入节表里我们看到一个对TerminateProcess的引用。

似乎是段循环，利用“CreateToolhelp32Snapshot”API遍历进程名称，如果满足条件，就终止掉它们。那些我们之前看到的黑名单似乎验证了这一点。

那我们能做点啥呢？改变程序的运行逻辑，使其不再调用TerminateProcess，也就没啥影响了。检查该部分的外部引用（Xref’s, eXternal REFerenceS), 可以看到函数为00401D2A所调用。有个‘jnz’指令负责决定是否调用那段负责查询、终止进程的过程处理。如果我们能修复这段程序，使其不再调用，将其跳过，就可以运行黑名单上的程序啦。