Dridex a représenté un cauchemar pour les utilisateurs, les entreprises et les institutions financières depuis plusieurs années maintenant, à tel point que pour beaucoup, il est devenu la première chose qui vient à l'esprit quand on parle de chevaux de Troie bancaires.

Des recherches récentes d'ESET montrent que les auteurs du tristement célèbre cheval de Troie bancaire Dridex sont également à l'origine d'une autre famille de logiciels malveillants de haut niveau - un rançongiciel sophistiqué détecté par les produits ESET comme Win32/Filecoder.FriedEx et Win64/ Filecoder.FriedEx. FriedEx et également connu sous le nom de BitPaymer.

Dridex

Le cheval de Troie bancaire Dridex est apparu pour la première fois en 2014 comme un robot relativement simple inspiré de projets plus anciens, mais les auteurs ont rapidement transformé ce robot en un des chevaux de Troie bancaires les plus sophistiqués du marché. Le développement semble être régulier, avec de nouvelles versions du bot incluant des corrections mineures et des mises à jour hebdomadaires, avec des pauses occasionnelles. De temps en temps, les auteurs présentent une mise à jour majeure qui ajoute des fonctionnalités cruciales ou des changements plus importants. La dernière mise à jour majeure de la version 3 vers la version 4, publiée au début de l'année 2017, a attiré l'attention pour son adoption de la technique d'injection Atom Bombing et plus tard dans l'année a introduit un nouvel exploit jour-zéro MS Word, qui a aidé à propager le cheval de Troie à des millions de victimes.

Au moment d'écrire ces lignes, la version la plus récente de Dridex est 4.80 et inclut le support des webinjects dans la version 63 de Chrome. Dridex 4.80 est apparu le 14 décembre 2017.

Note : L'an dernier, nous avons lancé un outil qui aide à identifier les hameçons malveillants dans les navigateurs Web populaires. L'outil est conçu pour aider les intervenants en cas d'incident à découvrir les infections potentielles des chevaux de Troie bancaires, y compris Dridex.

FriedEx

Initialement baptisé BitPaymer, basé sur le texte de son site web de demande de rançon, ce rançongiciel a été découvert au début du mois de juillet 2017 par Michael Gillespie. En août, il est revenu sous les feux des projecteurs et a fait la une des journaux en infectant les hôpitaux du NHS en Écosse.

FriedEx met l'accent sur des cibles et des entreprises de plus haut niveau plutôt que sur les utilisateurs finaux habituels et est généralement livré via une attaque de force brute RDP. Le ransomware crypte chaque fichier avec une clé RC4 générée aléatoirement, qui est ensuite cryptée à l'aide de la clé publique RSA 1024 bits codée en dur et enregistrée dans le fichier .readme_txt correspondant.

En décembre 2017, nous avons regardé de plus près un des échantillons FriedEx et avons remarqué presque immédiatement la ressemblance du code avec celui de Dridex. Intrigués par les premières découvertes, nous avons décidé de creuser plus profondément dans les échantillons FriedEx et découvert que FriedEx utilise les mêmes techniques que Dridex pour cacher un maximum d'informations sur son comportement.

Il résout tous les appels de l'API système à la volée en les recherchant par hachage, stocke toutes les chaînes de caractères sous forme chiffrée, recherche les clés et les valeurs du registre par hachage, etc. Le binaire qui en résulte est très discret en termes de caractéristiques statiques et il est donc très difficile de dire ce que fait ce logiciel malveillant sans une analyse approfondie.

Nous avons donc décidé de poursuivre notre analyse et celle-ci a révélé un certain nombre d'attributs supplémentaires qui ont confirmé nos soupçons initiaux, soit que ces deux familles de logiciels malveillants ont été créées par les mêmes développeurs.

Similarités dans le code

Graphique 1 : Comparaison dans les fonctions de GetUserID présentées à la fois dans les échantillions de Dridex et de FriedEx

Graphique 1 : Comparaison dans les fonctions de GetUserID présentées à la fois dans les échantillions de Dridex et de FriedEx

Dans le graphique 1, nous pouvons voir une partie d'une fonction utilisée pour générer un UserID qui peut être trouvée à travers tous les binaires Dridex (chargements et modules bot). Comme nous pouvons le voir, la même fonction spécifique à Dridex est également utilisée dans les binaires FriedEx. La fonction produit les mêmes résultats - elle génère une chaîne à partir de plusieurs attributs de la machine de la victime qui sert d'identificateur unique de la victime donnée, soit dans le botnet dans le cas de Dridex, soit dans le rançongiciel avec FriedEx. En effet, les captures d'écran feraient un bon je de « trouver les différences »!

Ce type de ressemblances avec Dridex est présent dans tous les binaires FriedEx et seules quelques fonctions qui correspondent le plus souvent à la fonctionnalité de rançon spécifique ne se trouvent pas dans l'échantillon Dridex (c'est-à-dire la boucle de chiffrement de fichier et la création de fichiers de message de rançon).

Graphique 2 : Comparaison de l'ordre des fonctions dans les échantillons de Dridex et de FriedEx. Les fonctions manquantes dans l'autre échantillon sont mises en surbrillance dans la couleur correspondante.

Graphique 2 : Comparaison de l'ordre des fonctions dans les échantillons de Dridex et de FriedEx. Les fonctions manquantes dans l'autre échantillon sont mises en surbrillance dans la couleur correspondante.

Une autre caractéristique partagée est l'ordre des fonctions dans les binaires, ce qui se produit lorsque la même base de code ou bibliothèque statique est utilisée dans plusieurs projets. Comme nous pouvons l’observer dans le graphique 2, si l'échantillon FriedEx semble dénué de certaines des fonctions présentes dans l'échantillon Dridex et vice versa (ce qui est causé par le compilateur en omettant les fonctions non référencées/non utilisées), l'ordre demeure néamoins le même.

Remarque : Les paires de noms de fonction générées automatiquement, basées sur les adresses de code (sub_CA5191 and sub_2A56A2, etc), ne correspondent évidemment pas, mais le code auquel elles se réfèrent correspond.

Il convient également de mentionner que Dridex et FriedEx utilisent le même packer de logiciels malveillants. Cependant, étant donné que l'encaisseuse est très populaire de nos jours (probablement en raison de son efficacité à éviter la détection et l'analyse gênante) et utilisé par d'autres familles bien connues comme QBot, Emotet ou Ursnif, nous ne considérons pas que ceci constitue une preuve suffisante.

Chemin PDB

Lors de la construction d'un exécutable Windows, le linker peut inclure un chemin d'accès PDB (Program Database) pointant vers un fichier contenant des symboles de débogage qui aident le développeur à déboguer et à identifier les plantages. Le fichier PDB n'est presque jamais présent dans les programmes malveillants, car il s'agit d'un fichier séparé qui n'entre pas dans la distribution. Cependant, lorsque le chemin d'accès est inclus, il peut fournir des informations précieuses, car les fichiers PDB sont situés dans le même répertoire que l'exécutable compilé par défaut et ont généralement le même nom de base suivi de l'extension .pdb.

Comme on peut s’en douter, les chemins PDB ne sont pas souvent inclus dans les binaires de logiciels malveillants. En effet, les attaquants ne veulent pas divulguer d'informations. Heureusement, certains échantillons des deux familles comprennent des chemins PDB.

Graphique 3 : Liste de tous les chemins PDB des projets Dridex et FriedEx

Graphique 3 : Liste de tous les chemins PDB des projets Dridex et FriedEx

Comme vous pouvez le voir au graphique 3, les binaires des deux projets se retrouvent dans le même répertoire au nom distinct. En nous basant sur une recherche dans toutes nos métadonnées d'échantillons de logiciels malveillants, nous avons conclu que le chemin S:\Work\_bin\ est unique aux projets Dridex et FriedEx.

Horodatage

Nous avons trouvé plusieurs cas de Dridex et FriedEx avec la même date de compilation. Cela aurait bien sûr pu être une coïncidence, mais après un examen plus attentif, nous avons rapidement écarté la théorie du simple hasard.

