挖矿程序为你打开“天堂之门”

阅读量    59465 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

一、前言

过去两年可以称为勒索软件之年。毫无疑问,勒索软件是最为流行的一种恶意软件。但去年年底时,我们开始注意到一种现象,那就是勒索软件日渐式微,挖矿程序开始粉墨登场。这种趋势可能会延续到2018年,并随着时间的推进不断增长。

从受害者的角度来看,某种程度上这也算是一种解脱,因为挖矿程序不会像勒索软件带来巨大的安全风险。虽然挖矿程序的确会降低系统性能,但当你清除掉这些程序,就可以像之前那样继续使用自己的主机。你不会损失任何数据,这一点与勒索软件大为不同。

从恶意软件研究人员的角度来看,挖矿程序并没有太多吸引人的地方。这些程序不值得深入研究,主要是因为它们都是基于众所周知的开源组件开发而成,很少或者没有经过混淆处理。

然而,随着时间的推移,我们发现挖矿程序开始引入一些非常有趣的技巧。在最近发现的一个样本中,我们观察到了一种名为“天堂之门(Heaven’s Gate)”的技术,利用这种技术,恶意软件可以通过32位的加载器注入到64位进程中。这种技巧并不新颖,最早可回溯到2009年,但在捕获到的新样本中发现这种技术仍然是非常新奇的一件事情。

如果你是恶意软件分析方面的初学者,欢迎你继续阅读本文,了解什么是天堂之门,以及如何分析这种技术。

 

二、恶意样本

释放器 #17b3491e0028d443f11989efaeb0fbec2

我们在分析Ngay的后续攻击活动中找到了这个样本(参考此处了解更多细节)。在调查类似样本的过程中,我找到了@_qaz_qaz发表的一篇文章,这篇文章中介绍了某次攻击活动中出现的一个类似样本,但他在并没有分析天堂之门技术。

释放器 #2ed575ba72ea8b41ac2c31c8c39ce303b

32位的加载器(在第一阶段中释放出来):ca54fa2cf8a7e3e2cd457811f336de44

 

三、恶意行为分析

为了观察注入行为,我们必须在64位系统上运行这个样本。我们可以发现样本会运行notepad程序,程序使用的参数为典型的挖矿参数:

在ProcessExplorer中查看内存字符串时,我们可以清晰地看到正在运行的并不是真正的notepad程序,而是xmrig这个门罗币挖矿程序:

因此,目前我们可以确认一点,那就是内存中notepad的镜像已经被替换,攻击者很有可能使用的是RunPE(Process Hollowing)技术。

攻击者使用的是32位释放器,但它会将载荷注入到64位notepad中:

有趣的是,官方的Windows API并不支持这种注入方式。我们可以通过64位应用程序(使用Wow64 API)读写32位进程的内存,但不能反过来。

但还存在一些非官方的解决方案可以实现这个目标,比如名为“天堂之门(Heaven’s Gate)”的技术。

 

四、天堂之门概述

2009年,黑客Roy G. Biv首次提出了天堂之门技术。随后出现了各种适配程序,比如Wow64ext库以及W64oWoW64库。2015年,Alex Ionescu在一篇文章中介绍了针对此技术的缓解措施。

现在我们来看一下这种技术的工作原理。

4.1 在64位Windows上运行32位进程

在64位Windows上运行的每个32位进程都会运行在名为WoW64的一个特殊子系统中,该子系统可以模拟32位环境。我们可以把它看成在64位进程中创建的一个32位沙盒。因此,系统首先会为进程创建64位环境,然后在里面再创建32位环境。应用程序会在32位环境中运行,不能访问64位环境。

如果我们利用64位扫描器从外部扫描32位进程,我们可以看到该进程内部中同时包含32位和64位DLL。最关键的一点是,它包含2个版本的NTDLL:32位版(加载自SysWow64目录)以及64位版(加载自System32目录):

然而,32位进程无法看到64位环境,只能使用32位DLL。为了注入到64位进程中,我们需要使用64位版本的相关函数。

4.2 代码段

为了访问被禁用的64位环境,我们需要理解隔离机制的具体原理,事实证明这并不复杂。我们可以通过代码段中的不同地址访问32位及64位代码:32位的地址为0x23,64位的地址为0x33。

