Malware en .NET: curiosidades, desafíos y técnicas para ocultar información

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone

Hace algunos días revisamos 4 herramientas para analizar malware en .NET, por lo que hoy vamos a compartir con ustedes el resultado del análisis de una variante de malware que usa una curiosa técnica para ocultar el payload y así intenta evadir su detección. El archivo que vamos a estudiar corresponde a una variante de las familias de malware detectadas por ESET comoMSIL/Injector.LES y se propagó bajo el nombre ConsultoMultaOnline.exe, principalmente enBrasil con el 72% de las detecciones.

El motivo por el cual compartimos con ustedes este análisis es que encontramos una curiosa manera en la que se oculta el payload dentro de una imagen. Las técnicas utilizadas muestran algunas de las artimañas que los atacantes intentan utilizar para evadir las protecciones de los sistemas, y de esta manera infectar a sus víctimas.

Estas son las detecciones de MSIL/Injector.LES dividas por países:

detecciones-msil-injector

Las técnicas que utiliza este malware para esconder su payload no son tan comunes; lo que más nos llamó la atención fue encontrarnos con la siguiente imagen:

Imagen Oculta

Para entender su importancia en el objetivo del malware, tendremos que analizar el ejecutable que la almacena dentro de sus recursos y cómo es que la utiliza. Para lograr este objetivo, utilizaremos diferentes herramientas para analizar malware en .NET de las referenciadas anteriormente. De esta manera, perderemos menos tiempo en entender su estructura y podremos ver su código. Al abrir la muestra con dnSpy y ver el método principal observamos lo siguiente:

Main ()

El proceso que ejecuta el wrapper es bastante lineal, ya que carga los recursos alojados dentro del ejecutable al crear una instancia de ResourceManager y decodifica el payload que se encuentra cifrado con AES (Advanced Encryption Standard). Todas estas acciones se ejecutan en 5 líneas de código y utilizando las librerías que provee .NET y ciertos métodos propios que analizaremos más adelante. Luego invertirá los bytes del array en el cual decodificó la imagen con la clave que extrajo de los recursos.

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

BitmapToByte

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

Una vez decodificado el payload, se busca el EntryPoint del ejecutable y se invoca para su ejecución. En este punto, que ya comprendimos qué es lo que hace el wrapper, podemos extraerel payload para analizarlo por separado, sin la necesidad de ejecutar este malware en un sistema. Para lograr este cometido, lo vamos a hacer a mano exportando los resources y con un script en Python.

Nuestro pequeño programa realizará el proceso inverso, descomponiendo la imagen en sus valores de RGBA, para luego utilizar la clave AES para decodificar el payload utilizando PIL. Esta es una librería de Python para el manejo de imágenes y con un poco de ayuda que encontramos en StackOverflow sobre cómo manejar archivos BMP con RGBA, llegamos a la siguiente instancia:

ImageDecoder

Ahora, si sumamos esto a algunas líneas que nos permitan decodificar algo cifrado con AES y sumamos todo, llegamos a obtener el payload ejecutando las siguientes líneas de código:

ImageUnpacker

Así logramos obtener el segundo ejecutable, que no es ni más ni menos que una variante de otro malware detectado por ESET como MSIL/Injector.JEI. Sí, aunque no lo crean, todavía no hemos llegado 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 lo podremos abrirlo también con dnSpy para inspeccionar un poco sus acciones:

Segundo payload

Una primera aproximación a la función Main() del segundo archivo nos permite identificar que realiza acciones similares al primero: extrae el archivo MAIN alojado en los resources 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. Ahora, sobre esta última familia de códigos maliciosos hemos hablado en más de una ocasión y sabemos que se observan mayormente en Brasil.

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, que con el pasar del tiempo toman cada vez mayor relevancia.

Fuente:http://www.welivesecurity.com/

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone
Tags: