Le trojan Dyre dans le milieu bancaire défie les défenses traditionnelles

Le cheval de Troie Dyre (aka Dyreza, Dyranges), dans le milieu bancaire, constitue une menace constante et fondée dans le paysage de la cybercriminalité depuis que son existence a été rapportée pour la première fois en 2014. Et durant la majeure partie de l’année 2014, les auteurs de la menace ont semblé satisfaits de l’utiliser avec peu ou pas de changements dans les techniques de livraison.

Toutefois, fin 2014 et tout au long du mois de janvier 2015, les distributeurs du cheval de Troie bancaire Dyre ont fait évoluer de manière soudaine et rapide leur logiciel malveillant et son infrastructure. Ils ont modifié leurs TTP pour essayer d’améliorer les chances de livraison et d’installation du logiciel. Nous avons noté en particulier des changements constants dans les modèles de spam, la randomisation des URL, l’obfuscation JavaScript et des tentatives de contournement de l’analyse et du sandbox.

E-mails non sollicités

Comme Proofpoint et d’autres ont précédemment décrit les courriers, Dyre est distribué par l’intermédiaire de vastes campagnes quotidiennes d’e-mails non sollicités, donnant accès à des URL malveillantes, ainsi que via des pièces jointes exécutables zippées. La plupart de ces e-mails sont créés à l’aide de modèles de texte brut et ressemblent à s’y méprendre à un message spam typique.  Alors que certains signes de changement dans l’approche et l’infrastructure étaient visibles avant janvier, les modèles d’e-mails et logiciels malveillants demeuraient relativement inchangés.

Un exemple de mail spam typique, ci-dessous, en texte brut utilisé habituellement par Dyre
Cependant, plusieurs campagnes d’e-mails non sollicités observées ce mois-ci contenaient des e-mails élégants au format HTML, comme cet échantillon qui prétend être envoyé par une importante banque de détail basée au Royaume-Uni, et des échantillons utilisant comme appât d’autres sociétés de services financiers américaines bien connues.

En général, les cybercriminels continuent de faire appel à des appâts en lien avec un message, un document, un fax, une facture livrés ou avec un sujet bancaire. Les enregistrements de Proofpoint indiquent que ces appâts sont utilisés depuis que Dyre a été détecté pour la première fois durant l’été 2014, principalement sans doute parce que les agresseurs se sont aperçus en les testant qu’ils étaient efficaces.  Se sont ajoutés à cela quelques sujets plus opportuns, comme un e-mail relatif à l’IRS.

Randomisation d’URL

