La forma más sencilla de analizar un archivo malicioso consiste en ejecutarlo en un entorno controlado y observar los resultados. A tales efectos, la utilización de máquinas virtuales se hace vital, ya que permite la recuperación casi instantánea del estado inicial de la máquina. Por ello, en diversas ocasiones el malware incluye mecanismos para detectar si está siendo ejecutado en un entorno virtualizado, situación ante la cual modifica su camino de ejecución para esconder su verdadero comportamiento. Hoy analizaremos algunas de estas técnicas mediante un caso práctico.
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, en este blog ya hemos respondido a la pregunta “archivos CPL, ¿por qué no debo hacer clic en ellos?”. 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 y wine_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. En una próxima entrega les estaré mostrando otras técnicas anti-VM utilizadas por el malware, quizás no tan conocidas. ¡Será hasta entonces!
SHA-1 de la muestra analizada
1068ede1f3f9ed14b57cf1e69ea329d05312a00b - Notificacao-Infracao.cpl
