新版本的IcedID木马使用隐写有效载荷

这篇博文由@hasherezade撰写，贡献来自@siri_urz和Jérôme Segura。

保安公司Proofpoint最近发表了一份报告他们将一系列恶意垃圾邮件活动归因于一个名为TA2101的威胁行动者。最初是针对德国和意大利用户的Cobalt Strike和Maze勒索软件，后来的一波恶意电子邮件针对美国，并推出了IcedID木马。

在我们分析这个垃圾邮件活动的过程中，我们注意到有效负载的实现方式发生了变化，特别是一些代码被重写和新的混淆。例如，IcedID木马现在通过隐写术，因为数据是用有效的PNG图像的内容进行加密和编码的。根据我们的研究，这些变化是引入的2019年9月（尽管2019年8月旧装载机仍在使用)。

主IcedID模块存储时没有典型的PE报头，并由一个使用自定义报头结构的专用加载器运行。我们的安全分析师@hasherezade之前在SAS会议(时髦的恶意软件格式)．

在这篇博客文章中，我们将仔细研究这些新的有效载荷，并描述它们的技术细节。

分布

我们的垃圾邮件蜜罐收集了大量包含“USPS投递失败尝试通知”主题行的恶意邮件。

每封电子邮件都包含一份据称来自美国邮政服务的微软Word文档作为附件。文档的内容被设计成通过暗示内容已经被编码来引诱受害者启用宏。

看一下嵌入的宏，我们可以看到以下元素:

有一个假错误消息显示给受害者，但更重要的是，ICEDID特洛伊帖作者隐藏了UserForm的恶意指令作为标签。

宏从标签中抓取文本，转换它，并在执行期间使用：

URL1 = DCR（GH1.Label1.Caption）
Path1 = DCR（GH1.Label2.Caption）

例如:

104 116 116 112 58 47 47 49 48 52 46 49 54 56 46 49 49 57 56 46 50 51 48 47 119 111 114 100 117 112 100 46 116 109 112
皈依:http://104.168.198.230/wordupd.tmp

67、58、92、87105110100111119115、92,84101109112,92101114101100,46116109112
转换为：C:\Windows\Temp\ered.tmp

tmp文件是在URLDownloadToFileA函数的帮助下下载的可执行文件，保存到给定的路径并运行。接下来，我们将进一步研究下载示例的功能和实现。

行为分析

和以前一样，人们观察到IcedID将一种药物注入svchost，并在其掩护下运行。根据配置，它可能下载也可能不下载其他可执行文件，包括涓涓细刻．

删除文件

恶意软件丢弃磁盘上的各种文件。例如，在％AppData％中，它可以节省标记物扰乱的有效载荷（photo.png)及下载程序的更新:

它还创建一个具有随机名的新文件夹，其中它以加密的形式保存下载的配置：

在%TEMP%文件夹中，它删除了一些非恶意的帮助元素:sqlite32.dll.(用于读取网页浏览器中的SQLite浏览器数据库)，以及用于拦截流量的证书:

查看证书，我们可以看到它是由VeriSign签名的：

坚持

应用程序在计划任务的帮助下实现持久性:

该任务有两个触发器：在用户登录时和在计划的时间。

交通概述

大部分流量是SSL加密的。我们还可以看到websockets和地址的使用，格式如下:data2php吗?<键>”、“data3.php吗?<键>”。

攻击浏览器

IcedID木马被称为银行木马，事实上，它的一个重要特征是能够窃取与银行交易相关的数据。为了达到这个目的，它将它的植入物注入到浏览器中，挂钩API，并执行人在浏览器攻击．

在被感染者的记忆里svchost过程中，我们可以看到配置webinject的字符串。webinject是模块化的(通常是为了窃取数据而将HTML和JavaScript代码注入网页)。

核心机器人在记忆里运行svchost观察系统上运行的进程，并向浏览器中注入更多的植入物。例如，看看Mozilla Firefox:

通过扫描过程PE-sieve，我们可以检测到浏览器中的一些dll已经被钩住，并且它们的执行被重定向到恶意模块。

Firefox浏览器中已经安装了以下钩子:

• nss3.dll: SSL_AuthCertificateHook - > 2 c2202 [2 c1000 + 1202]
• ws2_32.dll：connect-> 2c2728 [2c1000 + 1728]

在Internet Explorer中观察到一个不同的设置:

