实例讲解基于Volatility的内存分析技术Part 2

大家好，欢迎回到我们的内存分析系列文章。如果您还没有读过该系列的第一部分，不妨先移步下列地址：

实例讲解基于Volatility的内存分析技术，Part 1

现在，我们简要回顾一下前文内容：（对于阅读过上一篇文章的读者，可以直接跳到下一节）上次，我们还没有来得及考察注入IEXPLORE.EXE进程中的恶意代码的具体用途，文章就戛然而止了。不过，我们已经通过apihooks命令找出了主机中所有“钩子”的实例，具体如下所示：

一个经典的IAT hook的例子（详细的解释见上一篇文章）

如上所示，上面的代码段已经被“钩住”了，准确来说，被钩住的模块是kernel32.dll库。在这里，CALL指令不再调用LoadLibraryW，而是调用另外一个注入到内存中函数，从而执行如下所示的恶意代码（详情请参考上一篇文章）：

为了弄清这段代码的作用，我们可以借助于vaddump命令。该命令可以用来转储出一段内存中的内容。就这里来说，我们将通过它把内存中的模块转储出来，然后用IDA（或其他反汇编器）进行反汇编处理。

不过，这里有一个小问题：在上一篇文章中，我们曾经用过malfind命令，它用于寻找注入到内存中的所有模块。不幸的是，命令结果表明，我们在内存中并没有找到任何模块：

malfind命令的输出，我们可以看到这里并没有MZ头部

通常当一个模块被注入到内存中时，应该是能找到相应的MZ头部的，不好这对我们来说是一个好的迹象：说明注入的模块在内存中没有被篡改，或者头部没有被分页。当然，也可能是由于经过混淆处理的缘故，模块的头部已经从内存中清除掉了。如果恶意软件作者采取这一措施的话，会极大提高该恶意软件的调查难度，这是因为，我们必须重建这些头部，才能反汇编这些模块，而重建过程是需要花费很多时间的。

幸运的是，我们可以使用impscan命令，该命令可以用来检索代码对其他模块进行的API调用的信息，以便理解注入代码的功能。

impscan的工作原理是扫描进程内存中对JMP [< address >]或CALL [< address >]等函数的调用，这基本上就是告诉我们函数地址存储在内存中的< address >（一个地址指针）。这种调用有时用于从IAT中检索函数地址，而IAT其实就是一个包含导入函数地址的数组。

volatility所做的事情，就是跟踪这些调用，看看IAT存储了哪些函数指针，以及这些指针指向被加载到内存中的模块内的哪些函数。

现在我们知道了impscan的工作原理，接下来，我们将IEXPLORE.EXE进程的id指定为该命令的参数，因为我们的恶意代码就加载在这个进程里面，我们要弄清楚它的作用。另外，我们还需要提供加载到内存中的恶意模块的基地址，这样volatility就知道在哪里扫描导入函数了。

我们如何获取恶意模块的基地址呢？

我们将结合apihooks中的hook示例和vadinfo命令输出中的快速搜索功能（有关vad的详细解释，请参阅上一篇文章）来获取恶意代码的基地址。

现在，我们已经具备了所需的一切，接下来，让我们运行impscan命令：

Impscan命令

Impscan命令的运行结果

我们现在已经可以看到导入函数列表了。此外，我们还可以看到IAT列，它显示了IAT数组中元素的地址，而在它的右侧，则显示了包含在该数组元素中的导入函数的地址。另外，impscan命令还向我们显示了导入函数的名称，这可以帮助我们通过函数名称了解代码的作用。

下面是如何使用impscan命令的示例：

将IAT与反汇编代码进行比较后发现，我们的代码中的调用会将我们带到IAT中的相应地址。

如我们所见，我们可以查看impscan命令的输出，并将其与注入的代码进行比较，以找出每个函数调用正在执行的操作。例如，在上面的展示中，注入的代码调用了FreeLibrary。而FreeLibrary则会释放加载的动态链接库（DLL）模块，并在必要时减少其引用计数。当引用计数达到零时，模块将从调用进程的地址空间卸载，句柄也随之不再有效。

现在，我们我们已经可以查看注入的代码并理解其功能了。不过，这种方法面临的一个问题是，为了了解更多的情况，需要花费大量时间来阅读所有这些汇编代码。所以，我们可以使用impscan的另一种方式是：只查看导入函数并了解模块使用了哪些函数。这样，只要瞄一眼函数名称，而不一定要通过阅读汇编代码来了解代码逻辑，我们就可以了解这个恶意软件想要做什么。

这样，我们的重点就变成了通过impscan查找可疑函数，然后使用其他volatility命令跟踪恶意软件可能在做什么就行了。

我们的恶意模块涉及很多可疑的函数。对于那些熟悉volatility和数字取证的人来说，不要担心，我不会逐一解释。但首先，我想从一些简单的东西开始：注册表。

我们可以看到，恶意软件导入了一些API来使用注册表。大家可能都知道，注册表中包含了许多敏感信息和设置。并且，某些恶意软件会利用注册表来实现持久性，方法是通过编辑autorun键添加一个可执行文件，从而在启动时自动运行。就这里来说，恶意软件可能试图通过检查注册表中某些文件的存储位置来窃取敏感信息。

实际上，Volatility提供了一个非常棒的命令，叫做handles。这个命令可以让我们查看一个进程使用的句柄。总所周知，Windows是使用对象来表示和访问系统资源的，包括文件、设备、键等。本质上，一个对象是通过使用内核中的每个进程句柄表来进行访问的。也就是说，打开一个对象后，系统就会在句柄表中添加一个指向该对象的指针。而Volatility则正好可以利用这一事实，来扫描内存中的句柄。

我们将使用带有管道功能的handles命令，并筛选出仅包含注册表项的输出。

为了节约版面，我们只截取了部分感兴趣的列表。

下面，我们对这些结果进行解读。首先，我们可以看到一个以typedurls结尾的键。Internet Explorer可能经常使用这个注册表键（应该如此），但它也可能被特洛伊木马程序滥用，以获取受害者使用的网站信息。这是一种很好的间谍技术，尤其是代码被注入到Internet Explorer中时。另一个类似的键是RUNMRU，它列出了最近运行的程序，黑客如果想深入了解用户的活动，可能会想检查这些程序，并把这些信息也渗透出去。

另一个有趣的事情是，DRIVERS32注册表键以某种方式被使用。这可能暗示着这个恶意软件可能在我们的主机上也安装了一个驱动程序，并且可能会以某种方式使用它。我还看到一些与IE安全设置相关的注册表键也被使用了，这可能是攻击者为了降低主机的安全措施的级别，使其更容易受到其他攻击的另一种方法。

在结束本篇文章之前，我想指出，我们并没有看到注册表中恶意活动的有力证据，没有使用任何自定义注册表键（至少我们没有看到任何这样的东西）。我们只能推测这个恶意软件在注册表中做了什么。在该系列的下一篇文章中，我们将借助于volatility提供的其他工具，来准确地理解恶意软件试图实现的具体目标到底是什么。

感谢您的阅读，更多精彩内容，敬请期待！