DanaBot reçoit des paquets « en plusieurs étapes » pour Noël

Pour Noël, DanaBot a reçu ce que seuls les pirates informatiques rêvent d’avoir : un nouveau botnet, livré en plusieurs petits paquets « en plusieurs fois », qui peuvent voyager dans le temps.

La récente campagne de malware DanaBot révèle des faits intéressants sur les mécanismes de diffusion de son cheval de Troie bancaire. Pour éviter d’être détectés aussi longtemps que possible pendant qu’ils conçoivent un nouveau botnet, les pirates répartissent la diffusion de leur malware en une série d’étapes. Et si le malware se trompe de cheminée à une étape donnée — par exemple en atterrissant dans le mauvais pays ou sur la plateforme d’analyse de malwares d’un chercheur en sécurité — les pirates gagnent alors du temps en mettant immédiatement le destinataire suspect sur leur liste noire. C’est une stratégie de Père Noël malveillant totalement éprouvée.

Plein de petits cadeaux

Répartir le processus de déploiement du malware en une série d’étapes spécifiques semble plus problématique que de diffuser la charge utile en un seul paquet. Mais cette stratégie vise à laisser le moins de traces possibles sur le disque ciblé, particulièrement dans les environnements en sandbox sur machine virtuelle. Les chercheurs, dont Avira, utilisent une variété de plateformes d’analyse automatisées sur les malwares afin de classer une première fois les échantillons entrants, un fait bien connu des cybercriminels. En entravant la capacité des chercheurs d’obtenir de nouveaux échantillons complets, les pirates espèrent maintenir des taux de détection aussi faibles que possible, pour les versions actuelles et futures de leurs créations.

Ce premier paquet est rien que pour vous

Le premier paquet est un e-mail de spear-phishing (une variante ciblée d’hameçonnage) contenant une pièce jointe qui consiste en un VBScript contenu dans une archive. Ces e-mails ont ciblé des particuliers en Pologne puis également en Italie, Allemagne, Autriche, France, Finlande et peut-être d’autres pays européens.

Outre un e-mail dans sa langue, chaque destinataire reçoit une variante distincte et déroutante de ce script, qui a pourtant la même fonctionnalité :

Le deuxième paquet provient du serveur C&C

Le lien vers la charge utile de la 2e étape, qui utilise également le langage de script Visual Basic, se fait en exécutant dynamiquement des lots d’ordres reçus depuis l’un des serveurs C&C (Command & Control). Les pirates semblent avoir déposé de nombreux noms de domaine peu coûteux à cette fin avec des domaines de premier niveau comme « .club » ou « .science » et ont choisi d’héberger l’infrastructure back-end sur des serveurs compromis et/ou achetés de manière frauduleuse.

La diffusion de cette 2e étape semble dépendre de plusieurs variables comme l’adresse IP du destinataire et une vérification de cette dernière par rapport à une liste noire d’adresses IP. Si le serveur C&C n’« aime » pas l’adresse IP émettrice, il diffuse alors un ordre d’exécution de mise en veille ou quelque chose du genre. La méthode wrapper d’appel traite correctement cela via la commande « On Error Resume Next ».

La provenance prime pour le paquet de la 3e étape

Si l’« appel » est fait depuis l’Allemagne, l’Autriche ou l’Italie, la charge utile de la 3e étape est également envoyée :

L’exécution de cette charge utile tire parti d’une méthode de contournement du contrôle du compte utilisateur en trafiquant le registre Windows et en lançant un processus de Haut niveau d’intégrité : eventvwr.exe (qui à son tour essaie d’ouvrir evenvwr.msc en appelant la fonction ShellExecute).

Les opérations d’écriture de la base de registre ciblent la commande shell « Ouvrir » associée au type de fichier msc. Ils sont censés être ouverts par mmc.exe (Microsoft Management Console). Cependant, là, les pirates passent à rundll32.exe afin de charger et d’exécuter, à l’aide de privilèges élevés, la charge utile malveillante contenue dans le fichier dll droppé :

Premier fait intéressant sur le dll utilisé dans le composant de la 3e étape : la fonction f1 exécutée par rundll32.exe est absente de la structure du répertoire des exports PE :

Cela est corrigé plus tard au moment de l’exécution dans la routine DllMain, afin d’être détecté par le processus rundll lors de l’appel GetProcAddress :

En outre, DllMain est également responsable du déchiffrement des chaînes chiffrées, du chargement dynamique des DLL requis et de la création d’un tableau d’import personnalisé dans la section « .bss » :

Ça part à l’Est

Pour commencer, f1 analyse la syntaxe de la ligne de commande et supprime un fichier spécifique, qui peut être transféré comme argument facultatif : rundll32.exe [chemin vers le dll], f1 [chemin vers le fichier].

