由于原文大部分为技术分析，为了对整个关于CIA的网络武器泄露事请进行完整复 盘，黑鸟在此给各位交代一下背景。

首先，万恶之源来源于维基解密泄露的CIA文档，其中对于CIA的网络武器

2017年3月7日，维基解密（WikiLeaks）网站公布了大量据称是美国中央情报局（CIA）的内部文件，其中包括了CIA内部的组织资料，对电脑、手机等设备进行攻击的方法技术，以及进行网络攻击时使用的代码和真实样本。利用这些技术，不仅可以在电脑、手机平台上的Windows、iOS、Android等各类操作系统下发起入侵攻击，还可以操作智能电视等终端设备，甚至可以遥控智能汽车发起暗杀行动。

维基解密将这些数据命名为“7号军火库”（Vault 7），一共有8761份文件，包括7818份网页以及943个附件。在公布时，维基解密对文件内容进行了一些删节处理，包括个人真实信息（姓名、邮件地址等），数以万计的IP地址，以及真实的二进制文件。

维基解密表示在对文件进行进一步的分析之后，会逐步公开这些被删节的信息。同时，维基解密称此次公布的数据只是一系列CIA机密材料的第一部分，被称为“元年”（Year Zero），后续还会有更多资料陆续公布。

其中有几个很著名的模块，本文的分析便是基于其中的Athena项目进行进一步的扩展分析。

项目介绍

https://wikileaks.org/vault7/

数据地址

https://wikileaks.org/ciav7p1/

所有项目名称

本文提到的雅典娜项目文件

以下内容全程技术分析，建议收藏文章慢慢观看，无论是对于排查是否入侵以及后续进一步的跟踪行动都有奇效。网络战争的一项重要元素便是对敌方网络武器的了解程度，这一点在本文体现的淋漓尽致。

引言

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_at	该指令用于计划任务相关的设置。
cmd_idlewatch	该指令主要通过 GetLastInputInfo 监控机器设备的活动情况
cmd_wincontrol	通过 postMessage 向指定 gui 发送消息，结合 SendInput 鼠标左键的操作，再配合一开始设置的隐藏桌面，以实现对用户机器上任意 GUI 应用的控制。
cmd_catInstall	该指令主要通过 DCOM loader 设置 IPC$,ADMIN$ 共享的方式以实现在局域网的传播。

其中 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 ，这句话的意思就是“这是我们的流量”

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

指令	含义
Copy	拷贝文件
Move	移动文件
Rename	修改文件名
Info	获取系统信息
Exit	设置退出标记
Close	同上
Quit	同上
Uninstall	卸载该驱动
Ndisls	列举自有协议信息
Dir	列目录
Ls	同上
Pwd	获取当前目录
Cd	切换目录
touch	创建文件
del	删除文件
rm	同上
Rmdir	删除目录
Mkdir	创建目录
Cat	查看文件
Type	同上
view	同上
Ps	列举进程
lsmod	加载驱动
Kill	关闭进程
Fexec	文件执行
bexec	脚本执行
Close	文件句柄关闭
of	打开文件
cf	关闭文件句柄
rf	读文件
wf	写文件

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 通信，并接收如下指令：

控制命令	功能描述	相关网络行为
	初始行为，获取指令	GET /agent/checkin
get-scanner	获取扫描模块	GET /agent/get-scanner
run-scanner	运行扫描模块，并回传扫描结果	POST /agent/put-scan 回传扫描结果
exfil-file	压缩并回传文件	POST /agent/put-file 上传文件
destroy-agent	销毁

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 的接口功能进行总结：

函数名	功能
InitFunc_0	获取版本信息
InitFunc_1	通过 /etc/init.d 和 /etc/rc.d 写入 ConfigInitdFile 维持持久化
InitFunc_2	通过写入多种 shell 的配置文件维持持久化
InitFunc_3	通过写入 XSession 相关配置文件维持持久化
InitFunc_4	从代理 URL 中解析网络代理
InitFunc_5	URL 相关解析
InitFunc_6	常量赋值
InitFunc_7	生成 UUID
InitFunc_8	从系统环境变量获取代理配置
InitFunc_9	HTTP 通信函数初始化
InitFunc_10	HTTP 通信接口函数
InitFunc_11	HTTP 代理函数初始化
InitFunc_12	本地环回接口处理
InitFunc_13	TCP 通信函数初始化
InitFunc_14	密钥链访问，实现