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 lanzamos 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 nos detuvimos a observar de cerca una de las muestras de FriedEx y casi instantáneamente notamos la semejanza del código con Dridex. Intrigados por los hallazgos iniciales, profundizamos en las muestras de FriedEx, y descubrimos 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
En la Imagen 1 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).
Otra característica compartida es el orden de las funciones en los binarios, que ocurre cuando la misma base de código o biblioteca estática es utilizada en múltiples proyectos. Como podemos ver en la Imagen 2, mientras la muestra de FriedEx parece carecer de algunas de las funciones presentes en la muestra de Dridex y viceversa (lo que es causado por la omisión de funciones inutilizadas/sin referencia del compilador), el orden se mantiene.
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 adivinar, 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.
Como puedes ver en la Imagen 3, 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, hemos concluido que el camino S:\Work\_bin\ es único para los proyectos Dridex y FriedEx.
Marcas temporales
Hemos 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 descartamos 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.
En la Imagen 4, 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 5, 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.
Información del compilador
La información del compilador solo contribuye a reforzar la evidencia que hemos 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.
Aparte de las claras similitudes con Dridex, nos cruzamos con una variante de 64-bit de ransomware no reportada previamente. Como la versión común de 32-bit de ransomware puede apuntar tanto a sistemas x86 como x64, consideramos a esta variante como una algo curiosa.
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.
Fuente:https://www.welivesecurity.com/la-es/2018/01/30/friedex-ransomware-bitpaymer-trabajo-autores-dridex/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad