导航菜单

RATicate攻击活动分析

 

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安装程序

RATicate攻击活动分析

NSIS安装包中含压缩内容,其中有可执行程序,由安装包加载到内存中。 这些内容可以通过压缩工具(如7 zip)提取出来。

RATicate攻击活动分析

样本释放文件类型包括:

  • 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 目录:

RATicate攻击活动分析

安装包释放到临时目录中的文件中仅有两个与恶意软件有关:

  • aventailes.dll(Loader)
  • Cluck(加密内容)

我们将重点分析这两个文件。

不过我们发现这些安装程序的payload有所不同。 在对发现的样本进行分析的过程中——手动分析以及借助沙盒工具——我们发现了数种不同的RAT及窃密软件,包括Lokibot,Betabot,Formbook与AgentTesla。 但是这些安装程序在执行时都遵循相同的过程。

 

0x02 第一阶段:Loader & Shellcode

在第一阶段,安装程序将部署初始Loader——恶意DLL文件。 然后,DLL文件开始解密payload,并最终将payload注入到内存中(此时NSIS安装包在释放junk file)。 下图展示了分析样本如何创建cmd.exe进程——注入payload到该进程:

RATicate攻击活动分析

RATicate攻击活动分析

样本创建子进程的内存内容如上所示。 payload位于地址0x400000处。

RATicate安装包释放的恶意DLL(本例中是aventailes.dll )本质是一 Loader,可能由此次活动策划者开发,存储于临时目录中。 分析的所有Loader都是只有一个输出函数的DLL文件,尽管各样本中Loader的名称和输出函数不尽相同。(本例中是Inquilinity)

RATicate攻击活动分析

如前文所述,该输出函数会被NSIS的System插件调用。 输出函数会加载并执行shellcode(位于Loader的.rdata区块)。 解密shellcode使用了一个简单的算法,该算法于不同Loader中不尽相同。

然后,由Loader加载的shellcode会读取存有其他Loader及payload的加密文件——Cluck。这些Loader(PE文件)和shellcode会在之后两个阶段中按需解密。第一阶段,由Loader调用的shellcode完成解密工作,解密后内容包含异或运算的密钥(用于解密shellcode2Loader2),shellcode[shellcode 2]及一PE文件[Loader 2]。

RATicate攻击活动分析

第一阶段的工作流程如下所示:

RATicate攻击活动分析

第一阶段的工作流程:

  1. 执行NSIS exe。
  2. System.dll插件加载并调用Loader(aventailes.dll)。
  3. Loader的输出函数解密shellcode 1并调用之。
  4. shellcode1读取加载到内存中的Cluck文件。
  5. shellcode1解密shellcode2和Loader2并映射shellcode2,然后调用之。
  6. shellcode2将Loader2映射到内存中。

 

0x03 第二阶段:shellcode 2 & Loader DLL

当Shellcode 2将 Loader 2加载到内存中后,开始第二阶段解密 。Loader 2读取Cluck文件来解密其他内容。 根据包含加密内容的文件名(本例中是Cluck)动态生成异或运算密钥,该密钥用于解密第二阶段的数据。如下图所示,解密完成后,文件的第二部分中存储了另一个异或运算密钥(xor_key 2),该密钥用于解密其他内容,例如字符串,shellcode和PE文件。

RATicate攻击活动分析

RATicate攻击活动分析

第二阶段工作流程:

  1. Loader 2执行其DllEntryPoint。
  2. Loader 2再次读取Cluck文件。
  3. Loader 2从Cluck中解密未使用的shellcode。
  4. Loader 2从Cluck读取的数据中解密shellcode 3。
  5. Loader 2执行shellcode3,该shellcode3解密最终payload(PE文件)。

 

0x04 第三阶段:Injection

解密工作完成之后,shellcode 3将在一子进程中注入最终payload。其使用了NtCreateSection + NtMapViewOfSection 注入技术

以下是分析时提取出来的组件:

RATicate攻击活动分析

 

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分析了观察到的攻击,并收集了有关其他受害者的开源信息:

RATicate攻击活动分析

上图展示了经分析后的NSIS安装包感染链。它揭示出用于感染受害者的两种常见模式:

RATicate攻击活动分析

在图表上叠加以上两种方式,可以看出其都用于同一目标企业。其他目标企业也可能采用相同的方法:

RATicate攻击活动分析

我们能够从VT中检索与此活动相关的一些电子邮件。通过这些电子邮件,我们能够确定一些攻击活动的目标:

RATicate攻击活动分析

Campaign 3中的一封电子邮件,以“banking confirmation”作为诱饵:

RATicate攻击活动分析

我们在VirusTotal中发现许多电子邮件没有显示收件人的地址,或者收件人地址填充了发件人字段中的地址。在这种情况下,我们分析了电子邮件标题,因为标题包含与电子邮件相关的许多信息,例如原始收件人:

RATicate攻击活动分析

在对NSIS安装包分析的过程中,我们发现与原始样本具有相同junk file的样本里,确定了至少5个不同的恶意软件家族用作最终payload,它们均是窃密木马或RAT:

  • ForeIT/Lokibot
  • BetaBot
  • Formbook
  • AgentTesla
  • Netwire

然后,我们分析了用于这些payload的C2,检查它们之间是否存在联系,并检查其是否将窃取到的数据发送到相同或相似的服务器。

以下是此次活动中一些确定的恶意软件家族及其C2:

