Son muchos los casos en los que programadores dejan para su propio uso parámetros de configuración no documentados o funcionalidad «oculta» en las aplicaciones que desarrollan. El otro día dimos con lo que a primera vista parecía uno de estos casos:

Nos encontrabamos Miguel y yo en plena reunión matutina (el desayuno con pincho de tortilla incluido), cuando me comentaba que en una de sus frecuentes sesiones de depuración creía haber encontrado funcionalidad en el propio API de Windows para ocultar threads, no sin antes acabar el pincho de tortilla nos pusimos a comentarlo…

El código en cuestión se encontraba en la función RtlQueryProcessDebugInformation, exportada por NTDLL.DLL, esta función es usada por varias funciones de Tool Help exportadas por KERNEL32.DLL, las cuales son usadas para obtener información sobre los procesos activos en el sistema.

 

 

Previamente al código que observamos en este desensamblado se llama a RtlCreateUserThread en caso de que el proceso del que estemos recolectando información sea «remoto». La cuestión era … ¿qué información se estaba estableciendo en el Thread que se creaba?, si consultamos la documentación de ZwSetInformationThread vemos que el parametro ThreadInformationClass que corresponde con ese extraño 0x11, sólo tiene dos posibles valores:

¿Qué será ese 0x11?, es aquí cuando uno decide echar mano del DDK donde están definidas las estructuras necesarias para utilizar estas funciones, nos encontramos con lo siguiente:

 

 

 

 Resulta que si que aparecía en «ntddk.h»! y el nombre era bastante descriptivo. Despues de hacer algunos cutre-programas nos dimos cuenta de que en realidad el thread si que se listaba… ¿para qué se usaba este item entonces?, googleando un poco encontramos un comentario en rootkit.com, vaya parece que no eramos los primeros que nos parabamos a pensar en esto :-).

Finalmente descubrimos que este item aparentemente es utilizado para evitar que el debugger reciba eventos de debug del thread que manipula, y que el propio Sistema Operativo lo utiliza para evitar interferir en una posible depuración al obtener otro proceso información del los procesos activos en el sistema.

Conclusiones finales:

•  El DDK nos puede dar más de una sorpresa (no todo lo que está ahí definido está documentado 😀 )
•  Tal y como comentan en ese post en rootkit.com esta puede ser una técnica antidebug interesante 😉

 

Un saludo y hasta la próxima!