Nous surveillons une nouvelle cybermenace qui combine des formats de fichiers pour créer un malware plus polyvalent.
Auteurs : Luigino Camastra, Jan Širmer, Adolf Středa et Lukáš Obrdlík
Depuis août 2018, nous surveillons une nouvelle famille de malwares que nous appelons Rietspoof. Rietspoof est un nouveau malware à plusieurs étapes présentant des caractéristiques et des fonctionnalités impressionnantes. Lorsque nous avons commencé à surveiller Rietspoof, il était mis à jour environ une fois par mois. En janvier 2019, nous avons remarqué un changement de fréquence et les mises à jour étaient à présent quotidiennes.
Rietspoof utilise plusieurs étapes, combinant différents formats de fichiers, pour fournir un malware plus polyvalent. Nos données suggèrent une première étape livrée via les clients de messagerie instantanée, tels que Skype ou Messenger. Le malware fournit un VBS très obfusqué ainsi qu'une deuxième étape codée en dur et chiffrée, un fichier CAB. Le fichier CAB est enrichi d'un exécutable signé numériquement avec une signature valide, principalement via Comodo CA. Le fichier.exe installe un téléchargeur lors de la quatrième étape.
Il est intéressant de noter que la troisième étape utilise un simple protocole TCP pour communiquer avec un serveur de commande et de contrôle, dont l'adresse IP est codée en dur et en binaire. Le protocole est chiffré par AES en mode CBC. Dans la première version, nous avons observé que la clé était dérivée de la connexion initiale et dans une seconde version, elle est dérivée d'une chaîne codée en dur. Dans la seconde version, le protocole prend en charge son propre protocole fonctionnant sur TCP et tente également d'exploiter les requêtes HTTP/HTTPS. Il est rare que le protocole de communication d'un serveur de commande et de contrôle soit modifié dans une telle mesure, étant donné le niveau d'effort requis pour le modifier. Bien que la modification des méthodes d'obfuscation soit courante, la communication d'un serveur de commande et de contrôle reste généralement relativement constante pour la plupart des malwares.
Ce téléchargeur utilise un protocole local pour récupérer une autre étape (étape 4) à partir d'une adresse codée en dur. Alors que le protocole de l'étape 3 inclut des fonctionnalités de bot, celui de l'étape 4 agit en tant que téléchargeur désigné uniquement.
Par ailleurs, le serveur de commande et de contrôle ne communique qu'avec des adresses IP américaines, ce qui nous amène à l'hypothèse que nous étudions une attaque spécifiquement ciblée ou que les pirates informatiques utilisent la gamme IP des États-Unis à des fins de test uniquement. Et il est possible que d'autres étapes n'aient pas encore été révélées. Voici les résultats de notre analyse complète à ce jour.
La première partie du VBS est une fonction permettant de déchiffrer et de déobfusquer les fichiers binaires intégrés.
Sur la base de cet extrait, il est évident que le script commence à lire le code à une position spécifique, en déobsuquant le fichier CAB et en le préparant pour la prochaine étape. Le code est converti caractère par caractère en sa valeur ANSI et ajouté à la variable counter. À chaque étape, la variable counter est soumise à la fonction ou exclusif avec val_01 (codée en dur à 15) et elle est ajoutée à des octets déjà décodés. Il est intéressant de noter qu'à chaque étape, la chaîne var_str_01 est également ajoutée à var_str_02.
Après cette étape, la chaîne var_str_02 est utilisée comme paramètre pour une nouvelle fonction. Le second paramètre est TempPath avec le nom de fichier suivant :
À cette étape, le fichier CAB est enregistré dans le dossier Temp de l'ordinateur sous le nom « JSWdhndk.sjk ». L'étape suivante doit en être extraite, ce qui est effectué via expand.exe :
Le script vérifie d'abord si l'utilisateur connecté est un administrateur en lisant simplement la clé de registre « HKEY_USERS\S-1-5-19\Environment\TEMP ». Si c'est le cas, il configure True pour func_read_Registry
Lorsque cet indicateur est défini sur True, le VBS modifie la date sur 01/01/2109, supprime le fichier CAB de %TEMP%, exécute le fichier exécutable étendu et supprime le script original pour brouiller les pistes. Ensuite, il modifie à nouveau la date et indique la date réelle. La date provisoire indiquant l'année 2109 n'est pas utilisée dans les fichiers script non déposés. Au début, nous pensions qu'il ne s'agissait que d'une coquille et que la date provisoire prévue était le 01/01/2019, mais cette hypothèse ne s'est pas confirmée.
L'utilisation de cmd/c par les auteurs du malware pour l'exécution des commandes depuis la ligne de commande est intéressante. Jetez un œil à la description de cette commande :
Il s'agit très probablement d'une tentative de mise en échec des détections de comportement via la génération de plus de lignes de commande avec des commandes exécutées.
Même si l'étape précédente est ignorée, si l'utilisateur actuel n'est pas l'administrateur, l'étape suivante consiste à exécuter le fichier PE étendu. Dans un premier temps, le script supprime une tâche planifiée Microsoft Windows DOM object helper. Cette tâche est réalisée par les créateurs du malware pour s'assurer qu'ils peuvent créer une nouvelle valeur dans les tâches de planification pointant vers le fichier PE étendu à l'étape précédente ; elle est configurée pour s'exécuter après une minute. Ensuite, le fichier CAB est supprimé du répertoire %TEMP%.
Dans la nouvelle version du VBS, les auteurs du malware ont ajouté une nouvelle fonction de persistance lancée à partir du 22 janvier 2019. Le script crée un nouveau fichier LNK au démarrage sous le nom WindowsUpdate.lnk. Ce fichier lnk exécute un fichier PE étendu après le démarrage pour s'assurer que l'exécutable fonctionnera si la machine est redémarrée.
Presque toutes les versions du fichier VBS contiennent un nouveau certificat, par exemple :
Lorsque nous convertissons un bloc de code base64 en bloc de code hexadécimal, puis que nous analysons cette chaîne hexadécimale ASN.1, nous obtenons le numéro de série de ce certificat :
La plupart des certificats sont délivrés par COMODO ou Sectigo
Jusqu'à présent, nous avons observé deux versions de la troisième étape de Rietspoof et constaté qu'elles diffèrent principalement en termes de protocole de communication. Cette étape a les capacités d'un simple bot : elle permet de télécharger des fichiers, de démarrer des processus ou de lancer une fonction d'autodestruction. Le serveur de commande et de contrôle semble également avoir intégré une clôture virtuelle de base (geofencing) en fonction de l'adresse IP.
Nous n'avons reçu aucune commande « intéressante » lorsque nous avons tenté de communiquer depuis le réseau de notre salle informatique, mais lorsque nous avons virtuellement transféré notre faux client aux États-Unis, nous avons reçu une commande contenant l'étape suivante.
Nous avons constaté que le développement de cette troisième étape évoluait rapidement et exécutait parfois deux branches différentes à la fois. Lors de notre analyse, le protocole de communication a été modifié à plusieurs reprises et de nouvelles fonctionnalités ont été ajoutées. L'obfuscation des chaînes de caractères était prise en charge dans les versions précédentes, mise en place plusieurs jours plus tard, puis le 23 janvier, nous avons constaté que des échantillons annulaient certaines de ces modifications. Les versions plus récentes prenaient également en charge l'option de ligne de commande « /s », utilisée pour une installation en tant que service nommé « windmhlp ».
La commande « HARDWARE » n'est envoyée que si l'ID client envoyé est affiché pour la première fois. La commande « OK » entraîne toujours la fin de la communication. Ce protocole simple est exécuté périodiquement à quelques minutes d'intervalle.
La première version de la communication de la troisième étape utilise un protocole plutôt simpliste. Dans un premier temps, une clé et un vecteur d'initialisation sont générés par une connexion consistant en un message et une réponse, tous deux de 32 octets aléatoires et d'une somme de contrôle CRC32 de 4 octets.
Ensuite, les octets aléatoires sont soumis à la fonction ou exclusif et l'application de la fonction SHA256 sur le résultat donne la clé. Par ailleurs, appliquer l'algorithme MD5 au condensé SHA256 donne le vecteur d'initialisation. Désormais, ces paramètres sont utilisés pour chiffrer les messages par AES-CBC.
Notez que la fonction de remplissage est étrangement conçue : le dernier bloc est rempli de 16 octets, si nécessaire, et 16 autres zéro octets sont toujours ajoutés après le dernier bloc.
Connexion initiale et génération de clé suivante : il existe un
contrôle du tableau des ports, non affiché, qui déborde entre ces deux blocs.
Chaîne « HELLO\n » obfusquée, puis
déobfusquée ; caractère générique d'obfuscation
La communication commence par client_hello, un message contenant simplement « HELLO\n » qui appelle « HELLO\n » comme réponse (en fait, la réponse était toujours « HELLO\n\n\n\n\n\n\n... »). Ensuite, le client envoie une commande « ID:<MD5 of adapter MAC address>2.10\n ». Il reçoit une réponse « OK », « HARDWARE » ou une commande plus puissante.
Dans le premier cas, la communication se termine et la boucle de communication s'arrête pendant deux à cinq minutes. La réponse « HARDWARE » induit la requête « HW:<infos SE> CPU<infos CPU> RAM: <info RAM> USER: <privilèges de processus> », les privilèges de processus étant soit « admin » (le processus a des privilèges d'administrateur), soit « user » (autrement). Encore une fois, « OK » est reçu en réponse du message, mettant fin à la communication de la même manière.
L'une des six autres commandes suivantes peut être reçue, au lieu de OK :
|
DEL:<filename> |
Suppression du fichier, le nom du fichier est précédé de l'emplacement de %TEMP% |
|
RUN:<filename> |
Création du processus avec le fichier comme lpCommandLine, le nom du fichier est précédé de l'emplacement de %TEMP% |
|
DWN:<filename> |
Téléchargement d'un fichier, si le nom de fichier présente le suffixe .upgrade, puis vidage du script de mise à jour VBS qui remplace le malware par une version plus récente. |
|
UPL:<filename> |
Téléchargement du fichier depuis %TEMP% |
|
DAR:<filename> |
Téléchargement, sauvegarde dans %TEMP%/<nom de fichier> et exécution |
|
DSF:\n |
Autosuppression |
La deuxième version de la troisième étape de Rietspoof utilise un protocole assez similaire avec quelques nouveautés. La seconde version essaie de communiquer par HTTP/HTTPS, à moins qu'un proxy ne soit configuré, auquel cas elle recourt au TCP brut. Cette nouvelle version évite également la connexion initiale car elle utilise une chaîne codée en dur « M9h5an8f8zTjnyTwQVh6hYBdYsMqHiAz » au lieu de chiffrer deux chaînes au hasard avec la fonction ou exclusif. Encore une fois, cette chaîne est soumise à l'algorithme SHA256, ce qui donne une clé, et l'algorithme SHA256 se compose de la fonction MD5, donnant un vecteur d'initialisation. Ces paramètres sont utilisés pour chiffrer les messages par AES-CBC.
Chaîne obfusquée « HELLO\n »
Les requêtes HTTP GET, générées par le malware, sont plus ou moins ordinaires à l'exception de trois en-têtes. Voici un exemple de requête HTTP : Notez que l'en-tête Content-MD5 n'est pas obligatoire. En outre, il est utilisé de manière personnalisée et non conforme aux normes. La chaîne de l'agent utilisateur est codée en dur et en binaire.
GET /<chemin>?<données GET> HTTP/1.1
Host:<domaine>
Connection:close
Content-MD5:<message encodé base64>
User-agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Heureusement pour nous, l'ancien protocole est toujours présent pour les cas où un proxy HTTP est utilisé. Nous sommes convaincus qu'il peut servir de protection contre des attaques insignifiantes de l'homme du milieu pouvant être utilisées lors de l'analyse du malware. Toutefois, dans notre cas, il nous permet de déployer un nouveau script de suivi avec très peu de modifications car seul le protocole d'accord clé a été modifié.
Cette étape vise à établir un canal authentifié via le protocole NTLM sur TCP avec son serveur de commande et de contrôle dont l'adresse IP est codée en dur.
Lancer l'authentification NTLM
Boucle principale d'authentification et réception des données du serveur de commande et de contrôle
Ensuite, il commence à communiquer avec le serveur de commande et de contrôle via le canal susmentionné dans le but de récupérer une autre étape ou éventuellement la charge utile finale.
Comme vous l'avez lu précédemment, l'activité de ce nouveau malware, Rietspoof, a considérablement progressé en janvier 2019. Durant cette période, le développeur a utilisé plusieurs certificats valides pour signer les fichiers associés. Par ailleurs, les charges utiles ont fait l'objet d'un développement, c'est-à-dire que la mise en œuvre du protocole de communication de l'étape 3 a été modifiée à plusieurs reprises.
Bien que les données sur Rietspoof soient nombreuses, les motivations et le modus operandi sont encore inconnus, de même que les cibles visées. Et, à ce jour, les fichiers infectés par le malware sont rarement détectés par la plupart des logiciels antivirus.
Nos recherches ne peuvent pas encore confirmer si nous avons découvert l'intégralité de la chaîne de contamination. Bien que le malware ait des capacités de bot, il semble avoir été initialement conçu comme un injecteur. En outre, sa faible prévalence et l'utilisation d'une clôture virtuelle ouvrent la voie à d'autres inconnues. Nous avons peut-être manqué d'autres échantillons, distribués uniquement sur une plage d'adresses IP spécifique par exemple.
Nous ne partageons pas publiquement les IOC, mais si vous pouvez prouver à Avast que vous êtes un analyste ou un chercheur anti-malware, nous les mettrons à votre disposition. Dans ce cas, n'hésitez pas à contacter @n3ph8t3r, @StredaAdolf et @sirmer_jan via Twitter.
Avast est le leader mondial de la cybersécurité, protégeant des centaines de millions d’utilisateurs dans le monde entier. Protégez tous vos appareils avec notre antivirus gratuit primé. Protégez votre confidentialité et chiffrez votre connexion en ligne avec le VPN SecureLine.
Apprenez-en davantage sur les produits qui protègent votre vie numérique sur avast.com. Obtenez toutes les dernières nouvelles sur les cybermenaces d’aujourd’hui et comment les vaincre sur blog.avast.com.
Merci d’utiliser Avast Antivirus et de nous recommander à vos amis et votre famille.
1988 - 2024 Copyright © Avast Software s.r.o. | Sitemap Politique de Confidentialité