Analyse détaillée du logiciel malveillant ciblé utilisé contre les banques polonaises

L'aboutissement d’attaques informatiques visant des banques polonaises a récemment fait l’objet d’un article sur le portail de sécurité polonais ZaufanaTrzeciaStrona.pl (pour consulter la traduction en anglais, cliquez ici). Les conséquences des attaques y étaient présentées, dans des termes sensationnalistes, comme « d’une extrême gravité ». Les premiers communiqués ont très récemment été étayés par deux articles de blog de Symantec et BAE Systems. Des institutions basées au Mexique et en Uruguay ont également été touchées, avec des cibles encore plus importantes dans le viseur des pirates informatiques à l’échelle internationale. Ces attaques comportent de nombreux aspects intéressants, à commencer par les cibles, le vecteur de compromission, ainsi que les fonctionnalités spécifiques des exécutables malveillants utilisés. Si les deux premiers aspects ont déjà été analysés en détail, les fichiers binaires malveillants n’ont jusqu’à présent pas fait l’objet de beaucoup d’attention. L’objectif de cet article de blog est de fournir des détails techniques sur ce logiciel malveillant fort peu documenté jusqu’à présent.

Canal de distribution

Tout comme indiqué sur le portail de sécurité polonais, la menace s’installe insidieusement, par le biais d’une attaque de point d’eau, au cours de laquelle un site Web légitime, mais compromis, redirige l’utilisateur vers une page d’accueil piégée par un exploit. Dans le cas des attaques polonaises, le site Web officiel Komisja Nadzoru Finansowego (Autorité polonaise de contrôle financier) a servi de point de départ :

Selon les informations en notre possession, le site Web de l’autorité équivalente au Mexique, Comisión Nacional Bancaria y de Valores (commission nationale bancaire et des marchés financiers), a également servi de plate-forme pour des redirections similaires à caractère malveillant (malheureusement, les informations fournies par les services de suivi Web ou par l’institution elle-même n’ont pas encore confirmé, ni mentionné ces agissements). Selon nos informations, les redirections provenaient du sous-site suivant :

Étape 1 : L'injecteur

Si le kit d’exploits parvient à installer le logiciel malveillant, la charge utile malveillante (application de type console 64 bits) s’exécute sur l’ordinateur de la victime. Contrairement à l’injecteur signalé par BAE Systems, ce programme nécessite l’un des trois commutateurs dans la liste d’arguments suivante : -l, -e, ou -a (section (2) dans la figure suivante). Si le commutateur -l a la même signification, les deux autres sont nécessaires pour extraire les fichiers binaires de l’étape suivante à partir des ressources (section (4) de la figure) et pour démarrer (automatiquement) l’un d’entre eux sous la forme d’un service (section (5)) :

Dans la section (5) de la figure ci-dessus, l’injecteur tente de modifier la configuration d’un service système afin de récupérer le chargeur injecté sous la forme d’un service. Le service est configuré pour démarrer automatiquement, via le gestionnaire de contrôle des services, au lancement du système. Les privilèges administrateurs sont nécessaires pour atteindre cet objectif.

Contrairement aux autres étapes, la dissimulation de la menace n’a pas fait l’objet de beaucoup d’attention pour la première étape. Elle affiche même des messages qui fournissent des informations sur le statut de l’exécution (ici, il s’agit de l’extraction des ressources chiffrées ; cependant, les noms de fonctions originaux similaires à des informations de débogage sont absents).

L’injecteur tire parti d’un chargement d’API dynamique au lieu d’utiliser des fonctions Windows dans sa table d’importation (vous trouverez plus de détails sur ce processus dans le rapport Novetta intitulé « Operation Blockbuster » sur le groupe Lazarus, page 34). La section (3) de la figure ci-dessus affiche un wrapper de cette fonctionnalité, qui passe d’une bibliothèque système à l’autre.

Il semble que les pirates appellent la seconde étape « loader » (chargeur), et la troisième, qui contient la principale fonctionnalité de logiciel malveillant, « module ». Le chargeur est déchiffré, tandis que le module est tout simplement extrait et injecté en l'état. Pour limiter leur visibilité lors des analyses visant à trouver l’origine d’infections, les fichiers empruntent leur heure de création au fichier shlwapi.dll du système. Une fonctionnalité intéressante de l’algorithme de chiffrement employé réside dans le fait qu’il s’agit d’une version récente de l’algorithme de chiffrement de flux Spritz, similaire à RC4 (https://people.csail.mit.edu/rivest/pubs/RS14.pdf, 2014).Des implémentations  C et Python de Spritz sont d’ores et déjà disponibles et correspondent au code désassemblé suivant issu de l’injecteur :

