REVISTA .SEGURIDAD | 1 251 478, 1 251 477 | REVISTA BIMESTRAL

Análisis de un curioso packer de malware en .NET

Malware escondido en imágfenes con .Net

 

El análisis de malware involucra una gran cantidad de tecnologías. Dentro de las diferentes variantes de códigos maliciosos que se han visto últimamente, los cibercriminales comenzaron a aumentar el uso de amenazas desarrolladas en .NET. A continuación se presentará el análisis de algunas familias de malware que afectan en la región latinoamericana, además se compartirán algunas herramientas que se pueden utilizar para su estudio.

Al hablar acerca de esta tecnología es importante destacar que se trata de código intermedio ejecutado por el framework. Por lo tanto, al igual que otras tecnologías (como Java), a través del uso de diferentes herramientas es posible recuperar o recomponer gran parte de su código. De esta manera se logran simplificar las tareas de análisis estático para comprender sus acciones, aunque a veces puede haber un par de complicaciones.

Entre las herramientas existentes se utilizará dnSpy y un fork de otro proyecto conocido como ILSpy. Ambas herramientas permiten analizar y obtener el código fuente, incluso bajo determinadas capas de ofuscación.

El archivo a analizar corresponde a una variante de las familias de malware detectadas como MSIL/Injector.KYG o MSIL/Injector.LES que se propagó bajo el nombre ConsultoMultaOnline.exe a finales del mes de julio de 2015. La detección corresponde puntualmente al wrapper, que utiliza técnicas no tan comunes para esconder su payload pues lo oculta en la siguiente imagen:

 

Malware oculto

Imagen 1. Malware oculto

 

El proceso que ejecuta el wrapper es bastante lineal, ya que carga los recursos alojados dentro del ejecutable, decodifica el payload que se encuentra en la imagen y que a su vez está cifrado con AES (Advanced Encryption Standard) y luego invierte los bytes del arreglo (array). Todas las acciones se ejecutan en el cuerpo principal del programa (main):

 

Main()

Imagen 2. Main()

 

Observando el código de la captura anterior, hay dos métodos que se deberán analizar más a detalle para comprender realmente qué es lo que dicho código intentará hacer y cómo revertirlo. En primer lugar, se debe analizar BitmapToByte(), cuyo código es el siguiente:

 

BitmapToByte()

Imagen 3. BitmapToByte()

 

Esta función recibe la imagen presentada anteriormente y recorre cada uno de  sus pixeles  para extraer los canales RGBA (Red, Green, Blue, Alpha)  y concatenarlos en un array, hasta que la longitud del mismo sea igual a un valor predefinido en una variable global. Este paso, que es bastante extraño y particular, intenta evadir su detección.

Una vez descifrado el payload, se busca el EntryPoint del ejecutable y se invoca para su ejecución. En este punto es donde se logró comprender qué es lo que hace el wrapper y se pudo extraer el payload para analizarlo por separado sin la necesidad de ejecutar este malware en un sistema. Para tener éxito es necesario hacerlo manualmente, exportando los recursos con un script en Python.

Ese pequeño programa realizará el proceso inverso, descomponiendo la imagen en sus valores de RGBA y utilizando después la clave AES para decodificar el payload con PIL, un módulo de Python para el manejo de imágenes. Con un poco de ayuda (encontrada en StackOverflow sobre cómo manejar archivos BMP con RGBA utilizando esta librería) el código, un poco rudimentario, se ve así:

 

ImageDecoder.py

Imagen 4.  ImageDecoder.py

 

Ahora, sumando esto a algunas líneas que permitan decodificar algo cifrado con AES, se obtiene el payload al ejecutar las siguientes líneas de código:

 

ImageUnpacker.py

Imagen 5.  ImageUnpacker.py

 

Así se logró obtener el segundo ejecutable, que se trata de una variante de otro malware, detectado como MSIL/Injector.JEI. Sí, aunque sea difícil de creer, todavía no se llega al payload original sino que hay una segunda capa de protección.

Este segundo binario también se encuentra desarrollado en .NET, por lo que se puede abrir en dnSpy para inspeccionar un poco sus acciones:

 

Segundo payload

Imagen 6. Segundo payload

 

Una primera aproximación a la función Main() del segundo archivo permite identificar que realiza acciones similares al primero. Primero extrae el archivo MAIN alojado en los recursos del programa bajo el nombre STUB. Este último archivo también es detectado y corresponde con una variante de Win32/TrojanDownloader.Banload, utilizada para el robo de información bancaria.

En otras palabras, comprender cómo extraer los payloads más allá de las protecciones que utilicen los cibercriminales es un paso necesario para el estudio de cualquier familia de códigos maliciosos y que, con el pasar del tiempo, toma cada vez mayor relevancia.

Si quieres saber más consulta:

UNAM

[ CONTACTO ]

Se prohíbe la reproducción total o parcial
de los artículos sin la autorización por escrito de los autores

 

Hecho en México, Universidad Nacional Autónoma de México (UNAM) © Todos los derechos reservados 2017.