Direct kernel object manipulation

Direct kernel object manipulation (DKOM) is a common rootkit technique for Microsoft Windows to hide potentially damaging third-party processes, drivers, files, and intermediate connections from the task manager and event scheduler.

Overview

At its very core, a rootkit that employs DKOM hides itself from the Object Manager or Task manager. By modifying the linked list containing a list of all active threads and processes, this type of rootkit can essentially hide all traces from the Object Manager by wrapping the pointer away from the rootkit itself. This is possible due to the fact that kernel modules and loadable drivers have direct access to the kernel memory from its privileged access. When the system kernel pings to find the list of all processes running in the system, it relies on the EPROCESS to find them. However, because a Windows Kernel is thread based and not process based, pointers can be freely modified without any unintended effects.[1] By modifying linked list pointers to wrap around the rootkit process itself, the rootkit becomes invisible to the Windows event viewer and any system integrity applications that rely on this list. This allows DKOM rootkits to have free rein over the targeted system.

DKOM Uses [2]

  • Hide process
  • Hide drivers
  • Hide ports
  • Elevate privilege level of threads and processes
  • Skew forensics
  • Full control of system

Hiding from the Object Manager

Each process is represented as an object and is interconnected with one another in the operating system. Within each process, there is a pre-allocated set of space that contains the address of the current, next, and mutex_locked thread. This vital information is listed in the EPROCESS in memory; the section in the object manager contains a double linked list of all known processes running, which is also known as the EPROCESS. However, DKOM's take advantage of this structure by modifying the front link (FLINK) to point to the previous node of the processor that we want to hide, and pointing the back link (BLINK) of the hidden processor to the previous structure.[3] By modifying a subsection of the EPROCESS block, the list of currently active processes points around the hidden process. This essentially hides any paper trail of a given process or injector from the scrutiny of the scheduler because the process is hidden; yet it runs indefinitely because the thread it is in is active due to the round-robin policy.[2]

The main issue with this type of rootkit is that hidden processes are still able to run despite various context switches.[3] In a Windows scheduler, threads are segregated to perform tasks, not processes. Rather, a thread calls multiple processes during a given time frame. This process is controlled by the round-robin nature of the scheduler and threads are put on idle to allow other threads to be active. Even though a process becomes invisible to the task manager, the process still runs concurrently with the system because the threads are active.[4] This makes detecting hidden processes created by the rootkit extremely difficult.

Detection

Detecting rootkits is separated into many complex layers that include integrity checking and behavioral detection. By checking the CPU usage, ongoing and outgoing network traffic, or the signatures of drivers, simple anti-virus tools can detect common rootkits. However, this is not the case with a kernel type rootkit. Because of how these types of rootkits can hide from the system table and event viewer, detecting them requires looking for hooked functions. Not only is this very difficult to implement, but it also requires iterating through each and every node in the EPROCESS. However, even though the presence of any malicious processes is not physically present in the handler, calls are made to it in the background. These processes point to threads, network connections points to processes, and drivers point to threads. For a DKOM rootkit to be viable, it has to hide its presence from every single reference in the EPROCESS.[5] This means that the rootkit has to routinely update any linkers to point away from itself. By iterating through each and every entity in the scheduler (threads, object headers etc), detecting a DKOM rootkit is possible. Certain memory patterns or behaviors may appear in the scheduler, and if one is found, the actual rootkit can be eventually found as well.[5]

See also

References
  1. https://www.blackhat.com/presentations/win-usa-04/bh-win-04-butler.pdf Butler, Jamie. DKOM, HBGary. Retrieved 5/14/2014.
  2. http://bsodtutorials.blogspot.com/2014/01/rootkits-direct-kernel-object.html Miller, Harry. "BSOD Tutorials: Rootkits". BSODTUTORIALS, 27 January 2014. Retrieved 5/1/2014
  3. http://fluxius.handgrep.se/2011/01/02/ring-0f-fire-rootkits-and-dkom/ FlUxIuS Ring Of Fire: Rootkits. WordPress, 2 January 2011. Retrieved 5/5/2014
  4. https://www.symantec.com/avcenter/reference/when.malware.meets.rootkits.pdf Florio, Elia. "When Malware Meets Rootkits". Symantec, December 2005. Retrieved 5/09/2014
  5. http://jessekornblum.com/presentations/dodcc11-2.pdf jessekornblum. Windows Memory Forensics,. KYRUS Technology, (2006). Retrieved 5/14/2014
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.