A la hora de analizar malware, los analistas e investigadores nos encontramos con todo tipo de muestras. Como mencionamos anteriormente en este blog, muchas veces nos encontramos con binarios empaquetados cuya finalidad es dificultar su estudio. En esta oportunidad analizaremos una muestra que no solo esta empaquetada, sino que tiene otras características adicionales orientadas a dificultar su análisis y detección.

El binario estudiado en este caso, esta empaquetado con el popular empaquetador UPX, cosa que podemos ver fácilmente con el detector de packers ProtectionID:

Si queremos verificar esto, podemos mirar el Entry Point (EP) con un debugger:

Aquí podemos ver el clásico PUSHAD en el EP de un archivo empaquetado con UPX. Para desempaquetarlo podemos hacerlo a mano, utilizando un método llamado PUSHAD (no lo explicaremos en esta oportunidad pero si alguien quiere consultarlos, puede dejarnos un comentario), o el método mas sencillo, mediante el comando upx -d como vemos en el siguiente gráfico:

Vale destacar que este método no siempre funciona en versiones de UPX modificadas. Finalmente, con cualquiera de ambos métodos llegamos al Original Entry Point, mas conocido como OEP. Para este malware el mismo esta en la dirección 4012c2:

Ya con el programa desempaquetado, al ejecutarlo, una de las primeras llamadas a funciones interesantes que encontramos es GetUserDefaultUILanguage de la librería Kernel32.dll. Esta función sirve para identificar la configuración del lenguaje del teclado en el sistema operativo.

¿Por qué decimos que es una función interesante ? Porque serviría para restringir la infección del malware a determinados equipos con la finalidad de acotar su expansión geográfica. Este tipo de chequeos regionales podemos verlos en Swizzor, que utiliza la función GetSystemDefaultLangID para obtener el lenguaje del sistema. Luego lo compara con un valor hexadecimal para decidir si infecta o no el equipo. También observamos este tipo de acciones en Conficker, que utiliza la función GetKeyboardLayoutList, de la cual obtiene la distribución del teclado y a partir de ella chequea si se instala o no.

Siguiendo con el tema de protecciones anti-debugging, podemos ver que esta muestra posee protecciones contra máquinas virtuales y chequea si es ejecutado en alguno de los entornos virtuales mas conocidos como son VMware. VirtualBox, VirtualPC y QEMU. A continuación podemos ver dicha porción en el código:

Cómo vemos en la imagen de arriba, el código aparece completamente en amarillo, esto se debe a que al iniciar el programa, las direcciones de memoria donde están las instrucciones anti-virtuales se encontraban vacías. Esto nos indica que el código se descomprimió en ejecución. Para poder visualizar este código hay que ejecutarlo, sino solo veríamos estas secciones vacías. Aquí una imagen de como se veían estas mismas secciones antes de ejecutar el programa:

Para terminar con el análisis de las protecciones, esta muestra también chequea nombres y ID de procesos, en este caso como lo debuggeamos con el programa Immunity Debugger, el malware identifica el proceso Immunitydebugger.exe. Otra cosa interesante que hace es identificar si existe o no alguna solución antivirus instalada, en este caso, como tenemos instalado ESET Smart Security, lo detectará en la parte de código que vemos a continuación:

De todas las protecciones que detallamos en este post, la que mas nos perjudica a la hora de analizar malware es la protección anti-VM. Existen muchas formas de detectar que un archivo esta siendo debuggeado en un entorno virtual. Esto puede llegar a ser muy tedioso, ya que la mayoría de los análisis que se hacen son dentro de estos entornos virtualizados, para tratar de aislar así la infección y poder simular lo más posible el comportamiento del malware en un entorno "real". Por suerte existen varias formas de saltearse estas detecciones y lograr ejecutar el malware adentro de una maquina virtual, pero esto ya requiere mas conocimientos para poder identificar en que momento se realiza este chequeo. Una opción mas fácil y totalmente viable, aunque más costosa, seria poseer una maquina física específicamente dedicada para el análisis de malware ya que no recomendamos analizar muestras directamente en la computadora que se utiliza a diario.

Juan Esteban Forgia
Malware Analyst