• mswsock: hook_0 [7852] - > 525 d0 [implant_code+ 15 d0]
• ws2_32.dll：connect-> 152728 [implant_code+ 1728)

在浏览器内存中运行的ICEDID模块负责将WebInjects应用于攻击页面中安装恶意JavaScripts。

内联webinject脚本的内容可以在这里找到:inject.js.．

它还与内部的主机器人沟通svchost的过程。主机器人协调所有注入组件的工作，并将窃取的数据发送到命令和控制服务器(CnC)。

由于通信受到HTTPS保护的事实，恶意软件还必须安装自己的证书。例如，这是美国银行网站的有效证书：

相比之下，受IcedID感染的浏览器使用的证书：

变更概述

正如我们提到的，核心IcedID机器人以及专用的加载器都经历了一些重构。在这个对比分析中，我们使用了以下的老样本:B8113A604E6C190BBD8B687FD2BA7386D4D98234F5138A71BCF15F0A3C812E91

这个有效载荷的详细分析可以在这里找到:[1][2][3.］．

旧装载机与新装载机

详细描述了先前版本的IceDid Trojan的装载机在这里,在这里. 它是一个打包的PE文件，用于加载和注入无头PE。

主模块被注入svchost：

植入的PE被分成两个部分，第一个内存页（代表页眉）是空的。这种类型的有效载荷比完全PE注入更隐蔽（更常见）。但是，可以像正常PE一样重建标题并分析样本(此处提供了重构有效载荷的示例：395年d2d250b296fe3c7c5b681e5bb05548402a7eb914f9f7fcdccb741ad8ddfea)．

通过钩住植入物的重定向RtlExitUserProcess在svchost的ntdll内的函数。

当svchost试图终止，它却触发了一个跳跃进入被注射的PE的入口点。

加载器还填充了负载中指向数据页的指针。我们可以看到这个指针在有效负载执行的开始被加载:

在新的实现中，还有一个中间加载器元素实现为shellcode。下图显示了新的装载链:

shellcode具有与以前由加载器以PE形式实现的功能相似的功能。首先，它把自己注入svchost。

然后它解压缩并注入有效载荷，如前所述是无头照片（类似于所描述的在这里)．

比较核心

修改了核心机器人的实现。然而，在代码中，我们可以找到前面示例中已知的一些字符串，以及一组类似的导入API函数。我们还可以看到一些匹配的字符串和实现的逻辑片段。

新样本的类比片段：

在BinDiff的帮助下对两个重构样本进行比较，发现有相当多的差异和重写部分。然而，有部分代码在两者中是相同的，这证明了代码库保持不变。

让我们按照新IcedID包中所有元素的执行流程来执行。

的下载器

在当前的交付模型中，IcedID的第一个元素是下载器。它是一个PE文件，由密码器打包。每个样品的包装层都不同，所以我们将省略它的描述。解压后，我们得到了普通版本:FBACDB66748E6CCB971A0A9611B065AC.．

在内部，这个可执行文件很简单，没有进一步的混淆。我们可以看到，它首先查询CnC试图获取第二阶段，请求一个photo.png．它将生成的ID传递给URL。例子：

/photo.png？id=0198d464fe3e7f09ab0005000000fa00000000

Downloader使用编码有效载荷获取PNG。然后它加载文件，解码，并将执行重定向到那里。下面我们可以看到负责任的功能：

下载后，PNG文件将保存在磁盘上，并可以在系统重启时重新加载。下载程序将变成这种模糊格式的运行程序。通过这种方式，核心可执行文件只显示在内存中，而从不以EXE文件的形式存储在磁盘上。

“photo.png看起来像一个有效的图形文件:

在这段代码中，我们可以看到来自PNG的数据(从标签“IDAT”开始的部分)首先被解码为原始字节，然后这些字节被传递给进一步的解码函数。

用于解码字节的算法：

PNG被解密并注入下载器。在这种情况下，解码的内容变成了shellcode模块而不是PE。

加载器将一个参数传递给shellcode;那是装载它的底座。

装载机（shellcode）

如前所述，该阶段实现为独立于位置的代码（shellcode）。倾倒的样品可在此处提供：624年afab07528375d8146653857fbf90d．

