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

  • 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进行初步检测,报出一个错误:

p1

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

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

p2

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

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

p3

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

p4

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

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

第一个是PNG文件。

p5

然后是一个html文件。

p6

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

p7

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

p8

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

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

p9

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

p10

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

p11

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

p12

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

p13

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

p14

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

p15

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

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

p16

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

我知道你在想啥,主程序运行起来是啥样呢?就让我们来看看吧:

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

p18

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

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

p19

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

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

p20

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

p21

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

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

p22

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

strings

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

p23

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

p24

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

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

p25

开搞吧。 我比较喜欢用immunity进行修复,一是它简单,二来我也比较熟悉。定位到运行程序的子过程部分,进行条件跳转的指令在‘0x00401d4e’。将那片区域进行nop填充,使得指令流返回,而不是跳转到终止黑名单进程的00401d2c处。

p26

继续运行程序,开启一个被黑名单的程序进行测试。“regedit”也可以正常运转了,“process explorer”也没有被终止,我们成功了。

p27

p28

现在我们可以利用wireshark进行仔细的网络行为分析了,文件和注册表的分析利用procmon,好好的摆弄Process Explorer处理吧。

用Process Explorer看到程序通过80端口向我们前面挖掘出的C&C服务器发送一个syn包。

p29

Wireshark显示的更多。可以看到发向HTTP C&C服务器的syn包,也有一串的向未知域名的DNS请求。这是咋回事?

p30

服务器会继续回调,但我不想让它这样。可以修改“golden_egg.exe”中的资源节表,使其指向我自己的HTTP服务器,检查它的功能。还有很多可以干的,现在我们已经获得所需要的了,有了C&C地址,解压了程序,也有了它的HTTP特征以及它的行为。案子就这样结束了。又是一个收获的“星期三”啊。

如果你想下载该恶意程序,自己进行分析,可以在此进行下载,密码是‘infected’。

(全文完)

  • 我的微信
  • 这是我的微信扫一扫
  • weinxin
  • 我的微信公众号
  • 我的微信公众号扫一扫
  • weinxin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: