Campagne de dépendances à distance de PhantomRaven qui met en check npm

Ces derniers mois, la communauté JavaScript a de nouveau reçu un rappel inconfortable : les chaînes d'approvisionnement logicielles restent l'un des vecteurs préférés des attaquants. Une campagne connue comme "PhantomRaven", initialement détectée à la fin de 2025 et élargie par la recherche ultérieure, a été la publication de paquets malveillants dans le registre npm avec l'intention de voler des données sensibles des développeurs et des environnements d'intégration continue.

La particularité technique de PhantomRaven est son utilisation de dépendances dynamiques à distance (dépendances dynamiques à distance, RDD), une tactique simple mais efficace: au lieu d'intégrer le code malveillant dans le paquet publié, les attaquants pointent du paquet. fichier json vers une unité hébergée dans une URL externe. Lors de l'installation de npm, cette unité est téléchargée depuis le serveur de l'attaquant et exécutée, en évitant dans de nombreux cas les vérifications statiques automatisées qui analysent le contenu du paquet dans le registre. Vous pouvez voir une explication technique de la façon dont npm joue paquet. json dans la documentation officielle npm: https: / / docs.npmjs.com / cli / v9 / conforming-npm / package-json.

La recherche publique sur PhantomRaven, y compris celle d'Endor Labs, décrit plusieurs vagues de publication: après la découverte initiale de nouveaux tours ont été détectés entre novembre 2025 et février 2026, dans lesquels les attaquants ont lancé des dizaines de paquets à partir de comptes jetables. Endor Labs documente en détail la persistance de la campagne, la cohérence de la charge utile et l'infrastructure associée; votre rapport est disponible ici: https: / / www.endorlabs.com / learn / return / of-phantomraven. D'après ces analyses, de nombreux échantillons sont encore accessibles dans le dossier npm.

Une autre caractéristique récurrente de la campagne est l'utilisation de techniques de « slopsquatting » ou de typosquatting : des paquets malveillants essaient de ressembler à des projets légitimes très utilisés - par exemple Babel ou GraphQL Codegen - en publiant des noms qui pourraient être confondus avec ceux suggérés par des assistants automatiques ou par qui ils copient et collent rapidement une recommandation. La combinaison de noms convaincants et de dépendance à distance réduit la probabilité de détection et augmente la probabilité qu'un développeur installe le paquet par erreur.

Une fois le code malveillant atteint la machine, son objectif est clair et dangereux : recueillir des informations qui permettent à l'attaquant de se déplacer latéralement ou d'exfilter des secrets. Endor Labs note que les échantillons cherchent des fichiers locaux et des configurations telles que .gitconfig et .npmrc, des variables d'environnement et des jetons utilisés par les pipelines CI / CD - GitHub, GitLab, Jenkins, CircleCI -; ils collectent également des impressions système (IP, hostname, Node version) pour façonner la victime. L'envoi de données au serveur de commande (C2) est généralement effectué par HTTP GET, bien que les auteurs aient également utilisé POST et WebSocket pour assurer la redondance.

L'infrastructure utilisée par PhantomRaven a montré des modèles répétés: domaines qui incluent le mot "artefact", serveurs sur Amazon EC2 qui manquent souvent de certificat TLS, et une charge utile dont la plupart du code est resté inchangé entre les vagues. Cependant, les opérateurs ont tourné npm et post comptes, des métadonnées ajustées et modifié les paramètres PHP pour rester opérationnels avec des changements minimes.

Cela laisse plusieurs leçons pratiques pour tout développeur ou équipe de sécurité. Premièrement, il n'y a pas de raccourci : vérifier l'origine d'un paquet et sa publication est plus importante que jamais. Il ne suffit pas de copier celui suggéré par un chatbot ou de coller sans regarder un nom qui « sonne bien ». Inspecter package.json, examiner la réputation de l'auteur et du publicateur, et vérifier l'existence d'un dépôt source raisonnable sont des étapes simples qui peuvent éviter de nombreuses surprises désagréables. Pour ceux qui gèrent les pipelines et les dépôts, il est recommandé de permettre le balayage des unités et les outils de détection secrets qui sont intégrés dans le flux de travail; GitHub offre des fonctionnalités de numérisation secrète et de Dependabot pour les mises à jour de sécurité qui aident à réduire le risque: https: / / docs.github.com / fr / code-security / secret-scanning.

Il convient également d'appliquer des contrôles de sécurité sur les jetons et les identifiants : limiter la portée des jetons CI / CD, les faire pivoter régulièrement et ne pas les exposer dans des fichiers qui peuvent être lus par des processus tiers. Au niveau organisationnel, la pratique consistant à construire des artefacts dans des environnements isolés et à utiliser des listes d'autorisations de paquets fiables (plutôt que d'installer des paquets à partir de documents publics sans supervision) réduit la surface d'attaque. Des ressources telles que l'OWASP et l'analyse de la chaîne d'approvisionnement fournissent des conseils utiles sur l'hygiène des unités et la détection précoce : https: / / owasp.org / www-project-dependency-check /.

Il existe également des solutions commerciales et communautaires qui peuvent contribuer à atténuer les risques : scanners de sécurité des unités, miroirs de paquets privés et politiques de publication plus strictes dans les dépôts internes. Des plateformes telles que Snyk ont publié des guides et des analyses sur la façon dont les chaînes d'approvisionnement demeurent des vecteurs critiques; voir, par exemple, leur couverture des attaques de la chaîne d'approvisionnement: https: / / snyk.io / blog / Supply-chain-attaques /.

Bien que la technique de PhantomRaven ne soit pas sophistiquée du point de vue cryptographique ou d'obfuscation du code - la charge utile à peine changée entre les échantillons - son efficacité réside dans la simplicité opérationnelle et dans l'exploitation des habitudes humaines: s'appuyer sur des noms, suivre des exemples non vérifiés et des installations de fonctionnement dans des environnements privilégiés. Un petit changement dans les habitudes de développement et l'adoption de contrôles de sécurité de base peuvent réduire significativement l'exposition.

Si vous êtes un développeur, vérifiez vos projets et pipelines : recherchez des unités qui pointent vers des URLs externes dans le paquet. json, confirmez qu'il n'y a pas de paquets inconnus dans vos fichiers de verrouillage et envisagez de scanner des machines de développement et des coureurs CI avec des outils qui détectent des communications anormales vers des domaines suspects. Si vous dirigez une organisation, elle favorise des politiques de confiance zéro pour les paquets tiers et fournit aux équipes un catalogue d'unités approuvées et mises à jour.

L'industrie a déjà eu des épisodes similaires et les solutions sont largement connues. La leçon est que la surveillance doit être continue: les agresseurs répéteront les modèles qui fonctionnent et tourneront le minimum nécessaire pour aller de l'avant. Restez informé, appliquez des contrôles techniques et, surtout, vérifiez deux fois avant d'installer, sont des étapes qui font maintenant partie de la sécurité de base de tout projet basé sur npm.