Étape 2 : Chargeur

Nous avons constaté un autre indice attestant de la volonté de préserver le caractère furtif de la menace. Le chargeur est protégé par un « packer » commercial appelé Enigma Protector. Selon nos informations, le module est stocké dans un format chiffré et attend son déploiement par le chargeur. Après avoir analysé plus précisément cette protection, nous avons découvert l’utilisation d’un exemplaire non enregistré du logiciel Enigma v. 1.31 64 bits. Rien d’étonnant à cela. En effet, les auteurs de logiciels malveillants d'un tel niveau ne commettent normalement pas d’erreur aussi élémentaire que de révéler leur identité en utilisant une copie officiellement enregistrée. (Toutefois, il arrive que des criminels utilisent de façon abusive une application enregistrée piratée ou victime d’une fuite s’ils peuvent s’en procurer.) En règle générale, les auteurs d’attaques souhaitant mettre en place un botnet de grande envergure n’utilisent pas de packers commerciaux, car certains éditeurs de logiciels de protection contre les logiciels malveillants les détectent de façon générique. C’est pourquoi ils limitent la taille potentielle du botnet. Cependant, dans le cas d’une attaque ciblée, l’utilisation d’une telle protection présente certains avantages. Citons, par exemple, la reconstruction du fichier binaire d’origine (tel qu'il était avant d’être soumis au processus de camouflage binaire), qui n’est jamais une tâche aisée.

On croit à tort que seuls les ordinateurs équipés de Windows 64 bits peuvent être ciblés par cette menace. En effet, une variante 32 bits a également été extraite d’ordinateurs dans certaines institutions touchées. Si sa structure globale est identique, la variante 32 bits n’est pas une simple recompilation de la source de la version 64 bits. Elle comporte de légères différences : les étapes de l’injecteur et du chargeur sont combinées en une seule étape, le chiffrement classique RC4 remplace le chiffrement Spritz et l’étape du module est stockée dans le registre au lieu du système de fichiers. Enfin, la version 3.7 du logiciel Enigma Protector a été employée avec une seule licence développeur et elle a été apparemment utilisée pour protéger le fichier binaire le 11 janvier 2017.

Étape 3 : Le module

La troisième et dernière étape se rapporte au module relativement volumineux (~730 Ko) contenant les principales fonctionnalités du logiciel malveillant, à savoir les fonctionnalités de communication avec le C&C et de réception des commandes envoyées par les opérateurs.

Le module s’injecte dans toutes les sessions en cours d’exécution sur l’ordinateur Windows compromis.

La capture d’écran suivante montre la situation après le chargement du module dans le logiciel de désassemblage IDA Pro. La barre supérieure affiche différentes sections du fichier binaire : les sections de code en bleu et les sections de données en gris et jaune. La différence entre les sections cyan et bleu foncé réside dans le fait que le cyan représente le code lié de façon statique à partir des bibliothèques existantes. Outre le runtime C habituel, nous avons identifié la liaison avec une bibliothèque de transfert de fichiers multiprotocole open source du nom de libcurl (version 7.47.1, déployée le 8 février 2016), ainsi que des blocs de codes de projets tels que OpenSSL et XUnzip. Les effets de couleur de la barre ne sont pas générés automatiquement : dans ce cas, nous avons dû marquer explicitement les zones que nous considérions comme du code de bibliothèques lié et nous avons importé tous les noms de fonctions. Les sections en bleu foncé représentent le code écrit par les auteurs de l’attaque.

Une seule URL chiffrée est stockée dans le module. La communication est chiffrée. Nous n’avons pas enregistré de communications, car le serveur distant ne répondait pas au moment de l’analyse. Le module prend en charge un nombre assez important de commandes, suffisamment nombreuses pour le classer sans l’ombre d’un doute dans la catégorie des chevaux de Troie autorisant un accès à distance (RAT). Les commandes disponibles sont les suivantes : « SLEP », « HIBN », « DRIV », « DIR », « DIRP », « CHDR », « RUN », « RUNX », « DEL », « WIPE », « MOVE », « FTIM », « NEWF », « DOWN », « ZDWN », « UPLD », « PVEW », « PKIL », « CMDL », « DIE », « GCFG », « SCFG », « TCON », « PEEX », « PEIN ». La signification de la plupart des commandes est explicite en anglais (SLEP pour la mise en veille, PKIL pour supprimer un processus, UPLD pour l’exfiltration de données, DOWN pour le téléchargement, DEL pour la suppression d’un fichier, etc.). Il est possible que les fonctions libcurl d’origine aient été personnalisées pour répondre aux besoins des pirates informatiques. Cependant, il faut garder à l’esprit que libcurl est un immense projet auquel participent des centaines de contributeurs, qui comporte des dizaines de milliers de lignes de code et des centaines d’options. L’inspection et l’analyse précises des liaisons est en cours au moment où nous écrivons ces lignes.

