《深度剖析信息窃取工具DUQU2》由会员分享，可在线阅读，更多相关《深度剖析信息窃取工具DUQU2（25页珍藏版）》请在金锄头文库上搜索。
1、深度剖析信息窃取工具 DUQU2.0 木马0x00 前言今年年初，卡巴斯基实验室在安全扫描过程中，检测到了几个影响了自家内部系统的网络入侵行为。接着我们大范围调查了这些入侵事件。我们分析发现了一个全新的木马平台，这个平台出自 Duqu APT 小组之手。Duqu APT 小组是世界上最神秘，水平最高的 APT 小组。这个小组从 2012 年开始销声匿迹，直到今天又卷土重来。我们分析了这新一轮攻击，结果表明这是2011 年 Duqu 木马的升级版，怀疑与 Stuxnet 木马有关。我们把这个新木马和相关的平台命名为Duqu 2.0。Duqu 利用了 0-day 漏洞 CVE-2015-2360(
2、WindowsKernel 中的漏洞)和另外两个 0-day 漏洞，攻击了卡巴斯基实验室。微软在 2015 年 6 月 9 日修复了第一个漏洞，另两个漏洞在近期也得到了修复。0x01 木马剖析Filename:随机 / 根据具体样本而定MD5 (根据具体样本而定): 14712103ddf9f6e77fa5c9a3288bd5eeSize: 503,296 bytes文件属性MSI 文件具有一下属性Composite Document File V2 DocumentLittle EndianOS: Windows, Version 6.1Code page: 1252Title: 7080A
3、304-67F9-4363-BBEB-4CD7DB43E19D (randomly generated GUIDs)Subject: 7080A304-67F9-4363-BBEB-4CD7DB43E19DAuthor: 7080A304-67F9-4363-BBEB-4CD7DB43E19DKeywords: 7080A304-67F9-4363-BBEB-4CD7DB43E19DComments: 7080A304-67F9-4363-BBEB-4CD7DB43E19DTemplate: Intel;1033Last Saved By: 7080A304-67F9-4363-BBEB-4C
4、D7DB43E19DRevision Number: 4ADA4205-2E5B-45B8-AAC2-D11CFD1B7266Number of Pages: 100Number of Words: 8Name of Creating Application: Windows Installer XML (3.0.5419.0)Security: 4其他攻击中使用的 MSI 文件可能具有另外一些属性。例如，我们还发现了另外几个字段：Vendor: Microsoft or InstallShieldVersion: 1.0.0.0 or 1.1.2.0 or 2.0.0.0在 Windows
5、资源管理器的文件属性对话框中，可以查看某些字段。这个 MSI 数据包中有两个二进制文件：ActionDll 是一个 dll 文件，ActionData0 是一个经过 Camellia 加密，LZJB 压缩的数据payload(不同情况下的加密算法和压缩算法也不同)。实际上，经过加密或压缩的二进制数据块中，会有好几层可执行代码。在后面的文章中，我们详细地说明了这些组件。第一层：ActionDLL(msi.dll)原文件名: msi.dllMD5: e8eaec1f021a564b82b824af1dbe6c4dSize: 17920 bytesLink 时间: 2004.02.12 02:04:
6、50 (GMT)类型: 64-bit PE32+ executable DLL for MS Windows这个 DLL 只有一个 StartAction 导出函数，msiexec.exe 进程的上下文会调用这个函数。当这个函数被调用时，这个函数就会获取一个 MSI 属性-PROP，并用这个值来解密 actionData0包。接下来，这段代码会遍历 12 个需要解密并启动的 payload。这些 payload 是 MSI 的一部分，可能会包含以下名称：ActionData0, ActionData1, ActionData2。我们的这个数据包中只包含一个 paylioad-“ActionDa
7、ta0”。第二层：ActionData0主代码会被压缩和加密到这个二进制数据包中。这个二进制的组成包括可执行程序，位置无关代码块，和内嵌的数据对象。这些代码似乎遵循着某种框架，使用了很多辅助结构。辅助结构中包含了一些系统 API 的指针和内部数据块的偏移量。这些结构能反映出开发者的风格。当代码初始化时，一个字段(一般是前四个字节)中的 magic 值就会识别结构的状态和类型。这名编码员还喜欢根据模块和输出名称的哈希来导入系统 API。在可执行代码的很多层上都使用了这个哈希算法。通过两个 DWORD 常量就能识别： 0x8A20C27 和 0x67F84FC6。一般情况下，ActionData0
8、 中的代码会在一个内嵌的可执行程序-“klif.dll”上运行，由这个DLL 文件的导出函数表上的第二个函数执行。也就是说，函数名称无所谓，就是要按照函数表上的顺序。当调用这个导出函数时，下一阶段的辅助结构指针就会传递到这个函数上，这样指针就能使用上一层中设置的一些值。但是，在 klif.dll 执行之前，代码会尝试另一条路径。首先，代码会查找“api-ms-win-shell-XXXX.dll”，其中 X 可以是任意的十进制数。如果当前进程中没有这种名称形式的模块，名称就是无效的。这样的话，代码就会遍历查找任何符合名称形式的模块，首先从 api-ms-win-shell-0000.dll,
9、api-ms-win-shell-0001.dll, api-ms-winshell-0002.dll 开始。这应该是 Duqu 平台组件的一个依赖选项。在找到名称后，代码会尝试按照名称来映射内核(section kernel object)对象，这些名称是使用 PRNG 算法生成的。节名称的格式 “BaseNamedObjectsXXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX”，其中 X 是根据当前系统的启动时间生成的十六进制数字。到目前为止，节名称都是根据“machine/boot time” 来确定的，这样每个节名称都不一样，但是如果有其他模块的进程也使用了相同的名称生成
10、算法，进程就能定位这样的节。以 OSBoot 节为例，一旦生成了节名称，代码就会打开节，如果能找到节，代码就会从节中选取几个值，然后尝试打开特定的设备，并把 ICTL 代码发送到驱动上。驱动设备的名称和 IOC 代码都在KMART.dll 内的一个节中。这名编码员非常喜欢用节来访问数据。在映射 klif.dll 的代码 /数据时，还是要用节。另外也可以通过硬编码 magic QWORD 数: 0xA1B5F8FC0C2E1064 来找到这个节。一旦在当前进程的地址空间中找到了节，就由这个节来运行代码。当前的 MSI 文件数据包并不能应用这种执行路径，但是这种执行路径出现在了代码中，我们猜测这可
11、能是为了使用通用代码模版来创建当前的 MSI 数据包。当然，这也说明，其他的 Duqu 平台组件还具有另外的特征。第三层：klif.dllOriginal filename: klif.dllMD5: 3fde1bbf3330e0bd0952077a390cef72Size: 196096 bytesLink time: 2014.07.06 08:36:50 (GMT)Type: 64-bit PE32+ executable DLL for MS Windows很显然，这个文件伪装成了卡巴斯基产品的名称-“klif.sys”。虽然代码和文件信息与卡巴斯基产品完全不同，但是，这个模块的导出函
12、数名称使用了卡巴斯基实验室的缩写：KLInit 和 KLDone。当这个 DLL 加载到一个新进程中时，DLL 的内部结构就会初始化，比如给系统 API 提供指针的结构。这个模块的 payload 位于 KLDone 导出函数上，是导出函数列表上的第二个函数。这个导出函数是从上一层代码中调用的。 首先，模块会确保全局应用结构和关键函数 ntdll.dll, kernel32.dll and user32.dll，已经初始化。在调用系统 API 函数时，需要使用导出函数名称的哈希。哈希算法与前文提到的算法相同，并且也使用了相同的 magic 常量：0x8A20C27 和 0x67F84FC6。接
13、下来，代码会遍历正在运行的进程列表，并且获取每个进程的小写名称哈希。这个哈希可以是 0x3E3021CB 的硬编码值，也就是 “avp.exe”字符串的哈希。攻击 AVP.EXE如果“avp.exe ”进程正在运行，模块就会尝试打开 OSBoot-section，并且尝试攻击 avp.exe进程。攻击开始时，首先遍历下列产品的硬编码注册表项和注册表值，来识别卡巴斯基产品的安装路径： 在模块所查询的注册表值中包含了卡巴斯基产品的根目录路径，如“C:Program FilesKasperskyLabKaspersky Internet Security 15.0.0”一旦找到了注册表项和注册值，模
14、块就会确认 avp.exe 是不是在那个路径下面。另外它还会对文件执行一些额外的检查:环境变量的检查,文件能否被读取的检查,是否是一个 PE 文件的检查.之后这个模块执行如下动作:1.把 avp.exe 映射到它内部 2.改变内存区域的属性让代码执行 3.改变 avp.exe 内的字符 4.使用 SSE2 CPU 扩展对 avp.exe 打补丁.接着，模块会尝试启动一个新的线程，线程的开始位置就是其中一个补丁的位置。到目前为止，新的线程会首先调用 avp.exe 模块，这个模块会执行其他的一些调用，比如，跳回到 klif.dll。很显然，这次攻击是为了让 avp.exe 相信后续的调用是安全的
15、，相信调用堆栈是来自一个合法的 avp.exe 模块。继续研究代码，发现：新线程会立刻从 avp.exe 跳转会klif.dll，并且会尝试与卡巴斯基产品的微过滤器，也就是 klif.sys 通信。事实上，在与 klif.sys 通信之前，新线程会打开 OSBoot-section，并获取一个 IOCTL 代码和驱动设备的名称，然后把这个 IOCTL 代码发送给设备。这个节和相应的驱动(KMART.dll) 会给当前模块提供一定的支持。代码会获取当前进程名称的哈希，并且验证哈希是不是下列三个哈希之一：0x3E3021CB (avp.exe), 0xDE6D4DA0 (msiexec.exe),
16、 0xB915B2D8 (rundll32.exe)。如果能识别当前进程名称的哈希，模块就会打开KlifComm 微过滤器的通信端口，并且发送一些驱动通信信息，来和 klif.sys 通信。通过分析这些信息，我们发现这项技术能让 klif发现不了进程或线程操作。所有的杀毒产品都会认为这个注册过的项目是受信任的，所以不会扫描其活动，也不会检测或拦截其进程。另外，这个模块会要求卡巴斯基产品的自我防御支持，这个功能是防止木马利用系统技术来杀掉安全产品的进程。这样的话，即使是管理员用户也无法终止模块的进程。我们测试了卡巴斯基的其他一些产品，结果发现，这些产品都会检查进程的自定义数字签名来验证 caller 进程。截至目前，如果没有额外的驱动支持，这项技术不会成功。从 2010年开始，如果有进程尝试打开KlifComm 微过滤器的通信端口，卡巴斯基的产品就会验证这些进程的数字签名。这种攻击只能影响旧版的卡巴斯基产品，比如在 2009 年发布的KIS2010。 一般来说，攻击者现在不
