欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

用一个简单的trick在Jscript中禁用AMSI

来源:本站整理 作者:佚名 时间:2018-07-22 TAG: 我要投稿

这篇文章介绍了一种又快又猥琐的方法,可以在Windows Scripting Host 中禁用AMSI,而不需要管理员权限或者修改注册表密钥/系统状态(比如Defender之类AV都会监控这些修改)。我在最新的Windows10 1803型号上做了测试,仅供参考。
注:AMSI是微软的反恶意软件扫描接口。
我注意到DotNetToJScript 的默认脚本文件不能工作了,因为Windows Defender会阻止它,感谢所有将我的工具标记成恶意软件的朋友。

如果你仔细查看屏幕截图你会发现图中显示“Affected items:”是以amsi为前缀的。这表明检测不是基于文件而是基于 Antimalware Scan Interface的行为。当然你可以通过重新编写脚本来解决这个问题(它以一种很奇怪的方式在scriptlet中工作),但我永远都不会这样做。因为我从来没有为了使用“Sharpshooter“而编写它。我之前有一个绕过AMSI的想法,现在正好可以测试一下。
在看到MDsec最近关于PowerShell中AMSI的新bypass方法以及Tal Liberman在BlackHat Asis的演讲后,我受到了一些启发,准备再次挖掘下这种技术。但是我没在其它地方看到关于这种技术的描述,但是我还是决定写出来,因为如果我错了肯定会有人能纠正我的错误。
 
Windows脚本宿主如何加载AMSI
AMSI是作为COM服务器被实现的,用于通过内部通道与已经安装的安全产品进行通信。先前对AMSI的攻击是Matt Nelson通过劫持COM注册表完成的。脚本主机不支持直接调用COM对象,而是通过AMSI.DLL中导出的方法调用,我们可以通过在Process Monitor中设置适当的过滤器来观察被加载的情况。

我们可以使用Process Monitor的堆栈跟踪功能来查找负责加载的AMSI.DLL的代码。它实际上是脚本引擎的一部分,例如Jscript或者VBScript,而不是WSH的核心部分。代码的基础知识如下:
HRESULT COleScript::Initialize() {
  hAmsiModule = LoadLibraryExW(L"amsi.dll",
      nullptr, LOAD_LIBRARY_SEARCH_SYSTEM32);
  if (hAmsiModule) { ①
    // Get initialization functions.
    FARPROC pAmsiInit = GetProcAddress(hAmsiModule, "AmsiInitialize");
    pAmsiScanString = GetProcAddress(hAmsiModule, "AmsiScanString");
    if (pAmsiInit){
      if (pAmsiScanString && FAILED(pAmsiInit(&hAmsiContext))) ②
        hAmsiContext = nullptr;
    }
  }
  bInit = TRUE; ③
  return bInit;
}
基于这段代码我们能看到它在加载了AMSI DLL①后调用了AmsiInitialize ②方法来获取上下文句柄。这段代码的有趣之处是无论AMSI是否初始化它都会返回成功③。有三种情况会导致这段代码失败从而永远不会初始化AMSI,阻止加载AMSI.DLL,使AMSI.DLL不包含诸如AmsiInitialize之类的方法,或让AmsiInitializeto失败。
Tal Liberman在他的PPT第56页中提到你可以使用应用程序将AMSI复制到另一个目录,它将尝试从该目录加载AMSI.DLL。由于这个AMSI可能是一些不相关的DLL,它们不能导出AmsiInitialize ,那么加载将成功,其实是失败的。然而这个方法在有标志LOAD_LIBRARY_SEARCH_SYSTEM32时候不会生效,这意味着LoadLibraryEx 始终尝试首先从SYSTEM32 加载。AmsiInitialize 的失败显然是一个问题,但是我们很难阻止这个代码从 SYSTEM32 加载AMSI.DLL,那我们怎么办呢?我们当然可以预加载另一个AMSI.DLL。
 
劫持AMSI.DLL
我们如何以最少的代价加载替换AMSI.DLL?可能不是所有人都意识到LoadLibrary将在已加载DLL中查找所有请求加载DLL的名字,以便不会加载相同的DLL两次。这不仅适用于DLL的名称,还适用于主可执行文件。因此,如果我们能够让库加载器相信我们的主可执行文件就是叫做AMSI.DLL,那么加载器将返回它的上下文句柄。无法找到导出的AmsiInitialize会导致AMSI无法初始化但会继续执行而不是检查它。
如何在不修改进程内存的情况下将主可执行文件的名称更改为?很简单,我们将WSCRIPT.EXE复制到另一个目录,但是将其命名为AMSI.DLL然后运行它。我们如何运行AMSI.DLL,它不是需要SOMETHING.EXE吗?
在windows上有两种主要的进程执行方法,ShellExecute或者CreateProcess。调用ShellExecute时候,API会查找扩展的处理程序,比如.EXE或者.DLL,并根据结果执行特定操作。通常.EXE将重定向到只调用CreateProcess,其中.DLL会尝试将其加载到已注册的视图中,在默认的系统上则不会。
但是,CreateProcess不关心文件具有什么扩展名,只要它是基于其PE头的可执行文件即可。(实际上你可以使用native API调用DLL,但是我们无权在WSH访问)。因此,只要我们能够调用CreateProcess创建AMSI.DLL(WSCRIPT.EXE的副本),就会执行。要做到这一点,我们可以使用WScript.Shell的Execmethod直接调用CreateProcess。
var obj = new ActiveXObject("WScript.Shell");
obj.Exec("amsi.dll dotnettojscript.js");
这样一个名为AMSI.DLL的进程就运行了。当Jscript或者VBScript尝试加载AMSI.DLL时,它将获得主可执行文件的句柄,AMSI不再工作。据我所知,这个简短的script并没有被AMSI本身检测到,所以运行你想运行的“真正的”代码是安全的。

总结一下这个攻击:
1.  启动存根脚本,将WSCRIPT.EXE复制到已知的位置,并且命名为AMSI.DLL。这是位于不同位置的同一目录签名可执行文件,因此可能绕过纯粹基于签名的检测。
2.  在存根脚本中使用“真实”脚本执行新创建的AMSI.DLL
3.   额,就这么多了。
AFAIK不适用于PowerShell,因为它似乎破坏了代码中的一些重要东西,这使得PS无法运行。我不知道这是不是设计好的。不过,我知道这是一种绕过AMSI很蠢的方法,但它只是表明,恶意软件很容易在对检测平台进行修改时,这种自检功能很少能工作的很好。
 

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载