如何绕过AMSI for VBA

在本文中，我们将为读者详细介绍用于审查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就能将所有恶意宏代码拒之门外，这种想法是大错特错的。