通过VBA Purging技术实现宏混淆

通过VBA Purging技术实现宏混淆
2020-12-14 12:50:00 Author: www.4hou.com(查看原文) 阅读量:190 收藏

0x00 概述

恶意Office文件仍然是最受攻击者喜爱的一种技术，包括红队、金融恶意组织、APT组织。在这篇文章中，我们将重点讨论“VBA Purging”技术，这种技术最初是由Didier Stevens在2020年2月公开发布，并且我们近期在野外观察到越来越多的攻击者都在使用这种技术。在这里，将重点说明VBA Purging技术如何应用在复合文档二进制格式（Compound File Binary Format，CFBF）的Microsoft Office文档中，同时还将研究针对这种攻击技术的检测方式，最后介绍由Mandiant红队开发的新工具——OfficePurge。

0x01 MS-OVBA文件格式

在深入研究VBA Purging技术之前，我们首先要熟悉Microsoft定义的VBA宏规范，这里专注于使用CFBF格式的Microsoft Office 97文档中的MS-OBVA，暂时先不考虑Microsoft Excel “.xlsx”和Microsoft Word “.docx”文档中使用的比较流行的Open Office XML（OOXML）格式。

根据MS-OVBA的文件结构，所有VBA数据都被存储在一个结构中，其中包含不同类型流的结构化存储。Office文档中的VBA代码存储在各种模块流之中，模块流由两部分组成，分别是PerformanceCache（也称为P-code）和CompressedSourceCode。其中PerformanceCache部分是一个字节数组，其中包含已编译的VBA代码。

CompressedSourceCode部分包含使用Microsoft专用算法压缩后的VBA源代码。这两个部分的分界是由存储在dir流中的MODULEOFFSET来确定。模块流的示意图如下所示。

在将VBA宏添加到文档之后，VBA引擎会将编译后的版本保存在相关模块流的PerformanceCache结构中，以提高其性能。但是，如果Office应用程序的版本和架构与用于编译原始VBA代码的内容相匹配，则Office应用程序将仅会访问PerformanceCache。版本和实现信息存储在_VBA_PROJECT和__SRP_#流中。如果版本不匹配，则会将压缩的源代码解压缩，然后编译并运行。

0x02 技术对比：VBA Purging与VBA Stomping

2018年，Walmart安全团队研究了一种称为VBA Stomping的技术，并将其推广到了大家的视线之中。这个技术最早是由Vesselin Bontchev博士在2016年发现，可以让攻击者在Office文档中删除压缩的VBA代码，同时仍然可以执行恶意宏。这样一来，反病毒软件引擎就无法再检测到特定的VBA关键字。有关在野外应用了VBA Stomping技术的恶意样本，可以参考“STOMP 2 Dis: Brilliance in the (Visual) Basics”。

VBA Stomping利用了模块流的解释原理，将恶意的CompressedSourceCode与非恶意的VBA源代码进行了交换，但仍然保持PerformanceCache不变。但是，这一攻击技术是否能够成功运用要取决于Office版本，所以攻击者通常还需要对目标进行额外的检查，获取受害者使用的Office版本。

而我们这里分析的VBA Purging则以相反的方式来修改模块流。VBA Purging技术无需更改CompressedSourceCode，而是从模块流和_VBA_PROJECT流中完全删除PerformanceCache数据，将MODULEOFFSET的值更改为0，并删除所有SRP流。删除SRP流是必要的，因为_VBA_PROJECT和SRP流中包含与版本相关的PerformanceCache数据，在模块流中不包含PerformanceCache数据的情况下，会导致运行时错误。许多反病毒引擎和YARA规则都依赖于检测PerformanceCache中是否包含特定的字符串，而将其删除后，攻击者便可以使用更多传统的方法，执行可疑的函数（例如CreateObject），而不会再被检测到。

