Detecting Hooks [modified]
-
Hi all, I'm curious as to whether there are methods to detect forms of hooking on windows. I've been trying the WH_DEBUG hook to no success, code is below and it crashes every app under the explorer.exe tree.
HHOOK debughook;
LRESULT CALLBACK DebugProc(int nCode,WPARAM wParam,LPARAM lParam){
return CallNextHookEx(debughook,nCode,wParam,lParam);
}int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
debughook=SetWindowsHookEx(WH_DEBUG,DebugProc,hInstance,0);Any help with that would be appreciated, as well as any other suggestions on hook detection. My original goal was to make an effective keylogger detection app, but as of now that doesn't seem very likely anymore. Thanks. edit: is there any reason why a global IAT patch doesn't seem to work on
SetWindowsHookExA?modified on Wednesday, March 10, 2010 8:24 PM
-
Hi all, I'm curious as to whether there are methods to detect forms of hooking on windows. I've been trying the WH_DEBUG hook to no success, code is below and it crashes every app under the explorer.exe tree.
HHOOK debughook;
LRESULT CALLBACK DebugProc(int nCode,WPARAM wParam,LPARAM lParam){
return CallNextHookEx(debughook,nCode,wParam,lParam);
}int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
debughook=SetWindowsHookEx(WH_DEBUG,DebugProc,hInstance,0);Any help with that would be appreciated, as well as any other suggestions on hook detection. My original goal was to make an effective keylogger detection app, but as of now that doesn't seem very likely anymore. Thanks. edit: is there any reason why a global IAT patch doesn't seem to work on
SetWindowsHookExA?modified on Wednesday, March 10, 2010 8:24 PM
This is an excellent question. If you search over at MSDN you will discover: Win32 Hooks[^] The problem is that, if you want to detect ALL hooks, you're going to have to think about the Hooking techniques. The sneakiest hooks do NOT use the standard available Windows techniques. And, of course, Windows does not want you interferring in its Hooking Chain, so they don't provide you with an easy method of monitoring hook activity.
-
This is an excellent question. If you search over at MSDN you will discover: Win32 Hooks[^] The problem is that, if you want to detect ALL hooks, you're going to have to think about the Hooking techniques. The sneakiest hooks do NOT use the standard available Windows techniques. And, of course, Windows does not want you interferring in its Hooking Chain, so they don't provide you with an easy method of monitoring hook activity.
-
Of course. In fact, I haven't even considered going into kernel land yet, only usermode methods of detecting hooks. The article is interesting but I can't seem to use any of that to detect installed hooks. :confused:
-
In the book, "Rootkits: Subverting the Windows Kernel", by Greg Hoglund, the author devotes an entire chapter to Hooks, and in particular, IAT hooking, which is probably the best way to detect malicious code. I have copied a section here to give you an idea. He discusses hooking in terms of a rootkit injected into a remote computer. Import Address Table Hooking The simpler of the two userland hooking processes is called Import Address Table hooking. When an application uses a function in another binary, the application must import the address of the function. Most applications that use the Win32 API do so through an IAT, as noted earlier. Each DLL the application uses is contained in the application's image in the file system in a structure called the IMAGE_IMPORT_DESCRIPTOR. This structure contains the name of the DLL whose functions are imported by the application, and two pointers to two arrays of IMAGE_IMPORT_BY_NAME structures. The IMAGE_IMPORT_BY_NAME structure contains the names of the imported functions used by the application. When the operating system loads the application in memory, it parses these IMAGE_IMPORT_DESCRIPTOR structures and loads each required DLL into the application's memory. Once the DLL is mapped, the operating system then locates each imported function in memory and overwrites one of the IMAGE_IMPORT_BY_NAME arrays with the actual address of the function. Once your rootkit's hook function is in the application's address space, your rootkit can parse the PE format of the target application in memory and replace the target function's address in the IAT with the address of the hook function. Then, when the function is called, your hook will be executed instead of the original function. You can see that this is a very powerful yet rather simple technique. It does have its drawbacks, though, in that it is relatively easy to discover these types of hooks. On the other hand, hooks like these are used frequently, even by the operating system itself in a process called DLL forwarding. Even if someone is trying to detect a rootkit hook, determining what is a benign hook as opposed to a malicious hook is difficult. Another problem with this technique has to do with the binding time. Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the applic
-
In the book, "Rootkits: Subverting the Windows Kernel", by Greg Hoglund, the author devotes an entire chapter to Hooks, and in particular, IAT hooking, which is probably the best way to detect malicious code. I have copied a section here to give you an idea. He discusses hooking in terms of a rootkit injected into a remote computer. Import Address Table Hooking The simpler of the two userland hooking processes is called Import Address Table hooking. When an application uses a function in another binary, the application must import the address of the function. Most applications that use the Win32 API do so through an IAT, as noted earlier. Each DLL the application uses is contained in the application's image in the file system in a structure called the IMAGE_IMPORT_DESCRIPTOR. This structure contains the name of the DLL whose functions are imported by the application, and two pointers to two arrays of IMAGE_IMPORT_BY_NAME structures. The IMAGE_IMPORT_BY_NAME structure contains the names of the imported functions used by the application. When the operating system loads the application in memory, it parses these IMAGE_IMPORT_DESCRIPTOR structures and loads each required DLL into the application's memory. Once the DLL is mapped, the operating system then locates each imported function in memory and overwrites one of the IMAGE_IMPORT_BY_NAME arrays with the actual address of the function. Once your rootkit's hook function is in the application's address space, your rootkit can parse the PE format of the target application in memory and replace the target function's address in the IAT with the address of the hook function. Then, when the function is called, your hook will be executed instead of the original function. You can see that this is a very powerful yet rather simple technique. It does have its drawbacks, though, in that it is relatively easy to discover these types of hooks. On the other hand, hooks like these are used frequently, even by the operating system itself in a process called DLL forwarding. Even if someone is trying to detect a rootkit hook, determining what is a benign hook as opposed to a malicious hook is difficult. Another problem with this technique has to do with the binding time. Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the applic
I have copied a brief section here about the general techniques involved in looking for User Mode IAT hooks, again, from "Rootkits: Subverting the Windows Kernel". I have left out the description of Inline Hooks, because they are implemented in assembly language and require some experience in disassembling. Looking For Hooks A memory-based detection method is to look for hooks within the operating system and within processes. There are many places where a hook can hide, including the following: Import Address Table (IAT) System Service Dispatch Table (SSDT), also known as the KeServiceDescriptorTable Interrupt Descriptor Table (IDT) with one per CPU Drivers' I/O Request Packet (IRP) handler Inline function hooks The basic algorithm for identifying a hook is to look for branches that fall outside of an acceptable range. Such branches would be produced by instructions like call or jmp. Defining an acceptable range is not difficult (for the most part). In a process Import Address Table (IAT), the name of the module containing imported functions is listed. This module has a defined start address in memory, and a size. Those numbers are all you need to define an acceptable range. Likewise for device drivers: All legitimate I/O Request Packet (IRP) handlers should exist within a given driver's address range, and all entries in the System Service Dispatch Table (SSDT) should be within the address range of the kernel process, ntoskrnl.exe. Finding Interrupt Discriptor Table (IDT) hooks is a bit more difficult, because you do not know what the acceptable ranges should be for most of the interrupts. The one you know for sure, however, is the INT 2E handler. It should point to the kernel, ntoskrnl.exe. Inline hooks are the hardest to detect, because they can be located anywhere within the function—requiring a complete disassembly of the function in order to find them—and because functions can call addresses outside the module's address range under normal circumstances. In the following sections, we will explain how to detect SSDT, IAT, and some inline hooks. Finding IAT Hooks IAT hooks are extremely popular with current Windows rootkits. IAT hooks are in the userland portion of a process, so they are easier to program than kernel rootkits, and do not require the same level of privilege. Because of this, you should make sure your detection software looks for IAT hooks. Finding IAT hooks is very tedious, and implementing a search for them requires many of the techniques covered in previous chapters. Howev
-
In the book, "Rootkits: Subverting the Windows Kernel", by Greg Hoglund, the author devotes an entire chapter to Hooks, and in particular, IAT hooking, which is probably the best way to detect malicious code. I have copied a section here to give you an idea. He discusses hooking in terms of a rootkit injected into a remote computer. Import Address Table Hooking The simpler of the two userland hooking processes is called Import Address Table hooking. When an application uses a function in another binary, the application must import the address of the function. Most applications that use the Win32 API do so through an IAT, as noted earlier. Each DLL the application uses is contained in the application's image in the file system in a structure called the IMAGE_IMPORT_DESCRIPTOR. This structure contains the name of the DLL whose functions are imported by the application, and two pointers to two arrays of IMAGE_IMPORT_BY_NAME structures. The IMAGE_IMPORT_BY_NAME structure contains the names of the imported functions used by the application. When the operating system loads the application in memory, it parses these IMAGE_IMPORT_DESCRIPTOR structures and loads each required DLL into the application's memory. Once the DLL is mapped, the operating system then locates each imported function in memory and overwrites one of the IMAGE_IMPORT_BY_NAME arrays with the actual address of the function. Once your rootkit's hook function is in the application's address space, your rootkit can parse the PE format of the target application in memory and replace the target function's address in the IAT with the address of the hook function. Then, when the function is called, your hook will be executed instead of the original function. You can see that this is a very powerful yet rather simple technique. It does have its drawbacks, though, in that it is relatively easy to discover these types of hooks. On the other hand, hooks like these are used frequently, even by the operating system itself in a process called DLL forwarding. Even if someone is trying to detect a rootkit hook, determining what is a benign hook as opposed to a malicious hook is difficult. Another problem with this technique has to do with the binding time. Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the applic
"Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work." Does that mean if I compare the addresses of HookedFunction() and LoadLibrary(HookedFunction) I would be able to detect IAT hooks in my process? If so, any suggestions on how I might generalize this to every running process?
-
"Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work." Does that mean if I compare the addresses of HookedFunction() and LoadLibrary(HookedFunction) I would be able to detect IAT hooks in my process? If so, any suggestions on how I might generalize this to every running process?
hxhl95, The chapter about hooks from the Rootkits book by Hoglund is lengthy, and goes into great detail describing the most common hooking techniques used by malicious code. Rather than post the entire chapter (which would be HUGE), I just copied brief selections to give you an idea of what the general concept is. I left out a bunch of explanatory material. Alot of interesting information about the techniques used by malicious software are explained on: Rootkit[^] But, if you are trying to detect unauthorized hooks in your process address space (or others on the Local Machine), the concept is examine the address range of the DLL that exports the function called in the IAT of your process (the DLLs are all dynamically loaded by the system into your process address space), and determine if the address actually listed in the IAT corresponds to that range. If the process instead calls LoadLibrary and GetProcAddress to load the DLL on demand, the address entry in the IAT will NOT exist, so any malicious injected DLL code could not possibly overwrite the IAT address. (Actually, I'm unsure if the Operating System creates a temporary IAT entry at this point, but, I assume that it doesn't.) Go to SysInternals and download Process Explorer[^](FREE) to get a graphic representation of which dynamically loaded DLLs exist in your Process addesss space. Also,VMMap[^] is a very useful utility for understanding process address space memory allocations. An excellent overview of the Portable Executable format and its structures when loaded into memory is located at: Peering Inside the Portable Executable, Matt Pietrek[^]
-
hxhl95, The chapter about hooks from the Rootkits book by Hoglund is lengthy, and goes into great detail describing the most common hooking techniques used by malicious code. Rather than post the entire chapter (which would be HUGE), I just copied brief selections to give you an idea of what the general concept is. I left out a bunch of explanatory material. Alot of interesting information about the techniques used by malicious software are explained on: Rootkit[^] But, if you are trying to detect unauthorized hooks in your process address space (or others on the Local Machine), the concept is examine the address range of the DLL that exports the function called in the IAT of your process (the DLLs are all dynamically loaded by the system into your process address space), and determine if the address actually listed in the IAT corresponds to that range. If the process instead calls LoadLibrary and GetProcAddress to load the DLL on demand, the address entry in the IAT will NOT exist, so any malicious injected DLL code could not possibly overwrite the IAT address. (Actually, I'm unsure if the Operating System creates a temporary IAT entry at this point, but, I assume that it doesn't.) Go to SysInternals and download Process Explorer[^](FREE) to get a graphic representation of which dynamically loaded DLLs exist in your Process addesss space. Also,VMMap[^] is a very useful utility for understanding process address space memory allocations. An excellent overview of the Portable Executable format and its structures when loaded into memory is located at: Peering Inside the Portable Executable, Matt Pietrek[^]