记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

【连载】Bootkit硬盘取证 – 第二讲

2015-03-13 21:05

分享到:

t0120a85adda52c8c18.png

DriverStartIo例程

在之前的文章中,我们可以知道DriverStartIo是被微端口用来执行一些硬盘的I/0的请求。和IoCallDriver例程一样,DriverStartIo一般会执行两个参数,分别为一个device object和一个IRP。但是现在大部分的硬件设备都不是通过微端口进行访问和连接了,他们大部分情况下都是通过正常端口进行访问。(在第一讲里面有端口和微端口的介绍)

注释:

IRP:它也叫做输入输出封包,全称为i/o request packet。

IRP_MJ_SCSI例程一般是指向atapi.sys驱动中的IdePortDispatch例程。通过对它进行反编汇,我们能够发现这些发送请求的设备是如何从DeviceExtension层来接收信息的。
 

t014edd66c41be22d81.png

在开头部分,我们可以看到ebx是device extension的一个地址,它能够被所有的ATAPI设备所分享。

调用逻辑顺序:

从一个device object中得到微端口的device extension。

从另外一个微端口device extension的offset 0x5C中得到IdePort1的device extension。

从其它的device extension中的offset 0x0C得到IdePort1的device object。

调用IoStartPacket例程到IRP和IdePort1列陈的device object。


注释:

device extension:设备扩展(DEVICE_EXTENSION)是与设备对象相关的另一种重要的数据结构。

device object:就是一个设备的对象。它是驱动程序在内核中的数据结构,每个驱动程序有唯一DRIVER_OBJECT,IO管理器使用驱动程序对象代表每个设备驱动程序

t01aab41efc20611a5f.png

这个关系图描述了一个bootkit的组件信息

atapi.sys驱动可以创建微端的device口和IdePort的device,而这个两个device的DriverObject例程又指定了一个一模一样的驱动组件。所以在这个驱动组件中,用DriverStartIo来进行挂钩子或者插入rootkit是非常简单的。

运用WinDbg来检测DriverStartIo的rootkit

如果要检测DriverStartIo类型的rootkit,我们可以根据下面几个比较简单的步骤来执行。

首先我们可以根据下面的命令找到引导磁盘和磁盘叠层

http://p4.qhimg.com/t01d51f264fe74980de.png

在干净的系统里面所显示的磁盘叠层

http://p1.qhimg.com/t01d77772da40775b51.png

在被rootkit感染后所显示的磁盘叠层

根据我上一篇的文章,我想做一下修正。我之前说过被TDL4感染过的系统无法使用指令!drvobj和!devobj,但是我发现我的研究错了。。。事实并非如此。

你可能想在硬盘叠层里检查每一个驱动的组件,那么你可以使用“dt _DEVICE_OBJECT <address>”指令找到DriverObject例程。大部分的bootkit后门都在最底层的驱动文件里面,所以会使用这个指令给大家作为一个参考。

t012873bf149d170273.png

DriverStartIo 显示没有中bootkit

你可以看到DriverStartIo并没有被植入bootkit,因为这些地址显示的都是正常的符合。但是,这个并不是一个真正的驱动对象。我之前说过,IoStartPacket只能和IdePort1进行调用,并不是硬盘的微端口。这个意思就是当IoStartPacket调用DriverStartIo时,那么它就会从DriverObject例程得到一个驱动对象,然后就会得到DriverStartIo例程。很明显了,这个bootkit就植入在DriverStartIo里面。它只是很简单的创建了一个atapi驱动对象的副本,然后对DriverStartIo例程进行修改。之后,建立一个IdePort1驱动的DriverObject例程,那么它就会指向一个新的地址,也就是恶意的驱动对象。

事实就是,这个TDL4已经感染了系统,并且它成功在atapi的驱动对象里面植入了bootkit,然后把磁盘微端口的驱动的DriverObject例程换成了全部都是恶意代码的地址。并且不需要DriverStartIo进行修改。

还有一个更简单的方法来检测所有的虚假驱动对象。所有的设备的驱动都是指向同一个驱动对象。所以只要简单的枚举一下这些设备的微端口驱动,这样就可以查看所以的DriverObject例程是否都指向了同一个地址。

下面是这些方法的介绍。

方法1:DrvObj

带有bootkit的驱动对象都和真正的驱动对象有着个相同的名称,就是"\driver\atapi"。这时,你需要输入指令"!drvobj \driver\atapi 2"来查看那些是正常的驱动对象。在下面这张图里面你会发现有个驱动对象的地址变了,那么它很有可能带有bootkit。
 

http://p0.qhimg.com/t01ecd8090b116a1afd.png

方法2:NextDevice

枚举设备可以使用"dt _DEVICE_OBJECT <address>"命令。每一个驱动的对象里面都有NextDevice这么一个例程。这张图里面,我们可以看到所有的DriverObject例程。如果其中一个例程调用了微端口的驱动对象,那么这个例程很有可能感染了bootkit。
 

http://p5.qhimg.com/t01e16bf084b3430447.png

所以的设备都应该指向一个正确的驱动对象,而这个微端口却不是。

方法3: DeviceExtension

这个是最后一个方法,设备扩展能够改版从一个系统到另外一个系统。但是我之前提过,你可以在offset 0x5C中找到IdePort1例程的设备扩展,而不是在微端口的设备扩展进行寻找。这样的话,在offset 0x5C中的IdePort1例程的设备扩展,我们也就能够找到它的设备对象,因为IdePort1中的设备对象会指定一个真实的驱动对象。通过一个简单的指令,我们可以找到DeviceObject。
指令为"dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)", where "<address>"
 

t01896d93f25c6b32e2.png

  【连载】Bootkit硬盘取证 – 第一讲

本文由 360安全播报 翻译,转载请注明“转自360安全播报”,并附上链接。
原文链接:http://www.malwaretech.com/2014/12/phase-bot-fileless-rootkit-part-2.html


知识来源: bobao.360.cn/learning/detail/296.html

阅读:119727 | 评论:0 | 标签:无

想收藏或者和大家分享这篇好文章→复制链接地址

“【连载】Bootkit硬盘取证 – 第二讲”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

ADS

标签云