Non seulement les compilations avec la même date présentent des décalages horaires de plusieurs minutes au maximum (ce qui implique que les gars de Dridex compilent probablement les deux projets en même temps), mais les constantes générées aléatoirement sont également identiques dans ces échantillons. Ces constantes sont modifiées à chaque compilation, ce qui s’apparente à une forme de polymorphisme qui rend l'analyse plus difficile et éviter la détection.

Cela pourrait être complètement aléatoire dans chaque compilation ou basé sur une variable comme la date du jour.

Graphique 4 : Fonction GetAPIByHash dans les échantillons Dridex à 3 jours d’écart. La constante en surbrillance est différente

Graphique 4 : Fonction GetAPIByHash dans les échantillons Dridex à 3 jours d’écart. La constante en surbrillance est différente

Le graphique 4 compare deux échantillons de chargement de Dridex à 3 jours d’écart dans les horodatages de compilation. Alors que les chargeurs sont presque identiques avec la seule différence étant leurs données codées en dur, telles que les clés de cryptage et les IP C&C, les constantes sont différentes, tout comme tous les hachages qui sont basés sur elles. D'autre part, dans la figure 5, nous pouvons voir la comparaison du chargeur FriedEx et Dridex à partir du même jour (en fait, avec des horodatages à deux minutes d'intervalle). Ici, les constantes sont les mêmes, ce qui signifie que les deux ont probablement été construites au cours de la même session de compilation.

Graphique 5 : Fonction GetAPIByHash dans les binaires Dridex et FriedEx compilée le même jour. La constante en surbrillance est identique dans les deux échantillons

Graphique 5 : Fonction GetAPIByHash dans les binaires Dridex et FriedEx compilée le même jour. La constante en surbrillance est identique dans les deux échantillons

Informations de compilation

Les informations du compilateur ne font que confirmer toutes les preuves que nous avons trouvées jusqu'à présent - les binaires de Dridex et FriedEx sont compilés dans Visual Studio 2015. La version de linker trouvée dans les données d’entête de type PE et Rich Header confirme ceci.

Graphique 6 : Données Rich Header trouvées dans les échantillons de Dridex et de FriedEx

Graphique 6 : Données Rich Header trouvées dans les échantillons de Dridex et de FriedEx

Au-delà des similitudes évidentes avec Dridex, nous avons découvert une variante 64 bits du rançongiciel qui n'avait pas été signalée auparavant. Comme la version 32 bits habituelle du rançongiciel peut cibler à la fois les systèmes x86 et x64, cette variante constitue une curiosité à nos yeux.

Conclusion

Avec toutes ces évidences, nous affirmons avec confiance que FriedEx est en effet l'œuvre des développeurs de Dridex. Cette découverte nous permet de dresser un meilleur portrait des activités du groupe. Nous pouvons en effet voir que le groupe continue d'être actif et met non seulement à jour régulièrement son cheval de Troie bancaire pour maintenir son support webinject pour les dernières versions de Chrome et pour introduire de nouvelles fonctionnalités comme Atom Bombing, mais suit également les dernières tendances en matière de logiciels malveillants, en créant son propre rançongiciel.

Nous ne pouvons savoir précisément ce que l'avenir nous réserve. Nous pouvons néanmoins être sûrs que le groupe Dridex n'ira nulle part, qu'il continuera d'innover dans son ancien projet et qu'il risque d’agrandir son portfolio avec un nouveau projet ici et là.

Pendant longtemps, on a cru que le groupe Dridex n’avait qu’un tour dans son sac et se concentrait sur son cheval de Troie bancaire. Nous avons constaté que ce n'est pas le cas et qu’il peut facilement s'adapter aux nouvelles tendances et créer un autre type de malware qui peut concurrencer les plus avancés dans sa catégorie.

Indicateurs de compromis (IoC)

Win32/Dridex.BE C70BD77A5415B5DCF66B7095B22A0DEE2DDA95A0
Win64/FriedEx.A CF1038C9AED9239B6A54EFF17EB61CAB2EE12141
Win32/FriedEx.A 8AE1C1869C42DAA035032341804AEFC3E7F3CAF1