扒一扒CARBANAK的源代码，看它们是如何巧妙构思并运行的？（三）

前两篇文章（ 1 和 2 ），我们已经对CARBANAK的源代码本身进行了详细的分析，现在就让我们分析一下CARBANAK源代码的构建 工具 吧。

构建工具

让我们先来看看我们对CARBANAK构建工具的初始猜想和推断：

该工具会允许攻击者配置诸如C2地址、C2加密密钥和活动代码等详细信息，这个构建工具使用每个构建的新密钥加密二进制文件的字符串。

之所以会有以上的推论，是因为：

大多数CARBANAK的字符串都经过加密，以便使分析更加困难。我们注意到，对于我们遇到的每个示例，所有加密字符串的密钥和密文都会发生变化，即使在具有相同编译时间的示例中也是如此。另外，我们还观察到用于HTTP协议的RC2密钥在具有相同编译时间的示例之间发生变化。这些观察结果表明，可能存在构建工具。

图1显示了用于解码CARBANAK中的字符串的三个密钥，每个密钥都来自不同的CARBANAK示例。

对于每个构建版本，CARBANAK中字符串的解密密钥都是惟一的

事实证明，我们的推论是正确的，并在CARBANAK源转储中发现了一个构建工具，如图2中的英文翻译所示。

CARBANAK构建工具

使用此构建工具，你可以指定一组配置选项以及一个模板CARBANAK二进制文件，并将配置数据置换成二进制文件，以生成用于发送的最终的构建文件。 “前缀”文本字段允许操作符指定活动代码。管理主机文本字段用于指定C2地址，而管理密码文本字段是用于派生RC2密钥以加密通过CARBANAK的伪HTTP协议进行通信的密钥。

现在就可以确定有一个构建工具确实存在，并用于配置构建的活动代码和RC2密钥以及其他项目。要想知道编码的字符串是什么样的，只在构建工具的GUI中是找不到什么有价值的信息的，因此我们必须查看后门和构建工具的源代码。

图3显示了CARBANAK后门源代码中定义的一个名为ON_CODE_STRING的预处理器标识符，当启用该标识符时，宏会被自动定义，另外这些宏封装了 程序员 希望用二进制编码的所有字符串。这些函数将要编码的字符串用字符串“BS”和“ES”串联起来。图4显示了构建工具源代码的标头文件中的一小段代码，其中将BEG_ENCODE_STRING定义为“BS”，END_ENCODE_STRING定义为“ES”。构建工具会在模板二进制文件中搜索这些“BS”和“ES”标记，提取它们之间的字符串，使用随机生成的密钥对它们进行编码，并用编码的字符串替换二进制文件中的字符串。另外，我们还发现了一个名为bot.dll的可执行文件，它恰好是构建工具使用的模板二进制文件之一。在这个二进制文件上运行的字符串表明，特定于CARBANAK后门工作的最有意义的字符串实际上是被加载在“BS”和“ES”之间的，如图5所示。

ON_CODE_STRING参数使简单的字符串包装宏能够通过构建工具为编码准备字符串

编码字符串标记的builder.h宏

模板CARBANAK二进制文件中的编码字符串标记

对源代码的访问

下面是我们起初的两个推论：

1.根据我们所观察到的信息，我们认为至少CARBANAK的一些运营商可以直接访问源代码，并了解如何修改源代码或与开发人员建立密切关系；

2.一些运营商可能会独立编译他们自己的后门；

第一个推论是根据下列证据作出的:

尽管有可能使用构建工具，但我们在示例集中发现了57个独特的编译时间，其中一些编译时间非常接近。例如，在2014年5月20日，有两个版本编译的时间相隔约4小时，并配置为使用相同的C2服务器。同样，在2015年7月30日，有两个版本编译的时间相隔约12小时。

为了进一步研究，我们执行了两个编译时间非常接近的CARBANAK示例，以查看代码中的更改（如果有的话）。图6显示了一个这样的差异。

两个编译时间非常接近的CARBANAK示例之间的微小差异

POSLogMonitorThread函数仅在示例A中执行，而blizkoThread函数仅在示例B中执行（Blizko是俄罗斯资金转账服务软件，类似于PayPal）。 POSLogMonitorThread函数监视对特定销售点软件的日志文件所做的更改，并将解析后的数据发送到C2服务器。blizkoThread函数通过在注册表中搜索特定值来确定计算机用户是否是Blizko客户。通过了解这些细微的差异，我们搜索了源代码，再次发现使用了预处理器参数。

