原文地址：https://www.ired.team/offensive-security/defense-evasion/bypassing-cylance-and-other-avs-edrs-by-unhooking-windows-apis

概述

如果您尝试从运行CylancePROTECT的机器上转储lsass.exe进程内存的话，您就会发现，这是一件非常困难的事情。

在本实验中，我们将为读者演示如何顺利转储进程的内存并绕过Cylance（或任何其他防病毒/端点检测和响应解决方案），后者使用用户态API hooking来确定程序在执行过程中是否有恶意行为。

实际上，Hooking是一种古老的技术，我之前早有耳闻，但从来没有机会用过，直到我偶然发现Hoang Bui的一篇文章——该文章介绍了EDR的unhooking处理，具体地址为https://medium.com/@fsx30/bypass-edrs-memory-protection-introduction-to-hooking-2efb21acffd6。

虽然本实验演示的API Unhooking技术是在MiniDumpWriteDump API上下文中进行的，但是该技术同样适用于其他任何已hooked的API。

什么是hooking？

实际上，我们可以将API hooking与网络代理进行类比：您的应用程序进行的所有API调用（包括其参数），例如CreateFile、ReadFile、OpenProcess等均会被AV/EDR拦截并进行相应的检查，然后由AV/EDR裁定程序的操作/意图是否是恶意的。

如何进行hooking？

对于EDR厂商来说，他们对用户态API的hook方法是：劫持/修改Windows DLL（如kernel32/kernelbase和ntdll）中的函数定义（API）。

一般来说，函数定义是通过在其开头插入一个jmp指令来进行修改的。这些jmp指令将改变程序的执行流程——程序将被重定向到EDR的检查模块，该模块将判断程序是否表现出任何可疑的行为，具体来说，它们是通过分析传递给EDR正在hooking/监视的函数的参数来进行评估的。这种重定向有时被称为绕行/蹦床。

希望下面的图表有助于进一步阐明这一个过程：

值得注意的是，并非所有的函数都会被AV/EDR劫持。通常只有那些在已知恶意软件中被经常滥用的函数才会被hooked，这些函数包括CreareRemoteThread、NtQueueApcThread等。

实验过程

先让Cylance逮个正着

请注意，这个实验实际上是建立在另一个实验的基础之上的。在那个实验中，我编写了一个小型的C++程序，使用MiniDumpWriteDump Windows API转储lsass.exe进程内存，详情请访问https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dumping-lsass-passwords-without-mimikatz-minidumpwritedump-av-signature-bypass。

现在，让我们尝试在一个被CylancePROTECT监控的系统上运行这段代码（在上面的实验中编写的程序）。这时，该程序会因违规而被终止，相关消息为LsassReadstraight away：

正如您猜到的那样，Cylance hook了MiniDumpWriteDump的API调用。更准确地说，它实际上是hook了一个NtReadVirtualMemory函数，该函数来自ntdll.dll，而它是由MiniDumpWriteDump函数在幕后进行调用的。

确认Hook

用调试器执行该程序，我们可以观察到，在进程开始运行时，Cylance的内存保护模块，即CyMemDef64.dll被注入到了Invok-CreateMemoryDump.exe（我们的程序，它会调用MiniDumpWriteDump函数）进程中。这个模块将对Invok-CreateMemoryDump.exe中的API调用进行相应的检查。

既然我们知道MiniDumpWriteDump调用了NtReadVirtualMemory，那么不妨检查一下NtReadVirtualMemory的函数定义，看看是否有可疑之处。

@WinDBG
u NtReadVirtualMemory

我们立即看到，该函数的第一条指令是指向某个奇怪内存地址的JMP指令，该地址超出了ntdll模块的内存地址范围：

下面，让我们反汇编一下该地址：

 
@WinDBG
u 0000000047980084

我们可以立即注意到，还有多个指向Cylance内存保护模块CyMemDef64.dll的jmp指令——这证实了函数NtReadVirtualMemory已被hooked：

为了确认我们的程序最终将调用NtReadVirtualMemory，我们可以在其上放置一个断点并继续执行程序。如以下屏幕截图所示，这里命中了该断点：

如果我们继续执行程序，它将被重定向（jmp指令）到Cylance的内存保护模块，并且该程序将随着Violation：LsassRead消息的到来而崩溃。

Unhooking处理

为了进行unhook，换句话说，将被hooked的函数还原到其初始状态，我们需要知道它在被Cylance修改之前是什么样子的。

通过检查函数NtReadVirtualMemory的前5个字节，可以很容易做到这一点；在加载到内存之前，该函数位于c:\windows\system32\ntdll.dll库中。我们可以在ntdll的DLL导出表中看到该函数的相对虚拟地址（RVA）——在我们的实验中，该地址为00069C70（在您的系统上，该地址可能会有所不同）：

如果将RVA转换为物理文件位置（由于文件尚未加载到内存中，因此与RVA相同），我们可以看到该函数的前5个字节为4c 8b d1 b8 c3：

上面的意思是，如果我们将Cylance注入的NtReadVirtualMemory函数的前5个字节（e9 0f 64 f8 cf）替换为4c 8b d1 b8 3c，那么，Cylance将会“失明”，从而无法监视MiniDumpWriteDump API调用。

有了这些信息，我们可以更新程序，并让它找到函数NtReadVirtualMemory的地址，并通过将字节4c 8b d1 b8 3c写入该函数的开头部分来实现unhook，具体如下面的第17行代码所示：

重新编译并再次运行该程序将成功转储lsass.exe进程内存，而不会受到Cylance的干扰：

我们现在可以令转储文件offline并将其加载到mimikatz中……。

在这里，我们只对一个函数进行了unhook处理；对于其他函数，通过比较磁盘上的DLL文件中的函数定义和内存中的函数定义，如果跟内存中的函数定义不同，则意味着它被“钩住”了，这时，我们可以用磁盘上的定义中找到的指令进行覆盖即可。

参考资料

下面是很好的参考资料，其中包括Cylance对unhooking技术的描述：

（请在此处插入演示视频）

本文作者：mssp299

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/150747.html