DanaBot mis à jour avec une nouvelle communication C&C

Le cheval de Troie DanaBot, modulaire et en évolution rapide, a subi d'autres changements, avec la dernière version dotée d'un tout nouveau protocole de communication. Le protocole, présenté à DanaBot fin janvier 2019, ajoute plusieurs couches de cryptage à la communication C&C de DanaBot.

Outre les changements de communication, l'architecture et les identifiants de campagne (ID) de DanaBot ont également été modifiés.

L'évolution de DanaBot

Après avoir été découvert en mai 2018 dans le cadre de campagnes de spam ciblées en Australie, DanaBot a été très actif depuis, apparaissant dans des campagnes de spam en Pologne, Italie, Allemagne, Autriche et Ukraine, ainsi qu'aux États-Unis. Les campagnes européennes ont vu le cheval de Troie étendre ses capacités avec de nouveaux plugins et de nouvelles fonctionnalités d'envoi de publicités intempestives (spam).

Dans la télémétrie du 25 janvier 2019 d’ESET, nous avons remarqué des exécutables inhabituels liés à DanaBot. Après une inspection plus poussée, ces binaires se sont, en effet, révélés être des variantes de DanaBot, mais en utilisant un protocole de communication différent pour communiquer avec le serveur C&C. A partir du 26 janvier 2019, les opérateurs DanaBot ont cessé de construire des binaires avec l'ancien protocole.

Au moment de la rédaction du présent rapport, la nouvelle version est distribuée selon deux scénarios :

• En tant que « mises à jour » fournies aux victimes existantes de DanaBot;
• Comme malspam, en Pologne

Le nouveau protocole de communication

Dans le protocole de communication qui était utilisé avant le 25 janvier, les paquets n'étaient aucunement chiffrés, comme le montre la figure 1.

Figure 1 - Capture de paquets montrant l'ancien protocole avec les données en texte clair

Suite aux derniers changements, DanaBot utilise les algorithmes de chiffrement AES et RSA dans sa communication C&C. Le nouveau protocole de communication est compliqué, plusieurs couches de chiffrement étant utilisées. On l’observe dans la figure 2.

Figure 2 - Schéma du nouveau protocole de communication de DanaBot

Ces changements brisent les signatures réseau existantes et rendent plus difficile la rédaction de nouvelles règles pour les systèmes de détection et de prévention des intrusions. De plus, sans accès aux clés RSA correspondantes, il est impossible de décoder les paquets envoyés ou reçus; les fichiers PCAP des systèmes d'analyse en nuage (tels que ANY.RUN) deviennent donc inutilisables pour les chercheurs.

Figure 3 - Capture de paquets avec le nouveau protocole de communication en place

Chaque paquet envoyé par le client a un en-tête de 24 octets (0x18) :

Pour chaque paquet, l'en-tête est suivi par des données de paquet cryptées AES, puis une valeur de 4 octets indiquant la taille de remplissage AES, et enfin la clé AES avec chiffrement RSA. Chaque paquet est chiffré avec une clé AES différente.

Les réponses du serveur utilisent le même format. Contrairement aux versions précédentes, les données par paquets dans les réponses du serveur ne suivent aucune disposition spécifique (à quelques exceptions près).

Répartition des données par paquets

L'ancienne mise en page des données par paquets a été détaillée par Proofpoint en octobre 2018. Dans la dernière version de DanaBot, la disposition est légèrement modifiée, comme le montre la figure 4.

Figure 4 - Comparaison de la disposition des données par paquets dans la version précédente et la dernière version de DanaBot

Changements à l'architecture de DanaBot

Outre le changement de protocole de communication, DanaBot a également subi quelques changements d'architecture. Les versions précédentes de DanaBot incluaient un composant qui téléchargeait et exécutait le module principal. Le module principal a ensuite téléchargé et exécuté les plugins et les configurations.

La dernière version transfère ces deux responsabilités à un nouveau composant de chargeur, qui est utilisé pour télécharger tous les plugins avec le module principal. La persistance est obtenue en enregistrant le composant chargeur en tant que service.

Figure 5 - Comparaison entre l'architecture de la version précédente et de la dernière version de DanaBot

Commandes

Selon notre analyse, le composant chargeur utilise les commandes suivantes :

• 0x12C - Bonjour. Première commande envoyée par le client au serveur
• 0x12D – Télécharger le composant lanceur 32/64 bits
• 0x12E – Demander la liste des plugins et des fichiers de configuration
• 0x12F – Télécharger les fichiers de plugin et de configuration

Les plugins téléchargés et les fichiers de configuration sont chiffrés à l'aide d'une clé AES dérivée du Client ID. De plus, les plugins sont compressés au format ZIP en utilisant la compression LZMA, alors que les fichiers de configuration sont compressés en utilisant zlib.

Les commandes avec les numéros d'identification 0x130 - 0x134 sont envoyées par le module principal :

• 0x130 – Télécharger les informations collectées sur le serveur C&C (par exemple, capture d'écran de l'ordinateur d'une victime; informations système)
• 0x131 – Télécharger les informations collectées sur le serveur C&C (par exemple, liste des fichiers sur le disque dur de la victime)
• 0x132 –Demander d'autres commandes au serveur C&C ; il y a environ 30 commandes disponibles typiques des backdoors, incluant le lancement de plugins, la collecte d'informations système détaillées et la modification de fichiers sur le système client.
• 0x133 – Mettre à jour de la liste des serveurs C&C via le proxy Tor
• 0x134 – But exact inconnu; très probablement utilisé pour la communication entre les plugins et C&C

Changements dans les ID de campagne

Des recherches antérieures ont suggéré que DanaBot est distribué sous diverses identifiants « affiliées » ou « de campagne ».

Dans la version précédente de DanaBot, près de 20 ID de campagne différents étaient utilisés. Dans la dernière version, les ID de campagne ont légèrement changé. En date du 5 février 2019, nous voyons les pièces d'identité suivantes dans la nature :

• ID=2semble être une version de test, desservant un nombre limité de fichiers de configuration et aucun webinjects.
• ID=3 se répand activement, ciblant les utilisateurs en Pologne et en Italie, servant tous les fichiers de configuration et les webinjects pour les cibles polonaises et italiennes.
• ID=5 sert de fichier de configuration pour les cibles australiennes.
• ID=7 n'est diffusé qu'en Pologne, desservant des webinjects pour des cibles polonaises.
• ID=9semble être une autre version de test, avec une diffusion limitée et sans ciblage spécifique, desservant un nombre limité de fichiers de configuration et sans webinjects.

Conclusion

Les produits d’ESET détectent et bloquent tous les composants et plugins DanaBot sous les noms de détection énumérés dans la section IoCs.

Cette recherche a été réalisée par Kaspars Osis, Tomáš Procházka et Michal Kolář.

Indicateurs de compromission (IoCs)

Serveurs C&C utilisés par la nouvelle version de DanaBot

• 84.54.37[.]102
• 89.144.25[.]243
• 89.144.25[.]104
• 178.209.51[.]211
• 185.92.222[.]238
• 192.71.249[.]51

Webinject et serveurs de redirection

• 47.74.249[.]106
• 95.179.227[.]160
• 185.158.249[.]144

Exemples de hashes

Notez que puisque de nouvelles versions des composants de DanaBot sont publiées régulièrement, nous ne fournissons qu'un échantillon de hashes.

Plugins