前段时间，在审查一些发给MalSilo的样本报告的时候，有些细节吸引了我的注意，下面是其中一个样例的触发点。

里面的每一个恶意行为看起来都很普通，但在快速地检查一遍之后，会发现一些奇怪的元数据，这些元数据表明这个样本是用 CypherIT加了壳的。

在我通过搜索发现这些之前，这个加壳工具已经在一些论坛和YouTube里很出名了。

这篇分析报告的第一部分会对样例的各个层级进行分析，一直分析到涉及到RunPE(shellcode)的核心部分。

第二部分会对CypherIT网站上宣传的每个功能，分析其代码实现

第三分部会分析其他的一些加了壳的恶意软件，以及他们的payload。在这里要感谢MalSilo的backends（其中之一是恶意软件信息共享平台(MISP)）提供的恶意软件样本

最后但也很重要的是，我们会分析一下最新的几个样例

让我们开始揭开这个壳的神秘面纱。

样本的技术细节如下：

sample.exe

壳的执行流程如下：

sample.exe执行一次基本的反分析检查

1.执行AutoIT脚本

AutoIT代码：

启动执行逻辑：

移除Zone.Identifier

创建mutex

Sleep

运行PE资源块中附加的解密程序

执行RunPE（通过shellcode），在这个例子中，是self-process hollowing

安装持久化任务

最终的payload（在这个例子中是DarkComet）执行dirty job。

为了避开可能的监控，加载器的第一层只检查程序是否被调试，实现的方式是在偏移0x00403b7A

处调用古老的isDebugPresent

如果程序正被调用，就会显示一个假消息给用户，然后退出程序。

在这一步中，并没有进行额外的反分析检查，整个执行流完美地将控制权交给AutoIT的代码解释器。

样例的代码并没有被重度混淆，许多核心函数的名称还保持原样（例如，binder, startup,
persistautoinject,[...]）。

然而，整体代码可以被分为3块。

顶层：主要是AutoIT的一些原生的主要函数+基本的字符串混淆函数

中层：核心功能

底层：主要执行逻辑

让我们从底层开始；下图是开始部分的主要步骤

中间部分的代码存着的函数比这个样例的更多。有些存着加密函数的进入和退出行为。

在那些函数中，还有一些有趣的，但是本样例中没有使用到的函数：

PersistAutoinject

Binder

UACBypass

USBSpreader

AntiVM

在清理（译者注：去除字符串混淆）了一些函数并对部分函数重命名之后，payload注入RegAsm.exe的过程就很直观了。

请注意，$_cryptedfile存储着解密后的PE资源，这一PE资源是由加密器携带着的最终的payload。

根据函数的参数，储存在加壳器中的payload被附加到一个未被感染的文件的末尾，然后开始执行。

合并后的文件可被放进%temp%中，%appadata%或是原文件运行时所在的文件夹

基于操作系统的版本，有两种不同的UAC绕过方法

在Windows7或8中是通过eventwer,而在Windows10中是通过fodhelper。

该函数的实现是这样的：

枚举可移除的设备

对于每个设备，找到其对应的文件夹

对于每个没有 .pif
后缀的文件，将payload复制到文件夹中，并重命名为原名称加上 .pif 后缀

删除原始文件

该函数会进行三条注册表的检查

通用的注册表

VMware的注册表

VirtualBox的注册表

在代码的 top
部分，有几个很明显的函数调用，它们是RunPE和其他的操作系统调用的组成部分。

DllStructSetData

DllStructGetSize

DllStructGetPtr

DllStructGetData

DllStructCreate

DllCall

至于字符串混淆部分，去除混淆的函数是这样的

在脚本的各个地方都有反混淆线程调用，不过字符串的含义却很明显。

在使用脚本中硬编码的密码读取并解密（AES256）携带的payload之后，后面的操作如下述流程图所示。

考虑到 UPX 部分具有 on/off 特征，在其他例子中可能并不会启用。

shellcode（下图只是一小份代码片段）被嵌入到脚本里，并有一个专属的函数 RunPE
。函数主体被字符串混淆函数xharcuawtv隐藏起来了。

在将shellcode提取并转换为合适的格式后，第一条shellcode指令通过PEB来获取kernel32和ntdll的基地址，用于随后的API调用。

shellcode也使用了一个基本的哈希函数，而不是将各个Windows API的字符串直接存储。

负责计算hash的函数位于\@ 0x00000092

汇编代码段翻译成python还是比较简单的。

在枚举从kernel32.dll和ntdll.dll中导出的函数时，将shellcode中找到的哈希值与其字符串对应起来就有点烦琐，正如这部分开头所展示的那样

在最后，调用ResumeThread,恢复挂起的进程（已经将payload注入进去）并释放携带的恶意软件。

在网络上快速地搜索了一下与shellcode的wrapper相似的结果，找到了一个几乎完全相同的版本。该版本由一个用户在2016年发布于一个论坛上，原名叫作Wardow

假如说先前找到的是真的，那么一个可能是CypherIT的是直接由复制粘贴的wrapper/shellcode组成，再嵌入到加密器中。

先来看一看CypherIT的官网，从刚刚分析的代码中观察到的功能和官网列出的功能还是很容易一一对应起来的。

注意：截图日期为2019年4月

壳的价格从30到300欧元不等，除此之外，还提供7X24小时的Discord(译者注：国外一款语音聊天软件)技术支持。

