Dridex ha sido una pesadilla para los usuarios de computadoras, compañías e instituciones financieras desde hace ya varios años, tal es así que para muchos, se ha convertido en lo primero que viene a su mente cuando se habla de troyanos bancarios.
Una reciente investigación de ESET muestra que los autores del infame troyano bancario Dridex están también detrás de otra familia de malware de alto perfil – un ransomware sofisticado detectado por los productos de ESET como Win32/Filecoder.FriedEx y Win64/ Filecoder.FriedEx, también conocido como BitPaymer.
Dridex
El troyano bancario Dridex apareció por primera vez en 2014 como un bot relativamente simple inspirada en antiguos proyectos, pero rápidamente los autores convirtieron este bot en uno de los troyanos bancarios más sofisticados del mercado. El desarrollo parece ser estable, con nuevas versiones del bot lanzándose cada semana, con pausas ocasionales, e incluyendo pequeñas correcciones y actualizaciones. De vez en cuando, los autores introducen una actualización importante que agrega alguna funcionalidad crucial o grandes cambios. La última gran actualización de la versión 3 a la versión 4, lanzada a comienzos de 2017, ganó atención al adoptar la técnica de inyección de Atom Bombing, y más adelante ese mismo año al introducir un nuevo exploit MS Word zero-day, que ayudó a difundir el troyano entre millones de víctimas.
Al momento de escribirse este artículo, la versión más reciente de Dridex es la 4.80, e incluye soporte para webinjects en la versión 63 de Chrome. Dridex 4.80 fue lanzado el 14 de diciembre de 2017.
Nota: El pasado año se lanzó una herramienta que permite identificar hooks maliciosos en conocidos buscadores web. La herramienta está diseñada para ayudar a los afectados por un incidente a descubrir potenciales infecciones de troyanos bancarios, incluyendo Dridex.
FriedEx
Inicialmente denominado BitPaymer, basado en texto en su sitio web de demanda de rescate, este ransomware fue descubierto a comienzos de julio de 2017 por Michael Gillespie. En agosto volvió a ser centro de atención y ocupó los titulares tras infectar hospitales del Servicio Nacional de Salud (NHS, por sus siglas en inglés) en Escocia.
FriedEx se enfoca en objetivos y compañías de alto perfil más que en usuarios finales, y suele ser entregado a través de un ataque de fuerza bruta mediante Protocolo de Escritorio Remoto (RDP, por sus siglas en inglés). El ransomware cifra cada archivo con una clave RC4 generada aleatoriamente, que luego es cifrada utilizando la clave pública codificada 1024-bit RSA y guardada en el .readme_txt file correspondiente.
En diciembre de 2017 investigadores se detuvieron a observar de cerca una de las muestras de FriedEx y casi instantáneamente notaron la semejanza del código con Dridex. Intrigados por los hallazgos iniciales, profundizaron en las muestras de FriedEx, y descubrieron que éste utiliza las mismas técnicas que Dridex para ocultar la mayor cantidad de información posible acerca de su comportamiento.
¿Qué hace? Resuelve todas las llamadas hechas a la Interfaz de Programación de Aplicaciones (API, por sus siglas en inglés) del sistema en el momento a través de la función hash, almacena todas las cadenas de caracteres en un formato cifrado, busca claves de registro y valores mediante hash, etc. El binario resultante es de bajo perfil en términos de funciones estáticas, y es difícil saber qué está haciendo el malware sin un análisis más profundo.
Este análisis, rápido pero más a fondo, reveló un número de atributos adicionales que confirmaron nuestras sospechas iniciales – las dos familias de malware fueron creadas por los mismos desarrolladores.
Similitudes entre códigos
Comparación entre la función GetUserID presente en las muestras de Dridex y FriedEx
En la Imagen anterior podemos ver parte de una función utilizada para generar el ID de usuario que puede ser encontrado a lo largo de todos los binarios de Dridex (tanto loaders como módulos bot). Como podemos ver, la misma función específica de Dridex es también utilizada en los binarios de FriedEx. La función produce los mismos resultados – genera una cadena de diversos atributos de la máquina de la víctima que sirven como único identificador de la víctima en cuestión, ya sea en la botnet en el caso de Dridex, o del ransomware con FriedEx. De hecho, ¡las capturas servirían para un buen juego de “encuentre las diferencias”!
Este tipo de similitud con Dridex puede verse a lo largo de los binarios de FriedEx y sólo unas pocas funciones que corresponden principalmente a la funcionalidad específica de ransomware no se encuentran en la muestra de Dridex (por ejemplo, el loop de cifrado de archivos y la creación de archivos con mensajes de rescate).
Comparación del orden de las funciones en las muestras de Dridex y FriedEx. Las funciones que faltan en la otra muestra están resaltadas en el color correspondiente.
Nota: La función auto-generada nombra pares, basándose en direcciones de código (sub_CA5191 and sub_2A56A2, etc), que obviamente no coinciden, pero el código al que se refieren sí lo hace. También cabe mencionar que tanto Dridex como FriedEx utilizan el mismo paquete de malware.
Sin embargo, dado que el paquete es muy popular hoy en día (probablemente por la efectividad en evitar la detección y obstruir el análisis) y utilizado por otras familias conocidas, como QBot, Emotet o Ursnif, no consideramos realmente que eso solo sea evidencia suficiente.
Caminos PDB
Al construir un ejecutable de Windows, el enlazador puede incluir un camino PDB (Programa de Base de Datos) apuntando a un archivo que contiene símbolos de depuración que ayudan al desarrollador a quitar los fallos e identificar caídas. El archivo PDB actual no suele estar presente en el malware, porque es un archivo separado que no entra en distribución. Sin embargo, a veces sólo el camino, si está incluido, puede proveer información de valor, porque los archivos PDB están localizados en el mismo directorio que el ejecutable compilado por defecto y suele también tener el mismo nombre de base seguido por la extensión .pdb.
Como podemos imaginar, los caminos PDB no suelen estar incluidos en los binarios del malware, ya que los atacantes no quieren revelar información. Afortunadamente, algunas muestras de ambas familias sí incluyen caminos PDB.
Lista de todos los caminos PDB hallados en los proyectos Dridex y FriedEx.
Como puedes ver en la Imagen anterior, los binarios de ambos proyectos están siendo construidos en el mismo directorio, con su nombre distintivo. Basado en una búsqueda a lo largo de todos los metadatos de nuestra muestra de malware, se ha concluido que el camino S:\Work\_bin\ es único para los proyectos Dridex y FriedEx.
Marcas temporales
Se han encontrado diversos casos de Dridex y FriedEx con la misma fecha de compilación. Esto podría, por supuesto, ser una coincidencia, pero tras observar más de cerca, rápidamente se descarta la teoría de “sólo una coincidencia”.
Las compilaciones con la misma fecha no sólo tienen diferencias horarias de algunos minutos como máximo (lo que da a entender que quienes están detrás de Dridex probablemente compilen ambos proyectos concurrentemente), sino que las constantes generadas aleatoriamente también son idénticas en estas pruebas. Estas constantes cambian con cada compilación como una especie de polimorfismo, para hacer más difícil el análisis y evitar la detección.
Esto puede ser completamente aleatorio en cada compilación o estar basado en alguna variable, como la fecha actual.
Funciones GetAPIB y Hash en las muestras de Dridex con compilación de diferencia horaria de 3 días. La constante resaltada es diferente.
En la Imagen anterior, tenemos la comparación de dos muestras de loader de Dridex con una diferencia de tres días entre las marcas temporales de la compilación. Mientras los loaders son prácticamente idénticos, estando la única diferencia en los datos codificados, como las claves cifradas y los IP del C&C, las constantes son diferentes, y también lo son todos los hashes basados en ellos. Por otro lado, en la Imagen siguiente, podemos ver la comparación del loader de FriedEx y Dridex del mismo día (de hecho, con marcas temporales de sólo dos minutos de diferencia). Aquí, las constantes son las mismas, lo que significa que probablemente ambas fueron armadas durante la misma sesión de compilación.
Funciones GetAPIB y Hash en los binarios de Dridex y FriedEx compilados el mismo día. La constante resaltada es la misma en ambas muestras.
Información del compilador
La información del compilador solo contribuye a reforzar la evidencia que han hallado hasta el momento – tanto los binarios de Dridex como de FriedEx están compilados en Visual Studio 2015. Esto se confirmó tanto por la versión del enlazador encontrada en el PE Header como por la data del Rich Header.
Rich header data hallada en las muestras de Dridex y FriedEx
Conclusión
Con toda esta evidencia, aseguramos con confianza que FriedEx es sin duda el trabajo de los desarrolladores de Dridex. Este descubrimiento nos da una imagen más clara de las actividades del grupo – podemos ver que el grupo continúa activo y no sólo actualiza constantemente su troyano bancario para mantener su soporte de webinject para las últimas versiones de Chrome y para introducir nuevas funcionalidades como Atom Bombing, pero que también sigue las últimas “tendencias” del malware, creando su propio ransomware.
Solo queda adivinar lo que el futuro traerá, pero podemos estar seguros que el clan Dridex no se irá a ningún lado en el futuro cercano y que continuará innovando en sus viejos proyectos y, posiblemente, extienda su portfolio con nuevas piezas de vez en cuando.
Por un largo tiempo, se creyó que el grupo Dridex tenía sólo un truco bajo la manga y que mantenía el foco en su troyano bancario. Ahora, hemos descubierto que este no es el caso y que pueden adaptarse fácilmente a las nuevas tendencias y crear un tipo de malware distinto, capaz de competir con los más avanzados de su categoría.
IoCs
| Win32/Dridex.BE | C70BD77A5415B5DCF66B7095B22A0DEE2DDA95A0 |
| Win64/FriedEx.A | CF1038C9AED9239B6A54EFF17EB61CAB2EE12141 |
| Win32/FriedEx.A | 8AE1C1869C42DAA035032341804AEFC3E7F3CAF1 |
