Exécution, injection, infection, identification et… téléphone maison !

1. Introduction

Dès leur installation, les logiciels malveillants, ou malwaresanalysent et catégorisent le client nouvellement infecté. Cela permet, une fois ces informations transmises au serveur de commande et de contrôle, ou CnC server,d'opérer l'attaque prévue de manière plus ciblée. En effet, due à la grande disparité de systèmes ainsi que de versions, et il est dans en premier temps important de savoir à qui l'on se frotte.

Les premières phases sont très importantes pour le malware, car cela va déterminer le succès ou nom de l'infection. Cela signifie qu'une intégration propre et rapide dans le système est une priorité dans un premier temps. La collection d'informations sera aussi abordée à savoir comment réaliser un bon fingerprinting de la victime.

Emotet fait très bon usage de la cryptographie ainsi que des fonctions de hachage : en combinant le chiffrement symétrique et asymétrique pour l'ensemble de ses communications, il s'assure d'une confidentialité et d'une intégrité pour la transmission de données vers un serveur distant via un canal sécurisé.

La suite de l'article ne contiendra pas une analyse détaillée et en profondeur du malware, mais se concentrera sur le début de l'infection jusqu’au call home ou téléphone maison, c'est-à-dire la période entre son implémentation réussie dans le système jusqu'à la première communication du logiciel malveillant vers un serveur de commande et de contrôle.

2. Emotet

2.1 Présentation

Une nouvelle version d'Emotet est apparue de manière active dès le début de l'année. Distribué à grande échelle via notamment une vague de spam, le malwaresemble cibler les pays germanophones ainsi qu'une partie de l'Europe de l'Est.

Successeur dans la grande lignée des banking trojanetpassword stealer, son action principale est de voler des informations bancaires lors de la connexion du client à sa banque, ainsi que de dérober des mots de passe dans une moindre mesure.

L'échantillon utilisé pour mon analyse provient d'un faux e-mail de DHL contenant un lien censé rediriger l'utilisateur vers le suivi de sa livraison. À la place, l'utilisateur se voit proposer le téléchargement d'un fichier ZIP contenant une « facture » au format exécutable arborant l'extension exe, mais utilisant l'icône d'un fichier PDF.

La longueur de ce fichier exécutable est de soixante-dix caractères, et ce n'est pas juste pour faire joli. Ce procédé est même relativement malin, car la fin du nom ainsi que l'extension (exe) du fichier seront tronquées dans la plupart des modes d'affichage avec l'explorateur de fichiers, rendant plausible le fait de disposer d'une facture PDF si l'on se fie uniquement à l'icône du programme.

2.2 Packer & Loader

Emotet dispose de multiples mécanismes pour tenter de passer inaperçu, ce qui est aussi à double tranchant, car cela donne des pistes concernant la nature du programme. L'exécutable est obfusqué à l'aide d'un packer, ce qui rend son code illisible de manière statique.

De même que les strings ou la table des imports, rien n'est lisible en clair dans l'état initial et tout sera chargé et déobfusqué de manière dynamique dans la mémoire. Bien que cela lui permette de passer les tests de signature de la plupart des antivirus, cela le rend aussi suspect par la même occasion.

Au démarrage du malware, le packer charge dans un premier temps les librairies (dll) dont il a besoin et copie son exécutable depuis le répertoire ou il s'est exécuté à destination de %LocalAppData%. Cela va, en addition d'une clé de registre, garantir la persistance du malware après le redémarrage de la machine infectée.

L'ajout dans le registre est inscrit dans la ruche, ou hiveHKEY_CURRENT_USER, en y ajoutant une valeur contenant le nom de l'exécutable et son emplacement sur le disque dans la clé :

Après avoir assuré sa pérennité, le packer cherche à savoir s'il s'exécute au sein d'une machine virtuelle VirtualBox ou VMWare, si tel est le cas, le programme se termine. Ce mécanisme essaie d'éviter au malware d'être étudié ou son exécution dans un environnement d'analyse automatisé reposant sur des machines virtuelles.

Si l'environnement répond à ses attentes, la dernière étape consiste en l'exécution d'un nouveau processus avec comme état de création CREATE_SUSPENDED. Cet état du cycle de vie d'un processus permet de mettre en pause le thread principal du nouveau processus lors de sa création jusqu'à ce que la combinaison de méthodes SetThreadContext et ResumeThread soit appelée.

Cette technique permet d'injecter du code dans le processus nouvellement créé, avec la combinaison de VirtualAlloc et de WriteProcessMemory. Cela va donc démarrer une nouvelle application sans laisser de trace sur le disque.

Dès la reprise de l'exécution du nouveau processus qui contient maintenant du code décompressé, le processus actuel se termine sur un faux message d'erreur nous indiquant qu'Adobe Reader n'a malheureusement pas pu ouvrir notre facture au format PDF ;)

2.3 Injection

La fonctionnalité de ce nouvel exécutable maintenant actif en mémoire va principalement être d'injecter du code dans le processus explorer.exe. L'injection du cœur du malware Emotet dans un processus système permet une très bonne dissimulation ainsi qu'une profonde intégration. En effet, plus aucun processus lié au fichier d'origine n'est actif, et arrêter ce processus résultera en la fermeture de toutes les fenêtres de l'explorateur de fichiers.

Pour réaliser cette opération, Emotet va lister l'ensemble des processus en activité sur la machine et en calculer leur hash via une cuisine maison. Si cette valeur est égale à 0xB316A779, le processus désiré a été trouvé ainsi que son PID, valeur nécessaire pour réussir l'injection.

L'accès à explorer.exe se fait avec la valeur 0x438 comme demande de droit d'accès. Ce nombre est une addition des flags ci-dessous, et permet entre autres l'accès en lecture et écriture de l'exécutable rendant possibles l'injection et l'exécution de code dans ce dernier.

Dernière subtilité de cette injection, elle ne suit pas le schéma classiqueà savoir OpenProcess →WriteProcessMemeory → CreateRemoteThread, mais modifie le code de l'API ZwClose pour démarrer le code injecté à la fermeture du handle.

Cette technique permet de ne pas avoir à démarrer de remote thread et de compliquer encore un peu plus l'étude de son injection. De ce fait il faut redoubler de prudence lors de l'analyse, car l'on ne s'attend pas au premier abord à ce que du code soit exécuté lors de la fermeture d'un handle.

2.4 Payload

Après avoir passé les obstacles de l'obfuscation, des nouveaux processus ainsi que de l'injection, nous voici maintenant prêts à analyser le coeur du malware. En effet, la partie de code injectée dans explorer.exe contient les fonctionnalités d'Emotet, les étapes précédentes ne servant qu'à la dissimulation et le chargement en mémoire du programme.

Au démarrage du code injecté, Emotet charge deux librairies additionnelles, wininet.dll pour la création de connexions réseau et de transferts de fichiers, et crypt32.dll pour la gestion des certificats et de la cryptographie.

2.4.1 Récupération d'informations

Pour identifier le client infecté, Emotet va collecter toute une série d'informations à propos du système et de l'utilisateur. Cela lui servira par la suite à opérer des attaques suivant la langue ou la position géographique de l'utilisateur. Il va récupérer :

- Le numéro de série du volume logique sur lequel le système est installé. Peut être trouvé via la commande vol sous Windows :

- Le SID de l'utilisateur, ce qui identifiera l'utilisateur, les groupes dont il fait partie ainsi que ses privilèges. Un hash sera dérivé de cette valeur : 26D64F4E.

- Le nom de l'ordinateur, en remplaçant tous les caractères non compris dans la classe [a-zA-Z0-9] par un X, et en transformant la chaîne en majuscule. Cela lui évite les problèmes d'accents, tirets, caractères spéciaux et autres : tyrell-pc transformé en TYRELLXPC.

- Le pays configuré dans le système au format court de deux lettres : US.

Les données concernant le disque et le SID seront encore obfusquées par deux opérations XOR consécutives provenant de nombres codés en dur dans le malware.

Toutes ces données seront ensuite mises ensemble dans une chaîne de caractères au format %s_%s_%x%x. Les deux premières sous chaînes %s contenant le nom de l'ordinateur et le pays seront séparés du reste par un underscore.

Les données restantes obfusquées du numéro de série du disque ainsi que de l'indicateur de sécurité seront ajoutées en fin de chaîne au format hexadécimal %x.

Correctement formaté, en résultera finalement une chaîne du type :

-TYRELLXPC_US_27FFE27FBD356547

Réinterprété côté CnC server, ces informations pourtant courtes ont malgré tout une importance capitale pour la suite des fonctionnalités du malware.

2.4.2 Cryptographie

Pour garantir la confidentialité et l'intégrité de ses communications, Emotet combine intelligemment la cryptographie symétrique, asymétrique ainsi que le hachage des données. La transmission des données entre le malware et son CnC server repose sur une utilisation mixte de la cryptographie.

