04 septiembre 2012

A nadie se le escapa que el mundo del análisis de malware es un juego de apariencias, de técnicas de ocultación y de seguir pistas.

Hoy vamos a hablar de una técnica que sirve para ocultar evidencias ante un análisis estático de ejecutables.

Este tipo de análisis se basan en analizar un ejecutable y valorar en función de las funciones que son empleadas (hay funciones mas sospechosas que otras) sin ejecutar el binario con un debugger.

Por tanto, el objetivo es salir cuanto menos 'en la foto' y para ello vamos a hacer uso de la función GetProcAddress()

Esta función permite obtener la dirección de memoria de cualquier función disponible en una dll. ¿Y esto de que nos puede servir en este escenario? Lo vamos a ver con dos sencillos ejemplos.

Ejemplo 1: mini-dropper

Es un sencillo 'dropper' que se descarga un fichero empleando URLDownloadToFile() y luego lo ejecuta haciendo uso de WinExec(). Nada excesivamente emocionante, pero si efectivo

si compilamos este ejemplo usando Visual Studio:

>cl prueba.c Urlmon.lib

nos genera el ejecutable 'prueba.exe' que, si lo lanzamos, se descargará el fichero seleccionado y lo ejecutará.

Veamos este ejecutable bajo el microscopio de Peframe:


Vemos que las dos funciones que estamos empleando son bastante conocidas en el mundo del malware y son marcadas como 'suspicious'. Salimos en mitad de la foto, y sonriendo !

Si analizamos que DLLs son importadas empleando Dependency Walker:



Tenemos 'urlmon.dll' y 'KERNEL32.DLL'. También resulta sospechoso el uso de la dll 'urlmon.dll' y podría levantar sospechas durante un análisis

Ejemplo 2: mini-dropper 'stealth'


 

En este caso, la funcionalidad es exactamente la misma: descargar un binario y ejecutarlo, pero la salvedad es que no 'declaramos' nuestras intenciones llamando directamente a las funciones que necesitamos, en este caso, vamos a usar las funciones sospechosas 'al vuelo' llamando a LoadLibrary() y GetProcAddress() a quienes vamos a pedir que cargue las dlls que necesitamos y nos de las correspondientes direcciones de memoria. 

Compilamos el nuevo ejecutable:

 >cl pruebaget.c

Y lo volvemos a pasar bajo los ojos de Peframe:




En este caso, Peframe no encuentra nada sospechoso pese a que la funcionalidad del binario es exactamente la misma en los dos casos. ¡ Ya no salimos en la foto !

Adicionalmente como ventaja extra, tampoco aparece la DLL 'urlmon.dll' puesto que se carga al vuelo durante la ejecución del binario



En la próxima entrega veremos como lidiar con este tipo de ejecutables.

7 comments :

PolAsc dijo...

Que GRANDE eres Yago. Genial, estupendo, profundo y didáctico artículo!!! GRANDE!!! No creo que ahora mismo haya un profesional a esta altura en el escenario de este páis al menos. Colosal.

Yago Jesus dijo...

¡¡ Gracias !! Me alegra que lo hayas encontrado interesante. Siempre intentamos aportar nuestro pequeño granito de arena

Diego dijo...

¿Supongo que en la próxima entrega será sobre algo para "esconder" esas cadenas ("URLDownloadToFile()")?
Porque aunque no se vea que llames a esas funciones directamente si se hace una búsqueda y se encuentra la llamada a GetProcAdress() + esas cadenas la gracia se pierde.


Algunos antivirus hookean a nivel de kernel esta función sino recuerdo mal ¿verdad?


Un placer leerte, como siempre.


Saludos.

Yago Jesus dijo...

En realidad, tal y como está el binario ahora, una simple búsqueda por strings saca la URL. Pero el objetivo del post no era irnos a evasion de AVs o XOR de cadenas, etc.

La idea era presentar a GetProcAddress() como función sospechosa a tener en cuenta y sus motivos.

En el siguiente post, mi idea es 'debuggear' la aplicación y obtener las funciones a las que llama.

masticover dijo...

Awesome Yago! como siempre ;)

t31m0 dijo...

Sienpre buena info Yago .... XD

Hendrix dijo...

Si el AV hookea en la SSDT puedes saltarte el Hook y llamar a la función
adecuada correctamente sacando la dirección original de la función a
llamar sin sacarla de la SSDT, de este modo te evitas cualquier filtro
de AV en la SSDT.