在本文中，我们将为读者详细介绍用于审查 VBA 恶意代码的 AMSI 安全机制在设计方面存在的缺陷，以及攻击者是如何利用这些缺陷来绕过该防御机制的。请注意，本文中的示例代码只应作为概念验证，而不得用于其他用途。

关于 AMSI

在 Windows 10 中，微软引入了反恶意软件扫描接口（Antimalware scanning interface，AMSI），用于充当脚本解释器和反病毒引擎之间的交互接口。现在， AMSI 不仅支持 PowerShell 引擎、Windows 脚本宿主（wscript.exe 和 cscript.exe），并且，最近又提供了针对 Visual Basic for Applications（VBA）的支持。

简而言之，在这些解释器中执行命令时，运行时命令将发送至 AMSI 接口。如果防病毒（AV）软件 " 钩取 " 了该接口，则 AV 引擎将通过 AMSI 接收执行的运行时命令，然后决定是阻止还是允许其执行。通过利用发送运行时命令这一特性，AV 软件不仅能够 " 看到 " 在内存中运行的、经过去模糊处理的恶意代码，同时，还能实时阻止这些代码的恶意行为。

AMSI & VBA

在 2018 年 9 月，微软宣布实现了针对 VBA 的 AMSI 安全保护机制，并于 2019 年 1 月，在 MS Office 365 中提供该特性。所以，现在所有的 Office 365 用户都应该运行支持 AMSI 的 Office 版本。

这个实现的亮点在于（请注意 "logs" 和 "triggers" 之间的区别）：

· 针对 COM 方法和 Win32 API 的所有调用都将记录到 "Behaviour log" 中。

·某些具有高风险的调用已被标记为 "trigger"。 一旦发现它们，就停止宏执行，并将循环日志（circular log）的内容传递给 AMSI，供 AV 软件判断之用。

·根据测试情况来看，看起来像是基于 p 代码的攻击（其中 VBA 代码被检出）也会被 AMSI 引擎捕获（例如，使用我们的工具 EvilClippy 来操作文件的时候）。

·在默认配置中，并没有针对所有启用宏的文档启用 AMSI 引擎。默认情况下，"macro runtime scope" 被设置为 "enabled for low trust documents"。这意味着受信任的文档，即来自受信任位置的文档或受信任发布者签名的文档，在默认设置下是不会发送给 AMSI 引擎进行检测的。

第一种绕过方法：使用 Excel 4.0 宏指令

在 Excel 中，专门为 Excel 4.0 宏指令提供了一个宏引擎。这个引擎是在 Excel.exe 中实现的，而不是在 VBA 引擎 ( VBE7.dll ) 中实现的。由于 AMSI 引擎只与 VBA 挂钩，而对于基于 Excel 4.0 的攻击，则不闻不问。

第二种绕过方法：宏运行时范围 & 信任的滥用

在 AMSI 的作用范围方面，就默认的宏运行时范围设置来说，微软保留了几个法外之地，特别是 " 受信任文档 " 和 " 受信任位置 "。

不过，在作者的实验室环境中，所有 " 受信任文档 " 仍会交由 AMSI 进行安全审查。对于这种情况，我不知道由于 Microsofts 文档的描述有误，还是我自己某方面出错所致。

据官方文档称，对于来自可信位置的文档来说，在默认设置下是不会交由 AMSI 进行安全检测的。因此，我写了一个PoC宏代码，以利用这个特性。我的利用思路非常简单：

在文档打开时，通过 " 另存为 " 功能，将当前文档作为模板保存到受信任的位置。然后，通过该模板从受信任的位置打开一个新文件，这样就会触发 document_new 事件。

第三种绕过方法：利用无辜的 COM 函数

微软对于 " 无辜的 "COM 和 Win32 API 函数是区别对待的，对于后者，不仅会将其记录在相应的日志中，并且，它们还会带来许多可疑的 " 触发事件 "。因此，我们可以滥用不会惊动 AMSI 的 " 无辜的 "COM 函数，例如：

·实例化 Excel 并调用 executeExcel4macro 或 DDEInitialize。

·使用 WMI 和 "spawninstance" 绕过 ASR。

除此之外，可能还有很多其他的利用方法。经实验发现，如果函数名称包含诸如 "shell" 或 "execute" 之类的单词，很容易 " 惊动 "AMSI。

第四种绕过方法：利用具有 " 副作用 " 的非 Win32API/COM 函数

除了 Win32 API 和 COM 函数之外，其实 Word 和 Excel 中内置的各种函数，也可能会导致代码执行或禁用 AMSI。

众所周知，我们可以使用宏来编辑 Word 文件的内容，并将其另存为名为诸如 "disableamsi.reg" 和 "disableamsi.bat" 之类的文本文件。之后，如果我们在启动时保存该 bat 文件，并让该 .bat 文件通过 .reg 文件调用 regedit 的话，我们就可以通过 HKCU macroruntimescope 设置来禁用 AMSI 了（大多数公司不会配置 macroruntimescope GPO ，因此，我们可以非常安全地覆盖 HKCU 设置，根本无需担心 GPO 所带来的障碍）。 同时，利用这个批处理文件，还可以在不显示 splashscreen的情况下运行 Word 软件，从而悄悄地加载恶意 VBA 文件。

到目前为止最龌龊的方法：使用 Excel 的 "sendkeys" 函数发送键组合 CTRL+Esc。这样的话，就能打开受害者系统上的开始菜单，然后借助正确计时，就能运行任意命令（启动 calc 或 PowerShell 脚本）。

在我们的Github上，提供了这两种攻击方式的 POC 代码。

小结

微软为 VBA 引擎设计的 AMSI 机制，与用于脚本和 PowerShell 引擎的 AMSI 存在巨大的差异（或者应该说，前者的安全性能更差）。在本文中，我们为读者介绍了几种绕过针对 VBA 设计的 AMSI，由于它们利用的是 AMSI 固有的设计缺陷，因此，防御起来非常困难。

不过，我们可以通过采取以下措施，来稍微提高 AMSI 的安全性：

将 AMSIRuntimeScope 设置为扫描所有文档，而不是仅扫描不受信任的文档。 请注意，该设置可通过 GPO 进行控制。

通过 GPO 管理 " 受信任的位置 "：最好不要存在允许普通用户具有写权限的受信任位置。

我们最终的安全建议是，尽可能地禁止最终用户使用宏指令；对于确实需要使用宏指令的用户，让他们使用已签名的宏指令。千万不要天真地认为只要启用了针对 VBA 的 AMSI 就能将所有恶意宏代码拒之门外，这种想法是大错特错的。