如果我们按照正常方式调用某个地址,那么系统会使用默认设置的模式来解析这个地址。然而,我们可以使用汇编指令显示指定具体使用哪种模式。

 

五、挖矿程序中的天堂之门

之前已经有人分析过这个挖矿程序,这里我们就略过完整分析,直接跳到比较有趣的那部分内容。恶意软件会检查运行环境,如果发现自己运行在64位环境中,则会执行另一个分支,注入64位进程:

经过一些反分析检查步骤后,恶意软件会创建一个新的、处于挂起状态的64位进程(本案例中创建的是notepad进程):

恶意载荷后面会注入到这个进程中。

前面我们提到过,为了将载荷注入64位进程中,我们需要使用64位的函数。

首先,加载器获得了64位NTDLL的一个句柄:

关于get_ntdll函数内部的处理过程需要进一步分析一下。作为参考,我们可以了解一下ReWolf库中的类似代码

为了访问进程所对应的64位环境,我们需要修改段选择器(segment selector)。来看一下这款恶意软件如何进入64位模式:

以上代码貌似直接来自于这个开源库:

https://github.com/rwfpl/rewolf-wow64ext/blob/master/src/internal.h#L26

段选择器0x33被压入栈中。随后,恶意软件会调用下一行:(通过这种方式,下一行的地址同样会被压入栈中)

压入栈中的地址加了5字节偏移量:

最后,程序调用了RETF指令。RETF代表“far return”,是一条远转移指令。与RET指令不同的是,该指令可以同时指定执行流程应返回的具体地址及段(segment)。该指令会从栈上获取两个双字(DWORD)作为参数。因此,当执行RETF指令时,实际的返回地址为0x33:0x402A50

成功完成段修改后,系统会把从该地址开始的代码解释为64位代码。因此,在调试器中看到的32位代码实际上是64位代码:

为了快速切换相应的代码视图,我选择使用PE-bear的一个实用功能:

这段代码解释成64位代码后如下所示:

可以看到,这段代码的功能是将R12寄存器中的内容移动到栈上的某个变量中,然后再切换为32位模式。这么处理的目的是为了获取64位的Thread Environment Block (TEB,线程环境块),从中可以获取到64位的Process Environment Block (PEB,进程环境块),你可以参考这段代码了解更多信息。

恶意软件使用64位的PEB作为起点来搜索64位的NTDLL。搜索方式比较直白,用到了指向已加载库的一个指针,该指针为PEB结构中一个字段(大家可以参考另一份代码,这份代码封装得比较好)。在PEB结构中我们可以找到名为Ldr的一个字段:

Ldr是类型为_PEB_LDR_DATA的一个结构体,该结构中包含名为InMemoryOrderModuleList的一个entry:

该列表中包含当前进程在内存中已加载的所有DLL。我们需要遍历这个列表,找到我们感兴趣的DLL(即NTDLL)。这也就是前面提到过的get_ntdll函数的具体功能。为了找到正确的名字,该函数会调用某个函数(我们将其标记为is_ntdll_lib),逐字符检查程序库的名字是否与ntdll.dll相匹配,如下所示:

如果名字相匹配,则通过两个寄存器返回这个程序库的地址:

找到NTDLL后,我们只需要找到正确的函数即可。我们可以浏览DLL的导出函数表来完成这个任务:

需要获取如下几个函数:

NttUnmapViewOfSection
NtGetContextThread
NtAllocateVirtualMemory
NtReadVirtualMemory
NtWriteVirtualMemory
NtSetContextThread

这些函数是RunPE技术中常用的函数。首先,NtUnmapViewOfSection函数用来取消原始PE文件的映射。随后,恶意软件分配远程进程所需的内存,将新的PE写入这段内存中。最后,恶意软件会修改该进程的内容,开始执行注入的模块。

恶意软件会保存这些函数的地址,稍后再调用这些函数来操控远程进程(参考类似代码)。

 

六、总结

目前为止,挖矿程序作者并没有给我们带来太多惊喜,他们非常依赖开源组件来实现预期目标。本文分析的这个样本也是如此,作者还是用到了之前已经实现的某种技术。

天堂之门这个技术几年前早已问世。出于隐蔽性考虑,某些恶意软件会用到这种技术。但就本文分析的这个挖矿样本而言,作者的真正目标可能是想在目标架构中使用适当的载荷,以最大化利用目标环境性能。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多