提取恶意文档中的 payload
英文原文：https://blog.redbluepurple.io/other/malware-analysis/dynamic-analysis-of-malicious-office-documents此篇文章对初学者友好，介绍动态分析恶意 Office 文档和 VBA 宏以进行 payload 提取。
一、介绍
2020年，许多行为分析工具和 any.run 等公共服务可以轻松大规模地识别恶意 Office 文档，突出显示可疑指标。也就是说，与任何类型的恶意软件一样，较新的样本将不会被检测到，并且在发现时需要手动分析以提取最终 payload、了解功能并正确确定事件范围，同时还会生成在事件期间非常宝贵的运营情报和 IoC。
在这篇简短的文章中，我总结一些技巧和窍门，这些技巧和窍门将帮助你克服最常见的混淆和反分析技术，从而在逆向支持现代 VBA 的恶意 Office 文档时实现您的核心目标。
1.1 为什么不静态分析代码？
你可以，而且在某种程度上你需要这样做。@decalage2、@DidierStevens 和其他人创建了大量工具，可以帮助你在执行恶意文档的静态分析时采取的几乎任何步骤。 通读故意散布着未记录的函数和误导性语法的严重混淆的代码可能是一个耗时的过程，这是一个问题。
恶意软件研究人员在对新的和不熟悉的样本进行分类时选择的最常见方法是从 行为/动态分析 开始，以确定代码试图实现的一些关键目标。在许多情况下，确认给定样本是否恶意是唯一的目标，并且可以在那里完成任务。在这个阶段，我们可能已经有足够的信息来生成 IOC、对恶意软件进行分类和构建签名。如果需要，收集到的信息也将成为恶意软件研究等更复杂任务的绝佳切入点。
二、MS Office 调试
用于启用宏的样本的第一种也是最典型的方法是使用 MS Office 内置的 VBA 编辑器对其进行调试 —— 这在某种程度上保证了观察到的行为不会与受害机器上的行为有太大的偏差。然而，我们需要记住，一些技术，如 VBA-stomping 可能会阻止我们有效地使用它。
下面描述的大多数技术都需要安装 MS Office 套件。在某些情况下使用免费的替代品，如 LibreOffice 或 OpenOffice 可以工作，但不建议使用，因为恶意软件喜欢利用各种未记录的功能，这些功能可能在 VBA 的非 Microsoft 实现。
由于宏代码通常会包含大部分 dead 函数的基调来迷惑分析人员，因此最好从文档生命周期事件函数开始调试 —— 如 Auto_Open()、Document_Open() 等，并遵循用户可能会经历的执行流程在打开文档和 "启用内容" 时。
在单步执行代码 (F8) 时，可以通过将鼠标悬停在当前变量内容上，将它们添加到观察列表中，或者最方便的方法是 - 在 "Locals" 窗口中列出所有已初始化的局部函数变量以及当前值。这是一种强大的技术，允许我们将任何类型的复杂表达式解析为人类可读的代码。
Locals windows
Hover over initialized variable
当我们监控这些变量时，可能会观察到宏对自身进行反混淆，从 Form 对象和嵌入文件中提取 base64/hex blob，完成构建最终的 dropper payload，或者调用 Native API 函数以注入并迁移到更稳定的主机进程中 .
2.1 误导
在此过程中，可能会遇到反分析技巧，例如设置断点以越过它们的无意义循环、误导和简单的死代码，这些代码填充了从未使用过的变量，或者在执行中引入了短暂的延迟来欺骗行为分析。
An unreferenced Dim
A pointless For loop
2.2 最终 payload
如果遵循执行流程，使用几个断点 (通过循环跳转)，将到达最终 payload 正在组装和执行的点。
最常见的执行技术 (截至 2020 年) 使用 Application.Shell 或 WMI 方法来运行命令行。后者的好处是它不会创建可疑的并且相当容易检测父子进程关系。
由于 VBA 可以使用 ActiveX 对象和从 DLL（包括 kernel32、ntdll）导入的函数，因此还有许多其他执行技术，类似于恶意可执行文件所利用的那些。最值得注意的是，默认的 CobaltStrike maldoc 使用 WinAPI 将 shellcode 注入新生成的 rundll32。
在示例中，我们最终会偶然发现 Win32_Process 类名称，然后将带有 Start-BitsTransfer cmdlet 的解码 PowerShell 命令行传递给新创建的对象 —— 这种技术在未来几年不太可能减少流行，由于大多数网络犯罪分子正在从使用高度记录的 PowerShell 转向不太透明的接口，例如 WMI 或直接 API 调用。
Start-Bits Transfer cmdlet
Win32_Process WMI class
三、用 x64dbg 进行调试
让宏为我们做反混淆通常是最直接的。但是如果涉及的反调试技巧太多怎么办？这时我们可能希望将调试移到更低的级别，并在传递给 API 时拦截最终的 payload。
知道最常运行的恶意宏将导致创建新进程或某种形式的进程注入，我们可以在可用于此目的的有限 WinAPI 集上设置断点 —— 例如 CreateProcess，CreateProcessAsUser。
到达调用后，这将允许我们查看函数参数并有效拦截最终的 dropper payload。为此，我们可以将我们最喜欢的调试器附加到 EXCEL.EXE 并在 kernel32.CreateProcessW/CreateProcessA 上设置断点，我们应该在运行宏之后调用它。
此时，我们可以调查传递给该函数的参数。Microsoft 文档告诉我们，可以在第二个参数 lpCommandLine 中找到一个新的进程命令行。
在 Intel 的 x64 和 fastcall 约定的情况下，这意味着 RDX 寄存器，它似乎确实包含我们的 payload (在 x86 系统上，会在堆栈中找到所有参数)
这个恶意文档利用内联 Microsoft Scripting Host (mshta) vbscript 来执行远程代码 —— 这是一种常见且非常古老的技术。这种进程祖先在干净的系统上相当罕见，任何 EDR 软件都可以捕获，并且与 PowerShell 类似，对手正在远离它，转而采用更隐蔽的方法。
你可能遇到的一件事是将 mshta 与 WMI 结合使用 — 这也很容易检测到，但许多内部 SIEM 和 EPP 软件并没有很好地覆盖。
Dechained mshta + wmi
mshta
如果在早期分析阶段我们注意到指示 WMI 滥用的字符串，我们可以将高完整性 (作为 NT AUTHORITY/SYSTEM 运行) 调试器附加到 WmiPrvSE.Exe 进程，并转储 CreateProcessAsUser 函数的参数。
在转储中的第 3 个 (R8 - lpCommandLine) 参数处取消引用内存指针会显示 PowerShell payload，可以在 CyberChef 中复制和进一步分析：
由于 EXCEL 和 WMI Privileged Hoster 的安全上下文不同，此处不使用 CreateProcess API。
四、利用 AMSI 传感器 (ETS)
Microsoft 的反恶意软件扫描接口 (AMSI) 原生连接到 Office 用来运行宏的 VBA7 DLL，它通常能够在传递执行之前将去混淆的 WMI 对象和 WinAPI 函数及其参数等内容记录下来。
可以使用 AMSI 事件跟踪会话日志以非常轻松的方式转储最终的宏 payload。为此，首先启用 AMSI ETS 日志记录 —— 使用 logman 最简单。
运行恶意宏后，我们可以将日志导入事件查看器并调查 OFFICE_VBA 条目。在整个执行过程中经常会产生多个事件 —— 微软没有很好地记录这一点，但经验表明，一个事件的内容越大，它就越完整。
运气好的话，内容将包含接近 "明文" payload 的内容。
如果没有，我们可能想查看 AMSI 记录的其他事件，例如 WMI 事件。
五、Shellcode (scdbg, x64dbg)
在大多数情况下，shellcode 被注入到 Office 进程本身，然后作为新线程执行，并导致某种形式的进一步代码执行 (将恶意软件丢弃/注入到正在运行的进程中)。
VirtualAlloc 通常替换为 HeapCreate 和 HeapAlloc，而 CreateThread 可以替换为例如 EnumResourceTypesW 以获得相同的结果。
虽然它可以以隐蔽的方式注入，但在大多数情况下，所有这些技术都可能在目标进程中留下无备份的 RWX 内存页面。
为了快速取胜，通常希望识别这些异常页面，使用像 scdbg 这样的 shellcode 模拟器提取并注入的程序集，以便在 WinAPI 的上下文中理解它。
在分析 payload 的写入位置和方式时，AMSI 日志也很有帮助。例如，这就是使用 RtlMoveMemory API 逐字节移动 shellcode 的方式。
注入的代码可能会被异或并以解码器 stub 作为序言。不幸的是，它通常还涉及 "egg hunter"，并且在 Office 流程之外执行不会显示任何有意义的信息。这就是 ASM 知识和 IDA 技能派上用场的地方。
页:
[1]