预处理器参数会确定哪些函数将包含在模板二进制文件中

注意，这并不是运营商可以访问源代码的明确证据，只能作为参考。运营商不需要具备任何编程知识，只需简单指导如何在Visual Studio中添加和删除预处理器参数，即可对构建进行微调以满足他们对特定目标的访问需求。

第二个推论的证据是通过查看二进制C2协议的实现以及它随时间的推移而改变的过程：

多年来，这个协议经历了几次修改，每个版本都以某种方式建立在前一个版本的基础上。这些变化可能会使现有的网络签名失效，并使签名创建更加困难。

如图8所示，在我们的示例集中发现了二进制C2协议的五个版本。该图显示了在我们的示例集中找到每个协议版本的第一个注释编译时间，每个新版本都提高了协议的安全性和复杂性。

通过二进制编译时间显示的二进制C2协议的演变

如果CARBANAK项目位于中心位置，并且只将模板二进制文件交付给运营商，那么预期示例编译时间应该与二进制协议的发展保持一致。除了一个实现协议“版本3”的示例外，时间轴看起来是这样的。对于版本3没有列出日期的一个可能解释是，我们的样本集不够完整，无法包含该版本的第一个样本。这并不是我们发现的唯一一个在示例中实现过期协议的情况，图9显示了另一个示例。

使用过期版本的二进制协议的CARBANAK示例

在这个示例中，野外发现的CARBANAK示例使用的是协议版本4，而新版本至少已经发布了两个月。如果源代码保存在一个单独的中央位置，则不太可能发生这种情况。使用预处理器参数对模板二进制文件进行快速微调，再结合几个实现过时协议版本的CARBANAK示例，表明CARBANAK项目是分发给运营商的，而不是集中保存的。

以前未识别的命令的名称

源代码显示了一些命令的名称，这些命令的名称以前是未知的。实际上，它还显示了一些命令，这些命令在我们之前写的示例中完全没有出现过，因为该功能被禁用了。表1显示了在CARBANAK源代码中新发现的命令。

表1：以前未按名称标识的命令哈希值

msgbox命令在CARBANAK源代码中完全被注释掉了，并且严格用于调试，因此它从未出现在公共分析的样本中。同样，ifobs命令也没有出现在我们分析和公开记录的示例中，但可能出于不同的原因。图10中的源代码显示了CARBANAK能够理解的命令表，并且ifobs命令（0x6FD593）被#ifdef包围，除非启用了ON_IFOBS预处理器参数，否则ifobs代码无法编译到后门。

来自CARBANAK任务代码的命令表

然而，一个更有趣的命令是tinymet，因为它说明了源代码如何既有用又有误导性。

tinymet命令和相关载荷

在我们最初的CARBANAK分析中，我们指出命令0xB0603B4（当时名称未知）可以执行shellcode。源代码显示该命令（其实际名称为tinymet）旨在执行一个非常特定的shellcode。图12显示了用于处理tinymet命令的代码的简略列表，其中行号为黄色，隐藏的选定行（灰色）以更紧凑的格式显示代码。

缩写的tinymet代码清单

从第1672行开始的注释表明:

tinymet command
Command format: tinymet {ip:port | plugin_name} [plugin_name]
Retrieve meterpreter from specified address and launch in memory

在第1710行，tinymet命令处理程序使用单字节XOR密钥0x50来解码shellcode。值得注意的是，在第1734行，命令处理程序分配了五个额外字节，第1739行将5字节的mov指令硬编码到该空间中。它使用套接字句柄号填充mov指令的32位立即操作数，该套接字句柄号用于从服务器连接检索shellcode，这个mov指令的隐含目标操作数是edi寄存器。

我们对tinymet命令的分析到此就结束了，直到发现了名为met.plug的二进制文件。图12中的十六进制转储显示了此文件的结尾。

met.plug的十六进制转储