RATicate攻击活动分析

每种类型的恶意软件都共享相同的C&C。在某些情况下,甚至不同的家族——例如Lokibot和Betabot也都共享相同的C&C。

 

0x06 更多的攻击活动

按照这种模式寻找其他NSIS安装包——它们会在相同日期范围内丢弃相同junk file——我们发现了在2019年11月16日至2020年1月8日之间发生的5次不同的攻击活动。虽然这些活动中的每一个安装包都与我们的第一个样本不同,但是其行为与Campaign 3中观察到的行为相同(或至少相似):

RATicate攻击活动分析

0x06.1 CAMPAIGN 1 (NOVEMBER 16-20, 2019)

此次活动中所有NSIS安装包释放的junk file

RATicate攻击活动分析

此次活动中的部分payload:

RATicate攻击活动分析

这是我们从VirusTotal收集到的与Campaign 1相关的电子邮件:

RATicate攻击活动分析

下图展示了Campaign 1中的相互关系和感染链(基于VT上可用的数据)

RATicate攻击活动分析

0x06.2 Campaign 2 (November 25, 2019 to November 26, 2019)

此次活动中所有NSIS安装包释放的junk file

RATicate攻击活动分析

此次活动中的部分payload:

RATicate攻击活动分析

我们找不到与此次活动有关的电子邮件,因此无法分析其预期目标。下图展示了相似payload之间的关系:

RATicate攻击活动分析

0x06.3 CAMPAIGN 4 (DECEMBER 20, 2019 TO DECEMBER 31, 2019)

此次活动中所有NSIS安装包释放的junk file

RATicate攻击活动分析

此次活动中的部分payload:

RATicate攻击活动分析

收集到的与之相关的电子邮件:

RATicate攻击活动分析

RATicate攻击活动分析

0x06.4 CAMPAIGN 5 (JANUARY 3, 2020 TO JANUARY 8, 2020)

此次活动中所有NSIS安装包释放的junk file

RATicate攻击活动分析

此次活动中的部分payload:

RATicate攻击活动分析

收集到的与之相关的电子邮件:

RATicate攻击活动分析

下图展示了Campaign 5中的相互关系和感染链(基于VT上可用的数据):

RATicate攻击活动分析

 

0x07 对攻击活动策划者进行分析

分析所有发现的攻击活动,我们发现其C&C经常出现重复,如下表所示:

RATicate攻击活动分析

我们还发现,每次攻击活动的某些不同payload(大多数是Betabot,Lokibot,AgentTesla和Formbook)使用相同的C&C。这表明,同一参与者/组织正在管理这些恶意软件活动背后的Web服务器。

攻击活动时间表也有明显的聚集——但它们之间从来没有任何重叠,这表明它们是由相同的策划者连续进行的(包括我们将在下一次报告中介绍的第六次攻击活动):

RATicate攻击活动分析

在这些攻击活动中,不仅在同一次活动中跨不同payload共享C2,另外一些C2还在多次不同活动中共享,这也表明是同一参与者/组织策划了所有活动。

下表显示了各次活动之间的一些有趣的联系:

RATicate攻击活动分析

 

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攻击活动分析

根据他们现有的行为,我们不确定RATicate是专注于间谍活动还是仅仅充当其他组织的恶意软件提供商。有可能他们仅仅是向目标公司投递了恶意软件,以向其他组织的提供付费访问权限,或者他们是将InfoStealer与RAT用作更大的恶意软件分发工作的一部分。我们将继续分析新的攻击活动,以对其动机有更深入的了解。

 

0x09 “反沙盒”

在对第一个RATicate样本进行分析的过程中,我们发现安装包删除的Shellcode 3使用了许多有趣的技术来阻碍分析人员分析其API调用,并且使用了许多反调试技巧来进一步阻碍分析。但是我们在这些样本中也发现了一个奇怪的行为:如果以SHA256值作为文件名之后执行样本,程序将崩溃:

RATicate攻击活动分析

这种行为可以被视为一种反沙盒技巧。由于沙盒通常以样本哈希值作为文件名运行样本,帮该技术可以避免在沙盒环境中执行payload。但是在本例中,该行为实际上是由于代码错误所致。

在执行Shellcode 3期间发生错误:

RATicate攻击活动分析

Shellcode 3使用一种已知技术——通过在PEB中搜索LDR_DATA_TABLE_ENTRY来获取已加载模块的地址(例如库或可执行文件本身)。LDR结构中的信息包括已加载模块的名称和地址。程序代码会根据所需函数名称的哈希值来检查此结构,从而提供一种方式来动态解析要调用函数的地址。

RATicate攻击活动分析

该功能是在代码的 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中找到。

相关推荐

CVE-2020-0904:Hyper-V类型混淆任意地址解引用漏洞分析

译文声明 本文是翻译文章,文章原作者Daniel Fernandez Kuehr,文章来源:labs.bluefrostseC++urity.de 原文地址:https://labs.bluefrostsecurity.de/advisories/bfs-sa-2020-003/ 译文仅供参考,具体内容表达以...

JustSystems Ichitaro(一太郎)缓冲区溢出漏洞

  漏洞简介 IC++hitaro(一太郎)是日本JustSystems公司的一套文字处理软件。 JustSystems Ichitaro在处理JTD文档的过程中存在基于堆的缓冲区溢出漏洞,允许远程攻击者可利用该漏洞构建恶意文件,诱使用户解...