这个基于shellcode的加载器取代了前面描述的(来源:[1][2)加载器元素，它被实现为一个PE文件。首先，它在下载器中运行:

正如我们从下载代码所看到的，必须首先从解码模块开头的简单标题中获取shellcode入口点。我们看到，此标题存储更多用于加载下一个元素至关重要的信息：

由于此模块不再是PE文件，其分析更加困难。shellcode使用的所有API都会动态解析：

字符串是在堆栈上组合的:

为了使消除混淆更容易，我们可以在PIN跟踪器的帮助下跟踪混淆流程。这个阶段(在32位系统上)的跟踪日志显示了指示代码注入的api及其偏移量:

09 c; shellcode的入口点
69 b; ntdll。LdrLoadDll
717; ntdll.ldrgetprocedureaddress.
7 ab; ntdll。RtlWow64EnableFsRedirectionEx
7 cb; kernel32。CreateProcessA
7d6; ntdll.rtlwow64enablefsredirectionex.
7 f0; ntdll。NtQuerySystemInformation
8aa；ntdll.NtAllocateVirtualMemory
8 c6; ntdll。ZwWriteVirtualMemory
8ee; ntdll.ntprotectvirtualmemory.
907; ntdll.ntqueueapcthread.
916; ntdll.zwresumethread.

实际上，外壳代码注入自己的副本，将其入口点传递给APC队列。这一次，一些额外的参数被添加为线程上下文。

一旦shellcode从内部执行svchost，则采用另一种执行路径。它成为核心机器人的加载器。核心元素以压缩形式存储在shellcode的主体中。首先，它被解压。

从以前的实验中，我们知道有效负载遵循PE文件的典型结构，但它没有头。通常情况下，恶意软件的作者会在负载加载后擦除内存中的头信息。然而，事实并非如此。为了使有效载荷更隐蔽，作者没有存储该PE的原始头。相反，他们创建了自己的极简头文件，供内部加载器使用。

首先，selleccode通过解析自己的标题来查找下一个模块：

shellcode还加载了有效载荷的导入：

下面，我们可以看到负责遵循自定义头定义并在页面上应用保护的代码片段。加载下一个元素之后，执行被重定向到它的入口点。

下一个模块的入口点，函数在该模块中期望提供指向该数据的指针:

提供的数据在shellcode的末尾附加，并包含：初始可执行文件的路径，下载的有效载荷的路径（photo.png)等数据。

注意，所述分析是在32位系统上执行的。对于64位系统，外壳代码采用替代执行路径，并在天门术．然而，两个有效载荷版本的所有特征是相同的。

重建体育

为了使分析更容易，重建有效的PE标题总是有益的。这个问题有两种方法：

