如何绕过AMSI for VBA

fanyeee 技术 2019年4月29日发布
Favorite收藏

导语:在本文中,我们将为读者详细介绍攻击者是如何绕过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版本。

1.png

这个实现的亮点在于(请注意“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就能将所有恶意宏代码拒之门外,这种想法是大错特错的。

本文翻译自:https://outflank.nl/blog/2019/04/17/bypassing-amsi-for-vba/#more-565如若转载,请注明原文地址: https://www.4hou.com/technology/17638.html
点赞 0
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论