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. 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 

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. 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.

The main issue with this type of rootkit is that hidden processes are still able to run despite various context switches. 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.   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. 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.

See also
Rootkit
Windows Task Manager
Windows Task Scheduler
Object Manager (Windows)
Round-robin scheduling
Hooking
Linked list
device
Process (computing)
Pointer (computer programming)
Thread (computing)
Code signing
CPU time
Network traffic
Device driver

References

External links
Blackhat.com
Jessekornblum.com
bsodtutorials.blogspot.com 
symantec.com 
fluxius.handgrep.se

Windows rootkit techniques
직접 커널 객체 조작 (DKOM : Direct Kernel Object Manipulation)은 써드 파티 프로세스, 드라이버, 파일에 대한 잠재적인 손상 및 중계 연결을 작업 관리자와 이벤트 스케줄러로부터 숨기는데 사용되는 일반적인 루트킷 기법이다.

개요 
DKOM을 사용하는 루트킷은 핵심부에서 자신을 객체 관리자 또는 작업 관리자로부터 숨긴다. 모든 활성화된 스레드 및 프로세스의 리스트를 포함하는 연결 리스트를 수정함으로써 이런 형태의 루트킷은 객체 관리자로부터의 모든 추적에서 숨을 수 있다. 이것이 가능한 이유는 커널과 적재 가능한 드라이버가 자신의 권한을 가진 접근으로부터 직접적으로 메모리를 통해 접근할 수 있기 때문이다. 시스템 커널이 실행 중인 모든 프로세스의 리스트를 찾고자 할 때는 EPROCESS에 의존한다. 그러나 윈도우 커널은 프로세스 기반이 아니라 스레드 기반이기 때문에 연결 리스트의 포인터는 부작용 없이 수정될 수 있다. 루트킷 프로세스 자신을 감싸는 연결 리스트 포인터를 수정함으로써 루트킷은 윈도우 이벤트 뷰어 및 이 리스트에 의존하는 시스템 무결성 애플리케이션에서 보이지 않게 된다. 이것은 DKOM 루트킷이 대상 시스템에 대한 무한한 자유를 가질 수 있게 해준다.

DKOM 사용
 프로세스 숨기기
 드라이버 숨기기
 포트 숨기기
 스레드와 프로세스의 권한 상승
 포렌식 우회
 시스템에 대한 완전한 제어

객체 관리자로부터 숨기기 
객체로 표현되는 각 프로세스는 운영 체제 내에서 서로 연결된다. 각 프로세스 내부에는 현재, 다음 그리고 mutex_locked 스레드의 주소를 포함하는 공간의 집합이 선 할당되어 있다. 이 중요한 정보는 메모리의 EPROCESS에 목록화되어 있다; 객체 관리자의 섹션은 EPROCESS로도 불리는 실행중인 알려진 프로세스들의 더블 연결 리스트를 포함한다. 그러나 DKOM은 이 우리가 숨기고자 하는 이전 노드를 가리키는 front link (FLINK)를 그리고 마찬가지로 back link (BLINK)를 수정함으로써 구조체를 이용한다. EPROCESS 블록의 세부 항목을 수정함으로써 현재 활성화된 프로세스들의 리스트는 숨겨진 프로세스를 둘러서 가리킨다. 프로세스가 숨겨졌기 때문에 이것은 근본적으로 스케줄러의 정밀 조사로부터 주어진 프로세스나 인젝터에 대한 증거를 숨겨준다.

이러한 타입의 루트킷과 관련된 중요한 점은 숨겨진 프로세스들이 다양한 문맥 전환들에도 불구하고 계속 실행될 수 있다는 점이다. 윈도우 스케줄러에서 스레드들은 프로세스가 아니라 작업(task)을 수행하기 위해 분리되어 있다. 대신 스레드는 주어진 시간 프레임 동안 여러 프로세스들을 호출한다. 이 프로세스는 스케줄러의 라운드 로빈 방식에 의해 제어되며 스레드들은 다른 스레드가 활성화되는 동안 대기 상태에 놓여진다. 비록 프로세스가 작업 관리자에게는 보이지 않지만 프로세스는 스레드가 활성화되어 있기 때문에 시스템과 동시에 실행된다. 이것은 루트킷에 의해 만들어진 숨겨진 프로세스를 탐지하는 것을 극도로 어렵게 만든다.

탐지 
루트킷을 탐지하는 것은 무결성 검사 및 행위 탐지를 포함한 여러 복잡한 단계로 나뉜다. CPU 사용, 네트워크 트래픽, 드라이버 시그니처 등을 검사함으로써 간단한 안티 바이러스 도구들은 흔한 루트킷들을 탐지할 수 있다. 그러나 이것은 커널 형태의 루트킷의 경우에는 통하지 않는다. 왜냐하면 이러한 형태의 루트킷들이 시스템 테이블이나 이벤트 뷰어, 루트킷 탐지로부터 숨기 위해 사용하는 방법으로 인해 후킹된 함수들을 찾는 것을 필요로하기 때문이다. 이것은 구현하기 매우 힘들 뿐만 아니라 또한 EPROCESS의 모든 노드에서 각각 반복할 필요가 있다. 그러나 비록 어느 악의적인 프로세스들의 존재가 물리적으로 핸들러에서 존재하지 않는다고 해도 호출들은 반드시 백그라운드에 있어야 한다. DKOM 루트킷이 성공하기 위해서는 자신의 존재를 EPROCESS에 있는 모든 단일 참조로부터 숨겨야 한다. 이것은 루트킷이 일상적으로 어느 자신을 가리키는 어느 링크도 만들어지지 않도록 업데이트해야 한다는 것을 의미한다. 스케줄러에서 모든 개체에 각각 반복함으로써 DKOM 루트킷을 탐지하는 것은 가능하게 된다. 특정한 메모리 패턴들이나 행위들이 스케줄러에서 발견된다면 실제 루트킷도 결국 탐지할 수 있게 된다.

같이 보기 
 루트킷
 윈도우 작업 관리자
 윈도우 작업 스케줄러
 객체 관리자
 라운드 로빈 스케줄링
 후킹
 연결 리스트
 주변기기
 프로세스
 포인터 (프로그래밍)
 커널 (컴퓨팅)
 스레드
 코드 사이닝
 CPU 타임
 네트워크 트래픽
 장치 드라이버

각주

외부 링크 
 Blackhat.com
 Jessekornblum.com
 bsodtutorials.blogspot.com
 symantec.com
 fluxius.handgrep.se 
루트킷