引言

2017年3月7日，维基解密首次在其网站对外曝光了美国中央情报局（CIA）相关资料，并且代号为Vault7[参考链接: 5]，并且从当月直至9月7日每周都会对外披露其中一个项目的相关资料内容[4]。在这批泄露资料中，主要涉及其相关网络武器库和行动项目的代号和对应文档介绍，鲜有具体的涉及implant（植入物）的技术实现和利用细节。

2017年4月，国外安全厂商赛门铁克和卡巴斯基分别发布了对相关网络武器库的研究报告，其分别命名为Longhorn[1]和The Lamberts[2]。在相关的研究报告中给出了涉及多种网络武器的命名和分类，以及其归属的关联性判断依据等，但涉及实际技术分析的内容依然很少。

奇安信威胁情报中心红雨滴团队对历史曝光的CIA网络武器及相关资料进行研究，并发现了多种网络武器文件，并且根据分析的结果与现有公开资料内容进行了关联和判定。并且我们还发现这些网络武器曾用于攻击中国的目标人员和机构，其相关攻击活动主要发生在2012年到2017年（与Vault7资料公开时间相吻合），并且在其相关资料被曝光后直至2018年末，依然维持着部分攻击活动，目标可能涉及国内的航空行业。

本报告是结合对具体网络武器样本的技术分析，并与公开情报中的相关资料和代号相对应起来。

网络武器

Athena（雅典娜）项目

简介

Athena（雅典娜）项目是维基解密于2017年5月19日披露的，其用于在Windows系统（从XP到Windows 10）上提供远程信标（beacon）和程序加载的木马程序，从其功能介绍也可以推断出其更可能用于获取到攻击立足时，向目标主机植入的攻击模块，并用于加载和执行下阶段载荷。Athena是由CIA与美国本土的Siege Technologies公司合作开发的（后者于2016年被Nehemiah Security收购）。

我们找到了和Athena相关的样本文件，并且发现其就是卡巴斯基报告中提及的Black Lambert。

Loader模块

这里对样本进行分析，该样本也在卡巴报告中的Black Lambert中所提及，该样本曾出现在利用Windows 字体0day漏洞CVE-2014-4148的攻击事件中。可以看到其导出函数并不是正常的字母名字，而是一个数字编号。我们也发现这一特征在多种攻击样本中出现，这也符合Vault7相关泄露资料中，其关于相关攻击代码的开发的约定策略。

样本运行之后首先会检测一些windows中的指定进程是否存在（可以看到这些都是一些比较少见的windows相关进程），如果存在则获取对应的processid，否则获取当前进程的processid，用于之后的注入。

其从样本指定偏移的位置读取payload，这个字段的偏移通过遍历节表，找到正常节代码最后的部分，该部分是一个去掉头的payload，获取到对应的位置后，读取其中的内容并修复对应的pe头，并且加载执行。

Payload模块

Loader模块释放的pe文件如下所示，从该后门的函数量可以看出这是一个功能复杂的攻击模块，其入口函数为winlib_1。

其实现了非常丰富的控制指令，其中也包括一些特殊功能，如：

支持GUI程序的后台点击；

支持作为隧道转发工具；

使用共享命名管道实施横向移动和模块执行。

字符串解密算法

该后门对其中使用的字符串都进行了加密，每一个加密的字符串实际上是以下的格式保存的，即前四个字节保存了加密字符中block的个数，通过xor key保存，每个block 4个字节，通过do，while循环中的算法解密。

控制指令

控制指令相关同样是加密存放，下面对解密后的部分重要指令进行说明：

其中cmd_catInstall通过共享的方式传播下发后续的载荷，代码下发之后删除该共享，所以这里其实需要攻击者获取到相关设备的访问凭据，否则无法设置对应的共享。

关联和归属

从下图可以看到Payload模块实现的指令几乎涵盖了维基解密泄露的Athena项目文档中所提及的所有相关控制指令。这也是我们将Black Lambert和Athena项目相关联的原因。

