xfocus logo xfocus title
首页 焦点原创 安全文摘 安全工具 安全漏洞 焦点项目 焦点论坛 关于我们
添加文章 Xcon English Version

基于CallStack的Anti-Rootkit HOOK检测思路


创建时间:2007-11-02
文章属性:原创
文章提交:MJ0011 (tyjaaa_at_163.com)

基于CallStack的Anti-Rootkit HOOK检测思路:

MJ0011
2007-11-2
th_decoder@126.com

Anti-Rootkit目前扫描Hook的方法主要有以下几种:

1.对抗inline -hook ,IAT/EAT Hook

Anti-Rootkit使用读取磁盘上系统文件并将之进行map\重定位后,同内存中的代码进行对比的方法来检测inline hook(或EAT/IAT HOOK,后同),类似的工具例如Rootkit Unhooker, gmer, Icesword等等

为了对抗Anti-Rootkit的inline Hook扫描,Rootkit们使用一些方法来进行自己HOOK的隐藏

例如Shadow Walker的方法,HOOK Int 0Eh缺页中断来隐藏内存中被HOOK的代码

或者是例如流氓软件CNNIC中文上网,HOOK FSD的IRP_MJ_READ,当读取到ntfs.sys等文件时,修改数据,将错误的结果返回回去,导致Anti-rootkit工具误认为内存中的代码是正确的

多种方式都可以让这种传统的INLINE HOOK检测方法失效

2.Object Hook

Object Hook一般更隐藏,更难检测

为大家所熟知的Object hook例如有修改driver object中的MajorFunction dispatch表

或者是hook KeyObject(KCB)中的一些call back routine/GetCell Routine(zzzzevazzzz放出过相关代码)

又或者是hook Object中一些其他的通用链中的代码指针来进行自我隐藏/保护功能(例如tombkeeper的一些文章提到的细节)

目前的办法一般是扫描这些OBJECT的结构,找到对应指针,利用特征搜索、模块范围对比等方法,检测他们是否被HOOK

类似的工具例如 rootkit unhooker,gmer(rootkit unhooker中检测的object hook较多)

但这些工具都只能检测他们已知的object hook

一旦Rootkiter利用未知的object hook进行隐藏,或者是转换平台,数据结构发生变化,就很难检测到object hook, 传统的Object hook检测方式也很容易被rootkiter饶过,
详见我的<<绕过现代Anti-Rookit工具的内核模块扫描>>一文



这里提出一种新的hook检测方式: 即利用CallStack进行HOOK检测

让我们来看一种典型的rootkit的HOOK方式:

例如hook \\FileSystem\\Ntfs的 IRP_MJ_DIRECTORY_CONTROL来进行文件隐藏,rootkit.com有上相关的代码

它们的代码通常是这样的

NTSTATUS HookFsd(LPCWSTR DrvName)

{

//....获得ntfs的driver object

g_OldNtfsDriCtl = drvobj->MajorFunction[IRP_MJ_DIRECTORY_CONTROL];

//保存原始的dispatch 地址

drvobj->MajorFunction[IRP_MJ_DIRECTORY_CONTROL] = MyNtfsDriCtl ;

//用自己的dispatch 地址替换原始地址

//,,,,,

}



NTSTATUS   MyNtfsDriCtl(PDEVICE_OBJECT devobj , PIRP pIrp)

{

NTSTATUS stat ;

//一些初始化处理.....

  __asm

{

push  pIrp

push devobj

call g_OldNtfsDriCtl

mov stat ,eax

}

//首先调用原始函数,以便得到结果

//下面进行处理,hack CompletionRoutine,或者是直接修改 UserBuffer的数据

//...

}

上面就是一个hook fsd来隐藏文件的ROOTKIT的大概结构

让我们来看看,在MyNtfsDriCtl中call g_OldNtfsDriCtl时,发生了什么?

它会跳转到原始的g_OldNtfsDriCtl中,并且保存返回地址,这个返回地址在哪儿?rootkit的代码体内!

那么就简单了,我们简单地Hook 原始dispatch中的更深层的地方,例如,Ntfs的DriectoryControl快结束时会call KeLeaveCriticalRegion或者IofCompleteRequest

我们HOOK这个地方,然后,当这个调用触发时,我们检查esp,并向上回溯堆栈,找到call stack,我们发现了什么?

哈哈!rootkit的返回地址!

再简单的使用ZwQuerySystemInformation,就可以知道这个地址位于哪个模块中,ROOTKIT定位成功!(如果抹去了模块,可以定位这块内存为unknow image)

这样,只要HOOK特定的地方,再在ring3调用相关服务,触发hook,检查call stack,就可以轻松得到rootkit的返回地址了(或者hooker的返回地址,不一定是rootkit :p )

示例代码就不写了,有几个注意问题:
1.call stack中会有其他一些系统的模块或者硬件驱动的模块,要考虑如何把他们区分出来的问题,相信这个很简单了,呵呵

2.使用这种方式,只要你HOOK的地方正确恰当

可以检测到90%以上的object hook,无论object结构如何变化,或者是未知的object hook,或者使用一些方式进行object hook的隐藏

(例如<<绕过现代Anti-Rookit工具的内核模块扫描>>中提到的方法),
都会被检测出来

但并非所有的inline hook方式都可能被检测出来,例如修改被HOOK函数参数后使用jump 指令而不是call指令跳转到原始函数,这样就检测不出来

另外HOOK的位置也十分关键,HOOK的位置不对,一些ROOTKIT可能HOOK的路径就会被放过,HOOK得过深的话,进程context就会丢失(例如hook到disk或atapi来检测文件/磁盘HOOK时),这样判断上就会有一定的困难

3.call stack的分析方法,这个也很简单了,这里就不多说了