为了揭开恶意软件的神秘面纱、让每个人都能更好的了解日常网络威胁，网络安全公司certego决定做一档名为Malware tales的专栏，作为该档专栏开篇文章的介绍对象——Gootkit，certego将对其最近出现的新变体、从代码级别做深入分析。

简介:

1、威胁

2、payload交付

3、Gootkit可执行文件

4、第一阶段:加壳的Gootkit

5、第二阶段:站稳脚跟

6、第三阶段:检入阶段

7、最后阶段

8、额外发现

9、总结

威胁

自2014年夏天问世以来，GootKit木马就被人们广泛认为是现今活跃的最复杂的银行木马之一，它的目标是窃取受害者的可用信息，通过劫持银行账户来执行交易，主要在意大利及欧洲其他地区活动。关于GootKit银行木马之前的威胁报告可在此阅读。而今天我们将深入分析上周新出现的一类变体。

payload交付

此次检测到的样本中，GootKit采用了常见的钓鱼邮件的方式。下图是一封用意大利语写的电子邮件正文，内容是让用户点击红色字体确认订单信息，用户一旦点击后将下载恶意附件。

下载的文件是一个名为“GLS_Notifica.js”的严重混淆的Javascript文件。如果用户打开它，默认情况下本机Javascript解释器wscript.exe将被执行，并执行以下HTTP请求：

hxxp://redok.com[.]mx/tmp/337.php

之后将下载了一个文件夹文件，该文件是一个可以由Windows本机提取的存档文件。里面有一个可移植的可执行文件，它将保存在％TEMP％文件夹（“C：\ Users \ <username> \ AppData \ Local \ Temp”）中并执行。

Javascripts下载器是常见的交付payload的方式，因为对其稍微混淆可能就会使它们很难被防毒引擎检测到。

Gootkit可执行文件

在自动化环境中首次运行样本后，我们发现此版本中多了一些新的内容——恶意软件作者为恶意代理加了新的一层保护。如下图所示，第一张表示的是在2018年12月期间于意大利发现的Gootkit变体，第二张则是当前测试样本。（图片来自AnyRun）

这意味着，为了拖延分析师们对逆向解析的速度，原始程序是加壳的，并且也能让像Yara规则这样效率低下的静态分析工具失去了发挥空间。

第一阶段:加壳的Gootkit

在这种情况下，恶意软件分析人员知道，他必须在不浪费时间的情况下尽可能快地提取原始payload，以尝试理解这一阶段的内部工作。

有一个很好的开源工具可以在几秒钟内解决这个问题。它叫做PE-Sieve (Github地址)。尽管它并不总是有效，但在这种情况下，它可以转储原始可执行文件的未映射版本，因为该样本使用一种称为Process Hollowing的技术，也叫RunPE，技术手段包括：启动处于挂起状态的新进程、“掏空”进程内容、用恶意代码替换它，最后恢复线程。

在下图中我们可以看到，“CreateProcessW”的第6个参数被设置为“4”，表示进程将以挂起状态启动。

这是一种众所周知的技术，它可以通过监视执行注入所需的Windows API调用轻松检测出来，但这里也有些出人意料的地方：我们无法找到按照执行流程所需的API调用。虽然能检测出NtCreateProcess、NtGetContextThread、NtReadVirtualMemory和NtSetContextThread，但最重要的一些地方似乎被遗漏了：

· NtUnmapViewOfSection，用于“掏空”目标进程

· NtWriteVirtualMemory，写入目标进程

· NtResumeThread，恢复挂起的线程

让我们看看发生了什么!

在其内存空间中进行一些shellcode注入之后，进程执行对IsWow64Process API的调用，应用程序使用该API来检查该进程是否要在WOW64环境下运行，WOW64是Windows操作系统的子系统，能够让此类32位应用程序在64位操作系统上运行。

检查的结果会被用于两个不同的代码路径，但殊途同归，其目的都是在内核模式下运行上述缺失的API调用之一。这意味着，以这种方式，传统的用户级监视工具将无法捕捉这些调用，而RunPE技术则不会被注意到。

具体来说，如果进程在32位环境中运行，它将使用SYSENTER命令切换到内核模式，如果是64位的环境，它将使用SYSCALL命令执行相同的操作。

更复杂的是，32位应用程序的上下文中是无法调用SYSCALL命令的，这意味着可执行文件需要利用“套中套”（trick-into-the-trick）的技巧才能执行此操作，此种技术手段是一种被称为天堂之门（The Heaven’s Gate）的技术。实际上，由于RETF指令，可以将代码段(CS)从0x23更改为0x33，从而在运行的进程上实际启用64位模式。

在下面的图像中，框中标示了“Gate”的入口和出口，其中包含执行SYSCALL操作的64位代码。

在下图中，我们可以看到在打开Gate之前(灰色=挂起的进程)和关闭Gate之后(橙色=正在运行的进程)的进程状态。

Gootkit利用The Heaven's Gate作为反调试技术，而大多数常用调试器都无法正确处理这种状况，分析师也无法逐步拆解The Heaven's Gate的代码。关于The Heaven's Gate更多信息请点击此处。

第一阶段比我们预想的更为复杂，因为它结合了各种技术，超越了混淆和隐秘的极限。

第二阶段：获得立足点

在这一阶段，我们继续分析解压的Gootkit样本。

第一个相当具有突破性的发现是，进程中会检查是否存在名为“ServiceEntryPointThread”的互斥对象，如果存在，则进程将自行终止。

