Anti-Rootkit HOOK Detection Based on CallStack

MJ0011
2007-11-2
Th_decoder@126.com

Currently, Anti-Rootkit scans the Hook in the following methods:

1. Fight Against inline-hook, IAT/EAT Hook

Anti-Rootkit uses the method of reading system files on the disk and relocating the map to detect the inline hook (or EAT/iat hook, and later) by comparing the code in the memory ), similar tools such as Rootkit Unhooker, gmer, and Icesword

To prevent inline Hook scanning of Anti-Rootkit, Rootkit uses some methods to hide their own hooks.

For example, in the Shadow Walker method, the HOOK Int 0Eh page breaks to hide the code hooked in the memory.

Or, for example, if the rogue software CNNIC accesses the Internet in Chinese, HOOK the IRP_MJ_READ of FSD. when sys and other files, modify the data and return the wrong results back, resulting in the Anti-rootkit tool mistakenly believing that the code in the memory is correct.

Multiple methods can invalidate this traditional inline hook detection method.

2. Object Hook

Object hooks are generally more hidden and more difficult to detect.

For example, you can modify the MajorFunction dispatch table in the driver Object for well-known object hooks.

Or call back routine/GetCell Routine in hook KeyObject (KCB) (zzzzevazzzz has released the relevant code)

Or hook some other code pointers in the common chain in the Object for self-hiding/protection (for example, the details mentioned in some articles of tombkeeper)

The current method is generally to scan the structure of these objects, find the corresponding pointer, and use feature search, module range comparison, and other methods to check whether they are hooked

Similar tools such as rootkit unhooker and gmer (many object hooks detected in rootkit unhooker)

However, these tools can only detect known object hooks.

Once the Rootkiter uses an unknown object hook for hiding, or the conversion platform, the data structure changes, it is difficult to detect the object hook. The traditional Object hook detection method is also easily used by rootkiter,
For more information, see my article <bypassing kernel module scanning of modern Anti-Rookit tools>

 

Here we propose a new hook Detection Method: Using CallStack for HOOK Detection

Let's look at a typical rootkit HOOK method:

For example, the IRP_MJ_DIRECTORY_CONTROL of hook \ FileSystem \ Ntfs is used to hide the file. The related code on rootkit.com is displayed.

Their code is usually like this

NTSTATUS HookFsd (LPCWSTR DrvName)

{

//... Get the ntfs driver object

G_OldNtfsDriCtl = drvobj-> MajorFunction [IRP_MJ_DIRECTORY_CONTROL];

// Save the original dispatch address

Drvobj-> MajorFunction [IRP_MJ_DIRECTORY_CONTROL] = MyNtfsDriCtl;

// Replace the original address with your own dispatch address

//,,,,,

}

 

NTSTATUS MyNtfsDriCtl (PDEVICE_OBJECT upload BJ, PIRP pIrp)

{

NTSTATUS stat;

// Some initialization processes .....

_ Asm

{

Push pIrp

Push mongobj

Call g_OldNtfsDriCtl

Mov stat, eax

}

// Call the original function to obtain the result.

// Perform the following processing: hack CompletionRoutine, or directly modify the UserBuffer data.

//...

}

The above is a hook fsd to hide the approximate structure of the file's ROOTKIT.

Let's take a look at what happened when calling g_OldNtfsDriCtl in MyNtfsDriCtl?

It will jump to the original g_OldNtfsDriCtl and save the return address. Where is the return address? Rootkit code body!

We can simply Hook deeper aspects of the original dispatch. For example, when the Ntfs DriectoryControl ends, it will call KeLeaveCriticalRegion or IofCompleteRequest.

We HOOK this location, and then, when this call is triggered, we check esp and trace back the stack to find the call stack. What did we find?

Haha! Rootkit return address!

Simply use ZwQuerySystemInformation to know which module the address is located and the ROOTKIT is located successfully! (If the module is erased, you can locate the memory as unknow image)

In this way, as long as the HOOK is specific, call the relevant service in ring3, trigger the hook, and check the call stack, you can easily get the return address of the rootkit (or the return address of the hooker, not necessarily rootkit: p)

The sample code will not be written. There are several notes:
1. There will be other system modules or hardware-driven modules in the call stack. We should consider how to differentiate them. I believe this is very simple.

2. If this method is used, as long as the HOOK is correct and appropriate

More than 90% of object hooks can be detected, no matter how the object structure changes, unknown object hooks, or object hook hiding in some ways.

(For example, <bypassing the kernel module scanning of modern Anti-Rookit tools> ),
Will Be Detected

However, not all inline hook methods may be detected. For example, you can use the jump command instead of the call Command to jump to the original function after modifying the HOOK function parameter.

In addition, the HOOK location is critical. If the HOOK location is incorrect, some ROOTKIT may miss the HOOK path. If the HOOK is too deep, process context will be lost (for example, when hook to disk or atapi to detect file/disk HOOK), so there will be some difficulties in judgment.

3. call stack analysis method. This is also very simple. I will not talk about it here.