Manipulación directa de objetos del kernel

La manipulación directa de objetos del kernel (DKOM, por sus siglas en inglés) es una técnica común de los rootkits de Microsoft Windows para ocultar procesos , controladores , archivos y conexiones intermedias de terceros potencialmente dañinos del administrador de tareas y del programador de eventos .

Descripción general

En esencia, un rootkit que emplea DKOM se oculta del Administrador de objetos o del Administrador de tareas . Al modificar la lista enlazada que contiene una lista de todos los subprocesos y procesos activos, este tipo de rootkit puede ocultar prácticamente todos los rastros del Administrador de objetos al encapsular el puntero fuera del propio rootkit. Esto es posible gracias a que los módulos del kernel y los controladores cargables tienen acceso directo a la memoria del kernel desde su acceso privilegiado. Cuando el kernel del sistema realiza un ping para encontrar la lista de todos los procesos que se ejecutan en el sistema, se basa en EPROCESS para encontrarlos. Sin embargo, dado que un kernel de Windows se basa en subprocesos y no en procesos, los punteros se pueden modificar libremente sin efectos no deseados. ^{[ 1 ]} Al modificar los punteros de la lista enlazada para encapsular el propio proceso del rootkit, este se vuelve invisible para el Visor de eventos de Windows y cualquier aplicación de integridad del sistema que dependa de esta lista. Esto permite que los rootkits DKOM tengan control total sobre el sistema objetivo.

Usos de DKOM ^{[ 2 ]}

Ocultar proceso
Ocultar conductores
Ocultar puertos
Elevar el nivel de privilegios de los subprocesos y procesos.
Análisis forense sesgado
Control total del sistema

Ocultarse del Administrador de objetos

Cada proceso se representa como un objeto y está interconectado con los demás en el sistema operativo. Dentro de cada proceso, hay un conjunto de espacio preasignado que contiene la dirección del hilo actual, el siguiente y el mutex_locked. Esta información vital se lista en el EPROCESS en memoria; la sección en el administrador de objetos contiene una lista doblemente enlazada de todos los procesos conocidos en ejecución, que también se conoce como EPROCESS. Sin embargo, los DKOM aprovechan esta estructura modificando el enlace frontal (FLINK) para que apunte al nodo anterior del procesador que queremos ocultar, y apuntando el enlace posterior (BLINK) del procesador oculto a la estructura anterior. ^{[ 3 ]} Al modificar una subsección del bloque EPROCESS, la lista de procesos actualmente activos apunta alrededor del proceso oculto. Esto esencialmente oculta cualquier rastro de un proceso o inyector dado al escrutinio del planificador porque el proceso está oculto; sin embargo, se ejecuta indefinidamente porque el hilo en el que está está activo debido a la política round-robin. ^{[ 2 ]}

El principal problema con este tipo de rootkit es que los procesos ocultos aún pueden ejecutarse a pesar de los diversos cambios de contexto. ^{[ 3 ]} En un planificador de Windows, los subprocesos se segregan para realizar tareas, no procesos. En cambio, un subproceso llama a múltiples procesos durante un período de tiempo determinado. Este proceso está controlado por la naturaleza round-robin del planificador y los subprocesos se ponen en estado de inactividad para permitir que otros subprocesos estén activos. Aunque un proceso se vuelve invisible para el administrador de tareas, el proceso sigue ejecutándose concurrentemente con el sistema porque los subprocesos están activos. ^{[ 4 ]} Esto hace que la detección de los procesos ocultos creados por el rootkit sea extremadamente difícil.

Detección

La detección de rootkits se divide en muchas capas complejas que incluyen la verificación de integridad y la detección de comportamiento. Al verificar el uso de la CPU , el tráfico de red entrante y saliente , o las firmas de los controladores, las herramientas antivirus simples pueden detectar rootkits comunes . Sin embargo, este no es el caso de un rootkit de tipo kernel. Debido a cómo estos tipos de rootkits pueden ocultarse de la tabla del sistema y el visor de eventos, detectarlos requiere buscar funciones interceptadas . Esto no solo es muy difícil de implementar, sino que también requiere iterar a través de cada nodo en el EPROCESS. Sin embargo, aunque la presencia de cualquier proceso malicioso no esté físicamente presente en el manejador, se realizan llamadas a él en segundo plano. Estos procesos apuntan a hilos, las conexiones de red apuntan a procesos y los controladores apuntan a hilos. Para que un rootkit DKOM sea viable, tiene que ocultar su presencia de cada referencia en el EPROCESS. ^{[ 5 ]} Esto significa que el rootkit tiene que actualizar rutinariamente cualquier enlazador para que apunte lejos de sí mismo. Al iterar a través de cada una de las entidades del planificador (hilos, encabezados de objetos, etc.), es posible detectar un rootkit DKOM. Ciertos patrones o comportamientos de memoria pueden aparecer en el planificador, y si se encuentra alguno, eventualmente también se puede encontrar el rootkit real. ^{[ 5 ]}

Véase también

Referencias

↑ https://www.blackhat.com/presentations/win-usa-04/bh-win-04-butler.pdf Butler, Jamie. DKOM, HBGary. Recuperado el 14/05/2014.
1 2 http://bsodtutorials.blogspot.com/2014/01/rootkits-direct-kernel-object.html Miller, Harry. "Tutoriales de BSOD: Rootkits". BSODTUTORIALS, 27 de enero de 2014. Consultado el 1/5/2014
1 2 http://fluxius.handgrep.se/2011/01/02/ring-0f-fire-rootkits-and-dkom/ Anillo de fuego de Fluxius : Rootkits . WordPress, 2 de enero de 2011. Consultado el 5/5/2014
↑ https://www.symantec.com/avcenter/reference/when.malware.meets.rootkits.pdf Archivado el 28/08/2017 en Wayback Machine. Florio, Elia. «Cuando el malware se encuentra con los rootkits». Symantec, diciembre de 2005. Consultado el 09/05/2014.
1 2 http://jessekornblum.com/presentations/dodcc11-2.pdf jessekornblum. Análisis forense de memoria de Windows . KYRUS Technology, (2006). Recuperado el 14/05/2014