九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

admin

102855
文章

87
评论

2023年5月11日01:21:16评论26 views字数 6976阅读23分15秒阅读模式

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

写在前边

1.本文原文为K A, Monnappa. 2018年发表的《Learning Malware Analysis》的章节选段，本文均为译者对相关内容的翻译及实践记录，仅供各位学术交流使用。另出于易读性考虑，对部分字句有所删改。

2.如各位需要引用，请做原文引用，格式如下所示：

[序号]K A, Monnappa. LearningMalware Analysis[M]. 2018.06. Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.

3.因文章整体内容较长，完整内容将会在本公众号拆分为多篇内容分别发出。本文为该系列的第八篇。

往期内容请参见合集《Learning Malware Analysis》

9. 内核回调函数和计时器

Windows操作系统允许一个驱动程序注册一个回调例程，当一个特定的事件发生时，这个回调例程将被调用。例如,如果一个rootkit驱动希望监控的执行和终止所有进程上运行系统,它可以注册回调例程的过程事件通过调用内核函数

PsSetCreateProcessNotifyRoutine PsSetCreateProcessNotifyRoutineEx

或PsSetCreateProcessNotifyRoutineEx2。当进程事件发生(启动或退出)时，rootkit的回调例程将被调用，然后可以采取必要的操作，例如阻止进程启动。

以同样的方式，rootkit驱动程序可以注册一个回调例程来接收通知，当映像(EXE或DLL)加载到内存时，当文件和注册表操作执行时，或当系统即将关闭时。换句话说，回调功能使rootkit驱动程序能够监视系统活动，并根据活动采取必要的操作。

在以下链接中，我们可以获得一些文档化和无文档化的内核函数列表，rootkit可能会使用这些函数来注册回调例程:

https://www.codemachine.com/article_kernel_callback_functions.html

*左右滑动查看更多

内核函数在Windows驱动程序工具包(WDK)中的不同头文件(ntddk.h、Wdm.h等)中定义。获取文档中内核函数的详细信息的最快方法是进行快速谷歌搜索，这应该会将我们带到WDK在线文档中的适当链接。

回调的工作方式是一个特定的驱动程序创建一个回调对象，该对象是一个包含函数指针列表的结构。创建的回调对象会被通告，以便其他驱动程序使用它。然后，其他驱动程序可以向创建回调对象的驱动程序注册它们的回调例程。

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/callback-objects

*左右滑动查看更多

创建回调的驱动程序可以与注册回调的内核驱动程序相同，也可以不同。要查看系统范围内的回调例程，可以使用回调volatile插件。在一个干净的Windows系统上，我们通常会看到各种驱动程序安装了许多回调，这意味着回调输出中的所有条目不是恶意的;需要进一步分析才能从可疑内存映像中识别恶意驱动程序。

在下面的例子中，Mader rootkit执行了SSDT挂钩，还安装了一个进程创建回调例程来监视系统上运行的所有进程的执行或终止。特别是，当进程事件发生时，恶意模块核心内地址为0xf66eb050的回调例程系统调用。

Module列指定了回调函数在其中实现的内核模块的名称。Details列给出安装回调的内核对象的名称或描述。识别出恶意驱动程序后，可以进一步调查它，或者将其转储到磁盘进行进一步分析(反汇编、反病毒扫描、字符串提取，等等)，如这里的moddump命令所示:

$ python vol.py -f mader.vmem --profile=WinXPSP3x86 callbacksVolatility Foundation Volatility Framework 2.6Type Callback Module Details --------------------------- ---------- ---------- ------- IoRegisterShutdownNotification 0xf9630c6a VIDEOPRT.SYS DriverVgaSave IoRegisterShutdownNotification 0xf9630c6a VIDEOPRT.SYS Drivervmx_svga IoRegisterShutdownNotification 0xf9630c6a VIDEOPRT.SYS Drivermnmdd IoRegisterShutdownNotification 0x805f5d66 ntoskrnl.exe DriverWMIxWDM IoRegisterFsRegistrationChange  0xf97c0876  sr.sysGenericKernelCallback 0xf66eb050 core.sys PsSetCreateProcessNotifyRoutine 0xf66eb050 core.sys KeBugCheckCallbackListHead 0xf96e85ef NDIS.sys [REMOVED]---Ndis miniport$ python vol.py -f mader.vmem --profile=WinXPSP3x86 modules | grep -i core Volatility Foundation Volatility Framework 2.60x81772bf8 core.sys 0xf66e9000 0x12000 system32driverscore.sys$ python vol.py -f mader.vmem --profile=WinXPSP3x86 moddump -b 0xf66e9000 - D dump/Volatility Foundation Volatility Framework 2.6Module Base-----------0x0f66e9000 Module Name      Result----------------- ------ core.sys         OK: driver.f66e9000.sys

*左右滑动查看更多

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

在下面的例子中，TDL3 rootkit安装进程回调和镜像加载回调通知。这允许rootkit监控进程事件，并在可执行映像(EXE、DLL或内核模块)映射到内存时获得通知。条目中的模块名称设置为UNKNOWN。这告诉我们，回调例程存在于一个未知模块中，如果rootkit驱动程序试图通过解除KLDR_DATA_TABLE_ENTRY结构的链接来隐藏，或者如果一个rootkit正在运行一个孤儿线程(一个隐藏或从内核模块分离的线程)，就会发生这种情况。

在这种情况下，UNKNOWN条目让我们很容易发现可疑条目:

