Depuis quelques années, les logiciels malveillants bancaires (également appelés banquiers) sont de moins en moins populaires auprès des cybercriminels, notamment parce que les sociétés anti-logiciels malveillants et les développeurs de navigateurs Web élargissent continuellement la portée de leurs mécanismes de protection contre les attaques de chevaux de Troie bancaires. Il en résulte que les fraudes bancaires conventionnelles deviennent chaque jour plus compliquées à réaliser, ce qui fait que les auteurs de logiciels malveillants consacrent leur temps et leurs ressources à développer des types de logiciels malveillants plus faciles à réaliser et plus rentables, tels que les rançongiciels, le cryptominage malveillant et les voleurs de cryptomonnaies.
Nous avons découvert une nouvelle famille de logiciels malveillants bancaires utilisant une technique novatrice pour manipuler le navigateur : au lieu d'utiliser des méthodes d'injection de processus complexes pour surveiller l'activité de navigation, les logiciels malveillants accrochent les événements clés de la boucle de messages de la fenêtre afin d'inspecter les valeurs des objets de la fenêtre pour l'activité bancaire.
Une fois l'activité bancaire détectée, le logiciel malveillant injecte du JavaScript malveillant dans la page Web, soit via la console JavaScript du navigateur, soit directement dans la barre d'adresse. Toutes ces opérations se font à l'insu de l'utilisateur. Il s'agit d'une astuce en apparence simple qui permet néanmoins d'annuler les mécanismes avancés de protection des navigateurs contre les attaques complexes.
Introduction
Nous avons d'abord remarqué que le groupe à l'origine de ce logiciel bancaire malveillant diffusait ses projets antérieurs - l'un d'entre eux étant un logiciel bancaire malveillant volant de la cryptomonnaie en remplaçant les adresses de portefeuille dans le presse-papiers - en janvier de cette année. Le groupe s'est concentré sur les logiciels malveillants visant le presse-papiers pendant quelques mois et a finalement introduit la première version du logiciel bancaire malveillant, détectée par ESET le 13 mars dernier sous le nom de Win32/BackSwap.A.
Dans la figure ci-dessous, on observe une augmentation spectaculaire du taux de détection par rapport aux projets précédents, tel qu'il ressort de nos processus d'arrière-plan. Les auteurs ont été très actifs dans le développement du logiciel bancaire malveillant et ont continué à introduire de nouvelles versions sur une base quotidienne, en ne prenant des pauses qu’en fin de semaine.
Figure 1 : Vue d'ensemble des détections de logiciels malveillants bancaires Win32/BackSwap.A et des projets précédents.
Distribution et exécution
Le logiciel bancaire malveillant est distribué par le biais de campagnes de courriers indésirables qui portent une pièce jointe d'un downloader JavaScript grandement obscurci, appartenant à une famille communément connue sous le nom de Nemucod. Ces campagnes de courriers indésirables ciblent les utilisateurs polonais.
Très souvent, les machines victimes sont également compromises par le célèbre téléchargeur Win32/TrojanDownloader.Nymaim, qui semble être diffusé en utilisant une méthode similaire. Au moment d'écrire ces lignes, nous ne savons pas si ce n'est qu'une coïncidence ou si ces deux familles sont directement liées.
La charge utile est livrée sous la forme d'une version modifiée d'une application légitime et partiellement écrasée par la charge utile malveillante. L'application utilisée comme cible pour la modification est changée régulièrement. On compte en effet parmi les applications utilisées dans le passé TPVCGateway, SQLMon, DbgView, WinRAR Uninstaller, 7Zip, OllyDbg et FileZilla Server. L'application est modifiée pour passer directement au code malveillant lors de son initialisation. Une des techniques utilisées pour y parvenir est d'ajouter un pointeur à la charge utile malveillante dans la table de fonction _initterm(), qui est une partie interne de C Run-Time Library qui initialise toutes les variables globales et autres parties du programme qui doivent être initialisées avant que la fonction principale() ne soit appelée.
Figure 2 : Tableau de pointeurs _initterm d'une application légitime avec un pointeur vers le shellcode du logiciel bancaire malveillant à la fin.
Cette méthode peut rappeler la« trojanisation ». Cependant, la différence est que l'application originale ne fonctionne plus, et une fois que le contrôle est transféré au logiciel bancaire malveillant, il ne reviendra jamais au code original. Par conséquent, l'intention n'est pas de faire croire aux utilisateurs qu'ils exécutent l'application légitime, mais plutôt d'augmenter la furtivité du logiciel malveillant contre l'analyse et la détection. Cela rend le logiciel plus difficile à repérer pour un analyste, car de nombreux outils d'ingénierie inverse comme IDA Pro montreront la fonction main() originale comme un début légitime du code de l'application et un analyste pourrait ne rien remarquer de suspect au premier coup d'œil.
La charge utile est un blob de code indépendant de la position avec toutes ses données incorporées. Les chaînes de caractères sont stockées en texte brut, ce qui ruine sa très petite empreinte, car toutes les API Windows nécessaires sont recherchées par hash pendant l'exécution. Le logiciel bancaire malveillant commence par se copier dans un dossier de démarrage afin d'assurer la persistance, puis poursuit avec sa fonctionnalité bancaire.
Méthodes d'injection conventionnelles
Pour pouvoir subtiliser de l'argent sur le compte d'une victime via l'interface bancaire sur Internet, un programme malveillant bancaire typique s'injectera lui-même ou son module bancaire spécialisé dans l'espace d'adresse de processus du navigateur. Pour de nombreuses raisons, ce n'est pas une tâche facile - tout d'abord, comme mentionné précédemment, l'injection pourrait être interceptée par une solution de sécurité tierce. Le module injecté doit également correspondre à la qualité binaire du navigateur - un module 32 bits ne peut pas être injecté dans un processus de navigateur 64 bits et vice versa. Il en résulte que les chevaux de Troie bancaires doivent généralement porter les deux versions d'un module donné afin de supporter à la fois les versions 32 bits et 64 bits des navigateurs.
Une fois injecté avec succès, le module bancaire doit trouver des fonctions spécifiques au navigateur et les accrocher. Le logiciel malveillant recherche les fonctions responsables de l'envoi et de la réception des requêtes HTTP en texte brut, respectivement avant le chiffrement et après le déchiffrement. La difficulté de trouver ces fonctions varie d'un navigateur à l'autre - dans le cas de Mozilla Firefox, les fonctions sont exportées par la bibliothèque nss3.dll et leurs adresses peuvent être recherchées sans effort par leurs noms largement connus. D'autre part, Google Chrome et d'autres navigateurs basés sur Chromium ont ces fonctions cachées et implémentées profondément dans le binaire, ce qui les rend très difficiles à trouver. Cela oblige les auteurs de logiciels malveillants à mettre au point des méthodes et des modèles spécialisés qui ne fonctionnent que pour la version spécifique du navigateur. Une fois qu'une nouvelle version sort, de nouvelles méthodes et de nouveaux modèles doivent être mis en œuvre.
Si les bonnes fonctions sont trouvées et que les crochets sont installés avec succès (notez que les crochets peuvent également être détectés par une solution de sécurité), le cheval de Troie bancaire peut commencer à modifier le trafic HTTP ou rediriger la victime vers un autre site Web se faisant passer pour une banque tout en simulant la validité d'un certificat. Des techniques similaires sont incorporées par des chevaux de Troie bancaires actifs de haut niveau, tels que Dridex, Ursnif, Zbot, Trickbot, Qbot et bien d'autres.
Nouvelle technique de manipulation du navigateur
Win32/BackSwap.A utilise une approche complètement différente. Il gère tout en travaillant avec des éléments Windows GUI et en simulant l'entrée de l'utilisateur. Cela peut paraître trivial, mais il s'agit en fait d'une technique très puissante qui résout de nombreux problèmes associés à l'injection de navigateur conventionnel. Tout d'abord, le logiciel bancaire malveillant n'interagit pas du tout avec le navigateur au niveau du processus. Ceci signifie qu'il n'exige pas de privilèges spéciaux et contourne tout durcissement du navigateur par un tiers, qui se concentre habituellement sur les méthodes d'injection conventionnelles. Un autre avantage pour les attaquants est que le code ne dépend ni de l'architecture du navigateur ni de la version de ce dernier, et qu'un chemin de code fonctionne pour tous.
Le logiciel malveillant surveille l'URL actuellement visitée en installant des crochets d'événements pour une gamme spécifique d'événements pertinents disponibles via la boucle de messages Windows, tels qu’EVENT_OBJECT_FOCUS, EVENT_OBJECT_SELECTION, EVENT_OBJECT_NAMECHANGE et quelques autres. Le crochet recherchera les modèles d'URL en recherchant dans les objets des chaînes de caractères commençant par https récupéré, en appelant la méthode get_accValue depuis l'interface IAccessible de l'événement.
Figure 3 : Technique utilisée pour récupérer les URL actuellement visitées à partir du navigateur. Ces URLs sont récupérées en vérifiant la sous-chaîne [ht]tp[s] (en rouge).
Figure 4 : Banker recherche des chaînes de caractères bancaires spécifiques - la première chaîne est un titre de fenêtre, la seconde fait partie d'une URL.
Une fois identifié, le logiciel bancaire charge le JavaScript malveillant approprié pour la banque correspondant à partir de ses ressources et l'injecte dans le navigateur. L'injection de script se fait également d’une manière simple mais efficace.
Dans les échantillons plus anciens, le logiciel malveillant insère le script malveillant dans le presse-papiers et simule la combinaison de touches pour ouvrir la console du développeur (CTRL+SHIFT+J dans Google Chrome, CTRL+SHIFT+K dans Mozilla Firefox) suivi de CTRL+V, qui colle le contenu du presse-papiers et envoie ENTER pour exécuter le contenu de la console. Enfin, le logiciel malveillant envoie à nouveau la combinaison de touches de la console pour fermer la console. La fenêtre du navigateur est également rendue invisible pendant ce processus - pour les utilisateurs réguliers, il peut sembler que leur navigateur a simplement gelé pendant un moment.
Dans les nouvelles variantes du logiciel malveillant, cette approche a été mise à niveau - au lieu d'interagir avec la console du développeur, le script malveillant est exécuté directement depuis la barre d'adresse, via des URLs de protocole JavaScript; une fonctionnalité peu utilisée et supportée par la plupart des navigateurs. Le logiciel malveillant simule simplement en appuyant sur CTRL+L pour sélectionner la barre d'adresse suivie de la touche DELETE pour effacer le champ, puis tape dans« javascript : » en appelant SendMessageA en boucle, puis colle le script malveillant avec la combinaison CTRL+V. Il exécute ensuite le script en envoyant la touche ENTER. À la fin du processus, la barre d'adresse est effacée pour éliminer tout signe de compromission.
Dans la figure 5, on peut voir une partie du code d'injection de la console. Tout d'abord, le logiciel malveillant détermine le navigateur en vérifiant le nom de classe de la fenêtre d'avant-plan (en bleu). Le JavaScript malveillant est copié dans le presse-papiers (en rouge). Ensuite, l'opacité de la fenêtre du navigateur est modifiée en 3, ce qui la rend invisible (en violet). Le vert marque la partie de la fonction ToggleBrowserConsole, qui active et désactive la console du navigateur.
Figure 5 : Technique d'injection de script.
Win32/BackSwap.A supporte les attaques contre Google Chrome, Mozilla Firefox. De plus, dans les versions récentes, ses auteurs ont également ajouté la prise en charge d'Internet Explorer. Cependant, cette méthode fonctionnera pour la plupart des navigateurs aujourd'hui, à condition qu'ils disposent d'une console JavaScript ou qu'ils implémentent l'exécution de JavaScript à partir de la barre d'adresse, les deux étant des fonctions standard des navigateurs de nos jours.
Les trois navigateurs pris en charge ont une fonctionnalité de protection intéressante, qui a été conçue à l'origine comme une contre-mesure contre les attaques Self-XSS. Lorsque les utilisateurs tentent de coller du texte commençant par « javascript : » dans la barre d'adresse, le préfixe du protocole est supprimé et les utilisateurs doivent l’entrer manuellement dans la barre d'adresse pour exécuter le script. Win32/BackSwap.A contourne cette contre-mesure en simulant la saisie du préfixe dans la barre d'adresse, lettre par lettre, avant de coller le script malveillant.
Une autre contre-mesure implémentée par Mozilla Firefox interdit de coller des scripts dans la console par défaut et affiche plutôt un message avertissant les utilisateurs des risques potentiels, les forçant à d'abord taper « autoriser le collage ». Le logiciel bancaire malveillant contourne ce problème en exécutant la commande shell illustrée à la figure 6, qui modifie le fichier de configuration prefs.js et supprime cette contre-mesure.
Figure 6 : La commande shell utilisée pour supprimer la protection par collage de la console de script Firefox.
JavaScript malveillant
Le logiciel bancaire malveillant implémente un script spécifique pour chaque banque ciblée, puisque chaque site bancaire est différent et a un code source et des variables différentes. Ces scripts sont injectés dans les pages que le logiciel malveillant identifie comme étant à l'origine d'une demande de virement bancaire, comme le paiement d'un compte de service public. Les scripts injectés remplacent secrètement le numéro de compte bancaire du destinataire par un numéro différent et lorsque la victime décide d'envoyer le virement, l'argent sera envoyé aux attaquants à la place. Les mesures de protection contre les paiements non autorisés, comme l'autorisation à deux facteurs, ne seront d'aucune utilité dans ce cas, car le propriétaire du compte envoie volontiers le virement électronique.
Win32/BackSwap.A a eu des scripts malveillants ciblant cinq banques polonaises au total, soit PKO Bank Polski, Bank Zachodni WBK S.A., mBank, ING et Pekao. Ses auteurs retirent parfois certaines banques de la liste des cibles et dans la version la plus récente, par exemple, ils n'ont laissé que trois banques : PKO BP, mBank et ING. Dans les versions plus anciennes, les attaquants récupéraient les numéros de compte bancaire des serveurs C&C qui étaient hébergés sur des sites Web WordPress piratés. Dans les versions récentes, ils ont stocké ces numéros de compte directement dans les scripts malveillants. Les numéros de comptes bancaires malveillants changent très fréquemment, et presque toutes les campagnes en ont une nouvelle.
Comme nous pouvons le voir dans la figure ci-dessous, le logiciel ne volera de l'argent que si le montant du virement se situe dans une certaine fourchette - ils visent généralement des paiements entre 10 000 et 20 000 PLN, ce qui correspond à une somme entre 2 800 et 5 600 dollars US. Le script remplace le compte bancaire du destinataire d'origine, et remplace également le champ de saisie de ce numéro par un faux qui affiche le compte bancaire d'origine, de sorte que l'utilisateur voit le numéro valide et risque d’être moins suspicieux.
Figure 7 : Une partie du JavaScript malveillant. Les zones en rouge indiquent la vérification du montant du virement et le remplacement du numéro de compte bancaire du destinataire.
Conclusion
Win32/BackSwap.A nous montre que dans la bataille en cours entre l'industrie de la sécurité et les auteurs de logiciels malveillants bancaires, les nouvelles techniques malveillantes n'ont pas nécessairement besoin d'être très sophistiquées pour être efficaces. Nous pensons qu'à mesure que les navigateurs deviennent mieux protégés contre l'injection de code conventionnel, les auteurs de logiciels malveillants attaqueront les navigateurs de différentes manières et Win32/BackSwap.A pourrait bien nous avoir montré l'une des possibilités.
Les solutions ESET détectent et bloquent la menace désignée comme étant le cheval de Troie Win32/BackSwap.A.
Nous avons informé les fournisseurs de navigateurs concernés de la technique innovante d'injection de scripts.
Un merci spécial à Paweł Śmierciak pour avoir découvert cette famille et son aide dans cette recherche.
Indicateurs de compromission (IoCs)
| 9BC4C1D5403DDD90712CE87225490A21D1EDC516 | JS/Nemucod.EAN trojan |
|---|---|
| CF5A74C268661501156663F74CD5E20603B0F261 | Win32/BackSwap.A trojan |
| 6251F9AD0E5F551AC4A6B918EF366E86C4CCFDC4 | Win32/BackSwap.A trojan |
| 2DC9760A7C6E9D261C73EFB7B2604840734BC058 | Win32/BackSwap.A trojan |
| A68901D0D8C1247FF280F9453E3AE45687C57566 | Win32/BackSwap.A trojan (JavaScript) |
