0x00 前言
今年年初，卡巴斯基实验室在安全扫描过程中，检测到了几个影响了自家内部系统的网络入侵行为。
接着我们大范围调查了这些入侵事件。我们分析发现了一个全新的木马平台，这个平台出自Duqu APT小组之手。Duqu APT小组是世界上最神秘，水平最高的APT小组。这个小组从2012年开始销声匿迹，直到今天又卷土重来。我们分析了这新一轮攻击，结果表明这是2011年Duqu木马的升级版，怀疑与Stuxnet木马有关。我们把这个新木马和相关的平台命名为"Duqu 2.0"。
Duqu利用了0-day漏洞CVE-2015-2360（WindowsKernel中的漏洞）和另外两个0-day漏洞，攻击了卡巴斯基实验室。微软在2015年6月9日修复了第一个漏洞，另两个漏洞在近期也得到了修复。
0x01 木马剖析Filename:随机 / 根据具体样本而定MD5 (根据具体样本而定): 14712103ddf9f6e77fa5c9a3288bd5eeSize: 503,296 bytes文件属性
MSI文件具有一下属性
其他攻击中使用的MSI文件可能具有另外一些属性。例如，我们还发现了另外几个字段：
Vendor: Microsoft or InstallShieldVersion: 1.0.0.0 or 1.1.2.0 or 2.0.0.0
在Windows资源管理器的文件属性对话框中，可以查看某些字段。
这个MSI数据包中有两个二进制文件：
ActionDll是一个dll文件，ActionData0是一个经过Camellia加密，LZJB压缩的数据payload（不同情况下的加密算法和压缩算法也不同）。实际上，经过加密或压缩的二进制数据块中，会有好几层可执行代码。
在后面的文章中，我们详细地说明了这些组件。
第一层：ActionDLL（msi.dll）原文件名: msi.dllMD5: e8eaec1f021a564b82b824af1dbe6c4dSize: 17’920 bytesLink时间: 2004.02.12 02:04: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-“ActionData0”。
第二层：ActionData0
主代码会被压缩和加密到这个二进制数据包中。这个二进制的组成包括可执行程序，位置无关代码块，和内嵌的数据对象。这些代码似乎遵循着某种框架，使用了很多辅助结构。辅助结构中包含了一些系统API的指针和内部数据块的偏移量。这些结构能反映出开发者的风格。当代码初始化时，一个字段（一般是前四个字节）中的magic值就会识别结构的状态和类型。
这名编码员还喜欢根据模块和输出名称的哈希来导入系统API。在可执行代码的很多层上都使用了这个哈希算法。通过两个DWORD常量就能识别：0x8A20C27和0x67F84FC6。
一般情况下，ActionData0中的代码会在一个内嵌的可执行程序-“klif.dll”上运行，由这个DLL文件的导出函数表上的第二个函数执行。也就是说，函数名称无所谓，就是要按照函数表上的顺序。当调用这个导出函数时，下一阶段的辅助结构指针就会传递到这个函数上，这样指针就能使用上一层中设置的一些值。
但是，在klif.dll执行之前，代码会尝试另一条路径。首先，代码会查找“api-ms-win-shell-XXXX.dll”，其中X可以是任意的十进制数。如果当前进程中没有这种名称形式的模块，名称就是无效的。这样的话，代码就会遍历查找任何符合名称形式的模块，首先从api-ms-win-shell-0000.dll, api-ms-win-shell-0001.dll, api-ms-winshell-0002.dll开始。这应该是Duqu平台组件的一个依赖选项。
在找到名称后，代码会尝试按照名称来映射内核(section kernel object)对象，这些名称是使用PRNG算法生成的。节名称的格式“\BaseNamedObjects{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX}”，其中X是根据当前系统的启动时间生成的十六进制数字。到目前为止，节名称都是根据“machine/boot time” 来确定的，这样每个节名称都不一样，但是如果有其他模块的进程也使用了相同的名称生成算法，进程就能定位这样的节。以OSBoot节为例，一旦生成了节名称，代码就会打开节，如果能找到节，代码就会从节中选取几个值，然后尝试打开特定的设备，并把ICTL代码发送到驱动上。驱动设备的名称和IOC代码都在KMART.dll 内的一个节中。
这名编码员非常喜欢用节来访问数据。在映射klif.dll的代码/数据时，还是要用节。另外也可以通过硬编码magic QWORD数: 0xA1B5F8FC0C2E1064来找到这个节。一旦在当前进程的地址空间中找到了节，就由这个节来运行代码。当前的MSI文件数据包并不能应用这种执行路径，但是这种执行路径出现在了代码中，我们猜测这可能是为了使用通用代码模版来创建当前的MSI数据包。当然，这也说明，其他的Duqu平台组件还具有另外的特征。
第三层：klif.dllOriginal filename: klif.dllMD5: 3fde1bbf3330e0bd0952077a390cef72Size: 196’096 bytesLink time: 2014.07.06 08:36:50 (GMT)Type: 64-bit PE32+ executable DLL for MS Windows
很显然，这个文件伪装成了卡巴斯基产品的名称-“klif.sys”。虽然代码和文件信息与卡巴斯基产品完全不同，但是，这个模块的导出函数名称使用了卡巴斯基实验室的缩写：KLInit 和KLDone。
当这个DLL加载到一个新进程中时，DLL的内部结构就会初始化，比如给系统API提供指针的结构。
不甚酒力，体会不了酒的美味，但却能感受知已的妙处。