下图展示了使用oledump提取的原始文档和使用VBA Purging技术的文档的OLE流。Module1 PerformanceCache在原始文档中是1291字节，而在使用了VBA Purging技术的文档中则为0字节。清除后的文档没有SRP流，并且_VBA_PROJECT流减少到7个字节。

使用oledump分析使用VBA Purging技术的文档：

0x03 测试VBA Purging技术的有效性

Mandiant红队开发了一个名为OfficePurge的C#命令行工具，用于测试该技术。OfficePurge支持使用CFBF文件格式的Microsoft Office Word、Excel和Publisher文档。在接下来的示例中，我们使用了OfficePurge和公共工具包Unicorm中的VBA Payload来测试VBA Purging技术的有效性。这里使用的是一个Microsoft Office Word文档，其中包含Base64编码后的PowerShell Payload。

使用Unicorn生成的宏Payload：

原始Word文档的字符串输出（下图）显示了Unicorn的Base64编码后的PowerShell Payload，有多个安全产品都检测到了该恶意Payload。而使用该技术后，由于删除了PerformanceCache，文档的输出中没有完全显示出Base64编码的Payload。但在CompressedSourceCode中，仍然包含Base64编码的Payload，不过Microsoft的自定义压缩算法会对字符串进行拆分，从而使静态分析的过程更难检测到特定字符串。

原始文档和使用该技术的文档的字符串输出：

我们将这两个文档都提交到了在线沙箱平台，以测试各种产品对其的检测能力。与原始文档（36/60）相比，在使用VBA Purging技术（12/61）后，VirusTotal的检测率下降了67%。与此同时，VirusTotal会将原始文档归类为“create-ole”、“doc”和“macros”，但对于使用该技术的文档却只能将其归类为“doc”。

原始Word文档的VirusTotal检测结果：

使用VBA Purging技术的Word文档的VirusTotal检测结果：

0x04 检测和侦查方式

使用OfficePurge，我们可以迅速清除已编译的VBA代码，并降低被安全产品检测到的概率，但我们还想进一步进行分析。站在防御的视角，我们可以利用之前的测试数据，以YARA规则的形式来构建条件判断检测逻辑，从而识别使用VBA Purging技术的文档，并发现此前未能检测到的恶意文档。在OfficePurge GitHub存储库的“sample-data”文件夹下，我们针对每个支持的文档类型生成了原始文档和使用该技术的文档，这些文档最终都会运行calc.exe。SHA256哈希值附在本文的末尾。

如前所述，这项技术涉及到从_VBA_PROJECT流中删除PerformanceCache数据。根据MSDN文档，_VBA_PROJECT流的最小长度为7字节，这样可以符合流的标头中的必填字段。我们建立了以下YARA规则，用7字节的_VBA_PROJECT流作为规则，检索CFBF文件：

rule FEYE_OLE_VBAPurged_1 {
    meta:
        author = "Alyssa Rahman (@ramen0x3f)"
        description = "This file has a _VBA_PROJECT stream that has been cleared. This is evidence of VBA purging, a technique where the p-code (PerformanceCache data) is removed from Office files that have an embedded macro."
    strings:
        $vba_proj = { 5F 00 56 00 42 00 41 00 5F 00 50 00 52 00 4F 00 4A 00 45 00 43 00 54 00 00 00 00 00 00 00 00 00 }
    condition:
        uint32(0) == 0xe011cfd0 and ( uint32(@vba_proj[1] + 0x78) == 0x07 )
}

使用上述规则可以在VirusTotal上搜索到大量恶意文件，这说明这样的恶意文件在野外已经非常普遍，被攻击者广泛使用。这个规则理论上可以检测出大多数公开记录的VBA Purging样本，例如9fd864e578d8bb985cf71a24089f5e2f（HornetSecurity）。但是，可能也会产生一些误报。正如Didier Stevens先前所指出的，某些公共库（例如：EPPlus）也可能会生成没有PerformanceCache数据的合法文档，但这样的文档恰恰匹配了VBA Purging技术检测规则的特征。

