TL; DR
Le paysage des menaces pesant sur la chaîne d'approvisionnement open source a profondément changé. Trois tendances convergentes redéfinissent le risque :
Les vers à reproduction autonome sont arrivés.
- Shai Hulud (Septembre 2025) : Première attaque de ver npm — vol d’identifiants via postinstall hooks, puis s'est republié de manière autonome sur environ 700 versions de paquets en utilisant des jetons de mainteneur compromis.
- Ver de verre (Octobre 2025) : Extension VS Code malveillante utilisant des charges utiles invisibles encodées en Unicode et un serveur de commande et de contrôle (C2) indestructible basé sur la blockchain (Solana). Plus de 35 000 installations, fonctionnalités complètes de RAT ciblant les portefeuilles de cryptomonnaies.
- Shai-Hulud 2.0 (Nov 2025) : Passage inter-registres de npm à Maven Central via des outils de mise en miroir automatisés, plus GitHub Discussions utilisé comme C2 et une solution de repli destructrice.
L'IA est désormais l'opérateur, et non plus seulement l'outil.
Une campagne de cyberespionnage documentée a été menée de manière autonome grâce à Claude, utilisé comme moteur d'orchestration : reconnaissance, exploitation, déplacement latéral et exfiltration, avec une supervision humaine minimale. La barrière à l'entrée pour les attaques sophistiquées est passée de l'exigence d'une « équipe d'experts » à celle d'une « personne capable de comprendre les instructions ».
Abus d'infrastructures à grande échelle
La campagne IndonesianFoods a inondé npm d'environ 44 000 paquets de spam exploitant les systèmes de récompense de la blockchain (protocole TEA), et ce pendant près de deux ans avant d'être nettoyée. Des scénarios d'attaques de type « red team » exploitent également l'infrastructure open source.
Conclusion
Chaque machine de développeur compromise représente désormais un point d'entrée potentiel pour la propagation de vers informatiques. Le vol d'identifiants permet une propagation autonome. L'IA peut orchestrer des attaques à la vitesse d'une machine. Les méthodes traditionnelles de détection et de neutralisation sont inefficaces face à des serveurs de commande et de contrôle immuables et à la propagation inter-registres. La défense doit partir du principe que la compromission est avérée et privilégier la rapidité du confinement.
Nouvelles menaces pour les écosystèmes open source : vers, logiciels malveillants conçus par l’IA et abus de confiance à grande échelle
L'écosystème open source est confronté à un changement de paradigme concernant les menaces pesant sur sa chaîne d'approvisionnement. Les logiciels malveillants traditionnels ne se propageaient pas d'eux-mêmes, l'intelligence artificielle n'était pas utilisée par les acteurs malveillants et la portée des attaques était limitée.
Ces derniers mois, nous avons assisté à la convergence de trois catégories de menaces qui, bien que préoccupantes individuellement, représentent une changement fondamental dans le paysage des risques liés au développement logiciel, considérés dans leur ensemble :
- Vers à reproduction autonome dans les écosystèmes d'emballageDes logiciels malveillants se propagent de manière autonome grâce au vol d'identifiants et à la republication automatisée. Chaque machine de développeur compromise devient ainsi un nouveau vecteur d'infection.
- Génération et exploitation de logiciels malveillants alimentés par l'IALes acteurs malveillants utilisent de grands modèles de langage pour écrire des charges utiles, découvrir des vulnérabilités et orchestrer des attaques à la vitesse de la machine.
- Exploitation de la confiance à grande échelleCertains acteurs abusent systématiquement des récompenses pour les contributions open source, l'infrastructure des dépôts et les outils de développement, créant des pics de milliers de publications de paquets spam, affectant les registres.
Les techniques clés permettant des attaques sophistiquées contre la chaîne d'approvisionnement logicielle ne sont plus théoriques. Elles sont désormais mises en œuvre, documentées et de plus en plus accessibles à des acteurs malveillants moins expérimentés. Les obstacles à la réalisation de telles attaques se sont effondrés : ce qui nécessitait autrefois des équipes d'attaquants chevronnés peut maintenant être exécuté par des agents d'IA avec une supervision humaine minimale.
Cet article examine des incidents récents impliquant directement des logiciels libres malveillants ou exploitant l'infrastructure de l'IA et des logiciels open source, analyse les nouvelles techniques qui les ont rendus possibles et explore les nouvelles capacités susceptibles de définir la prochaine génération de menaces. Enfin, la dernière section aborde les mesures à prendre pour limiter les risques.
REMARQUE : Affiche générée par IA, qui présente des lacunes importantes dans la compréhension de la situation. L’IA est loin d’être parfaite pour certains usages.
Sha1-Hulud : Première attaque de ver auto-réplicatrice contre Npm
Découvert le 14 septembre 2025, Shai Hulud Il s'agit de la première attaque de ver auto-propagative documentée dans l'écosystème npm. Le nom a été choisi par des cybercriminels qui semblent être des amateurs de science-fiction ! L'attaque a débuté avec des identifiants de développeur compromis, probablement obtenus via des campagnes d'hameçonnage usurpant l'identité de npm. login invites ou contournements de l'authentification multifacteur. Une fois à l'intérieur, le ver a exécuté une attaque en plusieurs étapes qui a transformé le vol d'identifiants en propagation autonome. L'attaque était suffisamment grave pour mériter une CISAlerte.
Architecture technique :
Le logiciel malveillant fonctionne via une charge utile JavaScript fortement minifiée et regroupée avec Webpack (bundle.js) qui s'exécute via un hook post-installation…
Récolte des informations d'identification :
Lors de son exécution, la charge utile met en œuvre une découverte de secrets exhaustive :
- Dumps
process.envet analyse le système de fichiers à la recherche de secrets à haute entropie - Exécute TruffleHog pour une analyse systématique des identifiants
- Interroge les points de terminaison des métadonnées du cloud (
169.254.169.254,metadata.google.internal) - Cible les jetons npm dans
.npmrc, les PAT GitHub et CI/CD secrets
Infrastructure d'exfiltration :
L'attaque par ver utilise plusieurs stratégies d'exfiltration :
- abus de GitHub Actions: Flux de travail contenant
${{ toJSON(secrets) }}qui sérialisent tous les secrets du dépôt.
Propagation autonome :
Le mécanisme d'auto-réplication du ver fonctionne selon l'algorithme suivant (en pseudo-code) :
function propagate(token, owner) {
userPackages = npmApi.listPackages(owner, token);
for (pkg in userPackages) {
tgz = npmApi.fetchTarball(pkg, token);
modified = injectBundleAndPostinstall(tgz);
npmApi.publish(modified, token);
}
} Avec n'importe quel jeton npm volé, le ver énumère tous les paquets appartenant au mainteneur compromis, injecte bundle.js avec un hook post-installation et des republications. Ce comportement autonome a fait passer le nombre de paquets infectés de quelques dizaines à plusieurs centaines en quelques heures.
Mesures d'impact :
- Détection initiale : 14 septembre 2025, par Daniel Pereira Le « patient zéro » semble être
rxnt-authentication:0.0.3. - Rayon d'explosion de l'attaque : Environ 700 versions de paquets malveillants ont été publiées, ciblant des systèmes importants totalisant des millions de téléchargements hebdomadaires. Ces attaques se limitent aux paquets npm et aux dépôts GitHub.
- Infrastructure : C2 à
217.69.3.218, exfiltration vers140.82.52.31:80/wall - Persistance: Flux de travail GitHub sur des branches nommées
shai-hulud - Indicateurs observables : Repos retournés au public avec
-migrationsuffixe
Shai-Hulud est un ver informatique spécialisé dans la collecte de données confidentielles. Il ne vise pas à voler de l'argent ni à détruire des infrastructures. Les données exfiltrées et les référentiels exposés peuvent être utilisés pour des attaques ciblées ; les dommages consécutifs liés au vol d'identifiants pourraient donc se manifester ultérieurement. Le véritable coût réside dans la remédiation, le renouvellement des identifiants et le risque d'attaques secondaires.
Un effet positif était obligeant GitHub/NPM à prendre des mesures immédiates : déprécier les jetons classiques hérités et autres références d'édition faibles, et tendre vers le « jardin d'Éden de l'OIDC » OpenSSF's Éditions de confiance .
Mais poursuivez votre lecture ! Le ver a de nouveau émergé des sables d'Arrakis.
Sha1-Hulud 2.0 : Le ver d’Arrakis contre-attaque
Deux mois après la campagne initiale Shai-Hulud, les auteurs de la menace sont revenus avec « La Seconde Venue » — une vague nettement plus agressive qui a tiré des leçons des faiblesses de la première attaque. La campagne s'est auto-identifiée par le biais de dépôts étiquetés « Sha1-Hulud : La Seconde Venue. »
Examinons les principales différences par rapport à la première vague. preinstall Le hook a remplacé le vecteur d'exécution post-installation d'origine. Selon Panther, @asyncapi/avro-schema-parser@3.0.25 Il a été le « patient zéro » de cette deuxième vague, exploitant une vulnérabilité. pull_request_target Déclencheur de flux de travail. (Si vous connaissez quelqu'un qui utilise cela, veuillez lire la suite.) Pourquoi la cible de la requête de tirage est-elle si dangereuse ? ).
Propagation inter-registres :
Le ver s'est propagé de npm à Maven Central via une réplication automatisée. mvnpm Cet outil, qui convertit les paquets npm en artefacts Maven sans contrôle de sécurité, a republié automatiquement des paquets npm compromis, tels que : posthog-node@4.18.1 as org.mvnpm:posthog-node:4.18.1.
Il s'agissait du premier ver inter-registres connu : une compromission de npm ayant un impact sur l'écosystème Java sans interaction directe. Maven Central a supprimé les artefacts le 25 novembre 2025, mais la période d'exposition a continué d'affecter les charges de travail Java/JVM. enterprise construire des systèmes.
Durée d'exécution de Bun pour l'évasion :
Les attaquants ont déployé un preinstall: node setup_bun.js crochet qui a installé le Corfou exécution pour contourner la surveillance spécifique au nœud. Bun a permis une exécution plus rapide pour la charge utile obfusquée de plus de 480 000 lignes (bun_environment.js) et a contourné l'instrumentation traditionnelle de Node.js.
GitHub Actions en tant qu'infrastructure de commandes :
Le ver a déployé des exécuteurs GitHub Actions auto-hébergés cachés dans $HOME/.dev-env/ sur Windows, macOS et Linux. Plus avancé encore, il a créé discussion.yaml des flux de travail qui écoutaient les événements de GitHub Discussions et exécutaient les corps des messages de discussion comme des commandes shell, transformant ainsi GitHub Discussions en un canal C2 invisible.
Capacité d'essuyage destructeur :
Contrairement à la première vague, qui se concentrait sur la collecte d'identifiants, Shai-Hulud 2.0 a introduit une essuie-glace destructeur Ce mécanisme se déclenchait en l'absence d'identifiants valides pour la propagation. Ce « dispositif de sécurité » garantissait des dommages même en cas d'échec de la réplication, marquant ainsi un passage d'opérations purement axées sur l'espionnage à des campagnes potentiellement destructrices.
Malgré l'utilisation de techniques furtives (environnement d'exécution Bun, obfuscation), la campagne a été extrêmement bruyante : republication de centaines de paquets, création de multiples dépôts publics, téléchargement massif de fichiers d'identifiants et installation de processus d'exécution auto-hébergés persistants. Ce rythme agressif contraste fortement avec les attaques traditionnelles contre la chaîne d'approvisionnement, qui reposent sur la furtivité. Il suggère une volonté d'infliger un impact rapide ou une tactique de « saturation » délibérée visant à maximiser les dégâts en un laps de temps très court.
GlassWorm : Le code invisible rencontre la blockchain C2
Le 17 octobre 2025, une extension VS Code nommée GlassWorm a introduit deux techniques sans précédent dans le paysage des menaces pesant sur la chaîne d'approvisionnement : un code malveillant invisible utilisant la furtivité Unicode et une infrastructure de commande et de contrôle basée sur la blockchain.
Technique de furtivité Unicode :
L'innovation majeure de GlassWorm réside dans l'exploitation des sélecteurs de variantes Unicode — des caractères spéciaux qui ne produisent aucun résultat visuel mais restent exécutables en JavaScript. Ceci génère du code malveillant qui apparaît sous forme de lignes vides dans les éditeurs de code, les comparaisons GitHub et la coloration syntaxique des IDE. Cette technique compromet fondamentalement la relecture humaine du code en dissimulant la logique exécutable dans des zones visuellement vides.
L'attaque ciblait les extensions VS Code disponibles sur la plateforme OpenVSX. L'analyse de l'extension CodeJoy (v1.8.3) a révélé d'importantes sections invisibles contenant du code JavaScript exécutable encodé avec des caractères Unicode non imprimables. Pour un développeur examinant le fichier, le contenu apparaît normal, avec des lignes vides. En revanche, pour l'environnement d'exécution JavaScript, il s'agit d'une charge utile malveillante complète.
Architecture C2 basée sur la blockchain :
GlassWorm met en œuvre un mécanisme de commande et de contrôle inviolable utilisant la blockchain Solana. Le logiciel malveillant recherche les transactions provenant d'une adresse de portefeuille codée en dur ; les champs de mémo de transaction contiennent des objets JSON avec des URL encodées en base64.
Cette architecture offre des avantages considérables :
- ImmutabilitéLes transactions blockchain ne peuvent être ni modifiées ni supprimées.
- l'anonymatLes portefeuilles de cryptomonnaies sont pseudonymes et difficiles à tracer.
- Résistance à la censureAucun fournisseur d'hébergement à presser, aucune infrastructure à saisir.
- Trafic légitimeLes connexions aux nœuds RPC de Solana sont indiscernables de l'activité blockchain ordinaire.
- Mises à jour dynamiquesDe nouvelles URL de charge utile peuvent être envoyées pour moins de 0.01 $ par transaction.
Même si les défenseurs bloquent le serveur de charge utile décodée (217.69.3.218Les attaquants peuvent simplement publier une nouvelle transaction pointant vers une URL alternative. Chaque système infecté récupérera automatiquement cette nouvelle adresse.
Sauvegarde C2 : Google Agenda
Par mesure de sécurité, GlassWorm utilise un événement Google Agenda comme canal C2 secondaire. Le titre de l'événement contient une URL de charge utile encodée en base64.
https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3DCela permet de proposer un service légitime qui contourne les contrôles de sécurité et peut être mis à jour simplement en modifiant l'événement du calendrier.
Livraison de la charge utile :
Les serveurs C2 acheminent des charges utiles chiffrées à l'aide d'AES-256-CBC. Les clés de déchiffrement sont générées pour chaque requête et transmises via des en-têtes HTTP personnalisés, garantissant ainsi que les charges utiles interceptées ne peuvent être déchiffrées sans une nouvelle requête.
ZOMBI : Capacités RAT à spectre complet
La charge utile finale (ZOMBI) transforme les postes de travail des développeurs infectés en infrastructure criminelle :
- Serveur proxy SOCKSDéploie des serveurs proxy pour acheminer le trafic des attaquants via les réseaux des victimes, permettant ainsi l'accès interne et l'anonymisation.
- WebRTC P2P: Établit des canaux de contrôle pair à pair qui contournent les pare-feu grâce à la traversée NAT.
- BitTorrent DHTUtilise des tables de hachage distribuées pour une distribution de commandes décentralisée qui ne peut pas être arrêtée.
- VNC caché (HVNC): Permet un accès invisible au bureau à distance, fonctionnant dans des bureaux virtuels qui n'apparaissent ni à l'écran ni dans le Gestionnaire des tâches.
Ciblage du portefeuille de crypto-monnaie :
ZOMBI recherche activement 49 extensions de portefeuilles de cryptomonnaies différentes, dont MetaMask, Phantom et Coinbase Wallet. Combiné à un accès distant invisible, cela permet le vol direct de fonds depuis les machines des développeurs.
Collecte et propagation des identifiants :
À l'instar de Shai-Hulud, GlassWorm collecte les jetons npm, les identifiants GitHub et les jetons d'accès OpenVSX. Ces identifiants permettent une propagation autonome vers d'autres paquets et extensions, créant ainsi un comportement de propagation semblable à celui d'un ver.
Mesures d'impact :
- Détection initiale: Octobre 17, 2025
- Installations totalesPlus de 35 800 sur les plateformes OpenVSX et VS Code (chiffre potentiellement gonflé par des bots).
- Extensions compromises: 16 confirmés (15 OpenVSX, 1 Microsoft Marketplace)
- Infrastructure: Primaire C2 à
217.69.3.218, exfiltration vers140.82.52.31:80/wall - Portefeuille Blockchain:
28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2(Solana) - Statut actuel :Actif, avec une infrastructure opérationnelle à la date de rédaction du présent document.
Cyberespionnage orchestré par l'IA
Nous apprenons tous à utiliser les outils d'IA. Au vu des techniques employées lors des attaques récentes, on peut se demander : Les acteurs malveillants utilisent-ils l'IA pour créer des logiciels malveillants ? Bien sûr. Mais ils peuvent amplifier encore davantage leurs attaques en utilisant l'IA comme arme d'orchestration. Il s'agit alors d'une campagne de cyberespionnage ; imaginez ces mêmes techniques appliquées à des attaques automatisées ciblant les logiciels libres.
En septembre 2025, Anthropic détecté et perturbé Il s'agit de la première cyberattaque documentée exécutée en grande partie sans intervention humaine. La campagne a atteint un taux d'exécution autonome de 80 à 90 %. utilisation de Claude Code comme moteur d'orchestrationDes agents d'IA effectuent des missions de reconnaissance, d'exploitation, de déplacement latéral et d'exfiltration de données. Cela marque le passage des attaques assistées par l'IA aux cyberopérations orchestrées par l'IA.
Le groupe de cybercriminels GTG-1002 (un groupe parrainé par l'État chinois) a ciblé une trentaine d'organisations des secteurs technologique, financier et gouvernemental. Ils ont développé un cadre autonome transformant Claude Code, un assistant de programmation, en un moteur d'opérations cybernétiques.
L'IA en tant que système d'orchestration
Plutôt que d'utiliser l'IA comme conseiller, GTG-1002 a utilisé Claude comme opérateur principalLe système décomposait les attaques en plusieurs étapes en tâches isolées, chacune paraissant inoffensive prise individuellement. Grâce à des messages soigneusement élaborés et à des profils prédéfinis, les attaquants incitaient Claude à exécuter des actions malveillantes sans qu'il en comprenne le contexte.
L'IA a exécuté les étapes techniques tandis que le moteur d'orchestration a suivi l'état de la campagne, géré les transitions de phase et agrégé les résultats sur des sessions s'étalant sur plusieurs jours. L'intervention humaine s'est limitée à une supervision générale : initialisation, sélection des cibles, approbation des escalades et validation de l'exfiltration.
Les outils courants (scanners de réseau, exploits de bases de données) étaient orchestrés via des systèmes personnalisés. serveurs MCP.
Cette approche automatise les opérations à une vitesse impossible pour les humains. Claude a même analysé des données volées pour prioriser les informations importantes, en conservant un contexte persistant d'une session à l'autre, tandis que des opérateurs humains revenaient ultérieurement pour examiner l'avancement.
Ingénierie sociale de l'IA : contournement des contrôles de sécurité
Le succès de la campagne reposait sur la capacité à convaincre Claude d'effectuer des tâches d'intrusion informatique malgré sa formation en matière de sécurité. La technique : tromperie de jeu de rôleLes attaquants se sont fait passer pour des analystes en cybersécurité menant des enquêtes légitimes. Combinée à l'isolation des tâches, cette technique a suffi à contourner les contrôles de sécurité de l'IA.
Les hallucinations, c'est génial !
Claude avait fréquemment des hallucinations : il rapportait des exploits réussis qui avaient échoué, inventait des identifiants, fabriquait de toutes pièces des découvertes. Pour l’instant, cela limite les opérations entièrement autonomes, mais à mesure que les modèles s’amélioreront, ces faiblesses s’atténueront. En attendant, un défaut courant de l’IA est paradoxalement notre meilleur allié 🙃.
Détection et réponse :
Anthropic a détecté la campagne grâce à des schémas d'utilisation anormaux révélant une intrusion systématique. L'entreprise a banni les comptes associés, informé les organisations touchées, collaboré avec les autorités et intégré les schémas d'attaque à des mesures de sécurité plus globales.
Implications pour la chaîne d'approvisionnement :
Chaque technique présentée ici est directement applicable aux écosystèmes de paquets. L'IA pourrait identifier de manière autonome les responsables de la maintenance vulnérables, générer des paquets malveillants et orchestrer des attaques à l'échelle du registre à la vitesse d'une machine. La barrière est passée de « l'équipe de cybercriminels experts » à « l'opérateur qui comprend le fonctionnement de l'IA ».
Vous avez besoin d'un exemple concret de réquisition de l'IA pour des cyberattaques ? Lisez ceci : ShadowRay 2.0Des attaquants retournent l'IA contre elle-même dans une campagne mondiale , où des adversaires ont utilisé les fonctionnalités d'orchestration de Ray (« le Kubernetes de l'IA ») pour exécuter un botnet de cryptojacking mondial qui s'est propagé de manière autonome sur les clusters Ray exposés.
Un autre exemple: S1ngularité attaque exploitant la même pull_request_target Il s'agit du problème mentionné précédemment. Il détecte les outils CLI d'IA installés localement (Claude, Gemini, Q avec des options de contournement) et les utilise à des fins de reconnaissance. telemetry.js charges utiles, Les invites comprenaient des choses comme ça:
Abus d'infrastructure : Campagnes de spam de colis à grande échelle
Outre les paquets distribuant des logiciels malveillants, l'écosystème open source est confronté à des abus d'infrastructure via des campagnes de spam qui inondent les registres de milliers de paquets. Le DevOps est couramment utilisé à des fins de cybercriminalité : les attaquants l'emploient régulièrement. SCMLes systèmes et registres pour l'OSINT, la distribution de composants de logiciels malveillants, l'extraction de données confidentielles et la gestion du contrôle et de la commande. Mais ces plateformes peuvent également être détournés à des fins non malveillantesBien que ces campagnes ne soient pas traditionnellement malveillantes, elles consomment les ressources du registre, polluent les résultats de recherche et érodent la confiance.
Deux exemples significatifs illustrent cette tendance : Cuisine indonésienne (en exploitant les récompenses des contributeurs) et le Campagne des Elfes (Tests de l'équipe rouge qui ont mal tourné).
Aliments indonésiens : Exploitation du protocole TEA
La principale motivation était la fraude financière par le biais de exploitation du protocole TEA , un système basé sur la blockchain conçu pour rémunérer les développeurs de logiciels libres.
Les attaquants ont publié des milliers de paquets interconnectés contenant tea.yaml Des fichiers liés à leurs portefeuilles Ethereum créaient des réseaux de dépendance circulaires destinés à gonfler artificiellement les statistiques de contribution. Des scripts automatisés publiaient environ 12 paquets par minute, contenant des noms indonésiens et des termes culinaires générés aléatoirement. Le fichier README d'un paquet mentionnait même des gains en jetons TEA, confirmant ainsi la motivation financière.
La campagne a touché environ 44 000 paquets (plus de 1 % de npm) et a duré près de deux ans. Les dépendances circulaires entraînaient l’installation de centaines de paquets indésirables après l’installation d’un seul paquet. La qualité des résultats de recherche s’est dégradée, la confiance dans les indicateurs de paquets a été compromise et la bande passante et le stockage du registre ont été fortement sollicités.
Bien que des abus du protocole TEA aient été constatés en avril 2024, leur suppression systématique n'a eu lieu qu'en novembre 2025, révélant ainsi des lacunes importantes dans la détection des abus du registre. Cet épisode a ébranlé la confiance dans les modèles de financement basés sur la blockchain et a mis en lumière la facilité avec laquelle les systèmes de récompense peuvent être manipulés.
Campagne des Elfes : Tests automatisés de l'infrastructure
Construction campagne des elfes En décembre 2025, l'accent était mis sur l'exploitation abusive de l'infrastructure plutôt que sur une intention malveillante. Les descriptions des paquets faisaient référence à un « défi de capture de drapeau » et à des « tests » (avec notamment le texte français : « Paquet généré automatiquement toutes les 2 minutes »), suggérant une origine dans la recherche en sécurité ou les exercices de CTF.cispar exemple.
Les colis ont suivi une procédure cohérente elf-stats-* Les noms étaient basés sur des thèmes saisonniers. Certains contenaient des reverse shells triviaux (de simples commandes bash d'une seule ligne), si rudimentaires qu'ils semblaient conçus uniquement pour des tests de détection plutôt que pour une véritable exploitation.
Le rythme opérationnel (un paquet toutes les deux minutes sur plusieurs comptes) a mis à l'épreuve les capacités de limitation de débit et de détection des abus de npm. La campagne a démontré que les attaques par déni de service automatisées peuvent persister pendant des heures, voire des jours, avant toute intervention, consommant ainsi des ressources de stockage, de bande passante et de modération.
Plus important encore, cela a indiqué à d'autres acteurs malveillants que les attaques par inondation automatisées sont réalisables, ce qui pourrait inspirer de futures campagnes d'abus.
Nouvelles tactiques, techniques et procédures (TTP)
| TTP | Technique | Impact | Détection |
|---|---|---|---|
| Propagation autonome par réutilisation d'identifiants | Après avoir récupéré des jetons npm, des identifiants GitHub ou des clés API de registre, le logiciel malveillant énumère par programme tous les packages appartenant au responsable compromis et injecte des charges utiles malveillantes dans les nouvelles versions. | Un seul jeton compromis peut infecter des dizaines, voire des centaines de paquets en quelques heures. Chaque nouvelle victime devient un point de propagation pour la propagation du virus. | Surveillez les pics soudains de publication de paquets provenant d'un seul responsable, surtout s'ils s'accompagnent d'un suivi post-installation suspect. hooks ou de grandes additions binaires. |
| Infrastructure C2 multicouche avec immuabilité blockchain | Le serveur de commande et de contrôle principal utilise des transactions blockchain (Solana, Ethereum) où les champs mémo contiennent des URL de charge utile chiffrées ou encodées. Le serveur de commande et de contrôle secondaire exploite des services légitimes (Google Agenda, Pastebin, GitHub Gists) comme canaux de secours. | Les méthodes traditionnelles de suppression échouent : les transactions blockchain ne peuvent pas être supprimées et il est difficile de distinguer un usage abusif légitime du service d'une utilisation normale. | Surveillez les requêtes RPC blockchain inhabituelles provenant des machines des développeurs, en particulier celles destinées à des adresses de portefeuille spécifiques. Suivez les connexions aux services de calendrier ou aux sites web copiés-collés depuis les environnements de développement. |
| Injection de code invisible via Unicode Stealth | Le JavaScript malveillant est encodé à l'aide de sélecteurs de variantes Unicode (U+FE00 à U+FE0F) et de caractères de largeur nulle qui ne s'affichent pas dans les éditeurs mais restent du code exécutable valide. | La revue de code devient inefficace. Les développeurs qui examinent les fichiers sources voient des lignes vides tandis que les interpréteurs JavaScript exécutent des logiciels malveillants cachés. | Analysez les fichiers sources à la recherche de caractères Unicode non imprimables, notamment les sélecteurs de variantes et les caractères de liaison de largeur nulle. Mettez en œuvre des contrôles automatisés qui décodent et analysent le contenu binaire réel des fichiers sources, et non leur représentation rendue. |
| Actions GitHub en tant qu'infrastructure d'exfiltration | Déployer des flux de travail contenant ${{ toJSON(secrets) }} Des expressions permettent de sérialiser tous les secrets du dépôt et de les envoyer par POST à des points de terminaison contrôlés par l'attaquant. Ce flux de travail s'exécute sur l'infrastructure de GitHub, en apparaissant comme légitime. CI/CD activité. | Vol complet des secrets du dépôt sans déclencher la détection d'exfiltration traditionnelle, car le trafic provient des plages d'adresses IP de confiance de GitHub. | Les fichiers de flux de travail de numérisation sont toJSON(secrets) modèles. Surveiller les flux de travail effectuant des requêtes HTTP externes avec des corps POST volumineux. Alerter en cas d'ajout de flux de travail à des dépôts sans PR correspondantes ou commit l'histoire. |
| Déploiement hybride de RAT dans les environnements de développement | Déploiement de fonctionnalités RAT complètes (proxy SOCKS, VNC, WebRTC P2P) spécifiquement conçues pour fonctionner sur les postes de travail des développeurs. Ciblage des identifiants de développement, de l'accès au code source et du positionnement sur le réseau interne plutôt que des données utilisateur classiques. | Les développeurs compromis donnent un accès direct aux dépôts de code source. CI/CD pipelines, infrastructure cloud et réseaux d'entreprise internes. | Surveillez les déploiements inattendus de serveurs proxy, les processus de serveurs VNC, les connexions WebRTC provenant des machines de développement et la participation au réseau BitTorrent DHT. Mettez en œuvre une segmentation réseau stricte et un filtrage du trafic sortant. |
| Infection de la chaîne de dépendance | Les paquets malveillants déclarent d'autres paquets contrôlés par l'attaquant comme dépendances. L'installation d'un seul paquet déclenche l'installation automatique de toute la chaîne. | Une seule dépendance malveillante peut introduire des dizaines de paquets contrôlés par un attaquant. Le nettoyage nécessite l'identification et la suppression de l'ensemble de la chaîne d'infection. | Analysez les graphes de dépendances afin de détecter les schémas inhabituels : dépendances circulaires, paquets frères aux noms aléatoires ou ajouts soudains de dépendances. Mettez en œuvre des installations utilisant uniquement un fichier de verrouillage pour empêcher la résolution automatique des dépendances. |
Posture défensive
L'ère des vers informatiques auto-réplicatifs dans la chaîne d'approvisionnement est arrivée. La défense exige automatisation, vigilance et contrôles architecturaux qui partent du principe que la compromission est possible, plutôt que d'espérer une détection forcée. Chaque installation de logiciel est un vecteur d'infection potentiel. Chaque identifiant est un mécanisme de propagation. La question n'est plus de savoir si des attaques se produiront, mais à quelle vitesse vous pourrez les détecter et les contenir lorsqu'elles surviennent.
Pour se protéger contre les logiciels malveillants de type ver, il est nécessaire de passer d'une analyse réactive à une prévention proactive et à une surveillance continue :
Pipeline Contrôles :
- Appliquer les installations avec fichier de verrouillage uniquement (
npm ci,yarn install --frozen-lockfile) pour empêcher les mises à jour automatiques des dépendances et garantir un verrouillage strict des versions. - Mettre en œuvre une analyse préalable des paquets et des arbres de dépendances complets, bloquant les paquets malveillants avant leur exécution.
- Bloquez les paquets présentant des caractéristiques suspectes : fichiers surdimensionnés, obfuscation, pré/post-installation inattendus hooks.
- Exiger une revue de code pour les ajouts et mises à jour de dépendances.
Gestion des informations d'identification :
- Réduisez la portée des jetons — les jetons publiés ne doivent cibler que des packages spécifiques lorsque cela est possible.
- Mettre en place des jetons à durée de vie courte avec rotation automatique.
- Ne stockez jamais de jetons dans le code source ou les variables d'environnement.
- Utilisez des comptes de service CI dédiés avec des privilèges minimaux.
Détection et surveillance :
- Suivre les habitudes de publication et recevoir des alertes en cas de pics inhabituels provenant de chaque responsable de maintenance.
- Surveillez les flux de travail GitHub Actions pour la sérialisation des secrets, tels que :
toJSON(secrets). - Ajouts au flux de travail d'analyse pour les requêtes HTTP externes.
- Détecter les nouveaux dépôts publics ayant des noms inhabituels ou un contenu encodé.
- Surveillez les postes de travail des développeurs pour détecter les serveurs proxy inattendus. CI/CD runners, processus VNC ou requêtes RPC blockchain.
Réponse à l'incident:
- Traiter toute exécution d'installation suspecte hooks comme compromis total.
- Partez du principe que tous les jetons sur les hôtes compromis sont volés — effectuez une rotation immédiate.
- Reconstruction affectée CI/CD coureurs à partir d'images propres.
- Auditez tous les packages appartenant aux comptes compromis afin de détecter les versions malveillantes.
- Vérifiez la persistance dans les flux de travail et les paramètres du dépôt GitHub.
Les fournisseurs d'IA affirment souvent que tout outil peut être utilisé à bon ou à mauvais escient. Les systèmes d'IA ne peuvent empêcher totalement le double usage, mais ils peuvent créer des obstacles et améliorer la visibilité des analyses forensiques. La véritable question de conception n'est pas « l'IA peut-elle être détournée ? » mais « dans quelle mesure pouvons-nous créer des obstacles sans nuire à son utilité légitime ? » Un fait demeure : Le piratage des systèmes d'IA actuels est bien trop facile.L'analyse des messages malveillants dans les attaques récentes montre que le non-déterminisme LLM s'étend à leurs guardrails.
Plusieurs pistes émergent pour améliorer la sécurité de l'IA : une authentification forte de l'origine, l'isolation des contenus fiables et des contrôles basés sur les politiques pour les systèmes externes (avec l'arrivée de protocoles comme MCP). Seul l'avenir dira si l'IA deviendra la prochaine arme des attaques à grande échelle contre les infrastructures open source.
Lire la suite
- Shai-Hulud : Le ver des paquets npm expliqué
- Attaque de la chaîne d'approvisionnement NPM Shai-Hulud 2.0
- GlassWorm : le premier ver auto-réplicateur utilisant du code invisible débarque sur la marketplace OpenVSX – Koi Security
- Perturbation de la première campagne de cyberespionnage orchestrée par l'IA signalée – Anthropic
- Analyse des invites de l'IA utilisées dans l'attaque Nx
- Compromission généralisée de la chaîne d'approvisionnement affectant l'écosystème npm – CISA
- Notre plan pour une chaîne d'approvisionnement npm plus sécurisée – Blog GitHub
À propos de l’auteur
Écrit par Luis Rodriguez , cofondateur et directeur technique chez Xygeni Sécurité.
Luis est un kinésicist, mathématicien, et CISSP avec plus de 20 ans d'expérience en sécurité logicielle. Il a dirigé et contribué à d'importantes initiatives de sécurité dans divers domaines. SAST, SCAet les technologies avancées d'analyse de code. Aujourd'hui, il se concentre sur software supply chain security, alliant recherche approfondie et ingénierie pratique pour aider les équipes à défendre les solutions DevSecOps modernes pipelineface aux menaces émergentes.