Cela redirige vers un composant hérité, un dropper PE lié à une vieille campagne de malware, qui ciblait soi-disant l’Ukraine. Si l’on regarde le composant correspondant de la 1re étape utilisé alors (un dropper JS), on s’aperçoit qu’il n’était conçu que pour fonctionner si le mois en cours est le mois de septembre. Cette étrangeté signifie qu’il n’infectera pas les autres systèmes à l’heure actuelle. Il semblerait donc que les cybercriminels aient expérimenté avec cette méthode de diffusion et qu’ils l’aient abandonnée.

L’étape suivante consiste à faire une empreinte du système en obtenant des informations temporelles associées au Windows shell (explorer.exe) et à faire des requêtes sur plusieurs valeurs du registre sous HKLM\HARDWARE\DESCRIPTION et HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion :
– HKLM\HARDWARE\DESCRIPTION\CentralProcessor\0\Identifier
– HKLM\HARDWARE\DESCRIPTION\CentralProcessor\0\ProcessorNameString
– HKLM\HARDWARE\DESCRIPTION\System\Identifier
– HKLM\HARDWARE\DESCRIPTION\System\SystemBiosDate
– HKLM\HARDWARE\DESCRIPTION\System\VideoBiosVersion
– HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId
– HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
Toutes ces informations sont concaténées — les chaînes de caractères sont reliées de bout en bout — et une série de 3 hachages MD5 est calculée avec l’API CryptHashData. Le premier hachage est calculé d’après la chaîne concaténée d’origine, tandis que les autres sont les hachages MD5 correspondant au précédent. Ceux-ci sont utilisés dans le cadre d’un protocole personnalisé pour communiquer avec le serveur C&C.

433 semble être le port préféré

Autre aspect intéressant sur la communication avec l’infrastructure C&C : les tentatives de connexion sont faites vers des adresses IP aléatoires sur le port 443. Ce port est régulièrement utilisé par HTTP sur TLS (HTTPS), mais ici il s’agit d’un protocole de communication spécial. Ils utilisent probablement ce port car il n’est pas bloqué par la majorité des règles de connexion sortantes des pare-feux.

Lorsque l’on sait qu’un plugin Remote Desktop Protocol (RDP) a été ajouté à DanaBot en septembre 2018 et que tous les hôtes ayant pu être contactés semblent être des hôtes Windows dotés d’un port RDP ouvert, il semblerait fortement qu’un botnet en peer-to-peer soit en train de se former. Au lieu des ensembles de serveurs C&C traditionnels, la charge utile principale et ses plugins sont livrés à partir d’autres machines infectées, qui ne se trouvent pas derrière un routeur/pare-feu NAT.

Les pirates peuvent voyager dans le temps

Et la cerise sur le gâteau concernant le mécanisme de diffusion : il peut éviter un déploiement de la charge utile lorsqu’il est exécuté dans un environnement en sandbox (comme une plateforme d’analyse de malware), en exploitant un composant responsable de la fonction d’automatisation et de suivi des comportements (voyage dans le temps).

Pour ce faire, il commence par injecter l’API « Send » de Winsock 2 :

La fonction « send » injectée restaure premièrement les octets d’origine non protégés puis appelle WSAIoctl avec un code de contrôle SIO_KEEPALIVE_VALS.

Après cela, le nouveau thread est créé et reçoit l’adresse du socket réseau comme paramètre. Ce thread essaiera de se mettre en veille pendant 20 secondes puis fermera le socket.

Pendant ce temps, le thread principal appelle la fonction « send » d’origine. Ayant anticipé que le back-end serait corrélé avec l’appel de mise en veille, le closesocket sera appelé plus tôt lorsqu’exécuté dans un environnement en sandbox, où la fonction d’accélération a lieu (c’est-à-dire, l’appel de mise en veille prend bien moins de temps). Résultat, le back-end sera notifié avec un segment TCP RST — et pourra également ajouter l’identifiant du matériel envoyé à une liste noire d’identifiants de matériels — le sandbox ne recevra donc plus les prochaines « mises à jour ».

Selon nos conclusions, les pirates derrière DanaBot conçoivent minutieusement leur infrastructure de diffusion, et se sont peut-être associés à des acteurs d’autres catégories de malwares. Avira détecte et bloque tous les composants faisant partie de cette structure de diffusion, sous les noms de détection listés dans la section IOC suivante :

ComposantSHA256Nom de la détection
VBS Downloader4a0e84e57709e85b019459daac005e343230

ed6b4b6aabeb910be2638c863bd8

VBS/Dldr.Agent
Dropper JS6b3102f414cb80197598ea82c2502b2eb8b08

a0c9ecf3226961fd7687cf50516

JS/Dldr.Agent
PE Downloader1cc53453be89506bfd42b4d94ccaae0b0e0595

e36fb6e223bdf08231d032a9de

TR/Dldr.Danabot
Dropper PE21b5e1330e5f768da01c235efbeacb284b0376

c9c7bd6d874f55550fc09ca31e

TR/Drop.Danabot
Module principal82edc6bc8f5e2a3cefc0d317350e10b884d0e40

ec8e3fd406ad750637e7344db

TR/Spy.Danabot

 

Cet article est également disponible en: AnglaisAllemandItalien