0x00 前言

我们最近遇到了一个大型的恶意软件样本，该恶意软件经过混淆，为我们提供了一些有趣的分析挑战。该恶意软件使用虚拟化技术，阻止生成完全反混淆后的内存转储，以防止静态分析过程。如果要对这个大型虚拟化样本进行分析，可能需要几天到几周的事件。为解决这一问题，FLARE逆向工程团队与Mandiant咨询团队之间开展了合作，最终将逆向工程的过程减少到数个小时的时间。

我们怀疑该样本是横向移动的工具，因此我们需要适当的环境来进行动态分析。事实证明，配置环境是必不可少的，我们希望赋能给遇到利用Windows域的恶意样本的其他分析工程师。在本篇文章中，我们将说明如何设置Windows域，以运行恶意软件，随后将介绍用于确认某些恶意软件功能的分析技术。

0x01 初步分析

在分析新型恶意软件样本时，我们首先要从最基本的静态分析开始，我们通常可以了解样本的类型和功能。利用这一信息，我们就可以规划分析的后续阶段，并专注于相关数据。我们从可移植的可执行分析工具开始，例如CFF Explorer。在这种情况下，我们发现样本较大，达到了6.64MB。这通常表明，样本中包含静态链接库，例如Boost或OpenSSL，这会导致分析过程变得困难。

此外，我们注意到，导入表中包含8个动态链接的DLL，每个DLL仅有一个导入函数，如下图所示。这是加壳程序和混淆程序用来导入DLL的常用技术，后续可以将这些DLL用于运行时链接，而不会公开恶意软件使用的实际API。

可疑导入：

我们在对字符串进行分析的过程中，证实了我们的怀疑，也就是这个恶意软件难以进行静态分析。由于文件太大，因此有超过75000个字符串需要考虑。我们使用StringSifter，根据与恶意软件的相关性，对字符串进行排名，但一无所获。下图展示了使用StringSifter得到的最相关的字符串。

StringSifter输出结果：

当我们遇到这类障碍时，通常会考虑使用动态分析的方法来揭秘恶意软件的行为。在这种情况下，我们的基础动态分析似乎有一些希望。在执行后，恶意样本打印出了用法说明：

Usage: evil.exe [/P:str] [/S[:str]] [/B:str] [/F:str] [/C] [/L:str] [/H:str] [/T:int] [/E:int] [/R]
   /P:str -- path to payload file.
   /S[:str] -- share for reverse copy.
   /B:str -- path to file to load settings from.
   /F:str -- write log to specified file.
   /C -- write log to console.
   /L:str -- path to file with host list.
   /H:str -- host name to process.
   /T:int -- maximum number of concurrent threads.
   /E:int -- number of seconds to delay before payload deletion (set to 0 to avoid remove).
   /R -- remove payload from hosts (/P and /S will be ignored).
If /S specifed without value, random name will be used.
/L and /H can be combined and specified more than once. At least one must present.
/B will be processed after all other flags and will override any specified values (if any).
All parameters are case sensetive.

我们尝试在暂停进程时通过转储内存来实现恶意样本的脱壳。但事实证明，这非常困难，因为恶意软件几乎立即就退出了，并且自行删除。通过使用下面的命令，我们最终成功获得了部分脱壳后的内存转储。

执行以运行二进制文件的命令：

sleep 2 && evil.exe /P:"C:\Windows\System32\calc.exe" /E:1000 /F:log.txt /H:some_host

我们选择了一个任意的Payload文件，并为Payload删除选择了一个较大的间隔。我们还提供了一个日志文件名和一个主机名，用于执行Payload。这些参数的作用在于缩短执行时间，因此我们就可以在进程终止时，将其挂起。

在两秒钟过后，我们使用Process Dump生成了内存快照。但遗憾的是，虚拟化仍然阻碍了静态分析过程，并且我们的样本大部分仍然被混淆。不管如何，我们还是成功提取到了一些字符串，也算是有了一些突破。

下面展示了我们发现的一些值得关注的字符串，这些字符串在原始的二进制文件中不存在。

内存转储中的字符串输出：

dumpedswaqp.exe
psxexesvc
schtasks.exe /create /tn "%s" /tr "%s" /s "%s" /sc onstart /ru system /f
schtasks.exe /run /tn "%s" /s "%s"
schtasks.exe /delete /tn "%s" /s "%s" /f
ServicesActive
Payload direct-copied
Payload reverse-copied
Payload removed
Task created
Task executed
Task deleted
SM opened
Service created
Service started
Service stopped
Service removed
Total hosts: %d, Threads: %d
SHARE_%c%c%c%c
Share "%s" created, path "%s"
Share "%s" removed
Error at hooking API "%S"
Dumping first %d bytes:
DllRegisterServer
DllInstall
register
install

到目前为止，根据我们的分析，我们怀疑这一恶意软件的作用是远程系统访问。但是，如果不提供一个可用于横向移动的测试环境，我们就无法证实我们的怀疑。为了加快分析，我们创建了一个虚拟化的Windows域。

这需要一些配置过程，因此在使用这一分析技术时，我们在这里详细记录了过程，以帮助其他研究人员。

0x02 创建测试环境