我猜Skype，ICQ和Jabber的时代就要过去了;-)

MalSilo可以用在多种后端中，有的用于存储元数据，有的是用于例子中这种场景 -
除此之外还有更多的用法。

到现在为止我们一直在关注加密器，而对于payload并没有太多的关注，我想，调查一下在这次攻击活动中是否还有相似的恶意软件，也是挺有意思的一件事情。

因为MalSilo本质上来说难于观察到全世界的安全威胁。不过它还是可以提供一些观察的视角。比如说，用它看看有多少例子传到了这个系统中。

通过查询MISP（后端#2）可以搜到我们想要的内容，将所有收集到的例子按时间排序。

下表显示总共有49个样子，我们先前分析的“首个病例”出现在2018-11-28。

因为MalSilo工作的方式，追踪每一个恶意软件家族的步骤都是独一无二的，因此对于这方面我没有太多的东西能够分享，但其中的关键点可以罗列如下：

创建加密器指纹的YARA规则（注意：到目前为止，这个规则是针对先前分析的版本制定的，并没有考虑最新的版本的情况）

用新的规则+个性化的脚本查询后端#1（样例存储的地方）

对于每一个匹配，从后端#2（MISP）中提取样例的元数据

对所有样例批量脱壳

对于每个样例

收集加密payload中硬编码的密码

解密携带的payload，提取并存储到磁盘中

payload指纹是通过静态或动态的手段来采集的。对于混淆或是加壳这些使静态分析手段无效的情况，可以使用动态检查。最终的结果如下：

AutoIT提供了一个简单的方式来将定制的资源添加到文件中，具体的实现方式是通过一个特定的用户定义函数（UDF,User
Defined Functions），也就是#AutoIt3Wrapper_Res_File_Add。

有趣的是，它暴露了嵌入资源的完整路径，因此，对于某些例子来说，它也暴露了构造这个payload的Windows用户名。

这些Windows路径的前半部分，暴露了下述名称

c:\users\user

c:\users\robotmr

c:\users\lenovo pc

c:\users\hp

c:\users\bingoman-pc

w:\work\client and crypter

c:\users\administrator

c:\users\pondy

c:\users\peter kamau

用每个payload里提取出Windows路径画出的柱形图，如下所示

从上图中可以发现，壳确实是被一些恶意软件所使用。

出于好奇，我分析了administrator
用户的加密器（也是由这篇文章开头调查到的用户构造的），分析表明这三个样例都是由同一个版本(或更老的？)的CypherIT生成的。

之所以说可能是由更老的版本生成的，是因为，如果看一下其他例子，可以发现混淆技术在不断地更新。

大约在2019.02.11，YARA规则的开发结束了，因为CypherIT进行了一次更新。

从2019.07.23时在MalSilo中观察到的一个最近的例子（7b252dbb6a39ea4814d29ebfd865f8a46a69dd9f）以及一些之前的（2019年2月-2019年7月）例子，表明混淆技术或多或少地在不断更新。

到这里我们再从头梳理一下。

最后一部分会调查一些函数，下面是一些结论。

在运行时，第一条指令是一个循环，由大量的if语句组成，在这里初始化了一些变量。

在循环之前设置了一个控制变量，确定接下来应该跳到哪一个块

到每个if代码段的结束部分，控制变量会重新初始化，确定下一次跳转到哪里

一旦代码块被执行，一个特定的函数会被解析并调用。

最后，执行流就几乎和旧版本一样了。

像上面描述的扁平化控制流（CFF，Control Flow
Flattening），几乎在每个函数中都有，还伴有字符串混淆，最后一例中，有时有，有时没有CFF。

当提到沙盒检测时，就不得不提到两个新的函数

检测VirtualBox和VMware的VM客户端工具

追踪鼠标移动

AntiVM_mouse_check的代码段使用了CFF和字符串混淆

恢复（译者注：去除字符串混淆和控制流扁平化）之后的AntiVM_mouse_check

AntiVM_process_check

恢复之后的AntiVM_process_check

关于payload，最新版本的payload存储在多个资源中，RESOURCE_TYPE_FONTDIR这个函数负责重建它，如下所示。

第一个函数参数，$data，接收一个由 | 分隔的资源列表，用它来重建最后的payload

$data=X|USXlhrrTcD|JqLn|hEuiNUhgRzrxs|nyFoHiqBt|PJYZYBUO|ChaHOMZLQtIa|AFpMebeesFkYteWii|FCSQpnQ|BHxAiLvVjtJlwSKA

关于shellcode没有什么特殊的地方好说的，它还是和之前分析的几个例子一样。

CypherIE并没有什么打破规则的技术，在揭开混淆层之后，可以发现它还是和2018年观察到的特征一样，只是添加了一些将各种技术组合起来的小把戏和一些功能（在最后一部分并没有完整地列出）

尽管最近使用了CFF和新的字符串混淆的样例增大了分析难度，但是因为其命名约定，一些函数和相关参数就显得有点多余。

如果说之前版本的样本是将payload存储在PE文件的一个section中，最新的版本则是将它分割开来存储在多个资源中，但是从本质上来说，重建的技术还是和以前一样。

除此之外，因为代码的框架逻辑在经过几次更新后仍然没有改变，一旦新的把戏被揭穿，分析步骤就和之前的样例一样了。

[注意]APP应用上架合规检测服务，协助应用顺利上架！