Des paquets npm de calendriers dissimulent RedShell, le beacon Linux de RedC2 4.0

Une simple importation suffit à lancer le malware

Des chercheurs de TrendAI, la division dédiée aux entreprises de Trend Micro, ont identifié un groupe de paquets npm trojanisés présentés comme des utilitaires de calendrier, de gestion des dates et des « streaks ». La découverte a été rendue publique le 21 août 2026.

Ces modules remplissent effectivement les fonctions annoncées, mais contiennent également le beacon Linux RedShell, un composant du framework de commande et contrôle RedC2 4.0. Le payload s’exécute automatiquement au chargement du module.

Il n’est donc nécessaire ni d’utiliser un script postinstall, ni d’appeler explicitement une fonction. Il suffit que l’application importe le paquet, y compris indirectement par l’intermédiaire d’une dépendance transitive.

Ce mécanisme élargit considérablement la surface d’attaque. Un développeur peut ne jamais avoir ajouté directement l’un de ces utilitaires à l’application, tout en le recevant dans l’arbre des dépendances et en déclenchant le malware au démarrage du processus Node.js.

Les paquets et fichiers binaires à rechercher

Les paquets et versions identifiés sont les suivants :

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

Le code malveillant est injecté dans dist/index.mjs, qui conserve les exports des utilitaires légitimes tout en servant de loader.

Lors de son chargement, le fichier localise le composant binaire inclus dans le paquet, modifie ses permissions pour le rendre exécutable, puis le lance comme processus détaché en arrière-plan. L’application peut ainsi continuer à utiliser les fonctions liées aux dates sans signal évident pour l’utilisateur.

Le payload peut porter différents noms :

• math-core.bin
• math-calc.bin
• calc-math.dat
• calc-cache.bin
• calc.bin
• calc-mapping.bin

Les fichiers se trouvent directement dans le répertoire dist/ ou dans dist/internal/. Selon l’analyse, leur contenu correspond au même beacon Linux RedShell pour RedC2 4.0.

Ce que RedShell peut faire sur un hôte Linux

RedShell collecte des informations de base sur le système compromis et les transmet à l’infrastructure de commande et contrôle lors du premier « check-in ». Il reste ensuite en attente d’instructions, qu’il exécute via /bin/sh avant d’en renvoyer les résultats à l’opérateur.

Les fonctionnalités observées comprennent l’accès interactif au terminal, la gestion des fichiers, le transfert de données et le déploiement de payloads supplémentaires. Le beacon peut également collecter des clés SSH et des identifiants enregistrés dans les navigateurs.

Ses fonctions comprennent notamment :

• la reconnaissance du système et du réseau ;
• l’exécution de commandes ;
• des mécanismes de persistance ;
• l’exécution en mémoire de fichiers ELF ;
• l’exécution de Beacon Object Files ;
• l’exécution d’assembly .NET et de shellcode ;
• un proxy SOCKS5 ;
• le pivoting vers d’autres systèmes du réseau.

L’ensemble de ces fonctionnalités dépasse le simple accès à distance. Un hôte infecté peut servir de point d’appui pour collecter des secrets, se déplacer dans le réseau de l’entreprise, relayer du trafic et charger d’autres composants.

Les variantes de RedC2 destinées à Windows et macOS offrent des capacités similaires de reconnaissance de l’hôte, d’énumération des utilisateurs, de gestion des fichiers et de collecte de données. La version Windows inclut également des fonctions de contournement de l’UAC, de détection et de manipulation des solutions antivirus et d’endpoint detection, d’exécution de code en mémoire et de facilitation du mouvement latéral. Ces fonctionnalités ne semblent pas disponibles dans la variante macOS.

RedC2 4.0 intègre un agent basé sur un LLM

RedC2 4.0 est présenté comme un framework multiplateforme pour Windows, macOS et Linux. L’acteur « MarlboroMan » en a fait la promotion sur Hack Forums au début du mois de juin 2026, le décrivant comme un produit conçu avec l’évasion pour objectif central.

