Conozca el malware AutoIT

Publicado en Seguridad, Servicios y Consultoría, por Juniper en 18/12/2016


En este post, Asher Langton, un especialista en malware del equipo Sky ATP (Advanced Threat Prevention o prevención avanzada de amenazas) de Juniper Networks, analiza un trecho del malware AutoIT. El AutoIT es un lenguaje y un interpretador de scripting usado principalmente para la gestión y la automación de tareas en Windows. Un malware escrito en AutoIT no es algo especialmente común, pero hubo recientemente un clon del Locky escrito en este lenguaje. Vamos a recurrir a tres diferentes capas de análisis, de manera a encontrar el payload malicioso en cada una de las técnicas de ataque usadas.
 

Capa 1
Esta muestra vino como un archivo WinRAR. Dentro de él, encontramos una diversidad de tipos de archivo.

 


La mayor parte de estos archivos se parece con archivos de imágenes y documentos comunes que compartimos todos los días, pero todos ellos, con excepción de los archivos dqu.exe, son archivos de texto simple. El archivo ejecutable es una copia del interpretador AutoIT, lo que se puede verificar buscando por su hash en VirusTotal:

 

 
En la pantalla de WinRAR que se ve arriba, se puede ver un comando de setup después que el archivo es desempaquetado:


Setup=dqu.exe tid.ivb


Como el dqu.exe es el interpretador de AutoIT, uno puede creer que el tid.ivb es el script de input. ¡Pero inicialmente este archivo está vacío!


Mirando más a fondo, notamos que esta es solo otra técnica utilizada para engañar la herramienta de análisis. El archivo contiene principalmente retornos de control (ASCII 0x0d) y líneas de feed (ASCII 0x0a), con el contenido real escondido dentro de un bloque:
 

 

Cuando analizamos el bloque de datos ofuscado, encontramos el script AutoIT:
 

 

Para facilitar el análisis, creamos un  script en Python, que nos permite renombrar las funciones y variables y así leer y remover más fácilmente algunas de las strings (secuencias de código) ofuscadas:
 

 

Al recorrer este código, vemos que el script es ejecutado sin un ícono de notificación, para evitar ser revelado. Él también duerme por 20 segundos para evadir a la detección del antivirus y, después, lee los datos de configuración de un archivo PDF falso:
 


La función (rebautizada) func_3 utiliza un nombre de directorio ('sqv') extraída del archivo PDF y comprueba que
1. el script está siendo ejecutado a partir del directorio AppDataRoamingsqv del usuario y
2. no existe una ventana abierta intitulada 'sqv'.


La última verificación fallará si el analista de malware esté ejecutando el script con el subdirectorio sqv abierto en Windows Explorer. Si cualquiera de estas condiciones fallar, el script va a finalizar todos los procesos en ejecución y forzará a un reinicio completo del sistema:



Una vez pasada esta etapa, el script continúa a leer datos del kcj.pdf:



En este punto, el $var_4 contiene una larga cadena hexadecimal extraída de kcj.pdf, y $ var_6 es una string de cinco caracteres generada aleatoriamente por func_1 (). En su forma original, este procedimiento era casi incomprensible:

 


El código desobscurecido es más fácil de entender:



Las entradas para esta función son la larga cadena hexadecimal citada arriba ($ var_10) y la string "897" ($ var_11). Tales variables, juntamente con la secuencia hexadecimal almacenada en $ var_12, son formateadas y usadas en una llamada de sistema del Windows:



Este uso del CallWindowProc es un trueque bien conocido para incorporar shellcode en scripts del Windows. La string $ var_12 representa código binario ejecutable, que podemos desarmar en el IDA Pro:
 

 

Este shellcode implementa la  RC4 stream cipher. Él toma $ var_11 como entrada y transforma la string larga $ var_10. Aquí está el código equivalente en Python:



Usando este script, podemos extraer el contenido descriptografado y… ¡es otro script AutoIT!
 

 

El nuevo script es grabado en el disco, todos los archivos en el directorio son definidos como 'ocultos' y el script es ejecutado.



Capa 2
El segundo script AutoIT usa técnicas de oscurecimiento adicionales, pero otra vez algunos cambios de nombre y simplificaciones hacen el código más legible.
 

 

La primera cosa a notar es que este script intenta leer un número de variables de configuración del PDF falso. Tales valores, si están presentes, se utilizan para modificar el comportamiento del script. La mayoría de estas opciones no es usada en esta instancia, pero una mirada al código nos muestra algunas de las funcionalidades disponibles, incluyendo la evasión del sandbox, la ejecución binaria y la capacidad de publicar contenido en la cuenta de Facebook de la víctima si la página web está abierta en un navegador:



En este caso, el script lee otra secuencia hexadecimal del archivo PDF, la descriptografa con el mismo trueque CallWindowProc/shellcode, graba el archivo en el disco y, enseguida, lo ejecuta. En vez de otro script AutoIT, la carga útil de esta vez es un archivo ejecutable portable (PE) estándar de Windows.

 

 


Capa 3
Afortunadamente, este ejecutable ha sido escrito en Visual Basic 5 y compilado para p-code, y existen herramientas comerciales para "descompilar" este tipo de ejecutable. Algunas de las funcionalidades son obvias, como esta rutina que roba contraseñas de cuentas, un aplicativo popular de mensajes instantáneas:



Además de una serie de otras funciones de robo de contraseñas, hay también una rutina llamada InjPE, que ejecuta un archivo de Windows (PE), inyectandolo en otro proceso. Pero ¿qué binarios serán inyectados? Podemos empezar con la sección de recursos de nuestro ejecutable.

 


El primer componente del recurso DVCLAL es una secuencia ASCII. En el Visual Basic descompilado, vemos que esta secuencia de caracteres es extraída y cada carácter es dislocado para arriba por 2:



Podemos decodificar la secuencia con una línea de Python:



El resultado es una URL, probablemente usada para filtrar los datos robados de la computadora de la víctima. Los otros dos componentes del recurso DVCLAL son archivos del Windows PE – WebBrowserPassView  e MailPassView –, utilitarios que exploran una computadora para buscar contraseñas "perdidas”. Ningún es un malware, estrictamente hablando, pero ambos son comúnmente usados para fines maliciosos.


Visión general
Descubrimos lo que busca el payload en la computadora de destino: contraseñas. La Capa 1 es el script AutoIT entregado en un ejecutable de extracción automática. La Capa 2 es un script AutoIT criptografado y descriptografado en el destino con el trueque CallWindowProc/shellcode. La Capa 3 es lo ejecutable escrito en Visual Basic, que a su vez contiene dos ejecutables más, usados como utilitarios para barrer la computadora de la víctima antes de filtrar los datos para una URL que encontramos escondida en la sección de recursos. Considerando la configuración y las partes no utilizadas de los scripts AutoIT, parece que los autores del malware usaron algún tipo de conjunto de herramientas para envolver y ofuscar su malware. En combinación con el uso de archivos de datos/configuración separados, esto viabiliza fornecer ejecutables exclusivos para cada víctima.


Lea también
Utilizar ROP para detectar malware es perder tiempo
Conozca los malwares que escapan a la detección y al análisis
Juniper divulga el primero de una serie de reportes sobre las amenazas del momento en la red

 

 


Tags: Seguridad, Criptografía, Python, Malware, Antivirus, Windows, Script AutoIT, Sandbox, Payload


Tags: seguridad, criptografia, python, malware, antivirus, windows, script-autoit, sandbox, payload


Posts Relacionados