ViteVenom: la nouvelle menace npm qui cache un RAT dans l'importation et utilise les blockchains comme C2

Les chercheurs en sécurité ont identifié une nouvelle vague de paquets malveillants dans l'écosystème de npm qui cible les développeurs à l'aide de l'outil de construction avant Vite. La campagne, appelée par certains analystes comme ViteVenom, fait partie d'une opération majeure liée à ce qu'on appelle ChainVeil et montre une évolution tactique importante: l'abus direct de l'écosystème de paquet pour introduire un chargeur (chargeur) qui obtient et lance un trojan d'accès à distance (RAT) à partir d'une infrastructure de commande et de contrôle (C2) basée sur plusieurs blockchains.

L'importance technique de l'attaque réside dans la méthode de livraison. Au lieu d'exfilter la charge utile à partir de domaines ou serveurs traditionnels qui peuvent être fermés, le code malveillant consulte les transactions publiques dans des chaînes telles que Tron et Binance Smart Chain, décodifie les données intégrées dans les champs de transaction, et récupère ainsi les points à la prochaine étape de malware. Cette approche rend les chaînes de blocs publiques une sorte de couche de stockage distribué et immunitaire à la prise directe des autorités, et rend difficile de briser l'infrastructure d'attaque.

Les paquets détectés ont été publiés à la fin de juin et au début de juillet 2026 et ont été conçus pour apparaître comme faisant partie de l'écosystème Vite au moyen de noms de champ (scoped) imitant l'espace de noms officiel. Parmi les paquets identifiés figurent des références à des paquets avec préfixes similaires à @ vitecs et des variantes qui incluent des chaînes telles que vite-tree, vite-ui et vite-ts, publiés sous différents responsables et avec des chiffres de téléchargement allant de dizaines à plus de mille. L'utilisation de noms ayant une portée pour prétendre faire partie du projet officiel est un changement tactique qui augmente la probabilité qu'un développeur ne les soupçonne pas.

Une autre caractéristique alarmante est que le code malveillant n'est pas lancé pendant l'installation, mais à Importation l'unité en temps de mise en œuvre. Cela réduit l'efficacité de nombreuses solutions de sécurité qui analysent les crochets d'installation ou les signatures de fichiers dans les dépôts de paquets, parce que le comportement nuisible n'apparaît que lorsque le code fait partie du paquet ou est exécuté dans l'application développeur.

Les implications pour les projets et les organisations sont claires : la chaîne d'approvisionnement des logiciels n'est plus un vecteur théorique mais un domaine opérationnel où les attaquants explorent des techniques sophistiquées pour persister et échapper à l'interruption. La dépendance à l'égard des infrastructures publiques, telles que les blockchains pour stocker les points et les charges, rend la détection et le blocus traditionnel difficiles, et nécessite une refonte des contrôles de réaction préventive et incidente dans les environnements de développement et de CI / CD.

Si vous soupçonnez que votre projet peut être touché, les mesures immédiates et les meilleures pratiques comprennent l'élimination de tout paquet engagé, une vérification approfondie des unités et des fichiers de configuration de l'environnement du shell (p. ex. .bashrc, .zshrc et .profile) pour les modifications non autorisées, et la rotation des lettres d'identité qui peuvent avoir été filtrées. À moyen terme, il convient de renforcer les politiques de gouvernance des unités : utiliser des fichiers de verrouillage vérifiables (fichier de verrouillage), exiger la révision des unités pour les dépôts, appliquer des restrictions d'évacuation dans les environnements CI pour limiter les connexions sortantes non autorisées et tenir à jour les inventaires SBOM pour savoir quels composants sont utilisés. La combinaison des contrôles préventifs dans la phase de développement et de détection du temps de performance est essentielle.

Les outils d'analyse de la composition du logiciel (SCA) et de numérisation des paquets peuvent aider à détecter les signaux de risque, mais ils doivent être complétés par des politiques humaines : vérifier la source des responsables, exiger l'authentification multifactorielle pour publier des comptes et observer des modèles d'importation inhabituels dans les dépôts. Il est également prudent d'incorporer des règles de verrouillage pour les appels sortants vers des nœuds et des API associés aux blockchains utilisés par les attaquants et de surveiller le trafic DNS et HTTP à la recherche de communications vers des serveurs C2 connus.

Pour ceux qui se développent avec Vite, il est recommandé d'examiner la documentation officielle et les pratiques de sécurité des écosystèmes, et de limiter l'adoption de paquets qui n'ont pas d'historique et d'entretien vérifiable. Vous pouvez commencer par consulter le site officiel de Vite https: / / vitess.dev / et examiner les bonnes pratiques de sécurité dans la chaîne d'approvisionnement dans des projets comme la chaîne d'approvisionnement logicielle OWASP : https: / / owasp.org / www-project-software-Supply-chain-security /. Pour ceux qui gèrent des unités à l'échelle de l'entreprise, des services tiers qui offrent la numérisation et la surveillance continue des paquets, tels que Snyk ou les outils de sécurité des dossiers de colis peuvent faire partie d'une stratégie d'atténuation plus vaste.

Enfin, cette campagne renforce une leçon déjà commune en matière de sécurité: il n'y a pas de solution unique. La détection, la prévention et les interventions doivent être intégrées à la gouvernance du développement et aux contrôles des réseaux. atténuer le risque que posent les chaînes d'approvisionnement modernes. Ceux qui maintiennent des projets publics et des paquets de consommateurs doivent supposer que toute nouvelle unité doit être vérifiée et que la visibilité continue des applications de production est essentielle pour contenir de tels incidents.