Hace ya varios meses presentamos en este blog una de las técnicas que el malware utiliza para persistir en un sistema infectado. Mediante la modificación de una llave del registro de Windows, agregando el valor AppInit_DLLs, puede lograrse la inyección de código malicioso en casi cualquier proceso. Luego, aprovechando el hecho de que hace unos días recibimos en nuestro Laboratorio de Investigación una muestra maliciosa que hace uso de esta técnica, hoy quiero mostrarles este ejemplo práctico del uso de AppInit_DLLs.
Como es de esperarse, si ejecutamos la muestra, a simple vista parecería que no ocurre nada en el sistema. Sin embargo, al realizar un debug podemos observar algunas cosas interesantes. Dejando de lado el hecho de que la muestra aparenta estar packeada, entre los pocos imports que vemos encontraremos GetProcAddress, con lo cual podemos colocar un breakpoint en aquellos lugares donde se referencia ese procedimiento. De este modo, veremos aquellas llamadas a la API que no figuran en los imports y que podrían decirnos algo acerca del funcionamiento de este ejecutable. Si por ejemplo nos detenemos y prestamos atención a CreateFile, observaremos lo siguiente:
En una de las llamadas a CreateFile vemos en el stack que se está tratando de crear un nuevo archivo ejecutable, llamado bsulbpk.exe. Si continuamos analizando el código que le sigue, veremos que se carga en memoria y se empiezan a ejecutar instrucciones del Programador de Tareas de Microsoft Windows (Task Scheduler).
¿Qué hace el malware con el Programador de Tareas? Simplemente crea una tarea que ejecute el archivo bsulbpk.exe en cada inicio del sistema. Esto podemos comprobarlo si vamos a la interfaz del Programador de Tareas y revisamos las tareas que han sido creadas:
Efectivamente hay una nueva tarea que ejecuta el nuevo archivo malicioso con un argumento especial; si no recibe este argumento, modifica su comportamiento. Pero entonces, ¿qué acciones realiza este nuevo ejecutable? Del análisis en Olly veremos que bsulbpk.exe se encarga de escribir un archivo DLL en disco y agregar un valor al registro. ¿Qué valor se agrega al registro? ¡Así es! Si están pensando en AppInit_DLLs, ¡adivinaron!
A partir de este momento, esta DLL maliciosa será cargada en memoria para cada proceso que utilice User32.dll. Por lo tanto, si realizamos el debug a cualquier ejecutable con interfaz gráfica, por ejemplo la calculadora de Windows, veremos no sólo que se carga la DLL maliciosa en memoria, sino que además el debugger se detiene en el código de esta DLL (en una instrucción de interrupción) antes de pasar al código de la calculadora.
En consecuencia, se está ejecutando código malicioso antes de que se cargue cada nuevo proceso en memoria. La DLL maliciosa realiza entonces un control, de tal modo de desaparecer de memoria si el proceso que está siendo debuggeado no es de su agrado para el robo de información. Así, con la calculadora de Windows, veremos que la DLL no permanece en memoria porque no hay nada atractivo para robar en ese proceso.
SHA-1 de la muestra analizada
ea59b0b9d176705fcc02a20b995d3383 - ctvqzym.exe