L’auteur du Dyre continue de faire évoluer son système de génération d’URL malveillantes.  Par le passé, une seule URL était utilisée depuis chaque domaine malveillant : par exemple, la campagne dont le sujet était Outlook le 12 janvier 2015 n’utilisait que le chemin d’URL « /outlook/settings.html » dans l’URL complète (c.-à-d., « hxxp://ferramentarighi[.]it/outlook/settings.html »). Ainsi, la détection et la création de signatures étaient relativement aisées grâce au chemin de l’URL : en effet, il était possible de créer des signatures individuelles pour des URL complètes telles que les suivantes :
hxxp://made-in-tunisia[.]net/ticket/fsb.html
hxxp://nhuavakhuontiensang[.]com/<bank_name>/transaction.php
hxxp://obralimpa[.]com/messagesbox/efax.php
hxxp://nexuschurch[.]org/messages/fax.php
hxxp://chippc[.]com/<bank_name>/doc.php
hxxp://www. saturncon[.]com/voicemail/listen.php
hxxp://netembilgisayar[.]com/document/faxmessage.php
hxxp://searchforamy[.]com/dropbox/doc.php
hxxp://easystoremakerprodemo[.]com/messages/get_message.php
hxxp://eastfallsopen[.]org/secure_documents/invoice1311_pdf.php
hxxp://santace[.]com/secure_download/invoice1311_pdf.php
hxxp://valeriacordero[.]com/documents/invoice0611_pdf.php
hxxp://sbsgroup[.]com/messages/fax.php
hxxp://www. thistledowncottage[.]com/dropbox/voicemail.php

En janvier, les auteurs du Dyre ont adapté leurs techniques et génèrent aujourd’hui des centaines d’URL par domaine.  Par exemple, plus de 400 URL malveillantes uniques ont été observées lors d’une seule campagne sur un seul domaine d’hébergement (hxxp://nellaway[.]com) le 23 janvier. Les URL étaient randomisées mais les sous-domaines incluaient le nom de la banque servant d’appât ainsi que des mots-clés tels que « sécurisé » et « paiement » au lieu des chaînes de caractères alphanumériques aléatoires qu’utilisateurs et signatures ont appris à reconnaître comme des preuves d’hameçonnage.  Comme cette pratique va sans conteste continuer d’évoluer, une manière plus efficace de bloquer les mauvais liens consiste désormais à bloquer le domaine lui-même.

Obfuscation du script et contournement du sandbox

En cliquant sur le lien dans le corps de l’e-mail, l’utilisateur accède à un premier site malveillant, puis du contenu JavaScript est chargé depuis deux domaines encore plus malveillants.  Tous les contenus JavaScript intégrés sont à présent obfusqués avec JJEncode. Celui-ci leur permet d’échapper à la détection par des technologies de type IDS et apparaît comme du charabia aux yeux d’un observateur moyen.

Après désobfuscation, le JavaScript effectue généralement un contrôle qui consiste à tenter d’empêcher une analyse automatique du logiciel malveillant grâce au sandboxing.  Nous avons observé l’utilisation de plusieurs techniques.  La première tente de déterminer, en détectant les mouvements d’une souris, si c’est un humain qui navigue sur le site.  Le code continue de s’exécuter et le logiciel malveillant n’est téléchargé que si des mouvements de souris sont détectés avec la fonction « document.onmousemove » de JavaScript, illustrée dans l’exemple ci-dessous :

Une autre technique de contournement consiste à calculer la taille de l’écran de l’utilisateur.  En théorie, cette technique permet au logiciel malveillant de détecter les machines virtuelles et les sandboxes dotés de petits écrans et d’interrompre son action.  Plus spécifiquement, ce code mesure la hauteur et la largeur de l’écran, ajoute les deux nombres l’un à l’autre et teste si le résultat est inférieur à 1000 (ce nombre varie).  Il s’agissait de la technique de contournement utilisée dans l’échantillon que nous avons analysé ; il n’a pas été fait usage de la détection de la souris mais cela a été rapporté.

Une autre technique récente inclut une minuterie régressive à 5 secondes.   Après le contrôle de la résolution d’écran, il se passe 5 secondes avant que le téléchargement commence : pendant ce temps, l’utilisateur peut cliquer manuellement sur le lien au bas de la page pour télécharger le logiciel malveillant.  Il n’est pas certain que l’objectif premier de la minuterie soit de contourner la détection par une analyse dans le sandbox, mais il est très probable que des situations surviennent dans lesquelles elle empêche l’intervention d’un outil d’analyse automatique.  Si ces contrôles sont effectués avec succès, le téléchargement commence.  En général, un Upatre zippé [lien] est téléchargé. Après exécution, il télécharge le Dyre le plus récent.

Randomisation binaire

Dans le cadre d’une autre technique introduite récemment et conçue pour empêcher une mise sur liste noire de fichiers basée sur le hachage, chaque fois que l’exécutable du logiciel malveillant est téléchargé, il s’agit d’un fichier exécutable unique.  En fait, les fichiers ont tous une taille identique et sont très semblables d’un point de vue binaire – les différences sont suffisamment grandes pour empêcher chaque nouveau fichier de générer un hachage correspondant à ceux des fichiers connus.  Pour déterminer comment les différences sont créées, nous avons comparé les fichiers téléchargés à quelques secondes l’un de l’autre depuis la même URL.  Seuls 10 octets divergeaient systématiquement dans ces fichiers, bien que toujours sur des offsets différents.

Échantillon 1 : <nom_service_bancaire>_document_pdf61311.exe
(Taille : 45 056 octets, MD5 : 925ddf26622fedeb8a50f7d021f40618)

Échantillon 2 : <nom_service_bancaire>_document_pdf81564.exe
(Taille : 45 056 octets, MD5 : 0c5265627df87616d82bb99fe68d5ae2)

Les différences entre les fichiers ont été identifiées au niveau des offsets suivants : 0x2D58, 0x2E50, 0x2FDF, 0x3216, 0x3DA2, 0x46CF, 0x495D, 0x4B10, 0x4C26, 0x 4FF8

Une analyse supplémentaire a montré que toutes les différences se situent à l’intérieur de la section de données de l’exécutable portable (une section appelée .neolit dans l’échantillon analysé). Lorsqu’on affiche le contenu de cette section, on s’aperçoit qu’elle est remplie de structures qui se répètent telles que 0xE9F7FAF4. Dans la capture d’écran ci-dessous, cette structure est interrompue par l’octet 0x92 au niveau de l’offset 0x2D58 (marqué en rouge).  Il s’agit de l’un des changements à 10 octets effectués durant le processus de randomisation.

Si l’on regarde plus attentivement dans le débogueur, on obtient la confirmation que les changements ont été introduits dans la section de données : aucun code valable n’est présent ici.  Nous en concluons qu’il est plus que probable que cette section (complète ou en partie) soit créée et remplie spécifiquement de manière à ne contenir aucune donnée utilisable et des modifications binaires peuvent être introduites sans affecter le fonctionnement du programme. Il est important de noter que cette logique de correctif continue d’évoluer et peut présenter des divergences en fonction des campagnes.

L’évolution soudaine et rapide du Dyre en ce qui concerne l’introduction de techniques de contournement souvent associées à des menaces plus sophistiquées et ciblées met en évidence l’un des défis essentiels du paysage cybercriminel actuel : un spectre de plus en plus vaste de logiciels malveillants et d’attaques tirent profit des techniques qui ont donné aux menaces les plus élaborées un niveau d’efficacité tel qu’elles peuvent contourner les systèmes de défense traditionnels fondés sur la signature et la réputation. Si l’e-mail reste le premier vecteur de menace pour les entreprises, l’évolution du Dyre démontre que celles-ci ne peuvent plus se contenter de faire la distinction entre les nuisances à grande échelle comme les spams et les menaces ciblées de volume moindre. Au lieu de cela, elles doivent s’adapter afin d’affronter un environnement dans lequel tous les e-mails non sollicités doivent être traités comme une menace potentielle susceptible d’utiliser des techniques de pointe.