Les informations devant être envoyées seront chiffrées de manière symétrique par une clé aléatoire RC4, et cette clé nouvellement générée sera elle aussi chiffrée à son tour de manière asymétrique avec une clé publique RSA contenue dans le malware.

Le serveur destinataire de ces informations pourra, à l'aide de sa clé privée correspondante, déchiffrer la clé de session et l'utiliser pour pouvoir lire les informations reçues. Cette technique rend très difficile le déchiffrement des requêtes réseau de manière automatisée, car une clé RC4 est générée de manière aléatoire avant chaque envoi de données.

La clé publique RSA de 1024 bits contenue dans le malware peut être extraite de la mémoire au moment de son importation par Emotet. Il est ensuite possible de la manipuler avec openssl. Cela permet par exemple outre de l'afficher, de la convertir, de l'exporter, ou encore de l'utiliser dans des scripts prenant en charge cette librairie.

Du côté de la clé de session symétrique RC4, elle est générée de manière aléatoire avec une longueur de 128 bits. Ces deux clés seront utilisées au moment de la création de la requête POST envoyée au CnC server. Cette requête possède une longueur de 202 Bytes et est composée des éléments suivants :

- La clé RC4 aléatoire chiffrée par le biais de la clé publique RSA.(128 Bytes)

- Le hashSHA1 des données utilisateur récupérées sur la machine infectée. (20 Bytes)

- Le chiffrement avec la clé symétrique RC4 des informations utilisateurs. (54 Bytes)

2.4.3 Envoi des données

Après avoir récupéré et chiffré les informations de l'utilisateur, Emotet essaie une première fois de les envoyer vers son serveur de commande et de contrôle. Si aucune réponse n'est reçue, l'opération va se réitérer chaque minute, et ce, jusqu'à ce qu'une réponse positive revienne en retour.

Si tel est le cas, la méthode libère les librairies wininet.dll et crypt32.dll dont la présence en mémoire n'est plus requise. La figure 6 illustre les différents appels, le temps d'attente, ainsi que la libération des librairies de manière limpide.

Lors de chaque essai, une nouvelle clé RC4 est générée de façon aléatoire, et douze adresses IP différentes sont contactées. Les informations sont envoyées via une requête POST avec http://%u.%u.%u.%u:%u/%d/%d.php comme format de destination sur le port 8080. L'envoi des données se fait sur une adresse PHP qui arbore comme nom de répertoire et de page, une valeur numérique %d dérivée du SID pouvant être négative, au contraire des composantes %u de l'adresse IP qui elles, sont non signées.

Voici un exemple des adresses contactées :

- http://64.207.148.216:8080/912327956/1921447554.php

- http://203.151.94.120:8080/912327956/1921447554.php

- http://31.192.211.140:8080/912327956/1921447554.php

-...

Comme user-agent, le malware dispose de :

- Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 7.1; Trident/5.0).

Les adresses IP, le port, ainsi que le user-agent sont écrits en dur dans le malware obfusqué par un mécanisme de XOR. Il est « regrettable » de ne pas avoir fait recours à un algorithme de génération de domaine (DGA), ou à une dérivation temporelle des adresses, car le blocage de ces dernières se fait souvent très rapidement, rendant par la suite le malware inopérant. À ce stade, Emotet attend une réponse de la part de son CnC server pour continuer son infection.

Conclusion

L'étude d'Emotet a permis de mettre en lumière la réalisation du fingerprinting d'un utilisateur avec un cas pratique. Le rapatriement des données ainsi extraites combiné à l'emploi d'un canal sécurisé montre les capacités évoluées que peut posséder un tel malware.

La compréhension et le déjouement de l'obfuscation ont été une composante non négligeable pour la compréhension du malware. En effet, il fait usage de packer, crée de nouveaux processus, threads, et s'injecte au cœur du système. De plus, il accroît sa discrétion en ne faisant qu'un usage limité du disque, le reste prenant place en mémoire.

L'implémentation d'une cryptographie mixte alliant RSA et RC4 rend très difficile un déchiffrement systématique des conversations comme cela est possible dans d'autres cas dès lors que la clé de session entre les deux parties a été trouvée.

Le fait de ne disposer que de douze adresses pour la communication entre lui et son CnC server laisse penser que de multiples versions existent avec dans chacune d'elles des IP différentes. Diffusée à large échelle notamment via e-mail, l'attaque a de grandes chances de réussir malgré le blocage rapide et systématique des adresses.