下阶段植入物

下阶段植入物是由Payload模块通过IPC$共享方式下发和执行的，并且在分析过程中，我们确实找到了相关的佐证依据。

下阶段植入物为一个dll模块，其落地文件名可能以随机字符串文件名或伪装成网络协议相关，如Winhttp32，winDNS，winftp32，winrdp64等。其启动主要通过两种方式：一是通过远程IPC管道利用regsvr32注册安装，二是首次在目标机器安装后，后续以服务形态执行和持久性维持。结合其启动方式特点，推测该模块主要用于内网横向移动阶段，并维持持久性。

这里我们以模块名为winhttp32.dll为例分析，其主要通过服务的方式启动：

将自身注册为NativeService的服务。

其通过命名管道的方式，和自身拷贝的子进程进行通信。

其实现了包括可以注入代码到进程，获取系统版本信息以及执行代码的三种功能。

关联和归属

在分析过程中，我们发现下阶段植入物用于运行不止一种载荷类型，其中常见的为分发运行Fluxwire Node模块，以及另外一种未知的执行模块。

Fluxwire Node

简介

Fluxwire是CIA为了实现mesh networking而创建的项目，在泄露的文档中包括了一份关于Fluxwire的Linux版本控制端的介绍和使用手册：

通过手册内容，可以看到整个fluxwire是支持多个平台，覆盖了window，linux，mac os等，且支持多个指令集的平台。

从文档中可以看到fluxwire一直到2015年11月都还在更新，遗憾的是整个fluxwire的文档主要在说明相关的攻击端使用，对用于失陷机器上植入的木马的设计并未详细介绍，只是说明其植入的模块称为Node。

Node模块

如下所示可以看到其依赖于两个参数，这两个参数为命令行中的argc，argv。Node模块启动时确实会传入一个文件路径参数，并通常伪装成数据文件，结合Node模块的功能分析，我们推测该数据文件才是具体的功能核心实现。

进入fun_Entry，首先判断参数是否为2，即是否传入了路径参数，之后读取参数路径文件中的内容，并搜索指定偏移的位置，根据该偏移进行后续的解密及倒入表的修复。

寻找偏移的算法如下，找到0x4286A1F5，且其后0x2c为0xF3D781AF的地址。

之后调用后续的模块，由于传入的文件无法获取，因此不知道攻击的后续。

在分析中，我们发现Node模块通常伪装成Netmeet.exe，而Netmeet是微软在Win95到WinXP内置的VoIP程序，Vista以后被移除。这也许就是在后续的失陷机器上我们没有找到对应伪装成netmeet载荷的原因之一。

关联和归属

在分析的样本中包含了一个PDB路径未被移除。

c:\users\bot\fluxwire-cmake\delta\mswin-x86\build\base\cmake\ddk_node\objfre_wxp_x86\i386\node.pdb

其中的pdb路径包含了fluxwire和node的关键词。我们直接google相关关键词，可以找到泄露的fluxwire相关文档时间是在2015年11月，而我们看到的包含了pdb的文件却是在2015年3月进行的攻击，因此存在嫁祸的可能性较小。

结合文档中对Node启动方式的介绍：

从文档中我们可以得知其Node程序在Windows下会以cmd.exe或者CreateProcess两种方式启动。在分析过程中我们确实找到了两种启动方式的证据，而后一种启动为则是通过winhttp32模块启动后通过命名管道执行的。

另一种横向移动模块

在分析中，我们找到了另一个直接通过winhttp32模块启动的载荷，但代码实现和fluxware node不同。

其主函数很简单，就是一个简单的loader。

首先通过动态获取函数地址的方式，获取到socket相关的函数，之后通过xor0x7F的方式解密的对应的cc。通过解密我们发现cc只是一个内网地址，因此基本可以确定，该模块是用于攻击者已经控制了内网中的一台主机，并将其转化为了对应的cc节点。

下载cc下发的模块，经过处理后设置内存页属性，并启动。

我们在研究Fluxwire使用手册时，其确实是支持在内网下做更多模块下发，并且有的还支持命名管道的通信方式。由于缺乏必要的证据链，我们暂时无法猜测该模块和Node的更多关联性。

Gray Lambert

我们找到了几个样本和卡巴报告中的Gray Lambert相似，由于暂未和CIA已知项目联系起来，所以这里延续卡巴的命名。

Loader模块

poolstr.dll是一个服务启动的dll，其可以由winhttp32模块启动。

其首先会读取资源，并解密。原始资源和解密后的字符串如下。

通过访问注册表的SYSTEM\CurrentControlSet\Services，这里应该是利用的lanmanserver，并写入Parameters下的ServiceDll。

接下来动态获取文件相关API，分配内存，并创建线程

从上述来看该dll应该是主要维持持久化的。

另一个Loader模块

msapi32.dll同样是一个服务dll。其有两个资源文件：

在线程中首先解密两个资源，1024资源是解密释放文件的路径：

然后从1023资源解密tlb文件，并写入目标路径，最后将其运行。

我们在一个主机上看到poolstr.dll和msapi32.dll几乎同时存在，我们推测poolstr是用来持久化运行msapi32.dll的。

Payload模块

mwapi32是一个网络流量监控和过滤模块，是由msapi32.dll从资源释放加载。

其首先尝试通过驱动获取过滤的流量。该dll会从下图的注册表项获取Description值，其中存储的是驱动注册的文件名，从而实现和驱动的通信。

若不存在对应驱动，那么其采用Windows的ETW机制来实现网络流量的过滤。其会启动ndiscap服务。

接着通过etw机制对网络日志进行监控。

其注册的监控session名为“K432ISD”加上一个UUID字符串。

White Lambert

在分析过程中，我们发现了多个样本与卡巴披露的White Lambert类似，其包含一个用户态dll和NDIS过滤驱动。

用户态模块

该样本为一个dll，其导出函数如下所示，其主要功能在DllMain中，该样本最终加载一个驱动。可以看到部分导出名同样以数字序号的形式存在。

DllMain中开启新线程以执行主要的功能。

样本中的主要字符串经过加密，加密算法如下，前四字节中保存了xor 后的长度，之后按4字节一个block的模式进行解密。

之后从中解密出两个驱动，并分别加载，其中驱动的加密方式和字符串一致，并通过RtlDecompressBufferat解压缩，相关驱动的信息保存到一段名为var_Driverinfo的内存中，其中第一个加载的驱动应该是一个测试驱动，第二个驱动才是真正的恶意代码。

var_Driverinfo格式如下所示

之后设置对应的服务注册表，并通过函数NtLoadDriver将对应的驱动加载运行起来。

可以看到第一个驱动为speedfan.sys，第二个驱动为UNC.sys。

可以看到speedfan实际上是一款系统监控相关的软件。

Speedfan.sys入口如下，简单创建了一下设备及对应的设备链接，对应的MajorFuncton中的dispatch函数也只是针对系统层的调用返回一些参数，因此这个地方猜测其作用应该是作为第一个驱动先加载，以确保其能正确加载起来，再加载之后的恶意驱动。

恶意驱动如下所示，加载之后首先同样是通过和之前一致的算法在配合RtlDecompressBufferat解压出最终的驱动，并寻址到入口并调用。

驱动模块

这个驱动似乎并不能通过osr driverloader的方式进行加载，因此推测其应该有自己实现的加载器。

这个驱动本身是一个加载器，解密出的内容是一个pe文件，其同样是个驱动。

后续解密的驱动是一个通过ndis流量过滤的rookit，通过过滤指定的cc流量以实现具体的功能，函数首先通过fun_Searchndissys确保系统中存在ndis.sys驱动，之后在函数fun_NdisRegisterProtocol中通过ndis注册了一个自有的协议，通过这个的回调来过滤对应网卡中的流量数据。

