Voici ce qui s'est réellement passé, étape par étape : Le 18 mai, des acteurs malveillants ont compromis le compte de publication de Nrwl (l'entreprise derrière Nx Console) sur le marché VS Code. Entre 12:36 et 12:47 UTC ce jour-là, ils ont poussé la version 18.3.4 de Nx Console contenant du code malveillant sur le marché en utilisant les identifiants légitimes de l'éditeur. La version compromise était cryptographiquement signée avec le certificat valide de l'éditeur Nrwl, ce qui explique pourquoi la vérification intégrée de VS Code l'a acceptée sans avertissement. Lorsqu'une instance de VS Code de n'importe quel développeur vérifiait les mises à jour des extensions pendant cette fenêtre de 11 minutes (ou lors d'une installation manuelle de Nx Console durant cette période), elle téléchargeait directement la version infectée à partir du marché officiel de Microsoft. L'extension n'a pas été piratée dans le sens où quelqu'un aurait modifié des fichiers sur un serveur, elle a été publiée par la porte d'entrée en utilisant des identifiants d'éditeur volés. Comment les attaquants ont-ils obtenu initialement les identifiants de publication de Nrwl sur le marché? C'est la partie qui manque à la plupart des couvertures. La publication sur le marché VS Code nécessite soit un jeton d'accès personnel (PAT) d'Azure DevOps, soit des identifiants OAuth liés à un compte Microsoft. Ces identifiants ont presque certainement été récoltés à partir d'une compromission précédente de la chaîne d'approvisionnement, peut-être lors d'une vague antérieure de la même campagne. Cela crée un modèle d'échec en cascade : compromettre un outil de développement pour voler des identifiants, utiliser ces identifiants pour publier des versions malveillantes d'un autre outil de développement, utiliser cet outil pour voler plus d'identifiants, répéter. Chaque itération augmente l'accès de l'attaquant aux comptes d'éditeurs à travers l'écosystème. La compromission de Nx Console n'était pas le point zéro, elle était déjà profondément dans la chaîne. Une fois l'extension empoisonnée installée sur la machine d'un développeur (y compris l'employé GitHub au centre de cette histoire), elle a exécuté automatiquement du code qui a scanné l'ensemble de la machine à la recherche d'identifiants. Les extensions de VS Code sont écrites en JavaScript et TypeScript, et elles s'exécutent dans Node.js, le même runtime JavaScript qui alimente VS Code lui-même. Lorsqu'une extension est installée, VS Code charge son code JavaScript directement dans l'espace du processus de l'éditeur avec un accès complet aux API Node.js. Le code malveillant dans Nx Console 18.3.4 a utilisé les API du système de fichiers Node.js (spécifiquement fs.readFile, fs.readdir et les fonctions de parcours de chemin) pour scanner récursivement le répertoire personnel de l'utilisateur et les emplacements de stockage d'identifiants courants. Il a recherché des fichiers correspondant à des modèles tels que.npmrc,.aws/credentials,.kube/config,.ssh/,.gitconfig,.netrc, et des fichiers de configuration pour 1Password CLI, HashiCorp Vault et Claude Code. L'extension a aussi appelé des API de processus enfant de Node.js (child_process.exec et child_process.spawn) pour exécuter des commandes système qui déversent des variables d'environnement, interrogent le trousseau de clés du système sur macOS (en utilisant l'outil en ligne de commande security) et extraient des identifiants du Gestionnaire d'informations d'identification Windows (en utilisant cmdkey). Tout cela se déroule en JavaScript pur exécuté avec les mêmes privilèges que l'utilisateur qui a lancé VS Code. Il n'y a pas de sandboxing, pas d'invites de permission, pas d'isolation au niveau du système d'exploitation. Les extensions VS Code sont conçues comme du code de confiance. Les identifiants récoltés ont ensuite été exfiltrés en utilisant le module https intégré de Node.js pour envoyer les données aux domaines contrôlés par les attaquants. Le code malveillant a obscurci le point de terminaison d'exfiltration en utilisant un encodage base64 et une concaténation de chaînes pour échapper à l'analyse statique, mais une fois l'extension exécutée, elle a effectué des requêtes HTTPS directes pour envoyer des charges utiles JSON compressées contenant chaque identifiant trouvé. Le fichier package.json de l'extension déclarait des événements d'activation qui la faisaient s'exécuter immédiatement au démarrage de VS Code (en utilisant l'événement d'activation "*", qui se déclenche à l'ouverture de tout espace de travail), ce qui signifie que les développeurs n'avaient pas besoin d'invoquer explicitement les fonctionnalités de Nx Console pour que le code malveillant s'exécute. Juste avoir VS Code en cours d'exécution avec l'extension installée était suffisant. La charge utile JavaScript a également injecté des hooks dans les propres API de stockage d'identifiants de VS Code (en utilisant les API vscode.authentication et vscode.workspace) pour intercepter tout identifiant auquel l'utilisateur accédait pendant sa session de travail, y compris les jetons OAuth GitHub que VS Code utilise pour sa propre intégration Git. À partir de là, l'attaquant a utilisé ces identifiants volés pour installer une deuxième extension empoisonnée sur la même machine de l'employé (GitHub n'a pas encore révélé quelle était cette extension). Cette deuxième extension a exfiltré environ 3 800 dépôts internes de GitHub au cours des heures ou des jours suivants. Le 20 mai, le groupe de menace TeamPCP faisait déjà la publicité des dépôts volés à la vente sur un forum de piratage pour 50 000 $ et plus, quelques heures avant que GitHub ne confirme publiquement la brèche. Les dépôts internes ne sont pas des données clients, ce sont quelque chose de pire pour la sécurité de l'infrastructure. Ces dépôts contiennent des scripts de déploiement, des identifiants de staging, des schémas d'API internes et des configurations d'infrastructure. L'accès au code source à ce niveau donne aux attaquants une vue d'ensemble sur la manière dont les systèmes de GitHub se connectent, s'authentifient et échouent. Chaque secret qui atteint un acheteur raccourcit la phase de reconnaissance pour toute attaque que cet acheteur planifiait déjà. Le cofondateur de Binance, CZ, a immédiatement averti quiconque avec des repos privés contenant des secrets en clair de tout faire tourner. Mike Riemer, CTO d'Ivanti, m'a dit que le réseau honeypot d'Azure montre maintenant des vulnérabilités connues exploitées en moins de 90 secondes, et que des identifiants volés peuvent réduire encore plus rapidement cette chronologie. La brèche de GitHub n'est pas arrivée toute seule. Le 19 mai, Endor Labs a détecté 42 paquets npm malveillants (le suivi plus large de Socket a trouvé 639 versions malveillantes sur 323 paquets) publiés dans l'écosystème de visualisation de données @antv d'Alibaba, qui voit environ 16 millions de téléchargements hebdomadaires. Cette vague a introduit la falsification de provenance : le ver Mini Shai-Hulud appelle maintenant Fulcio et Rekor à l'exécution pour générer des certificats de signature Sigstore valides pour chaque paquet qu'il propagent. L'outil de provenance montre un badge vert. La chaîne de construction appartient à l'attaquant. Peyton Kennedy, chercheur principal en sécurité chez Endor Labs, m'a dit que "TanStack avait la bonne configuration sur le papier : publication de confiance OIDC, provenance signée, 2FA sur chaque compte mainteneur. L'attaque a quand même fonctionné." Également le 19 mai, les acteurs de la menace ont compromis le workflow GitHub Actions actions-cool/issues-helper en redirigeant chaque tag existant vers un commit imposteur contenant du code malveillant qui exfiltre des identifiants des pipelines CI/CD (Intégration Continue / Déploiement Continu). Le domaine d'exfiltration correspondait à la vague Mini Shai-Hulud de @antv, reliant les clusters ensemble. Quelques heures plus tard, Wiz a détecté que TeamPCP avait compromis durabletask, le client Python officiel de Microsoft pour le cadre d'exécution de workflows Durable Task. Trois versions malveillantes ont été publiées sur PyPI (Python Package Index) dans une fenêtre de 35 minutes utilisant un compte GitHub compromis lors d'une opération précédente de TeamPCP. La charge utile vole des identifiants d'AWS (Amazon Web Services), Azure, GCP (Google Cloud Platform), Kubernetes, et plus de 90 configurations d'outils pour développeurs, puis se propage latéralement à travers l'infrastructure cloud. Le paquet enregistre en moyenne plus de 400 000 téléchargements mensuels. L'ensemble du schéma se répète : compromettre un outil populaire, exfiltrer les identifiants de chaque machine qui l'exécute, utiliser ces identifiants pour compromettre le prochain outil. TeamPCP construit une base de données d'identifiants qui s'étend à tout l'écosystème des développeurs, et ils vendent l'accès à quiconque paiera.