Un caso práctico de inyección de código malicioso

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:

analisis stack Create File

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

uso de task scheduler por malware en olly

¿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:

tarea maliciosa en programador de tareas

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.

olly calculadora inyectada

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

Autor , ESET

  • Fernando.A

    Muy interesante, gracias por compartirlo.
    Parece ser que el propio malware esta utilizando los mismos mecanismos de defensa que usamos para proteger el codigo de las aplicaciones (cifrado de funciones, control antidebugger, IV´s basura…)
    Solo una duda, que proceso tiene asociado ademas del antidebug para que el propio malware pueda discriminar que “la calculadora no es interesante”?
    Lo habeis loalizado?.

    Saludos
    Fernando.

    • proli

      Hola Fernando, muy buena pregunta.En este caso, el código malicioso que está siendo inyectado en los procesos utiliza una llamada a GetModuleFileName para comprobar en qué proceso anfitrión está corriendo. Si obtiene como respuesta chrome.exe, firefox.exe, iexplore.exe, opera.exe, entre otros, entonces abrirá una conexión a través del uso de un socket de comunicación. Como se observa, este malware inyecta los navegadores más comunes. Por otro lado, si el proceso inyectado no está en la lista (como es el caso de la calculadora), entonces el malware permanece silencioso y no realiza nada.

      ¡Saludos!
      Matías.

Síguenos