互斥对象是如何工作的呢?互斥机制是一种用于序列化对系统上资源访问的锁定机制。恶意软件有时使用它作为“感染标记”，以避免感染同一台计算机两次。互斥机制的迷人之处在于，它是一把双刃剑：安全分析人员可以预先安装互斥对象来为端点“接种疫苗”。(参考:Zeltser博客）。

这也意味着互斥对象将是一个很好的缓解指标，不仅可以用来检测感染，还可以用来预防感染。

回到前面的话题，我们发现该样本中实施了大量检查命令，以了解恶意软件是否在虚拟环境中运行，其中有一些检查命令包括：

· 检查注册表项“HKLM \ HARDWARE \ DESCRIPTION \ System \ CentralProcessor \ 0 \ ProcessorNameString”是否包含词“Xeon”。

· 检查计算机名称是“7SILVIA”还是“SANDBOX”，用户名是“CurrentUser”还是“Sandbox”，或者“sbiedll.dll”是否已加载。

· 检查“HKLM \ HARDWARE \ Description \ System \ VideoBiosVersion”是否包含“VirtualBox”一词。

· 检查“HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ SystemBiosVersion”是否包含字符串“VBOX”

如果其中一个检查失败，程序将在无限循环中执行Sleep操作，以阻止自动沙箱执行。

之后，我们遇到了一种特殊的持久性机制，该机制似乎已经运用在Gootkit中好几个月的时间了，在各类博文中也有记录，例如ReaQta的文章。

简单来说，infostealer会生成具有相同文件名的INF文件。

INF文件内容:

然后，INF文件在“HKCU \ Software \ Microsoft \ IEAK \ GroupPolicy \ PendingGPOs”中创建3个不同的注册表项（“Count”，“Path1”和“Section1”），目的是让威胁在重新启动时执行。

似乎只有Gootkit使用这种技术。当前知名的安全工具仍然无法检测这个机制，即使它已经使用了几个月的时间了。例如，著名的SysInternal Autoruns工具应该能够显示配置为在系统启动或登录时运行的所有程序，但它无法检测到此持久性方法。

通过代码，我们注意到，在运行时，Gootkit使用自定义算法解密它使用的字符串，以逃避异常行为的静态分析检测。

它是“堆栈字符串”，XOR命令和模运算的组合。

解密程序的详细解释请点击此处。

进一步跳过，最后调用“CreateProcessW”来启动Gootkit的新实例，参数如下:——vwxyz。

第三阶段:检入阶段

我们很快发现，使用引用的参数执行恶意软件将允许我们跳过前面所有的反分析控件部分，进入与命令与控制服务器开始相联的代码部分。

第一次检入到home是通过HTTPS对以下URL执行:

GET hxxps://avant-garde[.]host/rbody32

从图中可以看出，请求中添加了许多header，以便将受感染计算机的不同信息发送到C&C服务器。

特别是其中一个标题引起了我们的注意:“X-IsTrustedComp”。深入到代码中，我们发现如果在主机中有名为“crackmeololo”的环境变量，则该值将设置为“1”，否则设置为“0”。

这似乎是恶意软件作者实现的另一种“躲避”机制，可能是为了自己调试的目的而停止感染链。

最后阶段

来自前一个连接的响应包含了Gootkit的最后一个阶段，该阶段Gootkit配置为能在受感染的机器上正常工作。

恶意软件将动态加载“RtlDecompressBuffer”，调用它来解压payload，之后注入当前进程内存区域。

然后，执行流将转移到注入代码的起始部分。

最终的payload是一个大于5MB的DLL文件，因为它包含Node.js引擎，这可能需要运行一些嵌入式javascript文件。这时我们决定停止分析，把剩下的留给以后的工作。

其他发现

在调试时，我们注意到Gootkit不仅会检查名为“–vwxyz”的参数是否传递给命令行，它还检查是否有其他3个参数：

· –reinstall

· –service

· -test

奇怪的是，我们还没有发现恶意软件会主动使用这些参数。然而，通过对代码的逐步分析，我们发现以下三点:

1.“——reinstall”命令会执行一些奇怪的代码。首先，恶意软件使用“CreateToolHelp32Snapshot”检索当前正在运行的进程列表。

然后，它通过“Process32FirstW”和“Process32NextW”遍历检索到的列表，目的是获取活动的“explorer.exe”实例的句柄。

此时它杀死了“explorer.exe”进程。下图显示“TerminateProcess”命令之前的进程列表。

执行该命令后，我们发现恶意软件的新实例作为“explorer.exe”的子项生成。

发生了什么？我们进行了一些测试，似乎“explorer.exe”被杀死，然后由“winlogon.exe”自动重启。因此，“explorer.exe”访问了前面所说的持久性机制中涉及的密钥：

使用此技巧，恶意软件能够“重新安装”自身，而无需使用可疑的API调用，如“CreateProcessW”。

2. “ –  service”命令没有改变执行流程，除了创建一个名为“USERNAME_REQUIRED”的新环境变量并将其设置为“TRUE”。

最后我们发现最后的阶段会检查上述变量是否存在。

3. “-test”命令只是终止进程。

结论

我们探索了当今最广泛的Infostealers之一的一些功能，揭示了一些躲避检测的新老手段。

Certego积极监控每天的威胁，以改进我们的检测和响应方法，不断提高事件响应工作流程的有效性。

hashes

597f734c780f283d6cd7c7443700a65249b8350ec1ad58b8aa790a32f57eec4d

GLS_Notifica.js

5ed739855d05d9601ee65e51bf4fec20d9f600e49ed29b7a13d018de7c5d23bc

gootkit 1st stage

e32d72c4ad2b023bf27ee8a79bf82c891c188c9bd7a200bfc987f41397bd61df

gootkit 2nd stage

0ad2e03b734b6675759526b357788f56594ac900eeb5bd37c67b52241305a10a

gootkit DLL module

本文翻译自：http://www.certego.net/en/news/malware-tales-gootkit/

翻译作者：Change  原文地址：https://www.4hou.com/technology/16417.html