Des chercheurs en cybersécurité alertent sur une campagne de paquets npm trojanisés qui se présentent comme des utilitaires de calendrier et de suivi d’habitudes, tout en préparant une exécution discrète. Le but : déployer sur des systèmes Linux un implant de contrôle baptisé RedC2 4.0 Linux, capable de piloter la machine compromise et d’enchaîner des actions post-exploitation.
Ce qui rend l’affaire particulièrement préoccupante, c’est la façon dont la charge utile est déclenchée : il suffit d’importer le paquet, y compris via une dépendance transitive, pour que le code malveillant se mette en marche au chargement du module.
Des utilitaires “fonctionnels” qui cachent une charge utile
Les paquets identifiés arborent une apparence légitime. Ils fournissent bien les fonctions annoncées (des calculs liés à des métriques et à la mise en forme de données de type calendrier). Pourtant, sous cette couche “utile”, ils contiennent du code conçu pour déposer un implant malveillant.
Dans le détail, les chercheurs ont relevé plusieurs noms de paquets et versions ciblées, dont :
- streak-metrics-math@1.0.0, 1.0.1
- kit-map-vim@1.0.0
- streak-map-cache@1.0.0
- streak-map-kit@1.0.0
- map-streak-kit@1.0.0
- streak-cache-map@1.0.0
- streak-calc-metrics@1.0.0
- streak-calc-math@1.0.0
- streak-math-abz@1.0.0
- streak-metricsaz@1.0.0
- streak-math-metrics@1.0.0
- streak-metricazbd@1.0.0
- streak-metricsazb@1.0.0
- streak-kit-map@1.0.0
Autre élément déterminant : les binaires déposés dans l’archive changent de nom d’un paquet à l’autre. Les fichiers observés portent par exemple des noms du type math-core.bin, math-calc.bin, calc-math.dat, calc-cache.bin ou encore calc-mapping.bin. Leur emplacement varie aussi, soit directement dans dist/, soit sous dist/internal/.
Déclenchement immédiat au chargement : pas besoin de “hook” d’installation
Les paquets exploitent un mécanisme de chargement qui contourne des contrôles courants. Selon les informations publiées, lorsque le module est chargé, il :
- localise le binaire embarqué,
- le marque comme exécutable,
- le lance en tâche de fond détachée.
Point clé : aucune fonction de type “install hook” n’est nécessaire. Une simple importation depuis le graphe de dépendances suffit à faire exécuter le payload, y compris si le paquet n’est utilisé qu’indirectement (transitive dependency).
Le chargement est assuré par un fichier d’entrée du paquet, notamment dist/index.mjs, décrit comme un “trojan loader”. Il réexporte les helpers censés gérer la logique de dates, puis lance l’implant dès que le module est chargé.
RedC2 4.0 : un C2 axé sur l’évasion et la prise de contrôle
La charge déposée correspond à un beacon Linux lié à RedC2 4.0. Les chercheurs indiquent que ce beacon communique avec un serveur distant, ce qui permet de démarrer des opérations post-exploitation sur l’hôte compromis.
Dans la description de la menace, RedC2 4.0 Linux s’inscrit dans une logique de plateforme multiplateforme. Sur des forums liés à la cybercriminalité, l’outil est présenté comme un framework de commande et contrôle conçu avec une forte orientation vers l’évasion.
Ce framework (développé et diffusé activement) s’appuie sur des capacités C2 étendues, par exemple :
- accès terminal interactif,
- transfert de fichiers,
- livraison de charges utiles par étapes,
- collecte de données et opérations à grande échelle,
- opérations multi-beacons,
- visualisation réseau et tunneling hôte-à-hôte,
- exécution en mémoire (incluant des artefacts de type BOF, .NET et shellcode selon la variante).
Une fois déployé sur Linux, le beacon fournit notamment un accès via /bin/sh et expose des commandes spécifiques pour découvrir le système, manipuler des fichiers et exfiltrer des informations.
Fonctions Linux : exécution via /bin/sh, exploration et pivot réseau
Sur les machines Linux compromises, l’implant établit d’abord la communication avec le serveur de commande. Il s’enregistre en collectant des informations système puis transmet un message de “check-in”. Ensuite, il entre dans une boucle de traitement : réception d’instructions, exécution via /bin/sh, puis retour des résultats.
Les capacités mises en avant incluent :
- découverte du système,
- opérations sur fichiers,
- collecte de données (ex. clés SSH et identifiants liés à des navigateurs),
- exécution en mémoire de composants ELF,
- mise en place d’un proxy SOCKS5,
- pivoting réseau pour étendre la portée de l’attaque.
Extension “IA” : Red Agent et exécution guidée par langage naturel
La campagne ne se contente pas d’un simple agent C2. Les informations publiées indiquent l’existence d’une couche d’assistance par modèle de langage nommée Red Agent. L’idée est de permettre aux opérateurs d’orchestrer des tâches post-exploitation plus complexes à l’aide de requêtes exprimées en langage naturel.
Concrètement, le framework traduirait les intentions formulées sous forme de prompts en commandes exploitables pour les beacons. Selon les descriptions rapportées, cela abaisse la barrière à l’entrée en réduisant la nécessité de maîtriser entièrement la mécanique opérationnelle.
Ce volet “IA” est présenté comme un système d’exécution orienté tests d’intrusion, mais les chercheurs soulignent la manière dont ces briques peuvent être utilisées pour automatiser et accélérer des intrusions.
Ce que cela signifie pour les équipes qui utilisent npm
Cette découverte met en évidence un risque majeur des chaînes logicielles : une dépendance considérée “fonctionnelle” peut devenir un vecteur d’exécution à distance. Et parce que le déclenchement peut survenir dès l’import, les défenses qui ne surveillent que l’installation peuvent être insuffisantes.
Pour réduire l’exposition, les organisations peuvent notamment :
- vérifier les dépendances avec des outils de sécurité (et surveiller les versions),
- limiter l’usage de packages non indispensables,
- contrôler le graphe de dépendances, y compris les dépendances transitive,
- mettre en place des politiques de “reproducible builds” et de provenance,
- surveiller l’apparition d’exécutions inattendues lors du chargement de modules Node.js.
La priorité est de détecter les moments où un paquet exécute autre chose que du code “métier” attendu.
Contexte : la menace progresse avec d’autres attaques supply chain
Les chercheurs rappellent que ces événements surviennent dans un climat plus large d’attaques sur la chaîne d’approvisionnement logicielle. Dans une affaire distincte, trois crates Rust légitimes auraient aussi été compromises via une dépendance malveillante de type proc-macro déclenchée lors des builds (avec un mécanisme automatique côté compilation).
Même si ces exemples concernent des écosystèmes différents, la leçon reste la même : dès que la chaîne d’outillage sert de point de passage, l’impact peut être large et difficile à attribuer a posteriori.
Conclusion : méfiance envers les dépendances “qui font le job”
Les paquets npm trojanisés documentés ici montrent comment une attaque peut se camoufler dans du code apparemment utile, tout en déployant RedC2 4.0 Linux via un déclenchement immédiat au chargement. Avec une logique C2 orientée évasion et des capacités d’exfiltration et de pivot réseau, le risque dépasse largement le simple “typo” ou la faute de configuration.
Pour limiter les dégâts, il est essentiel de traiter les dépendances comme des composants critiques : analyser le graphe complet, restreindre les imports inutiles et surveiller les comportements anormaux dès l’exécution du module. En cybersécurité, ce n’est pas parce qu’un package rend un service qu’il est sûr.
Source: https://thehackernews.com/2026/08/14-trojanized-npm-packages-drop-redc2.html
