0x00 概述
在一系列可以追溯到2019年11月的恶意垃圾邮件活动中,某未确认身份的组织发送诸多安装程序,用以投递RAT及窃取受害者计算机信息的恶意软件。
我们已经确定了五次不同的攻击活动,位于2019年11月到2020年1月期间,其payload使用相似代码及指向相同C2。 攻击活动针对的企业位于欧洲,中东和韩国。这使得我们相信它们出于同一组织之手,故称之为RATicate。
在新发现的攻击活动中,我们发现其通过新冠肺炎(COVID-19)诱惑受害者打开恶意软件。 虽然其改变了策略,但我们仍怀疑此次攻击活动是该组织所为。
本篇文章中,我们将关注其初始载荷,即每次活动都使用到的 Nullsoft Scriptable安装系统(NSIS) 。 NSIS是一款开源工具,用以创建Windows安装程序及基于Internet的软件分发。 但它也被滥用了很长一段时间,用来伪装和部署恶意软件。 (在后续报告中,我们将讨论使用其他安装程序的攻击活动,以及该组织钓鱼策略的转变。)
0x01 初始载荷分析
NSIS一个有趣的功能是其支持插件,允许安装程序与其他组件(包括Windows操作系统组件)通信 (可用插件列表)。 这些插件本质为Windows DLL文件。 如果于安装程序构建期间选择某插件,会被自动添加到最终编译完成的$PLUGINS
文件夹内。
这些插件可以提供的功能包括:
安装程序引起我们注意是因为它们都释放一组相同的junk file
(这些文件并未被用来安装恶意软件)。过去我们看到过于NSIS安装程序中用junk file
以隐藏恶意软件;junk file
旨在迷惑分析人员,及干扰沙箱分析。这种行为引起了我们的兴趣,于是开始对其进行更为详细的分析。
我们发现所有样本都使用了 System.dll 插件,它允许使用者加载某DLL以及调用其输出函数。 恶意安装程序调用该DLL以注入payload到内存中(多数情况下经由 cmd .exe
)。
为了便于说明,本报告主要分析第一次发现的 NSIS安装程序:
NSIS安装包中含压缩内容,其中有可执行程序,由安装包加载到内存中。 这些内容可以通过压缩工具(如7 zip)提取出来。
样本释放文件类型包括:
- ASCII文本文件
- C源码(ASCII文本格式)
- 数据文件
- 64位ELF
- GIF
- JPEG
- BMP(Windows 3.x 格式,1643144)
- 32位可执行文件(DLL)
- 32位可执行文件(GUI)
- POSIX Shell(ASCII文本格式)
-
.pyc
文件 - XML 1.0
安装程序将释放junk file
到%TEMP%/careers/katalog/_mem_bin/page1/W3SVC2
目录:
安装包释放到临时目录中的文件中仅有两个与恶意软件有关:
- aventailes.dll(Loader)
- Cluck(加密内容)
我们将重点分析这两个文件。
不过我们发现这些安装程序的payload有所不同。 在对发现的样本进行分析的过程中——手动分析以及借助沙盒工具——我们发现了数种不同的RAT及窃密软件,包括Lokibot,Betabot,Formbook与AgentTesla。 但是这些安装程序在执行时都遵循相同的过程。
0x02 第一阶段:Loader & Shellcode
在第一阶段,安装程序将部署初始Loader——恶意DLL文件。 然后,DLL文件开始解密payload,并最终将payload注入到内存中(此时NSIS安装包在释放junk file
)。 下图展示了分析样本如何创建cmd.exe
进程——注入payload到该进程:
样本创建子进程的内存内容如上所示。 payload位于地址0x400000
处。
RATicate安装包释放的恶意DLL(本例中是aventailes.dll )本质是一 Loader,可能由此次活动策划者开发,存储于临时目录中。 分析的所有Loader都是只有一个输出函数的DLL文件,尽管各样本中Loader的名称和输出函数不尽相同。(本例中是Inquilinity)
如前文所述,该输出函数会被NSIS的System插件调用。 输出函数会加载并执行shellcode(位于Loader的.rdata
区块)。 解密shellcode使用了一个简单的算法,该算法于不同Loader中不尽相同。
然后,由Loader加载的shellcode会读取存有其他Loader及payload的加密文件——Cluck。这些Loader(PE文件)和shellcode会在之后两个阶段中按需解密。第一阶段,由Loader调用的shellcode完成解密工作,解密后内容包含异或运算的密钥(用于解密shellcode2与Loader2),shellcode[shellcode 2]及一PE文件[Loader 2]。
第一阶段的工作流程如下所示:
第一阶段的工作流程:
- 执行NSIS exe。
- System.dll插件加载并调用Loader(aventailes.dll)。
- Loader的输出函数解密shellcode 1并调用之。
- shellcode1读取加载到内存中的Cluck文件。
- shellcode1解密shellcode2和Loader2并映射shellcode2,然后调用之。
- shellcode2将Loader2映射到内存中。
0x03 第二阶段:shellcode 2 & Loader DLL
当Shellcode 2将 Loader 2加载到内存中后,开始第二阶段解密 。Loader 2读取Cluck文件来解密其他内容。 根据包含加密内容的文件名(本例中是Cluck)动态生成异或运算密钥,该密钥用于解密第二阶段的数据。如下图所示,解密完成后,文件的第二部分中存储了另一个异或运算密钥(xor_key 2),该密钥用于解密其他内容,例如字符串,shellcode和PE文件。
第二阶段工作流程:
- Loader 2执行其DllEntryPoint。
- Loader 2再次读取Cluck文件。
- Loader 2从Cluck中解密未使用的shellcode。
- Loader 2从Cluck读取的数据中解密shellcode 3。
- Loader 2执行shellcode3,该shellcode3解密最终payload(PE文件)。
0x04 第三阶段:Injection
解密工作完成之后,shellcode 3将在一子进程中注入最终payload。其使用了NtCreateSection + NtMapViewOfSection 注入技术。
以下是分析时提取出来的组件:
0x05 如何确定其为同一组织所为?
我们共发现了38个NSIS安装包,都具有如下相似的特征:
相同的junk file
。不仅仅是它们的名字,还有其内容。当NSIS脚本生成安装包时,攻击活动的参与者必须将这些文件统统保存在硬盘上。
相同的Loader:所分析NSIS安装包中所有的Loader都是相同的,不是在HASH值方面,而是在功能方面(具体如下)。
- 所有初始Loader都只有一个输出函数,并由NSIS安装包调用
- 初始Loader从加密数据中读取数据,以解密加载Loader 2的shellcode。
- 所有样本的Loader 2从加密数据中提取并解密shellcode 3。
- Shellcode 3负责解密最终payload并将其注入到远程进程中,在所有分析的样本之间都是相同的。
但是,我们分析的每个NSIS安装包释放了不同的恶意软件 。我们认为这出于两种可能的情况:恶意NSIS软件包是暗网论坛上出售的通用打包程序;或者该组织成员使用自行编写的Loader于每次攻击活动中部署不同的payload。
尽管在暗网论坛上有很多打包程序在出售,但我们认为不太可能是这种情况,因为如果是不同组织的成员使用相同的通用打包程序,那么junk file
应该会随payload变化而变化。因此,我们以攻击活动来自同一组织的假说继续进行调查。
虽然已有掌握的证据,但我们无法证明此组织对所有的攻击活动都负责,但是我们至少可以从相同的打包策略及组件中,找到一种将所有的攻击活动联系起来的方法。我们进行了进一步的分析,以寻找其确定的联系,我们将视线转向提供这些攻击活动的感染链。
我们发现在2019年12月8日至12月13日期间的恶意电子邮件活动中,一组NSIS安装程序投递了相同的junk file
。(在发现其他的NSIS安装程序之后,我们将这一波攻击活动称为Campaign 3)在我们观察到的攻击活动中,目标似乎都是关键基础设施提供商(或与关键基础设施相关的业务)。我们使用VirusTotal分析了观察到的攻击,并收集了有关其他受害者的开源信息:
上图展示了经分析后的NSIS安装包感染链。它揭示出用于感染受害者的两种常见模式:
在图表上叠加以上两种方式,可以看出其都用于同一目标企业。其他目标企业也可能采用相同的方法:
我们能够从VT中检索与此活动相关的一些电子邮件。通过这些电子邮件,我们能够确定一些攻击活动的目标:
Campaign 3中的一封电子邮件,以“banking confirmation”作为诱饵:
我们在VirusTotal中发现许多电子邮件没有显示收件人的地址,或者收件人地址填充了发件人字段中的地址。在这种情况下,我们分析了电子邮件标题,因为标题包含与电子邮件相关的许多信息,例如原始收件人:
在对NSIS安装包分析的过程中,我们发现与原始样本具有相同junk file
的样本里,确定了至少5个不同的恶意软件家族用作最终payload,它们均是窃密木马或RAT:
- ForeIT/Lokibot
- BetaBot
- Formbook
- AgentTesla
- Netwire
然后,我们分析了用于这些payload的C2,检查它们之间是否存在联系,并检查其是否将窃取到的数据发送到相同或相似的服务器。
以下是此次活动中一些确定的恶意软件家族及其C2:
每种类型的恶意软件都共享相同的C&C。在某些情况下,甚至不同的家族——例如Lokibot和Betabot也都共享相同的C&C。
0x06 更多的攻击活动
按照这种模式寻找其他NSIS安装包——它们会在相同日期范围内丢弃相同junk file
——我们发现了在2019年11月16日至2020年1月8日之间发生的5次不同的攻击活动。虽然这些活动中的每一个安装包都与我们的第一个样本不同,但是其行为与Campaign 3中观察到的行为相同(或至少相似):
0x06.1 CAMPAIGN 1 (NOVEMBER 16-20, 2019)
此次活动中所有NSIS安装包释放的junk file
:
此次活动中的部分payload:
这是我们从VirusTotal收集到的与Campaign 1相关的电子邮件:
下图展示了Campaign 1中的相互关系和感染链(基于VT上可用的数据)
0x06.2 Campaign 2 (November 25, 2019 to November 26, 2019)
此次活动中所有NSIS安装包释放的junk file
:
此次活动中的部分payload:
我们找不到与此次活动有关的电子邮件,因此无法分析其预期目标。下图展示了相似payload之间的关系:
0x06.3 CAMPAIGN 4 (DECEMBER 20, 2019 TO DECEMBER 31, 2019)
此次活动中所有NSIS安装包释放的junk file
:
此次活动中的部分payload:
收集到的与之相关的电子邮件:
0x06.4 CAMPAIGN 5 (JANUARY 3, 2020 TO JANUARY 8, 2020)
此次活动中所有NSIS安装包释放的junk file
:
此次活动中的部分payload:
收集到的与之相关的电子邮件:
下图展示了Campaign 5中的相互关系和感染链(基于VT上可用的数据):
0x07 对攻击活动策划者进行分析
分析所有发现的攻击活动,我们发现其C&C经常出现重复,如下表所示:
我们还发现,每次攻击活动的某些不同payload(大多数是Betabot,Lokibot,AgentTesla和Formbook)使用相同的C&C。这表明,同一参与者/组织正在管理这些恶意软件活动背后的Web服务器。
攻击活动时间表也有明显的聚集——但它们之间从来没有任何重叠,这表明它们是由相同的策划者连续进行的(包括我们将在下一次报告中介绍的第六次攻击活动):
在这些攻击活动中,不仅在同一次活动中跨不同payload共享C2,另外一些C2还在多次不同活动中共享,这也表明是同一参与者/组织策划了所有活动。
下表显示了各次活动之间的一些有趣的联系:
0x08 目标和动机
根据RATicate使用到的payload,很明显,该组织开展的活动旨在获得对目标公司内计算机的访问控制权。从这些活动中收集到的电子邮件确定其目标包括:
- 某罗马尼亚的电气设备制造商;
- 某科威特建筑服务和工程公司;
- 某韩国互联网公司;
- 某韩国投资公司;
- 某英国建筑供应商;
- 某韩国医学新闻刊物;
- 某韩国电信和电缆制造商;
- 某瑞士出版设备制造商;
- 某日本的快递和运输公司。
我们发现其目标至少在两次攻击活动中重叠:Campaign 1和2都针对电气设备制造商。在多个Campaign中可能会有更多共同的目标(我们仅通过查看VirusTotal的公开可用数据,而未分析非公开数据)。而且,许多(但并非不是全部)已针对的公司与关键基础架构有关。
我们已经检测到另外一个使用这些NSIS安装包的近期活动(1月13日至16日)。但是,随着我们深入分析该组织,我们发现其进行了其他的攻击活动——并且我们相信自1月份以来,该组织已开始使用其他Loader和打包程序。
其中一次活动是我们在三月份检测到的,此次活动使用COVID-19来诱使受害者打开payload。最新检测到的样本随各种VB编写的Loader一并投递——其中包括Proofpoint于2019年12月发现的Guloader。
我们认为这些攻击活动是由同一组织进行的,其原因如下:
- 其电子邮件的目标客户与之前Campaign相同。
- 部分检测到的payload是Betabot和Lokibot,它们于先前观察到的活动中出现。
- Betabot的C&C与之前Campaign中所发现的相似——它与Campaign 3中的Betabot使用相同的域名(stngpetty [.] ga),并且使用类似的路径(
/~zadmin/{NAME1}/{NAME2}/logout.php
):
根据他们现有的行为,我们不确定RATicate是专注于间谍活动还是仅仅充当其他组织的恶意软件提供商。有可能他们仅仅是向目标公司投递了恶意软件,以向其他组织的提供付费访问权限,或者他们是将InfoStealer与RAT用作更大的恶意软件分发工作的一部分。我们将继续分析新的攻击活动,以对其动机有更深入的了解。
0x09 “反沙盒”
在对第一个RATicate样本进行分析的过程中,我们发现安装包删除的Shellcode 3使用了许多有趣的技术来阻碍分析人员分析其API调用,并且使用了许多反调试技巧来进一步阻碍分析。但是我们在这些样本中也发现了一个奇怪的行为:如果以SHA256值作为文件名之后执行样本,程序将崩溃:
这种行为可以被视为一种反沙盒技巧。由于沙盒通常以样本哈希值作为文件名运行样本,帮该技术可以避免在沙盒环境中执行payload。但是在本例中,该行为实际上是由于代码错误所致。
在执行Shellcode 3期间发生错误:
Shellcode 3使用一种已知技术——通过在PEB中搜索LDR_DATA_TABLE_ENTRY来获取已加载模块的地址(例如库或可执行文件本身)。LDR结构中的信息包括已加载模块的名称和地址。程序代码会根据所需函数名称的哈希值来检查此结构,从而提供一种方式来动态解析要调用函数的地址。
该功能是在代码的 get_dll_base_addres_from_ldr_by_hash(dll_hash)
函数中实现的,而崩溃正是在此函数中发生的。该函数遍历LDR结构,计算所加载模块名称的HASH,并检查其是否匹配作为参数传递的HASH。
该函数将ldr_data_table-> BaseDllName.Buffer
的内容存入vulnerable_buffer
中,以便将ANSI字符串转换为UNICODE字符串。
但是,由于vulnerable_buffer
大小仅为104,并且其存储了Unicode字符串,这意味着其实际大小上仅为52个ANSI字符。所以,如果文件名的长度为53个或更多字符,则将发生缓冲区溢出。要使该程序崩溃,只需为样本提供57个字符的文件名(如this_is_57_length_filename_in_order_to_do_a_crash_PoC.exe
)即可。
经过分析,我们确认这是代码错误,而不是反沙盒技术。
0x10 IOC
与RATicate攻击活动相关的HASH可以在SophosLabs的GitHub中找到。