La version 3.0 avait été vendue en janvier, tandis que la version 2.0 était sortie en août 2025. RedShell Linux a été introduit avec la version 4.0, ce qui témoigne de l’évolution active du toolkit.

Le framework est également commercialisé sur le site clearnet Red Offsec, où il est proposé au prix de 99,99 dollars comme produit multi-OS et multilingue. Les conditions d’utilisation interdisent officiellement toute utilisation contre des systèmes non autorisés, mais ces clauses n’empêchent pas un usage criminel de l’outil.

Le package comprend RedC2 EXT, une extension en ligne de commande, ainsi que Red Agent, un composant basé sur un large language model. Ce dernier permet à l’opérateur de décrire en langage naturel l’action souhaitée, par exemple une reconnaissance du réseau ou un dump d’identifiants.

Le système convertit l’intention en séquences de commandes à envoyer aux beacons. Cette automatisation ne supprime pas la nécessité d’un accès initial, mais peut réduire les compétences requises pour mener des opérations post-compromission complexes et en plusieurs étapes.

Risques pour les développeurs et les infrastructures d’entreprise

Le risque concerne principalement les systèmes Linux qui installent l’un des paquets listés ou le reçoivent par l’intermédiaire d’une dépendance indirecte. Le fonctionnement normal des utilitaires peut retarder la détection : le module produit le résultat attendu tandis que le loader exécute le beacon en parallèle.

La compromission peut entraîner l’exécution arbitraire de commandes, le vol d’identifiants, la collecte de clés SSH, l’accès aux fichiers et l’installation de payloads supplémentaires. Dans les environnements d’entreprise, un proxy SOCKS5 et le pivoting peuvent transformer un simple poste de travail ou un serveur de build en point d’accès vers les systèmes internes.

Cette découverte est par ailleurs intervenue peu après une autre attaque de la supply chain ayant ciblé trois crates Rust légitimes : [email protected], [email protected] et [email protected].

Dans ce cas, la dépendance malveillante proc-macro1 pouvait exécuter automatiquement un malware multiplateforme lors des builds Cargo. Le composant dressait le profil de l’appareil, recensait les navigateurs fondés sur Chromium, assurait la persistance, contactait l’infrastructure des attaquants et téléchargeait d’autres payloads.

Le vol des identifiants utilisés par le mainteneur pour publier les paquets est suspecté. Des recoupements d’infrastructure ont également été observés avec de précédentes attaques de la supply chain visant Mastra et Axios, attribuées à des acteurs nord-coréens.

Contrôles immédiats et remédiation

Aucun correctif spécifique aux paquets npm concernés n’est connu à ce jour. Les organisations doivent les bloquer et les supprimer, en vérifiant les dépendances déclarées directement ainsi que l’ensemble de l’arbre transitif.

Les contrôles prioritaires sont les suivants :

1. analyser package-lock.json, les autres lockfiles npm et les caches locaux ;
2. rechercher les fichiers suspects dans les répertoires dist/ et dist/internal/ ;
3. vérifier la présence de processus Linux inhabituels lancés en arrière-plan ;
4. rechercher les connexions vers des infrastructures C2 inconnues ;
5. examiner la persistance, l’utilisation inhabituelle de /bin/sh, les proxys SOCKS5 et le pivoting ;
6. isoler les hôtes suspects avant la remédiation ;
7. renouveler les mots de passe, tokens, clés SSH et autres secrets présents sur les systèmes ;
8. conserver les éléments utiles à l’analyse forensique.

Pour prévenir ce type d’incident, il convient de mettre en place le pinning des versions, des allowlists de paquets, des analyses avant installation et des contrôles des modifications publiées dans les dépôts. Les environnements Cargo doivent également soumettre les dépendances proc-macro à des vérifications spécifiques, car elles peuvent exécuter du code pendant la compilation.