Análisis de malware: Dridex

En esta entrada reflejo un estudio de Dridex que realice hace ya algun tiempo (2016) y que he querido compartir en el blog.

La muestra de malware analizada pertenece a la familia de los troyanos bancarios Dridex.
Desde su aparición en 2014, Dridex ha ido evolucionado y actualmente su función principal es la de robar datos bancarios mediante técnicas de tipo MITB (Man-in-the-browser), además de añadir los equipos infectados a una botnet.

Vectores de infección.

Dridex generalmente se distribuye a través de campañas masivas de spam:

El email recibido contiene un adjunto, generalmente un documento ofimático de Microsoft Office con macros (Word y Excel). La mayoría de los emails utilizan temas relacionados con facturas (invoices) pendientes de pago o similares para captar la atención de la víctima y conseguir que abran el documento adjunto.

Una vez que el documento es abierto por la víctima, se ejecuta el contenido de una macro que no es más que un script en VBS (Visual Basic Script). El código VBS suele estar ofuscado y protegido por contraseña para dificultar su análisis. Además, algunos de ellos utilizan técnicas anti sandboxing para evitar ser detectados. El VBS actúa como un dropper para descargar el malware Dridex.
Una vez descargado el malware, este se ejecuta en background y se instala en el equipo de la víctima.
El flujo normal de infección se puede resumir en las siguientes fases:

1. La víctima recibe un email con un adjunto malicioso.
2. La víctima abre el documento adjunto y ejecuta la macro.
3. La macro ejecuta el script VBS.
4. El VBS descarga e instala Dridex.

Análisis de comportamiento.

Dridex tiene una arquitectura modular, lo que le permite descargar e instalar nuevos módulos e incorporar nuevas mejoras y funcionalidades.
La muestra de malware analizada se corresponde con el modulo inicial (loader), el cual se encarga de descargar otros módulos tras la infección.
Algunos detalles del ejecutable malicioso son:

En la ilustración anterior se puede ver como las propiedades del ejecutable han sido falsificadas, por ejemplo, intentando hacer creer a la víctima que se trata de la librería QtCLucene.dll y que es propiedad de Nokia Corporation.

Las librerías importadas pueden verse en la siguiente imagen:

Y los símbolos importados son:

Además, también tiene información de debug activada:

Tras ejecutar el malware en la máquina virtual comprobamos que realiza las siguientes conexiones:

Los servidores C&C a los que intenta conectarse para actualizar y descargar los módulos de Dridex son:

Tras realizar varios intentos de conexión fallidos, se puede llegar a la conclusión de que dichos C&C ya han sido dados de baja o interceptados por las autoridades. En Feodotracker podemos confirmar que los C&C están offline:

 

Gracias a la información proporcionada por Feodotracker y Whois, podemos confirmar que la localización geográfica de estos C&C se encuentra ubicada en Rusia y Ucrania.

Analizando el comportamiento del malware con API Monitor, se consigue obtener datos relativos a la botnet a la que pertenece la muestra. Los datos extraídos son los siguientes:

En concreto, esta información es obtenida de la llamada a la función vsnprintf en SHLWAPI.dll:

También se localiza el instante en el que se realiza la conexión con las direcciones IP de los C&C:

Respecto a los cambios en el registro de Windows, los cambios más destacables son:

El malware crea claves en el registro relacionadas con información de debugging del mismo, tal y como se vio anteriormente.
Además, accede a varias claves del registro donde se almacena información de navegación de Internet Explorer. Al tratarse de un troyano bancario, posiblemente rastree estos ficheros en busca de entidades bancarias con el objetivo de interceptar y manipular las peticiones HTTP que la víctima intercambia con estas entidades.
También accede a ramas del registro relativas a operaciones criptográficas («HKLM\SYSTEM\RNG\Seed»), suponemos que para cifrar la información recolectada en el equipo de la víctima y enviarla a través de una conexión segura a sus C&C.

Toda esta información también queda reflejada en el log de Process Monitor. Algunas de las claves más relevantes acerca del funcionamiento del malware se encuentran en la siguiente tabla:

Como se ha podido ver en la tabla anterior, el malware tiene capacidad para obtener información del sistema, como el nombre, software instalado, versión del sistema operativo, configuración de Internet Explorer, información de debugging y criptográfica.

No se ha detectado ningun sistema de persistencia a través de claves de registro, inyecciones en procesos, ni duplicados del ejecutable en directorios de inicio del sistema. Probablemente, el malware se instalará en el arranque del sistema con la descarga y posterior ejecución del módulo principal.

Emulación de un servidor C&C.

Al estar los C&C offline, el malware no es capaz de establecer una conexión contra ellos.
Nos interesa ver que tipo de información transmite, para ello, se ha emulado un servidor HTTPS con la IP del primer C&C (91.239.232.145) y que escucha en el puerto 8448. La simulación se ha llevado a cabo con InetSim y VirtualBox.
Una vez configurados los servicios, el malware establece una conexión contra el falso servidor C&C, pero el payload que transmite está cifrado y no ha sido posible descifrarlo. Aun así, desconocemos la respuesta que tendría el servidor C&C original.

Como se puede ver en el log anterior de InetSim, está configurado para que el servidor C&C responda con un fichero con extensión «.tmp», en nuestra intención de simular la descarga de un módulo nuevo.

Las conexiones han sido monitorizadas con «Wireshark» y podemos ver las conexiones en la siguiente imagen:

Análisis dinámico con OllyDBG.

En el análisis dinámico del malware con OllyDBG no se ha encontrado información extra, tan solo destacar una referencia a la función PathIsRelativeA, la cual devuelve True o False si la ruta pasada por parámetro es relativa o absoluta, respectivamente. Llama la atención la ruta «D:\24Q1\BBcToC1»:

También existe una llamada a la función GetComputerNameA, la cual devuelve el nombre del equipo de la víctima como se ha descrito en el análisis de comportamiento anterior:

Análisis estático con IDA Pro.

Al igual que en el análisis con OllyDBG, destacamos las llamadas a las funciones PathIsRelativeA y a GetComputerNameA:

También encontramos un timestamp en la sección de datos, posiblemente la fecha de creación, el 27 de Agosto del 2015:

Índices de compromiso (IOCs).

Se han generado los siguientes IOCs para detectar la presencia del malware:

• Regla para Snort:

• Regla para Yara: