Zloader : Retour Du Malware Bancaire Avec Une Nouvelle Variante

En décembre 2019, les chercheurs de Proofpoint ont observé des campagnes d'emailing distribuant largement une nouvelle version du malware bancaire ZLoader, qui semble être en cours de développement actif. Nous avons vu plus de 100 campagnes depuis le 1er janvier 2020 avec des destinataires aux États-Unis, au Canada, en Allemagne, en Pologne et en Australie. Les leurres par emails frauduleux portent sur des sujets variés, notamment des conseils pour se protéger des attaques liées à la COVID-19, des tests COVID-19 et des factures.

ZLoader, une variante du tristement célèbre malware bancaire Zeus, existe depuis 2006. Il s'agit d'un malware bancaire typique qui utilise des webinjects pour voler les identifiants et autres informations privées des utilisateurs des institutions financières ciblées. Le malware peut également voler les mots de passe et les cookies stockés dans les navigateurs web des victimes. Avec les informations volées en main, le malware peut utiliser le client VNC (Virtual Network Computing) qu'il télécharge pour permettre aux criminels de se connecter au système de la victime et d'effectuer des transactions financières illicites à partir du dispositif légitime de l'utilisateur bancaire. 

Près de deux ans après la dernière activité de ZLoader en 2018, nous avons commencé à observer des campagnes utilisant un nouveau malware bancaire qui présentait des fonctionnalités et un trafic réseau similaires à ceux du ZLoader 2016-2018 original. Cependant, au cours de notre analyse, nous avons remarqué qu'il manquait l'obscurcissement du code, le cryptage des chaînes et quelques autres fonctionnalités avancées du ZLoader original. Par conséquent, le nouveau malware ne semble pas être une continuation de la souche 2018, mais probablement une bifurcation d'une version antérieure.

Dans cet article, nous analysons la nouvelle version du malware et fournissons plusieurs exemples des campagnes de courrier électronique les plus intéressantes qui le diffusent. Nous continuerons à suivre ce nouveau malware comme une "variante de ZLoader" qui a fait son chemin dans la communauté au sens large.  

Contexte des nouvelles attaques de ZLoader

De juin 2016 à février 2018, un malware bancaire connu sous le nom de ZLoader (également connu sous le nom de DELoader ou Terdot) s'est répandu dans la nature. La lettre "Z" dans son nom a été donnée parce qu'il s'agit d'une variante du malware Zeus. La partie "loader" de son nom est due à sa caractéristique distinctive : il était distribué en tant que composant téléchargeur, qui téléchargeait et exécutait le composant principal du malware bancaire et d'autres modules à partir de son serveur de commande et de contrôle (C&C). 

À l'époque, de nombreux acteurs utilisaient le malware, mais le TA511 (Hancitor) était l'un des plus répandus. Vers novembre 2017, TA511 est passé de ZLoader à Panda Banker. D'autres acteurs de la menace ont commencé à suivre le mouvement et sont passés de ZLoader à d'autres logiciels malveillants. La dernière campagne d’emails que nous avons vue utilisant le ZLoader original remonte à février 2018. 

Analyse du malware bancaire ZLoader

Historique Des Versions 

Cette variante de ZLoader est en cours de développement. Nous avons assisté à la sortie de 25 versions depuis que la première (1.0.2.0) a été repérée dans la nature en décembre 2019. Comme le montre le tableau 1, environ 1 à 2 nouvelles versions ont été publiées chaque semaine : 

Tableau 1 : Versions de ZLoader en circulation

Au moment où nous écrivons ces lignes, la version 1.2.24.0 est la dernière en date et elle a été repérée dans la nature en mai 2020.

Anti-analyse De Zloader

ZLoader utilise plusieurs mécanismes d'anti-analyse pour rendre la détection et la rétro-ingénierie plus difficiles. Il s'agit entre autres de junk code, d'obfuscation constante, de hachage des fonctions de l'API Windows, de chaînes cryptées et de la liste noire C&C. Un exemple de code indésirable et d’obfuscation constante constant est illustré à la figure 1 : 

Figure 1 Exemple de code indésirable et d'obfuscation constante

Cette fonction renvoie la version du malware sous forme de DWORD (0x1021600) par XORing de deux constantes codées en dur (0x21F89813 et 0x20FA8E13). Le reste du code est superflu et sert à distraire l'analyste. 

Un autre mécanisme anti-analyse est le hachage des fonctions de l'API (Application Programming Interface) de Windows. Une implémentation Python de l'algorithme de hachage est disponible sur notre GitHub. Le tableau 2 présente quelques exemples de fonctions de l'API Windows et leurs valeurs de hachage :

Tableau 2 Exemples de fonctions de l'API Windows et leur valeur de hachage

Le prochain mécanisme anti-analyse est le cryptage des chaînes de caractères. La plupart des chaînes importantes de ZLoader sont cryptées à l'aide de XOR et d'une chaîne codée en dur (par exemple "7Gl5et#0GoTI5VV94"). Un exemple de script IDAPython pour décrypter les chaînes de l'échantillon que nous avons analysé est disponible sur notre GitHub. 

La dernière mesure anti-analyse que nous mentionnerons n'est pas intégrée dans le client malveillant mais est plutôt mise en œuvre dans le serveur C&C. Bien qu'elle varie en fonction de la campagne, nous avons remarqué une mise sur liste noire agressive des sandboxes et des systèmes d'analyse de malwares et un blocage important basé sur la géographie de l'adresse IP source de connexion. 

Configuration 

ZLoader poursuit la tradition de Zeus qui consiste à utiliser une structure de données appelée "BaseConfig" pour stocker sa configuration initiale. La figure 2 montre un exemple de la fonction de décryptage BaseConfig : 

Figure 2 Exemple d'une fonction de décryptage BaseConfig

Il utilise RC4 avec une clé codée en dur (par exemple "quxrfjxtmedqretawrxg"). Un exemple de configuration en texte clair est présenté à la figure 3 :

Figure 3 Exemple de texte en clair BaseConfig

Les données en texte clair sont interprétées comme une structure binaire et comprennent : 

• DWORD utilisé dans les communications C&C (par exemple 0x83) 
• Nom du botnet (par exemple "1") 
• Nom de la campagne (par exemple "07/04") 
• Jusqu'à 10 URL C&C (par exemple "hxxps://xyajbocpggsr\.site/wp-config.php" et "hxxps://ooygvpxrb\.pw/wp-config.php") 
• Clé RC4 utilisée dans les communications C&C (par exemple "41997b4a729e1a0175208305170752dd") 
• Timeouts et flags divers 

Command and Control 

ZLoader utilise des requêtes HTTP(S) POST pour command & control. Les données POST sont cryptées en deux couches. La première couche est RC4 et utilise la clé BaseConfig. La seconde couche est un cryptage basé sur XOR typique des variantes de Zeus, appelé "Visual Encrypt". 

Les données en texte clair sont structurées en utilisant une structure de données Zeus traditionnelle connue sous le nom de "BinStorage". BinStorage se compose d'un en-tête et d'un nombre variable d'éléments de données. L'en-tête a une taille de 48 octets et contient :

• Données aléatoires (20 octets) 
• Taille des éléments de données (DWORD) 
• Drapeaux (DWORD) 
• Nombre de données (DWORD) 
• Hachage MD5 des éléments de données (16 octets) 

Chaque élément de données commence par un en-tête de 16 octets contenant : 

• Id (DWORD) -- également connu sous le nom de "CFGID 
• Flags (DWORD) 
• Taille des données (compressées) (DWORD) -- ZLoader n'utilise pas la compression 
• Taille des données (non comprimées) (DWORD) 

Les données de réponse sont chiffrées de la même manière que les demandes. Une fois déchiffrées, elles utilisent aussi généralement la structure BinStorage. Nous examinerons trois demandes : la requête « hello » initiale, le téléchargement du composant principal et la mise à jour de la configuration. 

Les requêtes « hello » initiales contiennent un BinStorage avec les éléments de données du tableau 3 :

Tableau 3 BinStorage requête « Hello » initiale 

Une réponse affirmative du serveur C&C à la demande "hello" est un BinStorage vide.

Demande De Module 

Le composant "loader" de ZLoader télécharge le composant principal en utilisant un BinStorage décrit dans le tableau 4 

Tableau 4 Demande de module BinStorage

Le composant principal utilise également cette demande pour télécharger des modules supplémentaires pour divers éléments de fonctionnalité. Les modules comprennent OpenSSL, SQLite, Zlib, Certutil et VNC.

La réponse d'un module est chiffrée et formatée différemment des autres réponses. Elle est uniquement chiffrée en RC4 à l'aide de la clé BaseConfig. Une fois déchiffrée, elle contient un en-tête de 21 octets suivi d'un fichier PE. L'en-tête contient : 

• ID du module (DWORD) 
• Version du module (DWORD)  
• Inconnu (DWORD) 
• Longueur du module (DWORD) 
• Somme de contrôle du module CRC32 (DWORD) 
• Inconnu (BYTE)

Demande De Mise A Jour De La Configuration 

La dernière demande que nous examinerons est la demande de mise à jour de la configuration - généralement connue sous le nom de "DynamicConfig" dans le langage de Zeus. Elle utilise un BinStorage contenant les éléments du tableau 5 :

Tableau 5 Demande de mise à jour de la configuration

Les DynamicConfigs comprennent une variété de données, notamment :

