Análisis de un malware que detecta el entorno virtual

El análisis del malware se recomienda hacerlo en entornos controlados.

Antes de continuar, entre otros muchos, aquí podéis profundizar en el tema:

http://underc0de.org/foro/tutoriales-y-manuales/analisis-de-malware-enfoque-y-caso-practico-seguridad-informatica/


Sigamos...no obstante lo dicho, la ejecución de un malware en una máquina virtual, no nos exime que las nuevas generaciones de aquéllos contengan código que permita detectar si se ejecutan en un contexto virtualizado y en consecuencia, ocultar su   su verdadero comportamiento, el caso práctico a continuación explora esta hipótesis.


Para comenzar con el análisis, tomaremos un ejecutable de nombre Notificacao-Infracao.cpl  (#). Si bien a simple vista este archivo puede no parecer ejecutable. No obstante, si intentamos ejecutar este archivo en nuestra máquina virtual, no observaremos ningún comportamiento malicioso. En otras palabras, del análisis dinámico de la amenaza no obtendremos nada útil, pero del análisis estático vemos algunas strings sospechosas, como dos URL de descarga de archivos ejecutables, entre otras cosas. Luego, podríamos pensar que la muestra probablemente esté dañada, pero hay una string que nos llama la atención: “vmware”. Por ello, abriremos la muestra con IDA Pro y buscaremos dónde se hace referencia a esa string. Obtenemos lo siguiente:



Como se ha resaltado en la imagen, no sólo encontramos una referencia a VMWare, sino también a Wine y Virtual PC. También observamos que esas strings son utilizadas por sub_404720, que se encarga de almacenarlas en algún sitio. Bajo esta premisa, primeramente se almacena la cadena “Native”, que indicaría la ausencia de virtualización. Luego, se comprueba la presencia de Wine dos líneas más abajo, en sub_4ABAE8. Si esta sub-rutina determina la existencia de una emulación bajo Wine, la cadena “Wine” es almacenada, remplazando a “Native”. Caso contrario, se comprueba la presencia de VMWare en sub_4AB9E8 y de Virtual PC en sub_4ABB2C.

En la siguiente imagen vemos el código de comprobación para Wine. No nos detendremos demasiado en esta parte, pero podemos observar que se carga ntdll.dll en memoria y se realizan llamadas a wine_get_version ywine_nt_to_unix_file_name. Dichas rutinas no forman parte de la API de Windows, pero sí están presentes en Wine.


Luego, viene la parte del código que nos interesa y aquella que está disparando la detección en nuestro caso: la de comprobación de VMWare. En este caso, los autores del malware han utilizado un mecanismo bastante conocido: solicitar la versión de VMWare mediante la comunicación con los puertos de E/S. Esto es posible dado que VMWare monitorea e intercepta el uso de la instrucción in, acción necesaria para poder garantizar la comunicación entre la máquina virtual y el host.

En particular, cuando se ejecuta la instrucción “in eax, dx” con el número mágico 0x564D5868 (o “VMXh” en ASCII) en EAX, a través del puerto 0x5668 (“VX”) especificado en DX, se obtiene una respuesta que depende de la operación especificada en ECX y se almacena en EBX. Puede que todo esto suene a trabalenguas, pero es más sencillo de lo que parece: si se llama a la instrucción in con los registros como se ha especificado y con el código de operación 0x0A en ECX, y se obtiene como resultado el número mágico en EBX, sabremos que la aplicación está corriendo en VMWare. Esto puede observarse en la siguiente imagen:



Ahora, si abrimos la muestra con OllyDbg, probablemente nunca llegaremos a ejecutar estas instrucciones, y el programa terminará su ejecución prematuramente, al igual que nos ocurría inicialmente. Para evitar esta situación, debemos recordar que un CPL es en realidad una DLL. Así, el código de comprobación que estamos buscando se encuentra en DllMain, rutina que se ejecuta al momento de cargar el CPL en memoria, luego de una llamada a LoadLibrary. Por lo tanto, para poder esquivar el mecanismo de detección en Olly, sólo basta con parchear el salto luego de la comparación con el número mágico.

Además, si lo que buscamos es que la muestra también se ejecute fuera del debugger, podemos editar manualmente el archivo binario, y cambiar el valor del número mágico en la comparación.
No nos detendremos a explicar el mecanismo utilizado para la detección de Virtual PC, pero pueden verlo en la siguiente imagen. Se ve la utilización de la instrucción vpcext, la cual no existe en una arquitectura x86 nativa, pero sí en Virtual PC. De hecho, Olly no es capaz de interpretarla.




Luego de parchear la detección, podemos ver que la aplicación maliciosa continúa corriendo y ejecuta su payload: descarga dos archivos ejecutables desde dos URL distintas y los levanta con ShellExecuteA.




Si bien los mecanismos utilizados no son demasiado difíciles de encontrar, especialmente considerando que las strings no se encuentran cifradas en esta muestra, la inclusión del código en DllMain podría jugarnos una mala pasada.


(#) El tema de los archivos cpl podéis mirar aquí:

http://underc0de.org/foro/tutoriales-y-manuales/archivos-cpl-metodo-para-propagar-malware/