Le RAT ChainScript transforme les smart contracts Polygon en annuaire C2 évolutif
Découvrez comment le RAT ChainScript exploite ClickFix, Node.js et un smart contract Polygon pour rediriger son C2 et contrôler les machines infectées.
Image d’illustration générée par IA
De faux installateurs logiciels déclenchent la chaîne d’attaque Windows
Des acteurs malveillants utilisent une ingénierie sociale de type ClickFix pour installer un cheval de Troie d’accès à distance Windows jusqu’alors inédit, baptisé ChainScript. Ce malware offre aux opérateurs un accès interactif aux systèmes infectés tout en s’appuyant sur la blockchain Polygon pour localiser une infrastructure de commande et de contrôle remplaçable.
Le Blackpoint Adversary Pursuit Group a identifié quatre noms de build de ChainScript :
- ComponentTask33
- UpdateDigital
- HostShared
- OrchidViolet66
Ces builds se font passer pour des logiciels associés à Spotify, Zoom Workplace et Microsoft Teams. Un installateur aux couleurs de Spotify observé par les chercheurs est nommé ComponentTask33-4d14e6ac.msi.
Les applications légitimes sont usurpées ; aucune vulnérabilité touchant Spotify, Zoom Workplace, Microsoft Teams, Node.js ou Windows n’a été identifiée en lien avec cette campagne. Il n’existe donc aucune plage de versions concernées, aucun identifiant CVE, aucun score CVSS ni correctif éditeur.
L’intrusion repose plutôt sur la capacité à convaincre une victime de télécharger et d’exécuter un package MSI via msiexec.exe. Ce mode opératoire reprend le modèle ClickFix bien connu : une page web présente un problème ou une exigence d’installation fictive, puis demande à l’utilisateur d’effectuer une action qui exécute du code fourni par l’attaquant.
Les éléments propres à ChainScript, notamment sa chaîne d’installation et son résolveur basé sur Polygon, sont issus du rapport technique de Blackpoint APG.
Node.js, PowerShell et VBScript dissimulent l’implant
Après son exécution, le MSI malveillant installe le runtime Node.js et place plusieurs composants dans des répertoires aux noms évoquant Microsoft, sous %LOCALAPPDATA%. Ces fichiers comprennent l’agent JavaScript de ChainScript, des éléments de configuration et des binaires auxiliaires.
La chaîne de déploiement utilise ensuite des étapes PowerShell et VBScript dissimulées. VBScript sert de lanceur principal à l’agent JavaScript, qui s’exécute au moyen de l’environnement Node.js installé.
Cette approche offre à l’opération plusieurs occasions de se fondre dans l’activité normale du système. Les packages MSI sont couramment utilisés pour le déploiement en entreprise, PowerShell est un outil d’administration standard et Node.js peut déjà être présent sur les postes de développement. Le caractère suspect provient de leur enchaînement et de leur emplacement, plutôt que d’un exécutable en particulier.
Une fois lancé, ChainScript assure sa persistance au niveau de l’utilisateur au moyen d’une tâche planifiée. Il maintient également une clé de registre Run comme solution de repli, offrant un autre mécanisme d’exécution lors de la connexion de l’utilisateur.
Les informations disponibles ne précisent ni le nom de la tâche planifiée, ni le nom de la valeur de registre, ni les noms des fichiers installés, ni les hachages de fichiers, ni les chemins %LOCALAPPDATA% exacts. Les équipes de défense ne peuvent donc pas s’appuyer sur un ensemble complet d’indicateurs statiques présents sur l’hôte.
Une séquence comportementale utile à examiner est la suivante :
- Un MSI récemment téléchargé est lancé via
msiexec.exe. - L’installateur écrit un runtime Node.js et des fichiers JavaScript sous le profil d’un utilisateur.
- PowerShell ou VBScript lance ces fichiers ou interagit avec eux.
- Une tâche planifiée au niveau de l’utilisateur ou une clé Run apparaît peu après.
- Node.js établit une connexion WebSocket sortante.
Cette chaîne est nettement plus caractéristique que chacun de ses composants pris isolément.
Polygon sert d’annuaire à des serveurs C2 remplaçables
La particularité de ChainScript réside dans son processus de découverte C2 de type EtherHiding. L’implant ne dépend pas exclusivement d’une adresse de serveur intégrée en dur dans son code. Il interroge plutôt un smart contract Polygon pour connaître l’emplacement de son serveur WebSocket de commande et de contrôle actif.
Le processus de connexion comporte quatre étapes principales :
- ChainScript contacte le contrat Polygon concerné.
- Des données contrôlées par le contrat identifient l’infrastructure WebSocket actuelle.
- L’implant se connecte à ce serveur.
- Le serveur fournit les commandes et les tâches supplémentaires.
Un opérateur peut modifier les données de résolution afin de rediriger les machines infectées vers une infrastructure de remplacement. Les implants existants peuvent alors se reconnecter sans nécessiter de nouveau build du malware ni nouvelle interaction avec la victime.
Cette séparation rend les mesures de blocage classiques moins durables. La mise hors service ou le refus d’accès à un hôte WebSocket peut perturber temporairement les opérations, mais l’opérateur peut rediriger le malware tant qu’il conserve le contrôle du processus de résolution adossé au contrat.
Elle réduit également l’intérêt d’extraire une seule adresse réseau à partir d’un échantillon. La détection doit prendre en compte la requête adressée au smart contract, la session WebSocket qui suit et les processus responsables de ces deux activités.
Aucune adresse de contrat Polygon, aucun nom d’hôte WebSocket, aucune adresse IP ni aucune adresse de portefeuille de cryptomonnaies n’a été communiquée. ChainScript n’est par ailleurs associé à aucune vulnérabilité divulguée ni à aucune entrée du catalogue CISA Known Exploited Vulnerabilities.
L’accès à distance s’étend aux captures d’écran, aux charges utiles et aux portefeuilles
Une fois connecté à son serveur, ChainScript peut ouvrir des sessions interactives Command Prompt et PowerShell. L’opérateur bénéficie ainsi d’un contrôle direct, plutôt que de limiter le malware à un ensemble prédéfini de fonctions automatisées de vol de données.
Les commandes prises en charge comprennent :
- La lecture, l’écriture et toute autre manipulation de fichiers
- La capture d’écran
- L’installation de charges utiles supplémentaires
- L’exécution de JavaScript fourni à distance
- La mise à jour de l’implant
- La suppression de ses mécanismes de persistance
- L’inventaire des portefeuilles de cryptomonnaies dans les applications de bureau
- L’inventaire des extensions de navigateur liées aux portefeuilles de cryptomonnaies
Ces capacités peuvent avoir plusieurs conséquences pour les victimes. Les opérateurs peuvent examiner les données locales, surveiller l’activité affichée à l’écran, déployer d’autres malwares et utiliser les shells natifs pour aller au-delà des fonctions intégrées à ChainScript.
La recherche de portefeuilles est particulièrement notable, car elle permet d’identifier des cibles à forte valeur avant un vol ultérieur. Les informations disponibles n’établissent pas que chaque hôte infecté a subi un vol de cryptomonnaies et ne fournissent ni nombre de victimes ni répartition géographique de ChainScript.
La capacité de ChainScript à supprimer sa persistance complique également l’enquête. Un opérateur pourrait effacer certains artefacts tout en laissant d’autres charges utiles en place. Trouver et supprimer le MSI d’origine ne suffirait donc pas à établir que le système est sûr.
Les opérateurs de campagnes ClickFix filtrent également les visiteurs macOS
L’activité Windows s’inscrit dans une tendance plus large d’opérations ClickFix qui associent des commandes exécutées par l’utilisateur à une infrastructure conçue pour déjouer l’analyse automatisée.
Dans un avis distinct publié le 5 août 2026, Microsoft a documenté une campagne ClickFix ciblant macOS et diffusant MacSync ainsi que Atomic Stealer (AMOS). Microsoft n’a pas documenté indépendamment ChainScript ni son résolveur Polygon, mais ses observations montrent comment les sites de diffusion ClickFix peuvent révéler sélectivement du contenu malveillant.
Microsoft a identifié plus de 250 domaines front-end au cours de son suivi. Certains utilisaient des noms de type dictionnaire contenant file, tandis que d’autres ne comportaient pas ce terme. Parmi les exemples figuraient filecopperbasket, applefilevault et cloudsendhub.
L’infrastructure a évolué : les instructions malveillantes, auparavant placées directement dans le code HTML des pages, ont ensuite été remplacées par un profileur JavaScript léger. Ce code collectait des propriétés depuis navigator, screen, window, document, location et console, puis les complétait par des signaux matériels WebGL et des vérifications portant sur le fuseau horaire, l’état des iframes et la prise en charge du tactile.
Les visiteurs ressemblant à de véritables utilisateurs de Mac pouvaient recevoir l’incitation à télécharger le malware. Les robots d’indexation, les sandbox et les systèmes ne répondant pas aux critères pouvaient quant à eux voir une page vide ou un leurre sans rapport.
Sur une page répondant aux critères, accessible à l’adresse apricotfilepoint[.]com, un badge contrefait « Verified Publisher » était affiché et une commande curl obfusquée était proposée. Une autre requête adressée au même domaine renvoyait une fausse page Urban VPN Proxy.
Une seule réponse apparemment légitime constitue donc un indice peu probant. Tester une infrastructure suspecte avec un seul scanner ou un seul profil de navigateur peut faire passer inaperçu un contenu ClickFix diffusé sélectivement.
Les défenseurs doivent privilégier les comportements aux indicateurs figés
Les organisations peuvent commencer par rechercher le nom d’installateur connu, ComponentTask33-4d14e6ac.msi, sans supposer que tous les builds de ChainScript l’utilisent. Les autres noms de build signalés — ComponentTask33, UpdateDigital, HostShared et OrchidViolet66 — offrent des pivots de recherche supplémentaires.
Les équipes responsables des terminaux doivent corréler les activités de msiexec.exe, PowerShell, VBScript et Node.js, en particulier lorsque les fichiers concernés se trouvent sous %LOCALAPPDATA%. Les processus Node.js lancés depuis des répertoires de profils utilisateur récemment créés doivent faire l’objet d’une vérification s’ils ouvrent des connexions WebSocket ou exécutent du JavaScript inhabituel.
Les autres priorités comprennent :
- L’examen des tâches planifiées au niveau de l’utilisateur et des clés de registre Run récemment créées
- L’inspection du trafic WebSocket sortant inhabituel
- La corrélation de l’accès aux smart contracts Polygon avec l’activité de Node.js ou des scripts
- La surveillance des accès aux profils d’extensions de navigateur et aux données des portefeuilles de bureau
- La recherche de captures d’écran et de l’exécution de JavaScript fourni à distance
- La conservation des journaux PowerShell, de création de processus, du planificateur de tâches et du registre
Il convient de rappeler aux utilisateurs de ne pas coller de commandes dans PowerShell, Command Prompt ou macOS Terminal sous prétexte qu’un site web affirme que la vérification, l’installation ou le dépannage l’exige.
Il n’existe aucun utilitaire de suppression dédié à ChainScript. Tout terminal suspect doit être isolé et faire l’objet d’une investigation portant sur l’ensemble de la chaîne d’exécution, les éléments de persistance et les charges utiles secondaires — et pas uniquement sur le MSI initial. Le blocage des seuls C2 statiques risque de ne pas suffire, car le résolveur Polygon de l’implant a été conçu pour survivre à la mise hors service de serveurs backend individuels.
Sources
Cet article est une réécriture originale fondée sur les sources ci-dessous.
- source primaireMicrosoft MSRC
- The Hacker News