• URL C&C supplémentaires 
• Commandes à exécuter  
• user_execute - télécharger et exécuter  
• bot_uninstall – auto désinstallation 
• user_cookies_get - voler les cookies des navigateurs web 
• user_cookies_remove - supprimer les cookies des navigateurs web 
• user_passwords_get - voler des mots de passe 
• user_files_get - voler des fichiers  
• user_url_block - bloquer l'accès à l'URL 
• user_url_unblock - débloquer l'accès à l'URL 
• Webinjects (voir figure 4) 
• Utilisé en conjonction avec le mécanisme person-in-the-browser de Zeus pour manipuler et voler les identifiants des utilisateurs et d'autres données des sites web financiers (généralement).

Figure 4 Exemple d'extrait d'un webinject analysé

Algorithme De Generation De Domaines 

À partir de la version 1.1.22.0 (mars 2020), un algorithme de génération de domaine de secours (DGA) a été ajouté. Si ZLoader ne parvient pas à se connecter aux C&C à partir de la BaseConfig ou de la DynamicConfig, il génère 32 domaines ".com" à essayer. La DGA utilise la clé RC4 de BaseConfig pour crypter la date du jour comme amorce de départ. Cette seed est utilisée avec un algorithme de hachage de base pour générer 20 lettres minuscules. Une implémentation Python de l'algorithme est disponible sur notre GitHub. Le tableau 6 montre les premiers domaines générés par la DGA pour l'échantillon analysé le 8 avril 2020 :

Table 6 Example DGA generated domains from April 8, 2020

Analyse De La Campagne Du Malware Bancaire Zloader

Depuis que nous avons commencé à observer la nouvelle variante en décembre 2019, elle est devenue populaire et répandue. Au moment où nous écrivons ces lignes, nous documentons au moins une campagne ZLoader par jour, menée par divers acteurs et visant principalement des organisations aux États-Unis, au Canada, en Allemagne, en Pologne et en Australie. Vous trouverez ci-dessous des exemples de campagnes qui ont diffusé ZLoader au cours des derniers mois.  

Le 6 décembre 2019, nous avons observé une campagne par courrier électronique qui prétendait livrer une facture (figure 5).

Figure 5 Exemple de courrier électronique utilisé lors de la campagne du 6 décembre 2019

Les messages contenaient des pièces jointes au format PDF (figure 6) qui utilisaient la marque de plusieurs sociétés de logiciels de facturation

Figure 6 Exemple de PDF utilisé dans la campagne du 6 décembre 2019

Les PDF contenaient des URL renvoyant à un document Microsoft Word (figure 7). Le document utilisait des macros pour télécharger et exécuter la version "1.0.2.0" de ZLoader. Chacun des téléchargements a été filtré par Keitaro TDS (Traffic Distribution System) pour empêcher l'analyse automatisée

Figure 7 Exemple de document utilisé lors de la campagne du 6 décembre 2019

Le 30 mars 2020, nous avons observé une campagne d’emails utilisant de multiples leurres (figure 8) qui "avertissent" l'utilisateur de diverses arnaques COVID-19.

Figure 8 Exemple de courrier électronique utilisé dans la campagne du 30 mars 2020

Ces emails contenaient des URL renvoyant à une page d'accueil qui présente un défi CAPTCHA (figure 9) avant de renvoyer au téléchargement d'un document Microsoft Word (figure 10). Le document contenait des macros qui, si elles étaient activées, permettraient de télécharger la version "1.1.21.0" de ZLoader.

Figure 9 Exemple de CAPTCHA utilisé dans la campagne du 30 mars 2020

Figure 10 Exemple de document utilisé dans la campagne du 30 mars 2020

Le 4 avril 2020, nous avons observé une campagne d’emails (figure 11) qui contenait un message sur un membre de la famille, un collègue ou un voisin ayant contracté la COVID-19, et qui aurait fourni des informations sur les endroits où se faire tester

Figure 11 Exemple d’email utilisé dans le cadre de la campagne du 4 avril 2020

Les emails contenaient des fichiers Excel protégés par un mot de passe (figure 12). Le fichier utilisait des macros Excel 4.0 pour télécharger et exécuter la version "1.1.22.0" de ZLoader

Figure 12 Exemple de tableur utilisé dans le cadre de la campagne du 4 avril 2020

Conclusion sur la dernière variante du malware bancaire ZLoader

Cet article a analysé la dernière variante du malware bancaire Zeus et certaines des campagnes que nous avons vues le propager. Il utilise les fonctionnalités typiques des malwares bancaires, comme les webinjects, le vol de mots de passe et de cookies, et l'accès à des dispositifs via VNC pour voler des identifiants, des informations personnelles et finalement de l'argent aux cibles. Le malware bancaire Zeus et ses descendants sont un élément de base dans le paysage de la cybercriminalité depuis 2006. De Zeus à Citadel, Ice IX, Murofet, Gameover, ZLoader, KINS, Flokibot, Chthonic, Panda Banker, et de nouveau à ZLoader.

Indicateurs De Compromission