Des kits de ressources proches de Lazarus

Les chercheurs de BAE Systems décrivent l’injecteur 32 bits protégé par Enigma comme suit : « une fois décompressé, il injecte une variante d’un logiciel malveillant connu provenant du kit de ressources du groupe Lazarus ». En outre, Symantec déclare que « certaines chaînes de code observées dans le logiciel malveillant utilisé partagent des éléments communs avec du code issu des logiciels malveillants utilisés par le groupe de pirates informatiques dénommé Lazarus. » Il est également possible d’établir un lien dans le rapport publié par Novetta, notamment le chargement par API dynamique mentionné plus haut. Autant d’éléments qui nous incitent à décrire les propriétés essentielles d’un kit de ressources proche de Lazarus comme suit :

(1) Logiciel malveillant multiétape qui s’exécute en cascade
(2) L’étape initiale est une application de type console nécessitant au moins un paramètre
(3) Les modules WINAPI sont chargés de façon dynamique
(4) RC4 ou apparenté avec une longue clé utilisée pour le déchiffrement de l’étape suivante
(5) L’étape ou les étapes suivante(s) s’appuie(nt) sur des bibliothèques liées dynamiquement chargées en tant que service à l’aide du type de démarrage SERVICE_AUTO_START (les privilèges administrateurs sont requis pour cette action)

Selon les données en notre possession, des activités de plusieurs variantes de logiciels malveillants proches de Lazarus ont été récemment constatées sur la toile. Néanmoins, pour fournir une vue d’ensemble plus claire de la situation, nous avons besoin de temps pour collecter davantage d’informations pertinentes.

Une découverte étrange

Au cours de nos recherches, nous avons découvert un autre échantillon intéressant appartenant à la même famille de logiciels malveillants. Une application de type console nécessitant quatre paramètres dénommée fdsvc.exe (reportez-vous au point (2)), qui s’exécute en cascade (reportez-vous au point (1)). En outre, elle déchiffre l’étape suivante à l’aide de RC4 en utilisant une clé de 32 octets (reportez-vous au point (4)). Elle ne dispose pas des deux dernières propriétés. Par ailleurs, elle injecte la charge utile dans toutes les sessions Windows en cours d’exécution. En outre, la charge utile dispose d’une liaison statique avec libcurl v. 7.49.1. L’élément qui rend cet échantillon particulièrement intéressant est la façon dont l’étape finale analyse les commandes des opérateurs. Les opérateurs utilisent des commandes en Russe présentées sous la forme d’un Translit, une méthode permettant l’encodage de caractères cyrilliques à l’aide de caractères latins :

Cependant, nous devons nous montrer vigilants concernant l’attribution de ces caractères. Il se pourrait que la langue utilisée soit un leurre ! Une raison nous vient rapidement à l’esprit : les auteurs de logiciels malveillants entrent en général des commandes à l’aide de chiffres ou de raccourcis en anglais. L’utilisation d’une commande à 12 caractères est fort peu pratique.

Conclusion

Compte tenu des artefacts présents dans le code, nous pouvons dire qu’il ne s’agit ni de la réutilisation d’un code existant bien avant les attaques récemment perpétrées sur les institutions bancaires polonaises, ni d’un projet oublié et mis à l’arrêt. De plus, nous avons observé des cas de logiciels malveillants similaires à cet exemple au cours des dernières semaines. Les pirates informatiques qui se cachent derrière cette menace maîtrisent bien leur domaine. Dès lors, les équipes d'intervention rapide des institutions financières ou d’autres cibles d’envergure risquent de ne pas souvent dormir sur leurs deux oreilles dans un proche avenir. En fait, de nos jours, leur travail se résume à enchaîner des nuits blanches !

Indicateurs de compromission

Échantillons concernés par les attaques

Logiciel malveillant doté d’un Translit