在测试环境中，需要确保安装干净的Windows 10和Windows 2016（Desktop Experience）虚拟机。我们建议创建两台Windows Server 2016虚拟机，这样就可以将域控制器和其他测试系统分开。

在宿主机系统上的VMware Virtual Network Editor中，使用以下设置创建自定义网络。

1、在VMNet Information下，选择“Host-only”选项；

2、确保禁用“Connect a host virtual adapter”（连接宿主机虚拟适配器）选项，以防止连接到外部世界；

3、如果使用静态IP地址，应确保禁用“Use local DHCP service”（使用本地DHCP服务）选项。

如下图所示。

虚拟网络适配器配置：

然后，配置虚拟机的网络适配器，以连接到该网络。

1、为虚拟机配置主机名和静态IP地址；

2、选择域控制器IP作为所有虚拟机的默认网关和DNS服务器。

我们使用了下图所示的系统配置。

示例系统配置：

在完成所有配置后，首先将Active Directory（活动目录）域服务和DNS服务器角色安装到指定的域控制器服务器上。这可以通过Windows Server Manager应用程序，选择下图中所示的选项来完成。在添加角色后，就可以在整个对话框中使用默认设置。

域控制器上所需的角色：

一旦安装了角色，就可以运行升级操作，如下图所示。将Active Directory域服务角色添加到服务器后，可以通过通知菜单（标志图标）访问升级选项。添加具有完全限定根域名的新森林，例如testdomain.local。其他选项可以保留为默认值。在上述升级过程完成后，重新启动系统。

在服务器管理器中，将系统升级为域控制器：

在升级域控制器后，可以通过域控制器上的“Active Directory Users and Computers”（活动目录用户和计算机）创建测试用户帐户，如下图所示。

测试用户帐户：

在创建测试帐户后，继续将虚拟网络上的其他系统加入域。这可以通过高级系统设置来完成，如下图所示。使用测试帐户凭据，将系统加入域中。

为每个虚拟机配置域：

在将所有系统都加入域后，请验证每个系统是否可以ping其他系统。我们建议在测试环境中禁用Windows防火墙，以确保每个系统都可以访问测试环境中的另一个系统的所有可用服务。

富裕测试帐户所有测试系统的挂历元权限。这可以通过使用下面的命令，手动修改每个系统上的本地管理员组来完成，或者通过组策略对象（GPO）自动进行。

将用户添加到本地管理员组的命令：

net localgroup administrators sa_jdoe /ADD

0x03 在Windows域中进行动态分析

至此，已经完成了全部的准备过程。我们通过安装并启动WireShark和Process Monitor来准备测试环境。我们对所有三个虚拟机做了快照，并在客户端的测试域帐户的上下文中运行了恶意软件，如下所示。

用于运行恶意软件的命令：

evil.exe /P:"C:\Windows\System32\calc.exe" /L:hostnames.txt /F:log.txt /S /C

我们使用以下主机名（以行作为分隔），填充hostnames.txt文件，如下所示。

hostnames.txt的文件内容：

DBPROD.testdomain.local
client.testdomain.local
DC.testdomain.local

0x04 数据包捕获分析

通过分析数据包捕获中的流量，我们在主机列表中确认了与每个系统的SMB连接。在SMB握手完成之前，需要Kerberos票证。如下图所示，向用户请求了票证授予票证（TGT），并向每台服务器请求了服务票证（ST）。如果大家想要了解有关Kerberos身份验证协议的更多信息，可以参考我们最近的博客文章，其中介绍了该协议和新的协议。

Kerberos身份验证过程：

该恶意软件通过SMB访问C$共享，并写入文件C:\Windows\swaqp.exe。随后，它使用RPC启动SVCCTL，该SVCCTL用于注册和启动服务。SVCCTL创建了swaqpd服务，该服务用于执行Payload，随后被删除。最后，该文件也会被删除，并且我们未观察到其他恶意活动。流量如下图所示。

在数据包捕获过程中观察到的恶意软件行为：

通过我们使用Process Monitor对恶意软件行为进行分析的过程，我们证实了这一发现。然后，我们继续使用不同的命令行选项和环境运行恶意软件。结合我们的静态分析过程，我们可以自信地确定恶意软件的功能，其中包括将Payload复制到远程主机、安装和运行服务以及事后删除证据。

0x05 总结

如果要对经过大量混淆的恶意样本进行静态分析，可能需要花费数十小时。在这种情况下，动态分析就提供了一种替代的解决方案，但它需要分析人员预测并模拟适当的执行环境。在这种情况下，我们可以将我们的样本分析基础知识与虚拟化的Windows域结合起来，以实现最终的分析。通过将FLARE的逆向工程知识与Mandiant的安全咨询、红队攻防经验相结合，我们充分利用了各项技能，最终成功将分析所花费的时间减少到几个小时。我们通过从受感染主机中快速提取必要的指标来支撑事件的应急响应调查。同时，我们希望分享这些经验，以帮助其他人建立自己的横向移动分析环境。

本文翻译自：https://www.fireeye.com/blog/threat-research/2020/07/configuring-windows-domain-dynamically-analyze-obfuscated-lateral-movement-tool.html如若转载，请注明原文地址：