如下所示，fun_NdisRegisterProtocol中实际调用的是NdisRegisterProtocol，该函数用于注册一个自有的协议，其中的第三个参数中包含了对应的协议回调函数，这里奇怪的是这些回调函数似乎都没有实现，其中包含最终重要的ReceiveHandler（表示网卡收到数据时，会把对应的流量传入到该回调函数中），这里需要注意的是，攻击者注册的自有协议名为“KAPERSKY”与卡巴斯基名称kaspersky仅一字之差。这个函数最后将NdisRegisterProtocol注册成功之后的ndis句柄给返回了。

前面说到自有协议在实现的时候并没有设置回调函数，但是事实上并非如此，通过返回的ndis句柄直接在内存中搜索对应的TCPIP字段，然后将其中的内存地址替换成具体的函数，这里猜测，应该是通过ndis句柄的方式搜索回调函数在内存中的位置，并手动替换（因为驱动本身是在内核中，因此是可以通过一个句柄搜索到具体的回调对象中函数指针的位置的）。

通过流量过滤出攻击这个特殊流量，解析之后通过va_Dispitchtable调用指定的处理函数，如下所示可以看到THIS_IS_OUR_EOF，这句话的意思就是“这是我们的流量”

整个样本支持的功能如下所示：

Backdoor.Trojan.LH1

我们结合Twitter上一条相关推文进行扩展。

根据该推文的线索进行拓展，我们发现其中一个样本被检出为LH1，即为赛门铁克报告中提到的一类后门。

其注册为BiosSrv服务运行。

主体逻辑通过创建线程执行，并且随机休眠一段时间。

其首先从资源当中提取C2和PFX证书信息，其中101为PFX证书，102为域名。

PFX证书导出key为空，通过“opensslpkcs12 -in 1.pfx -out 1.key”命令导出其中的证书和私钥信息。

然后获取主机信息，包括Mac地址，计算机名，以及当前用户。

创建注册表SOFTWARE\\BiosInnovations，生成用户UUID，该UUID会作为标识并用于后续HTTPS通信头部的X-MV-Host字段。

该模块与远程服务器域名进行HTTPS通信，并接收如下指令：

Green Lambert

Green Lambert为可执行文件，并且与LP（Listening Post）通信。其也是唯一一个目前发现同时存在Windows版本和Mac版本的项目。

Windows版本

该样本为一个exe，通过分析之后发现这个样本的主要功能用于和远端的LP进行连接设置，同时具备浏览器相关凭据窃取及模块加载的功能。

代码的入口如下所示，首先通过函数fun_Init进行初始化，之后创建一个服务运行之后的主流程，服务名为smcsrv。

该样本中fun_init的操作中做了很多有意思的操作。

首先在fun_getallstr中一次解密出大量之后使用的字符串。

之后在fun_Getconf中解密出对应的配置文件，其中可以看到远端的LP配置。

在fun_InitfunBlock中按功能函数地址+功能字符的格式将对应的功能函数保存到一块内存中，如下所示可以看到其主要功能是设置对应的LP及简单的模块装载功能，其实现的指令集比Black Lambert少一些。

和LP通信，首次连接主要通过.login.php及getconf.php做登陆及配置文件更新的操作。

通过getfile.php下载后续攻击代码。

通过upload2.php上传相关数据。

同时该样本通过访问signons.sqlite文件获取firefox相关的凭据，需要注意的是firefox从2017年之后就将相关的文件由signons.sqlite变成logins.json。

通过pstorec.dll的PStoreCreateInstance函数来提取IE凭证信息。

使用guid “abe2869f-9b47-4cd9-a358-c22904dba7f7”解密保存的IE密码。

如下所示可以看到该样本中生成的函数结构体和BlackLambert也是完全一致的。

早期版本

我们还发现一个dll版本，其中的配置文件没有加密，猜测是早期的版本。

提取所有Windows版本的GreenLambert如下所示，第一列为配置文件中提取的样本id，其中红色的版本在卡巴的文章中出现过，而其他的版本则是之前未知的，这里猜测其每一个样本在攻击的行动中设定了特定的代号。