$ python vol.py -f tdl3.vmem --profile=WinXPSP3x86 callbacks Volatility Foundation Volatility Framework 2.6Type Callback Module Details ------------------------ ---------- -------- ------- [REMOVED]   IoRegisterShutdownNotification  0x805cdef4  ntoskrnl.exe  FileSystemRAW   IoRegisterShutdownNotification  0xba8b873a  MountMgr.sys  DriverMountMgr GenericKernelCallback           0xb878f108  UNKNOWNIoRegisterFsRegistrationChange  0xba6e34b8  fltMgr.sysGenericKernelCallback 0xb878e8e9 UNKNOWN PsSetLoadImageNotifyRoutine 0xb878f108 UNKNOWN PsSetCreateProcessNotifyRoutine 0xb878e8e9 UNKNOWN KeBugCheckCallbackListHead 0xba5f45ef NDIS.sys [REMOVED]--- - -Ndis miniport

*左右滑动查看更多

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

即使模块名是UNKNOWN，根据回调例程地址，我们可以推断恶意模块应该位于地址为0xb878的内存区域的某个地方。从模块插件的输出中，我们可以看到模块本身已经解除了链接，但是modscan插件能够检测到加载在0xb878c000且大小为0x11000的内核模块。

显然，所有回调例程地址都在这个模块的范围内。现在已经知道了内核模块的base地址，我们可以使用moddump插件来转储它，以便进一步分析:

$ python vol.py -f tdl3.vmem --profile=WinXPSP3x86 modules | grep -i 0xb878 Volatility Foundation Volatility Framework 2.6$ python vol.py -f tdl3.vmem --profile=WinXPSP3x86 modscan | grep -i 0xb878 Volatility Foundation Volatility Framework 2.60x9773c98 TDSSserv.sys 0xb878c000 0x11000 system32driversTDSSserv.sys

*左右滑动查看更多

像回调一样，rootkit驱动程序可以创建一个计时器，并在指定的时间经过时得到通知。rootkit驱动程序可以使用此功能来定期执行操作。它的工作方式是，rootkit创建一个计时器，并提供一个名为DPC(延迟过程调用)的回调例程，它将在计时器过期时被调用。当回调例程被调用时，rootkit可以执行恶意操作。换句话说，计时器是rootkit执行恶意代码的另一种方式。

关于内核计时器如何工作的详细信息，可参考以下Microsoft文档:

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/timer-objects-and-dpcs

*左右滑动查看更多

要列出内核计时器，可以使用timersVolatility插件。需要注意的一点是，计时器本身并不是恶意的;这是Windows的功能，所以在一个干净的系统上，你、我们会看到一些合法的驱动程序安装了计时器。与回调函数一样，可能需要进一步分析来识别恶意模块。由于大多数rootkit试图隐藏它们的驱动程序，因此，会创建明显的工件，可以帮助我们快速识别恶意模块。

在下面的例子中，ZeroAccess rootkit安装了一个6000毫秒的计时器。当这段时间过去时，将调用UNKNOWN模块中地址0x814f9db0的例程。Module列中的UNKNOWN告诉我们模块可能是隐藏的，但是例程地址指向恶意代码存在的内存范围:

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 timers

*左右滑动查看更多

除了计时器，ZeroAccess还安装回调来监视注册表操作。同样，回调例程地址指向相同的内存范围(从0x814f开始):

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 callbacks

*左右滑动查看更多

尝试使用modules, modscan，和driverscan插件来查找UNKNOWN模块不会返回任何结果:

$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 modules | grep -i 0x814f$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 modscan | grep -i 0x814f$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 driverscan | grep -i 0x814f

*左右滑动查看更多

检查驱动器列表发现了可疑的条目，其中基址和大小被归零(这是不正常的，可能是一个绕过的伎俩)。将基址归零解释了为什么模块、modscan和驱动程序不返回任何结果。输出还显示恶意驱动程序的名称仅由数字组成，这增加了怀疑:

$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 driverscan

*左右滑动查看更多

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

通过清空基地地址，rootkit使得司法分析人员很难确定内核模块的起始地址，这也阻止了我们转储恶意模块。我们仍然知道恶意代码的所在位置(以0x814f开头的地址)。一个引人注目的问题是，我们如何使用这些信息来确定基址?一种方法是取其中一个地址并减去一定数量的字节(反向)，直到找到MZ签名，但这种方法的问题是不容易确定要减去多少字节。

最快的方法是使用yarascan插件，这个插件允许你在内存中扫描一个模式(字符串，十六进制字节，或正则表达式)。因为我们试图找到位于内核内存中以地址0x814f开始的模块，所以我们可以使用带有-K的yarascan(它只扫描内核内存)来寻找MZ签名。

从输出中，可以看到地址为0x814f1b80的可执行文件。您可以将此指定为使用moddump插件将恶意模块转储到磁盘的基本地址。转储模块的大小大约为53.2 KB，即十六进制的0xd000字节。换句话说，模块从地址0x814f1b80开始，到地址0x814feb80结束。所有回调地址都在这个模块的地址范围内:

九维团队-青队（处置）| 使用内存取证检测高级恶意软件（八）

$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 yarascan -K -Y "MZ" | grep -i 0x814fVolatility Foundation Volatility Framework 2.60x814f1b80 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ.............. 0x814f1b90 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@....... 0x814f1ba0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x814f1bb0 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 ................ 0x814f1bc0 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........!..L.!Th 0x814f1bd0 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is.program.canno 0x814f1be0 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t.be.run.in.DOS. 0x814f1bf0 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode....$.......$ python vol.py -f zaccess1.vmem --profile=WinXPSP3x86 moddump -b 0x814f1b80 -D dump/Module Base Module Name Result----------- -------------------- ------0x0814f1b80 UNKNOWN OK: driver.814f1b80.sys$ ls -al[REMOVED]-rw-r--r-- 1 ubuntu ubuntu 53248 Jun 9 15:25 driver.814f1b80.sys