Les loaders, ces maliciels furtifs utilisés pour déployer des charges utiles élaborées

Comme le résumait Flashpoint Intel en juillet 2018, les loaders, sont des logiciels qui « pour l’essentiel, n’ont qu’une seule tâche : récupérer des exécutables malveillants ou des charges malicieuses à partir d’un serveur contrôlé par un attaquant ». Traditionnellement, « ils sont plutôt légers (moins de 50 ko) afin d’échapper à la détection par un antivirus et autres technologies de surveillance ». Plusieurs ont fait parler d’eux récemment, à l’instar de Smoke Loader, GuLoader, ou BrushaLoader. D’une certaine façon, ils peuvent faire penser aux chevaux de Troie, tels qu’AgentTesla, Trickbot, NanoCore, ou Remcos, mais leur éventail fonctionnel est bien plus limité.

Le chercheur Max Kersten s’est penché sur ReZer0v4, écrit en .Net, et a partagé avec nous son analyse en avant-première. L’occasion de plonger dans les entrailles de ces maliciels clés dans les chaînes d’attaques car « utiliser plusieurs d’entre eux pour se charger l’un l’autre est une tactique couramment observée », explique-t-il.

Sans surprise, impossible de se lancer dans la rétro-ingénierie du but en blanc : des techniques d’offuscation sont mises en œuvre pour essayer de passer inaperçu. L’outil libre de4dot est exploité pour « nettoyer le nom des classes, des méthodes et des champs. Après quoi, il peut être exporté dans Visual Studio pour permettre la reconstruction du code ». C’est là que « le chiffrement des chaînes de caractères va être analysé puis retiré » avant que ne commence véritablement la phase d’analyse du maliciel.

Celle-ci permet de comprendre la manière dont s’exécute le loader, pas à pas, et notamment de découvrir pourquoi son exécution n’est pas complète dans de nombreux bac à sable, ou sandbox : une fonction « vérifie la présence d’artéfacts qui ne sont généralement observables que dans des environnements virtuels ». Et si ceux-ci sont découverts, l’exécution s’arrête. De la sorte, les développeurs de ce maliciels peuvent notamment essayer de cacher aux analystes les composants de leur infrastructure de commande et de contrôle, ces serveurs avec lesquels communique le loader pour récupérer ses charges à télécharger : des informations précieuses qui permettraient d’en bloquer le fonctionner si elles venaient à être découvertes.

Mais l’analyse du code du maliciel permet surtout de comprendre comment ajuster la configuration des environnements de détonation, les bacs à sable, pour contourner ses propres contre-mesures…

Accessoirement, la charge utile intégrée est déchiffrée avant toute vérification et chargée dans un tableau (array) d’octets : « si un antivirus analysait la zone de mémoire de ce tableau, l’exécutable nouvellement chargé serait trouvé ». Un indice potentiel pour les éditeurs concernés. Mais cela implique aussi que, à des fins d’analyse, « il est possible de fixer un point d’arrêt sur le tableau d’octets afin d’en extraire le contenu dans un nouveau fichier » pour poursuivre l’analyse… et contourner les vérifications du maliciel.

La charge utile peut être exécutée de trois façons : soit injectée dans la mémoire du processus en cours, soit dans un nouveau processus crée dans l’état intialement suspendu, ou encore téléchargée et exécutée dans un nouveau processus.

L’analyse de ReZer0v4 fait également ressortir une fonction de persistance : elle « remplace deux valeurs dans [un fichier] XML pour créer une tâche programmée qui lance le loader au démarrage [de la machine infectée] ». Le travail Max Kersten fait ressortir un maliciel « capable d’une variété d’actions ». Le choix de celles qui sont effectivement exécutées « dépend d’une configuration prédéfinie ».

ReZer0 est observé dans la nature. La règle Yara écrite par Max Kersten pour en identifier les échantillons en fait ressortir plus de 200 soumis en ligne au cours des derniers mois. Mais cette analyse souligne surtout l’importance de la rétro-ingénierie sur les logiciels malveillants.