Mac OSX版本

Green Lambert存在一个Mac OSX版本。

其导出表中可以看出存在诸多初始化执行的方法，其会在main函数前执行。其主要用于初始化一些功能函数指针和参数。

例如这里将对应的函数指针添加到一个链表中，保存在全局的指针中。

可以看到这里有个版本号信息

这里对20个InitFunc的接口功能进行总结：

main函数中会解析传入的启动参数：

字符串解密算法

样本中所有字符串均被加密：

其中第一个字符通常为0，第二个字符为待解密字符串长度，第三和第四字符计算成xor key，从第五个字符起为加密字符串。

关联和归属

Green Lambert的Windows和Mac OS版本使用了几乎完全一样的字符串解密函数版本。

而Windows版本中解密的配置脚本的id字段和卡巴斯基文章提到的是一致的，因此确定这一系列的样本为Green Lambert。

其他

在分析中，我们还发现一些与CIA网络武器相关的样本文件，但暂时未发现其与上述网络武器之前的相互关系。

Stolen Goods

简介

Stolen Goods是CIA用来实现持久性的一个项目，其用于持久化Grasshopper安装器和Shellterm的shellcode注入程序。其涉及的一些文件如下，我们找到了其中一个内存加载模块的样本。

内存加载模块

从Stolen Goods文档中发现有个样本命中。从文档上得知其应该是内存加载器。其首先动态获取底层文件读写API：

然后物理读写文件

读取文件后，计算其sha256值

将生成的sha256格式化为以下字符串的驱动路径，然后和其通信。

然后从自身文件句柄中查找843和304号资源，并解密。但在这个dll中并未看到对应的资源文件。

最后将其加载到内存中。

控制基础设施

从维基解密披露文档我们得知CIA用于控制基础设施部署的项目名为HIVE，其由EDB部门所开发。下图是我们根据泄露的HIVE资料对其内部说明设计图进行了部分备注。

HIVE分为3个部分，implant，LP和CC。

其中Blot为隐藏的服务器。Honeycomb是植入物的行动管理网关。

其通信逻辑为：

1.选择一个看似正常的域名（coverdomain）和商用VPS服务，其上安装组件。VPS服务器连接Blot；

2.正常用户访问时，由于开启了可选验证标记（其利用了一个特殊的HTTPS服务选项“Optional Client Authentication”），则不验证并定向到CoverServer；

3.植入物访问时，会访问Honeycomb。

在实际的分析中，我们在LH1和Green Lambert中确实发现了implant中存在和LP通信的证据，并且在LH1中还利用了证书pinning来实现和远程的HTTPS通信。

我们对LH1中涉及的域名进行历史注册情况查询，可以发现该域名在2014年7月被注销，推测是否和相关活动被曝光有关：

攻击链

我们结合上述分析按照攻击链绘制了相关网络武器的利用过程和关系，并对其TTP进行横向对比。

总结

奇安信威胁情报中心红雨滴团队对CIA网络武器库中相关Implant进行了复盘分析，并基于公开报告和内部威胁情报数据对其进行了分类和攻击链的还原尝试。虽然部分环节依旧存在证据缺失，但我们基本可以结合具体样本和公开泄露资料对CIA网络攻击活动进行更加深入的认识，并找到其留下的痕迹和模式。

如有更多技术细节可以联系奇安信威胁情报中心红雨滴团队。

参考链接

1.https://www.symantec.com/connect/blogs/longhorn-tools-used-cyberespionage-group-linked-vault-7

2.https://securelist.com/unraveling-the-lamberts-toolkit/77990/

3.https://www.forbes.com/sites/thomasbrewster/2018/03/09/cia-russian-hackers-on-same-china-server-says-kaspersky/#304658659a30

4.https://wikileaks.org/vault7/

5.https://wikileaks.org/ciav7p1/

声明：本文来自奇安信威胁情报中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。