基于脚本的攻击或可绕过微软的反恶意软件扫描接口（AMSI）
写在前面的话
16年文章，原始出处：https://blog.csdn.net/SAKAISON/article/details/52637903
上个月，我在2016美国Black Hat黑客大会上讨论了一些关于微软反恶意软件扫描接口（AMSI）的内容。那场演讲和这篇文章中的内容是我对AMSI的一些个人见解，感兴趣的同学可以关注一下。
在Windows 10中，微软公司引入了反恶意软件扫描接口（AMSI），这个接口可以用来扫描基于脚本的入侵攻击和恶意软件。对于企业安全而言，基于脚本的入侵攻击往往是致命的，而且随着PowerShell的开源和添加了跨平台的支持，这类攻击将会变得越来越常见。
AMSI针对的是那些采用PowerShell、VBScript、以及JScript等语言开发出来的恶意脚本，它可以大大提升恶意脚本的检测准确率，并帮助用户有效地屏蔽这类恶意脚本。在脚本宿主准备运行某一段脚本代码之前，AMSI便会介入并尝试扫描出代码中潜在的恶意内容。而AMSI之所以如此高效的原因就在于，无论代码是否经过了模糊处理，无论代码被混淆到了什么样的程度，当脚本需要在脚本宿主中运行时，它都必须是以清晰的、未经过混淆处理的明文代码形式呈现给脚本宿主的。除此之外，由于代码在真正得到执行之前就被提交给了AMSI，所以代码的来源就并不重要了，代码可以来自于磁盘文件、系统内存或者来自于交互式输入，这些都不会对AMSI的效率产生影响。ASMI是一个开放的接口，而微软公司也曾公开表示，任何应用程序都可以调用这个API接口。在Windows 10中，Windows Defender就使用了这个接口。
但是，微软真的已经彻底击垮了基于脚本的攻击了吗？攻击者还有没有什么其他的办法呢？俗话说得好：道高一尺，魔高一丈。请大家继续往下看。
我与AMSI的那些事
我当时在实验室的Windows 10电脑上正在测试Nishang工具中的一些PowerShell脚本，那也是我第一次知道有反恶意软件扫描接口（AMSI）这个东西。
Nishang是一个基于PowerShell的渗透测试专用工具。它集成了框架、脚本和各种payload。这些脚本是由Nishang的作者在真实渗透测试过程中有感而发而编写的，非常具有实战价值。其中包括了下载、执行、记录键盘数据、dns、延时命令等脚本。
我当时发现，某些脚本似乎无法正常工作了，即使是那些从内存中加载的脚本也是一样，这就非常有意思了。由于我在长期的渗透测试工作中都会不可避免地使用PowerShell，所以我也可以算得上是半个PowerShell的“资深玩家”了。没错，让我感到有意思的正是那项可以在内存中检测Nishang脚本的技术。在进行了一番搜索之后，我偶然间看到了一篇写得非常好的文章［传送门］，这篇文章详细介绍了AMSI的各种特性和运行机制，感兴趣的同学可以阅读一下。简单来说，AMSI主要有以下几点特性：
－内存和数据流扫描。这也就意味着，对于ASMI而言，信息输入方式的区别并不会对ASMI的正常运行造成影响。这些信息输入方式包括磁盘文件、内存／数据流、以及手动输入等等。
－当经过反混淆处理的脚本代码提交至脚本宿主之后，AMSI接口便会将脚本源码提供给反病毒或反恶意软件产品。这也就意味着，对代码进行混淆处理其实并不会有太大的作用。
－当恶意脚本被提交给脚本宿主时，脚本代码是经过封装的。所以代码并不会使用powershell.exe来运行，而使用的是System.Automation DLL。
在我使用了各种不同的工具和技术来对AMSI进行测试之后，我发现AMSI的检测准确率还是非常高的，已经超过了我的预期值。
AMSI可以检测到的技术有哪些？
从内存中执行脚本 - 使用powershell.exe所提供的“-EncodedCommand”参数和我们所熟知的一行代码实现的“下载-执行（Download／Execute）”功能
当AMSI被禁用后，运行渗透测试人员最爱使用的Invoke-Mimikatz脚本时的截图：
|
1
|
PS C:\> Set-MpPreference -DisableIOAVProtection $
true
|
当AMSI被启用后（Windows 10默认开启），运行Invoke-Mimikatz脚本时的截图：
在不使用powershell.exe的情况下运行脚本－使用单独的runspace（p0wnedshell，psattack）和System.Automation.Dll（nps，Powerpick）。
非普通的脚本存储空间－从WMI命名空间、注册表键和事件记录日志中加载脚本。
应用白名单绕过方式－InstallUtil,，regsrv32和rundll32。
上述的这些技术均可以被AMSI检测到。由于AMSI可以处于脚本宿主的层面上运行，所以能够得到这样的检测效果也就不足为奇了。话虽如此，但这还是非常恐怖的。再加上现在Windows 10系统中的Windows Defender默认支持AMSI，所以情况各位可想而知。
但是逃避问题并不是我的一贯作风，所以我决定来看一看到底有没有什么方法可以绕过AMSI的检测。事实证明，我们还是有很多技术可以绕过AMSI的。
如何绕过AMSI？
强制使用PowerShell v2：在我撰写这篇文章的时候，PowerShell v2还不支持AMSI。如果.Net 3.0安装在目标Windows 10机器上的话（默认不安装），我们可以通过“-Version”选项来开启PowerShell v2
混淆处理
另外一种非常有趣的绕过方法就是更改PowerShell脚本的签名，这样反病毒软件就不会将AMSI提供过来的脚本检测为恶意脚本了。我尝试修改了Nishang中的一个脚本－Gupt-Backdoor，这个脚本之前曾被AMSI检测为恶意脚本。
我已经将代码中的帮助信息移除了，并且我用随机字符串替换掉了脚本代码中所有的函数名和变量名。
运行结果如下：
很明显，Windows Defender会寻找特定的函数名和变量名，而这也并没有什么稀奇的。
手动混淆那些包含了大量代码的脚本是非常困难的，尤其是像Invoke-Mimikatz这样的脚本，几乎不太可能手动完成代码混淆。但幸运的是，ISE-Steroids模块将会帮上我们的大忙。接下来，我准备对Nishang中的Invoke-Mimikatz脚本进行混淆处理。
现在，当我们加载了经过混淆处理后的脚本之后，该脚本就没有被检测到了。
这真是太棒了！但是请注意，一定要确保脚本中的函数调用活动发生在代码混淆之前。
这真的非常有趣，正如我在文章开头所描述的那样，如果脚本代码经过了混淆处理，甚至脚本中使用了base64编码，AMSI还是有其他的方法来检测的。但是上面这种混淆处理方式竟然可以绕过AMSI的检测，这确实让我有些摸不着头脑。而且我个人感觉我们还可以在Windows Defender和脚本签名上做文章，如果有哪位同学对这一话题有自己的观点或者看法的话，欢迎你与我联系。
卸载AMSI
Set-MpPreference
这个内置的cmdlet可以通过禁用Windows Defender的安全保护功能来屏蔽掉AMSI。
我们可以通过下面这段命令来禁用Windows Defender的实时检测功能：
|
1
|
PS C:\> Set-MpPreference -DisableRealtimeMonitoring $
true
|
但是在使用这个方法之前，有几件事情是你需要了解的：
1. 系统会向用户弹出提示通知；
2. 必须以高级权限运行这个shell命令；
3. Event ID 5001－Windows Defender实时保护功能被禁用。
我们还可以使用下面这个命令来屏蔽系统的检测：
|
1
|
PS C:\> Set-MpPreference -DisableIOAVProtection $
true
|
DLL劫持－p0wnedshell所使用的方法
Cornelis de Plaa (@Cneelis)发现了这个非常赞的方法，并且将其添加进了p0wnedshell之中。这是一种DLL劫持技术，当系统在加载p0wnedshell runspace时，脚本会在当前的工作目录下注入一个amsi.dll文件。这个dll文件是由runspace加载的，它可以卸载AMSI。这样一来，p0wnedshell就可以成功绕过AMSI了。如果各位同学对这项技术感兴趣的话，可以阅读一下这篇文章［传送门］。
Reflection（反射）－Matt Graeber设计的方法
这个方法并不要求我们使用高级权限来运行shell命令，而且也不会给用户显示提示通知。我很喜欢这个方法，因为它可以配合PowerShell脚本中的执行函数一起运行。比如说，我们可以用Nishang的Out-Word脚本来生成一个包含恶意代码的Word文档，并且让它在目标主机中下载并执行一个PowerShell meterpreter。
PS C:\test> Out-Word -Payload 'powershell.exe -ExecutionPolicy Bypass -noprofile
只要目标用户打开了Word文件，并且点击了“启用内容”，那么就会发生如下图所示的事情：
这样我们就在客户端攻击中实现了AMSI绕过。
总结
AMSI其实并不是什么所谓的安全“银弹”，虽然很多公司和企业长久以来一直都在寻找一种完美的安全解决方案，但是这样的方案明显是不存在的。但是从某种程度上来说，AMSI的确提升了Windows操作系统的整体安全性。
本文由 安全客 翻译，转载请注明“转自安全客”，并附上链接。