1. 手动查找和填充所有PE工件，例如:section、导入、重定位(如果所有这些元素都是由作者定制的，比如海洋莲花样品的案例）
2. 详细分析加载器并从自定义标题重建PE

既然我们可以访问加载程序的代码，我们可以采用第二种更可靠的方法:观察加载程序如何处理数据并重建字段的含义。

装载程序代码的一个片段，在此部分被处理:

基于分析重构的自定义头:

幸运的是，在这种情况下，恶意软件的作者只定制了PE头。Data Directory元素(导入和重定位)以标准形式保存，因此不需要转换这一部分。

此格式到PE的转换器可在此处提供：

https://github.com/hasherezade/funky_malware_formats/tree/master/iced_id_parser

有趣的是，旧版本的IcedID使用了类似的自定义格式，但有一个修改。在过去，在ImportDirector VA之前还有一个DWORD大小的字段，因此，最新的头文件比前一个短一个DWORD。

旧格式的模块：BBD6B94DEABB9AC4775BEFC3DC6B516656615C9295E71B39610CB83C4B005354

核心机器人(无头PE)

6 aeb27d50512dbad7e529ffedb0ac153- 一个重建的pe

查看这个模块的字符串，我们可以猜测这个元素负责该恶意软件执行的所有核心恶意操作。它与CnC服务器通信，读取sqlite数据库以窃取cookie，安装自己的man - in - browser攻击证书，并最终下载其他模块。

我们可以看到这是负责为CNC生成观察到的请求的元素：

在运行期间，恶意软件在CNC中不断监督。与服务器的通信是加密的。

字符串混淆

恶意软件使用的大多数字符串在使用前都被混淆和解码。解码使用的算法很简单:

为了静态解码字符串，我们可以重新实现算法和向其编码缓冲区的供应。另一个更容易的解决方案是加载原始恶意软件并使用其功能的解码器，以及偏移量给出的编码缓冲区。可用的例子在这里．

解码字符串对于进一步的分析很重要。尤其是在这种情况下，我们可以找到一些调试开发人员留下的字符串，通知我们对特定代码片段的恶意软件执行的操作。

一些已解码字符串的列表是可用的在这里．

可用的行动

下面给出了机器人主要功能的概述：

机器人通过打开插座而开始。然后，它到CNC的信标并初始化线程以获取一些特定操作：MITM代理，浏览器挂钩引擎和BackConnect模块（后门）。

它还调用初始化处理程序的函数，负责管理各种可用操作。全部列表：

通过较近处理程序的分析，我们注意到类似于第一元素，主机器人将各种元素作为隐写保护的模块检索。负责解码PNG文件的功能是类似于初始下载器中找到的功能：

这些png被用来携带恶意软件的各种更新内容。例如，更新url列表，以及其他配置文件。

数控系统控制的执行流程

恶意软件的回接功能允许攻击者在受害机器上部署各种命令。CnC还可以指示机器人从内部解码其他恶意模块，这些模块将部署在一个新的过程中。例如:

如果收到来自CnC的特定命令，机器人将解压缩存储在样本中的另一个缓冲区，并将其注入到新的实例svchost．

这种注入的实现方式让我们想起了旧版本的加载器。首先，在RtlDecompressBuffer的帮助下解压缩缓冲区:

然后，在首选地址0x3000分配内存。

一些来自NTDLL的函数和其他参数将被复制到结构中，存储在shellcode的开头。

我们可以看到shellcode将使用一些功能来加载另一个嵌入式PE。

类似于旧加载器，通过rttlexitUserProcess函数上的挂钩设置到新的入口点的重定向：

在缓冲区被解压后，我们可以看到另一段shellcode:

此外壳代码是无头PE模块的模拟加载程序。我们可以在加载程序将使用的PE头的自定义版本中看到：

转储外壳代码：469F3AEDD47DC820D9D64A253652D7436ABE6A5AFB64C3722AFB1AC83C3A3E1

此元素是一个额外的后门，可按需部署一个隐藏的VNC．作者还以“HDESK bot”(帮助台bot)的名称引用它，因为它让攻击者可以直接访问受害机器，就像它是一个帮助台服务一样。转化为体育:2959091 ac9e2a544407a2ecc60ba941b

下面，我们将分析core bot所实现的选定功能。注意，许多功能是根据需求部署的——取决于CnC给出的命令。在观察到的案例中，该机器人还被用作第二个恶意软件TrickBot的下载程序。

安装自己的证书

恶意软件安装自己的证书。首先，它将生成的文件放到%TEMP%文件夹中。然后，该文件被加载并添加到Windows证书存储中。

证书生成功能片段:

调用该函数来添加要存储的证书:

从IE窃取密码

我们可以看到此机器人在各种保存的凭据之后。在使用的不同方法中，我们识别来自凭证商店的数据。使用的方法类似于所描述的方法在这里．

我们可以看到，它使用了上面提到的GUID“abe2869f-9b47-4cd9-a358-c22904dba7f7”，该GUID用于添加凭证。在从商店读取凭据之后，机器人取消salt操作以获得明文。

窃取已保存的电子邮件凭证

该机器人正试图利用一切机会从受害机器中提取密码，同时也在寻找已保存的电子邮件凭据。

偷饼干

正如我们在行为分析期间观察到的那样，恶意软件在Temp文件夹中删除了SQLite3.dll。此模块进一步加载并用于对使用已保存的cookie进行浏览器数据库的查询。

恶意软件搜索包含特定浏览器cookie的文件：

我们可以看到解码字符串后的查询内容:

它的目标是火狐，以及Chrome和基于Chrome的浏览器:

执行查询的代码片段:

对Chrome数据库的查询列表：

SELECT name, value FROM自动填充

SELECT guid, company_name, street_address, city, state, zipcode, country_code FROM autofill_profiles

SELECT guid, number FROM autofill_profile_phones

从autofill_profile_names中选择guid，first_name，middle_name，last_name，full_name

SELECT card_number_encrypted, length(card_number_encrypted)， name_on_card, expiration_month || "/" ||expiration_year FROM credit_cards

SELECT username_value, password,password FROM logins WHERE username_value <> "

选择host_key，path，is_secure，（case expires_utc当0然后0 elte（expires_utc / 1000000） -  11644473600结束），名称，长度（encrypted_value），从cookie中加密_value

Firefox数据库的查询列表:

选择主机，路径，发布，到期，名称，来​​自Moz_cookies的值

SELECT fieldname, value FROM moz_formhistory

所有找到的文件都将其包装为tar存档并发送到CNC。

类似地，它创建了一个passff.tar“Firefox档案文件被盗:

把浏览器

如前所述，恶意软件攻击并钩住浏览器。由于类似的功能是由不同浏览器中的不同函数实现的，因此每个浏览器安装的一组钩子可能是唯一的。

首先，恶意软件在运行的进程中搜索目标。它使用以下算法:

它与前面的版本相似(已描述)在这里），但我们可以看到一些更改，即修改了校验和，并添加了一些额外的检查。然而，攻击浏览器的列表是相同的，包括最受欢迎的浏览器：Firefox，MS Edge，Internet Explorer和Chrome。

浏览器首先被专用的IcedID模块感染。就像这个版本的IcedID的所有模块一样，浏览器植入是一个无头PE文件。它的重建版本可以在这里找到:9 e0c27746c11866c61dec17f1edfd2693245cd257dc0de2478c956b594bb2eb3．

被注入后，这个模块在进程的内存中找到合适的dll，并设置重定向到它自己的代码:

解析指令并安装钩子:

然后，所选的API函数被拦截并重定向到插件。钩子通常安装在函数的开头，但也有例外。例如，在Internet Explorer中，mswsock.dll已被拦截:

查看在内存中拦截调用所涉及的元素:浏览器植入(无头PE)和额外的内存页:

Firefox的钩子的示例：

第一步:功能SSL_AuthCertificateHook有一个跳转重定向到植入模块:

步骤2:被植入的模块用适当的参数从附加页面调用代码:

步骤3：附加页面处的代码是原始函数的修补片段。执行修改后的代码后，它会返回原始DLL。

此挂钩的功能从上一个版本没有更改。

Webinjects

BOT以前所述的.dat文件的形式从CNC获取配置。首先，该文件由RC4算法解码。输出必须从“Zeus”关键字开始，并通过自定义算法进一步编码。专用于每个站点的脚本由脚本ID标识。

文件加载和解码后，我们可以看到内容:

机器人可以执行多种类型的webinject:

根据配置，机器人可能会替换网站代码的某些部分，或添加一些新的恶意脚本。

执行远程命令

如果由机器人实现的命令不足以用于操作员的需要，则该机器人允许从命令行执行命令的特征。

运行命令的输出通过指定的管道发送回恶意软件，然后提供回CnC。

成熟的银行家和小偷

从上面的分析可以看出，IcedID不仅是一个银行木马，而且是一个能够提取各种凭证的通用窃取者。它还可以作为其他模块的下载器，包括那些看起来像无害的PNG文件的隐蔽模块。

这个机器人是成熟的，由经验丰富的开发人员编写。它部署了各种典型的技术，包括zeus风格的webinject、用于各种浏览器的钩子、隐藏的VNC和backconnect。它的作者还使用了几种已知的混淆技术。此外，使用定制的PE头是一个有趣的好处，它降低了静态分析的速度。

在最近的更新中，恶意软件作者配备了带有隐写术的机器人。在威胁景观中看到它并不是一种新颖性，但它是一个让这个恶意软件更隐秘的功能。

妥协指标

沙箱运行：

https://app.any.run/tasks/8595602a-fa98-4cfa-80d7-98925091dc48/
https://app.any.run/tasks/a7abba78-cf6d-4c68-b94c-4835d5becb13/

主教法冠

• 执行：
  • 命令行界面
  • 通过模块加载执行
  • 计划任务
  • 脚本
  • Windows管理Intstrumentation

• 持久性:
  • 注册表运行密钥/启动文件夹
  • 计划任务

• 特权升级
  • 计划任务

• 国防逃税
  • 脚本

• 凭据访问
  • 凭证在文件中
  • 凭据倾销

• 发现
  • 网络共享的发现
  • 查询注册表
  • 远程系统发现
  • 系统信息发现
  • 系统网络配置发现

• 横向运动
  • 远程文件复制

来源:https://app.any.run/tasks/48414a33-3d66-4a46-afe5-c2003bb55ccf/

工具书类

关于IceID的旧变体:

• Deep Dive Into IcedID Malware - Kai Lu, Fortinet: [1][2][3.]
• https://medium.com/@dawid.golak/icedid-aka-bokbot-analysis-with-ghidra-560e3eccb766