这个规则还有另一个问题，就是不一定要完全删除_VBA_PROJECT流数据。尽管在该技术所有公开记录的样本中，流的大小都是7，但不一定需要遵循这个大小。

为解决上述问题，一种方案是比较文档宏的压缩版本和编译版本，查找其中是否存在未预期的变化。另外一种方案，还是使用YARA规则，但需要在_VBA_PROJECT流中搜索特定关键字或字节，如果p-code有效，则应该能够找到这些关键字或字节。

我们先从简单的入手，在OfficePurge中寻找特殊情况。在代码中，有一部分是用静态标头覆盖_VBA_PROJECT流：

// Remove performance cache in _VBA_PROJECT stream. Replace the entire stream with _VBA_PROJECT header.
byte[] data = Utils.HexToByte("CC-61-FF-FF-00-00-00");

通过网上查询，发现这个标头是根据Microsoft的规范而构建的。但如果我们比较原始文档和使用该技术的文档，会发现这个标头实际上与规范存在差异。

原始文档和使用该技术的文档对比：

存在这个标头，不一定说明文件是恶意的，或者是由OfficePurge工具创建的，但可以很好地说明该文件是通过程序创建的，而非Office产品。对于这种特殊情况，我们可以构建以下的规则，该规则将搜索带有“较小的”_VBA_PROJECT和可疑流标头的文档：

rule FEYE_OLE_VBAPurged_2 {
    meta:
        author = "Michael Bailey (@mykill), Jonell Baltazar, Alyssa Rahman (@ramen0x3f), Joseph Reyes"
        description = "This file has a suspicious _VBA_PROJECT header and a small _VBA_PROJECT stream. This may be evidence of the VBA purging tool OfficePurge or a tool-generated document."
    strings:
        $vba_proj = { 5F 00 56 00 42 00 41 00 5F 00 50 00 52 00 4F 00 4A 00 45 00 43 00 54 00 00 00 00 00 00 00 00 00 }
        $cc61 = {CC 61 FF FF 00 00 00}
    condition:
        uint32(0) == 0xe011cfd0 and ( uint32(@vba_proj[1] + 0x78) >= 0x07 ) and ( uint32(@vba_proj[1] + 0x78) < 0xff ) and $cc61
}

通过上述两个规则进行搜索，可以发现使用了VBA Purging技术（或者是某种自动化生成文档）的多种威胁和恶意软件。在VirusTotal上，我们可以利用这个规则发现很多Emotet Payload，这个结果也非常合理，因为Emotet主要依赖于恶意电子邮件附件进行传播。此外我们观察到最多的恶意软件是AgentTesla。

由于这些规则都可能会检测到合法文档，因此还不适合在正式产品中使用这些，但是可以将它们作为一个“弱信号”，在人工威胁狩猎中使用。目前，很多静态引擎在识别VBA Purging技术时准确性都不是太高，但动态分析技术（例如FireEye的MVX引擎）往往可以正确检测出恶意文档，包括使用VBA Purging技术的情况。

0x05 总结

由于企业不可或缺的会日常使用Office文档，因此攻击者会持续尝试构建恶意文档，将恶意宏指令隐藏在文档之中。VBA Purging技术恰好证明了威胁行为者正在不断发掘新的方法来逃避防御和检测。这篇文章中所讨论的内容希望能作为VBA Purging技术检测的一个起点，希望我们分享的这些工具和指标可以帮助大家发现恶意Office文档。

0x06 威胁指标

文件名：test.doc

描述：包含Unicorn宏Payload的Word文档（原始）

SHA-256：f4431f02fe1e624fdb7bf2243bb72f1899d7eccb1ed7b2b42ed86e001e8bff28

文件名：test2.doc

描述：包含Unicorn宏Payload的Word文档（使用VBA Purging技术）

SHA-256：98bd119f928e8db4ed45f5426f2c35c5f6d6ccc38af029e7ab4b9cfcc1447c53

文件名：excel_calc.xls