文件的末尾没有与五个缺失的字节对齐，这与任务源代码中动态组装的mov edi前导码相对应。但是，在源代码中找到的单字节XOR密钥0x50未能成功解码此文件。经过一些分析后，我们意识到这个文件的前27个字节是一个shellcode解码器，看起来非常类似于call4_dword_xor。图13显示了shellcode解码器和编码的metsrv.dll的开头。 shellcode使用的XOR密钥是0xEF47A2D0，它与5字节mov edi指令、解码器和相邻的metsr .dll在内存中的布局方式相匹配。

Shellcode解码器

解码产生了从偏移量0x1b开始的metsrv.dll副本，当shellcode执行退出解码器循环时，它会执行Metasploit的可执行DOS标头。

具有讽刺意味的是，拥有源代码会使我们的二进制分析偏向错误的方向，在实际存在使用四字节XOR密钥的27字节解码器前导码的情况下，建议使用单字节XOR密钥。此外，命令名称为tinymet，表明涉及TinyMet Meterpreter stager。这在某种程度上可能是这样的，但是源代码注释和二进制文件表明，开发人员和运营商已经可以直接下载Meterpreter而不用更改命令的名称了。

小结

访问CARBANAK的源代码和工具集，为我们提供了一个独特的机会来回顾前面的分析。以此来弥补原来分析的不足或加固对原来的分析推论。上述分析表明，即使没有访问源代码，只要有足够大的样本集和足够的分析，也可以达到同样的分析目的。例如在tinymet命令的情况下，有时，如果没有适当的上下文，我们根本就无法看到给定代码段的完整而清晰的目的。但是一些源代码也与附带的二进制文件不一致。

接下来，我们将介绍CARBANAK套件中一个有趣的工具：一个视频播放器，用于播放后门捕获的桌面录像。

视频播放器

CARBANAK后门可以录制受害者桌面的视频， 据报道 ，攻击者通过观看录制的桌面视频，以了解在目标银行工作员工的操作流程，使他们能够成功插入银行验证过程未检测到的欺诈性交易。视频数据文件格式和用于观看视频的播放器似乎是自定义编写的，如下图所示的视频播放器和木马的C2服务器被设计成一对一工作模式。

CARBANAK桌面视频播放器

C2服务器以视频播放器理解的自定义视频文件格式封装从CARBANAK木马接收的视频流数据，并根据视频播放器提前设定的规则将这些视频文件写入磁盘上的某个位置。下图所示的StreamVideo构造函数就创建了一个新的视频文件，该文件将填充从CARBANAK 木马接收的视频捕获数据，其中包括签名标记、时间戳数据和受感染主机的IP地址。以下这段代码是C2服务器项目的一部分。

carbanak\server\ server\ Stream.cs ： 来自C2服务器的代码片段，它将视频数据序列化到文件中

下图显示了LoadVideo函数，它是视频播放器项目的一部分。它通过查找TAG签名来验证文件类型，然后读取时间戳值和IP地址，就像它们由上图中的C2服务器代码写入一样。

carbanak\server\Player\ video .cs ： 播放器代码，它加载C2服务器创建的视频文件

如下面两个图所示，视频文件的扩展名为.frm。第一个图所示的C2服务器的CreateStreamVideo函数按照MakeStreamFileName函数中定义的约定格式化文件路径，然后调用第二个图的StreamVideo构造函数。

carbanak\server\ server\ RecordFromBot.cs ： C2服务器中的函数，用于格式化视频文件名并添加扩展名“frm”

下图中所示的视频播放器代码片段按着视频文件路径约定，在所有视频文件目录中搜索扩展名为.frm的文件，这些文件的开始和结束时间戳都在DateTime变量dt的范围内。

carbanak\server\Player\Video.cs：来自播放器代码的片段，用于搜索扩展名为“frm”的视频文件

我们遇到了几个视频文件的示例，但只有一些与这个视频播放器兼容。经过分析，我们发现至少有两种不同版本的视频文件格式，一种是压缩视频数据格式，另一种是原始格式。在对视频处理代码进行了一些轻微的调整之后，这两种格式现在都支持，样我们就可以播放所有视频示例了。

下图显示，攻击者似乎正在测试命令，并确保它们不会被某些安全监视工具检测到。

图中的命令列表都是关于持久性、屏幕截图创建和启动各种有效载荷的

总结

在这三篇文章中，我们详细分享了许多关于逆向一个大型、复杂的恶意软件家族的细节。