IDT Hooks

I came across a interesting question on the KernelMode forum, with regards to IDT hooking and if it's malicious within the context in which they posted the question.

I've decided to investigate further into the concept of IDT hooking, and why some software developers may wish to use this concept, even though it isn't advised by Microsoft, who have in fact protected the kernel from IDT hooking with Kernel Patch Protection (x64 systems only). The KPP was added, since IDT hooking can cause system instability, since this kind of activity isn't supported by the operating system. Any attempt to hook into IDT on x64 systems will lead to a Stop 0x109 bugcheck.

KPP doesn't protect against hooking of IDT or System Service table, since some software is dependent upon those features.

Some developers may wish to change the behavior provided by the SSDT (System Service Dispatch Table).

Hooking the IDT:

Hooking the IDT: Programming
Hooking Software Interrupts

If you have read through the two above articles, you may be wondering what is the IDTR register used for, and what are interrupt dispatch gates?

The IDTR register is simply used to store the IDT table, and help to locate the memory address in which the appropriate vector is residing. Vectors are our exception codes and interrupt numbers within the IDT. The interrupt dispatch gates are essentially the same thing as our interrupt descriptors within the IDT, they can be a interrupt gate (hardware interrupts), trap gates (software interrupts) or task gates (switches TSS and enables different thread/process to have control of the processor).

Malicious uses of IDT and SSDT Hooking:

Hooking of the INT2E handler for generic System calls, which allows User-Mode threads to transition into Kernel-Mode threads, could allow rootkits to have single hooking point on System calls. 

Hooking of the SSDT, could enable rootkits to have control over the I/O of calls from User-Mode, and allow modification of certain processes and registry keys.