Análisis del troyano Andromeda / Gamarue |
Hace unos días, tras leer este post sobre el fail de Joe Security con Andromeda, y encontrarme otra vez con varias muestras de la misma familia decidí que tenía que escribir algo sobre esto. Al menos para que me sirva de referencia y no tenga que empezar de cero la siguiente vez...Soy un poco Dory ;)
Cuando estuve trasteando con este malware hace unos meses me pareció bastante interesante por lo perrete que es a la hora de “debuguear” y analizar. Buscando un poco sobre el tema se pueden encontrar referencias con otro nombre, Gamarue, en este caso por parte de TrendMicro. Parece que está de moda renombrar el malware, y al final te encuentras con familias que tienen hasta tres nombres, como es el caso de Feodo / Cridex / Bugat. En fin, el caso es que entre la información que encontré están estos dos enlaces, con detalles técnicos muy útiles a la hora de meterse en faena:
Andromeda es un bot que últimamente he visto usarse simplemente como downloader de diferentes familias bancarias como son Ice-IX, Citadel o Sinowal / Torpig (si no tiene más de un nombre no mola). Pero como se ve en este post de Malware don't need Coffee, también se vende con diferentes plugins. Si el objetivo es recopilar credenciales, mediante los plugins Keylogger o Formgrabber más el Rootkit ("r.pack") es más que suficiente. De hecho, en uno de los análisis que hice se bajaba como “plugin” un archivo llamado "pony" que no era más que una muestra de Pony Loader / Fareit, del que ya hablé cuando se usó la temática del atentado de Boston para distribuir malware. Si el objetivo es la distribución y propagación de malware adicional entonces claramente la funcionalidad será la de downloader, aunque también se puede usar para ambas funciones a la vez.
En todos los casos en los que lo he visto venía empaquetado en un ZIP como adjunto de un correo electrónico. Este es un ejemplo de un correo que recibí a principios de junio:
El tráfico típico que puede identificar a Andromeda sería un HTTP POST de este tipo:
Se usa el User-Agent “Mozilla/4.0” y se envía una cadena codificada en Base64 que a su vez está cifrada con RC4. En el primer caso la clave es la que viene por defecto en muchas instalaciones, "d40e75961383124949436f37f45a8cb6". Y la información que se envía tiene el formato “id:%lu|bid:%lu|bv:%lu|sv:%lu|pa:%lu|la:%lu|ar:%lu”. Esto sería un ejemplo de los datos enviados:
id:753485172|bid:3|bv:518|sv:1281|pa:0|la:2196749529|ar:1
El significado de los parámetros es el siguiente:
- id: Bot ID
- bid: Build number
- bv: Bot version
- sv: Versión del Sistema Operativo
- pa: Si se trata de una plataforma x64
- la: IP (long)
- ar: Si se ejecuta con permisos de Administrador
La respuesta también se encuentra cifrada, pero en este caso se usa el Bot ID enviado en la petición como clave del RC4, y se añaden 4 bytes de CRC32 como cabecera. Dependiendo de la versión del troyano también se puede añadir una codificación Base64 antes de cifrar con RC4. El contenido depende de si el bot tiene tareas (tasks) asignadas o no, como puede ser la actualización del bot, instalación de un nuevo ejecutable/DLL, instalación de plugins, etc. Éste sería un ejemplo del contenido de la respuesta:
00000000 0f 00 00 00 02 01 00 00 00 68 74 74 70 3a 2f 2f |.........http://|
00000010 63 6c 6f 74 68 65 73 73 68 6f 70 75 70 70 79 2e |clothesshopuppy.|
00000020 63 6f 6d 2f 70 6c 75 67 2f 72 2e 70 61 63 6b 00 |com/plug/r.pack.|
00000030 02 02 00 00 00 68 74 74 70 3a 2f 2f 63 6c 6f 74 |.....http://clot|
00000040 68 65 73 73 68 6f 70 75 70 70 79 2e 63 6f 6d 2f |hesshopuppy.com/|
00000050 70 6c 75 67 2f 70 6f 6e 79 00 02 03 00 00 00 68 |plug/pony......h|
00000060 74 74 70 3a 2f 2f 63 6c 6f 74 68 65 73 73 68 6f |ttp://clothessho|
00000070 70 75 70 70 79 2e 63 6f 6d 2f 70 6c 75 67 2f 70 |puppy.com/plug/p|
00000080 63 62 00 01 14 00 00 00 68 74 74 70 3a 2f 2f 75 |cb......http://u|
00000090 74 61 68 62 6c 69 6e 64 73 2e 69 65 2f 63 69 74 |tahblinds.ie/cit|
000000a0 61 2e 65 78 65 00 00 0a |a.exe...|
Los primeros 4 bytes son el tiempo de envío de peticiones y después le sigue un array de las tareas a ejecutar, con un formato “Identificador de comando (1 byte) – Identificador de tarea (4 bytes) – Parámetro (X bytes)”. En este ejemplo se ve que el comando para instalar un plugin es 0x02 y para instalar un ejecutable adicional es 0x01, siendo el parámetro en los dos casos una URL.
Una vez que tenemos una muestra del binario de Andromeda ya sin packer/crypter, se puede usar IDA Pro junto con el script de IDAPython creado gracias al trabajo de 0xEBFE para descifrar y descomprimir los diferentes payloads. De esta forma se puede descubrir la clave RC4 utilizada para cifrar las comunicaciones y los posibles plugins.
Otra forma de sacar la clave es echando un vistazo a la memoria de los procesos creados por el troyano. Aunque la URL mostrada en la siguiente captura de pantalla no es la que usa el bot para comunicarse, la clave sí es válida:
Como curiosidad, en una de las muestras analizadas se podía ver un llamativo dominio del panel de control, “thisshitismoresafethanpentagonfuckyoufedsbecausethisisaf.com/image.php”:
Sin embargo, esto no era más que un mensaje para los amigos de Estados Unidos, ya que más tarde esta URL se modificaba mediante una operación XOR para obtener la verdadera URL del panel:
Otra de las cosas que no se mencionan en los análisis comentados anteriormente, es que Andromeda también crea hooks en las funciones NtQueryInformationProcess, NtOpenProcess y RtlRaiseException del proceso final creado (wuauclt.exe, en este caso):
El resumen de algunas de las técnicas usadas en el binario para dificultar el análisis son:
- Detección de breakpoints
- Uso de un manejador de excepciones específico para cargar el payload real.
- Comprobar si están cargadas ciertas DLLs como guard32.dll (Comodo Firewall) o sbiedll.dll (Sandboxie).
- Comprobar si algunos procesos prohibidos están en ejecución: vmwareuser.exe, vboxservice.exe, procmon.exe, wireshark.exe, etc.
- Comparación del identificador del disco principal ("system\currentcontrolset\services\disk\enum@0") con los strings “vmwa”, “vbox” y “qemu”.
- Comprobación de la velocidad de ejecución mediante la instrucción RDTSC.
Todas estas comprobaciones se pueden saltar si el checksum CRC32 del nombre del volumen de la unidad del sistema coincide con 0x20C7DD84. Se supone que ese sería el entorno de test del delincuente para ejecutar el binario y ver que todo funciona correctamente. Sin embargo, no es la única manera de ejecutar el payload real, como se sugiere en las actualizaciones del post de Joe Security (“The real payload is only shown if the volumn name of the system drive equals a specific checksum”), ya que pasando todos los checks anteriores el bot también se comunicaría con el panel de control correctamente. Es cierto que en algunas ocasiones esto no pasaba, pero creo que se puede achacar a la posible lentitud de la máquina virtual usada, no superando el check del RDTSC.
