### Versions compromises **Socket** et **StepSecurity** ont identifié trois versions malveillantes du package **node-ipc** : * [email protected] * [email protected] * [email protected] Ces versions contiennent un comportement de vol/backdoor obfusqué conçu pour identifier l'environnement hôte, énumérer et lire les fichiers locaux, compresser et découper les données collectées, encapsuler la payload dans une enveloppe cryptographique, et tenter une exfiltration via un point d'accès réseau sélectionné par logique DNS/adresse. ### Exfiltration de secrets Le code malveillant tente d'exfiltrer une large gamme de secrets de développeurs et de cloud vers un serveur de commande et de contrôle (C2) externe. Cela inclut plus de 90 catégories d'identifiants, tels que **Amazon Web Services**, **Google Cloud**, **Microsoft Azure**, des clés SSH, des jetons Kubernetes, des configurations GitHub CLI, des paramètres Claude AI et Kiro IDE, l'état Terraform, des mots de passe de base de données et l'historique des shells. Les données récoltées sont compressées dans une archive GZIP et transmises au domaine `sh.azurestaticprovider[.]net`. ### Compromission de compte Les versions compromises ont été publiées par un compte nommé "atiertant", qui n'est pas connecté à l'auteur original du package, "riaevangelist". Le compte "atiertant" n'avait aucun historique de publication antérieur lié au package **node-ipc**, suggérant une potentielle compromission de compte ou un ajout malveillant en tant que mainteneur. ### Analyse technique  Contrairement aux attaques typiques s'appuyant sur les hooks de cycle de vie NPM, cette attaque ajoute la payload malveillante sous forme d'une Expression de Fonction Immédiatement Appelée (IIFE) à la fin de `node-ipc.cjs`, provoquant l'exécution du malware de manière inconditionnelle lors de `require('node-ipc')`. La version 12.0.1 inclut une vérification d'empreinte SHA-256, la comparant à un hash codé en dur. Cela signifie que la version 12.0.1 n'est active que sur les machines où le chemin du module principal correspond au hash cible. Les versions 9.x n'ont pas cette restriction et exécuteront la payload complète sur tout système qui les charge. ### Techniques anti-détection Le malware utilise un canal d'exfiltration secondaire via des enregistrements DNS TXT après avoir remplacé le résolveur DNS du système par le DNS public de **Google** pour contourner la sécurité basée sur le DNS local. Il résout `sh.azurestaticprovider.net` en utilisant 1.1.1.1 (primaire) ou 8.8.8.8 (de secours) pour obtenir l'IP du C2, puis cible directement le résolveur à l'IP du C2 pour toutes les requêtes d'exfiltration. Ce détournement DNS direct vers le C2 est une technique anti-détection notable, car les requêtes d'exfiltration n'atteignent jamais les résolveurs DNS publics, rendant l'activité invisible pour les organisations qui s'appuient uniquement sur la journalisation DNS via les résolveurs d'entreprise. De plus, le malware tente de continuer son exécution indépendamment en se dupliquant dans des processus enfants détachés en arrière-plan, permettant à l'exfiltration de persister même après la terminaison de l'application parente. ### Implications "Cette campagne reflète comment les attaques sur la chaîne d'approvisionnement logicielle évoluent au-delà de simples packages malveillants pour devenir des opérations de récolte d'identifiants conscientes de l'infrastructure", a déclaré Avital Harel, responsable de la recherche en sécurité chez **Upwind**. "Les attaquants ciblent de plus en plus les identités et les systèmes d'automatisation qui alimentent les pipelines de livraison logicielle modernes tout en concevant des malwares spécifiquement pour se fondre dans le comportement normal des développeurs et des applications." ### Recommandations Il est conseillé aux utilisateurs de : * Supprimer les versions compromises de **node-ipc** et réinstaller une version connue comme propre (9.2.1 et 12.0.0). * Supposer une compromission et faire pivoter les identifiants et les secrets. * Auditer l'activité de publication NPM pour tout package accessible avec les jetons pivotés. * Examiner les journaux d'exécution des workflows pour toute activité suspecte. * Auditer les journaux du cloud pour vérifier les actions non autorisées effectuées par les identités IAM dont les identifiants étaient disponibles pendant la fenêtre de compromission. * Bloquer le trafic sortant vers le domaine C2.