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

阅读量    59131 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

这篇文章介绍了一种又快又猥琐的方法,可以在Windows Scripting Host 中禁用AMSI,而不需要管理员权限或者修改注册表密钥/系统状态(比如Defender之类AV都会监控这些修改)。我在最新的Windows10 1803型号上做了测试,仅供参考。

注:AMSI是微软的反恶意软件扫描接口。

我注意到DotNetToJScript 的默认脚本文件不能工作了,因为Windows Defender会阻止它,感谢所有将我的工具标记成恶意软件的朋友。

如果你仔细查看屏幕截图你会发现图中显示“Affected items:”是以amsi为前缀的。这表明检测不是基于文件而是基于 Antimalware Scan Interface的行为。当然你可以通过重新编写脚本来解决这个问题(它以一种很奇怪的方式在scriptlet中工作),但我永远都不会这样做。因为我从来没有为了使用“Sharpshooter“而编写它。我之前有一个绕过AMSI的想法,现在正好可以测试一下。

在看到MDsec最近关于PowerShellAMSIbypass方法以及Tal LibermanBlackHat 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很蠢的方法,但它只是表明,恶意软件很容易在对检测平台进行修改时,这种自检功能很少能工作的很好。

审核人:yiwang   编辑:边边

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多