Diseccionando SmokeLoader (o Yulia y sus proposiciones indecentes) |
A mediados de agosto empecé a recibir correos de Yulia. Se le veía ansiosa por que echara un vistazo a su sweet ass:
No estaba muy seguro, pero después de recibir algunos correos más (el último el 10 de septiembre) me animé a abrirlo. Fue entonces cuando me di cuenta de que no era más que el comienzo de una nueva campaña de distribución de SmokeLoader. Me llevé una gran decepción, así que decidí analizar los binarios por despecho :p
Éstas son algunas de las cabeceras y el contenido del cuerpo de uno de los mensajes:
Date: Wed, 13 Aug 2014 12:55:56 -0400
From: "Yulia" <negligentjsd185@dialectologic.in>
Subject: My new photo
Hi it is Yulia fuck me ass at night. Look at my sweet ass on a photo I wait for you
No tengo intenciones de duplicar la información ya publicada sobre este loader, así que se puede consultar como referencia el post publicado en julio en StopMalvertising y el que escribió mi compañero Michael Sandee hace un par de años. Desde entonces, SmokeLoader, también conocido como Dofoil, ha modificado el cifrado que usa en las comunicaciones con el panel de control, ha añadido nuevos plugins, etc.
Después de ejecutar el binario se puede ver fácilmente que algo está pasando en nuestro ordenador, ya que si se analiza el tráfico de red se verán unas peticiones POST muy extrañas a sitios conocidos. Las URLs de estos sitios son extraídas del registro de Windows, abriendo la clave “Software\Microsoft\Windows\CurrentVersion\Uninstall” y recolectando el contenido de los valores "HelpLink" y "URLInfoAbout" de los programas instalados.
Realmente, lo primero que se ve es una petición GET a http://www.msn.com/, después, un número "aleatorio" de peticiones POST a las URLs mencionadas anteriormente, la comunicación con el panel de control, y, finalmente, un número diferente de peticiones POST a las URLs recolectadas. Se supone que esto es un intento de ocultar la comunicación real con el panel de control, pero creo que lanzar peticiones POST con datos cifrados no es la mejor opción...
Puede ser que al ejecutar el binario no veas este patrón en el tráfico de red. En ese caso seguramente hayas sido detectado por nuestro amigo ;) Y es que el binario incluye una función anti-análisis que termina en un bucle infinito si no eres capaz de superar todas las comprobaciones.
SmokeLoader realiza las siguientes comprobaciones (algunas de ellas se mencionan aquí):
- Comprueba si el nombre del módulo contiene la palabra “sample”.
- Comprueba si el número de serie del volumen C: es 0xCD1A40 (ThreatExpert) ó 0x70144646 (Malwr).
- Comprueba si el módulo “sbiedll” (Sandboxie) y “dbghelp” se han cargado.
- Comprueba la clave del registro System\CurrentControlSet\Services\Disk\Enum, buscando las siguientes palabras:
- qemu
- virtual
- vmware
- xen
- Comprueba si AutoItv3, CCleaner y WIC están instalados en el sistema, mirando también en el registro (Software\Microsoft\Windows\CurrentVersion\Uninstall). Parece ser que esto es una técnica para detectar Joe Sandbox.
Para saber si el malware se está ejecutando en un sistema de 64 bits se comprueba el registro de segmento GS:
mov ax, gs
test ax, ax
jz short loc_2934D0
inc ds:is64Bits
Dependiendo del resultado de esta comprobación SmokeLoader usará una técnica diferente para inyectarse en el explorer.exe y crear un nuevo proceso svchost.exe. Las dos formas de inyectarse están bien explicadas en este post de AVG, donde se habla sobre una muestra de ZeuS (en uno de los casos se hace uso de las funciones FindWindow, GetWindowLongA y SetWindowLongA). Parece que esta parte del código también se ha copiado de otros troyanos...
Después de estos primeros pasos, el malware se inicializa, configurando el User-Agent (por defecto, Mozilla/4.0), realizando la petición GET a MSN, creando el botid, el mutex, etc. Es entonces cuando empieza la diversión, mandando las peticiones POST para despistar y comunicándose con el panel de control finalmente.
Las URLs del panel de control están "hardcodeadas" en el binario, usando operaciones XOR para ocultarlas. Existen al menos dos bloques de URLs con el siguiente formato cada una:
[CLAVE_XOR][BYTE2][BYTE3][BYTE3][TAMAÑO][DATOS]
El primer bloque podría ser la URL principal y el segundo la URL de backup, pero en las muestras que he analizado ambos bloques contenían la misma URL. Cada 10 minutos SmokeLoader envía una petición POST al panel de control para comprobar si existen nuevas instrucciones que ejecutar. Esta petición tiene el siguiente formato:
cmd=getload&login=$BOTID&sel=jopa1&ver=5.1&bits=0&admin=1&hash=&r=$GARBAGE
- cmd: Comando enviado al panel.
- login: Botid con formato %08X%08X%08X%08X%08X.
- sel: Identificador del comprador. Está "hardcodeado" e identifica el usuario relacionado con la campaña de distribución.
- ver: Versión del sistema operativo.
- bits: Indica si el sistema operativo es de 64 bits o no.
- admin: Indica si el malware se está ejecutando con privilegios de Administrador o no.
- hash: Hash del binario en disco (en el caso de que se trate de una versión persistente de SmokeLoader).
- r: Datos de relleno. Este es el único parámetro que se envía en las peticiones POST falsas mencionadas anteriormente.
Estos parámetros, contenidos en el cuerpo de la petición POST, están cifrados con una modificación del algoritmo RC4, obteniendo un bloque como éste:
[TAMAÑO][CLAVE][PARAMETROS_CIFRADOS]
La respuesta a esta petición contiene un código 404, pero se trata de una respuesta correcta, incluyendo un bloque de datos interesante. Estos datos están divididos a su vez en un primer bloque de dígitos y un segundo bloque de contenido cifrado. El bloque de dígitos se puede descifrar fácilmente agrupando éstos de tres en tres y convirtiendo cada grupo a su correspondiente byte (“214”=0xD6). El primer byte resultante es la clave XOR usada para decodificar los demás.
Después de decodificar la respuesta completa se obtiene algo parecido a esto:
Smk0|:|socks_rules=127.0.0.1|:||:|hosts_rules=127.0.0.1 localhost|:||:|plugin_size=60500
Dependiendo del cuarto carácter de la respuesta (“0” en este caso) el loader realizará una acción u otra, como puede ser solicitar la descarga de binarios adicionales, actualizarse, desinstalarse del sistema, etc. El segundo bloque recibido contiene varios plugins cifrados con el mismo algoritmo RC4 modificado. Este bloque contiene una cabecera de 21 bytes más una cabecera adicional de otros 21 bytes por cada plugin. La cabecera de los plugins tiene el siguiente formato:
[TAMAÑO_PLUGIN(4)][TIPO_PLUGIN(1)][CLAVE_MRC4(16)]
Además de estar cifrados, los plugins están también comprimidos con UPX y todos ellos exportan la función "Work". Estos son los plugins que vi cuando analicé los binarios:
- AVInfo.dll: Es un plugin escrito en Delphi que usa el Windows Management Instrumentation (WMI) para obtener el antivirus y firewall instalados. Si el antivirus no se detecta de esta forma entonces se comprueban los procesos en ejecución buscando algunos antivirus conocidos:
- avp.exe (Kaspersky)
- ccsvchst.exe (Norton)
- dwservice.exe (DrWeb)
- dwengine.exe (DrWeb)
- avgnt.exe (Avira)
- avguard.exe (Avira)
- malwaredefender.exe (Malware Defender)
Después de obtener esta información, ésta se manda al panel de control añadiendo este formato a la petición original: “cmd=avinfo&login=%s&info=%s777%s”. Los nombres del antivirus y el firewall detectados se separan mediante la cadena “777”.
- FTPGrab.dll: Este módulo se inyecta en todos los procesos en ejecución, decodificando a su vez otro plugin llamado Grabber.dll. Este nuevo plugin "hookeará" las funciones “send” and “WSASend” para recolectar los usuarios y contraseñas de los protocolos FTP, POP3, SMTP e IMAP. Esta información se manda añadiendo los parámetros “cmd=ftpgrab&login=%s&grab=” a la petición original, además de las siguientes líneas:
- pop3://%s:%s@%s:%d
- ftp://%s:%s@%s:%d
- imap://%s:%s@%s:%d
- smtp://%s:%s@%s:%d
- shell.dll: Si la respuesta del servidor incluye el parámetro “shell_rules”, este plugin se encarga de ejecutar el comando especificado y devolver el resultado codificado con Base64. Los parámetros de la petición en este caso serían “cmd=getshell&login=%s&shell=$RESULT&run=ok”.
Todos estos plugins se almacenan cifrados en disco, usando otra vez el algoritmo RC4 modificado y el botid como clave. Además de éstos, existe otro plugin llamado Rootkit.dll que "hookea" las funciones ZwQuerySystemInformation, ZwQueryDirectoryFile y ZwEnumerateValueKey para ocultar los procesos, archivos/directorios y claves del registro relacionadas con el binario.
Éstas son las muestras que usé para escribir este post:
4fe5f69ca1ab813e829479004f262ccd
db3745ec149818567de5d2dfc3477d25
a4b7e8bf966ee5c6e2c731e9047968d4
e1ee0990ffd0da3df13c1206a6bb9a4b
86ca12376ab5e27534029d23b2952a28
Las URLs del panel de control relacionadas con los binarios son:
hxxp://joppwer.in/
hxxp://offnamerty.ru/
hxxp://jtp888888.ru/
