La campagne qui transforme les unités en portes arrière et expose votre équipe de développement

Une campagne persistante liée à des groupes alignés avec la Corée du Nord a augmenté le risque sur la chaîne d'approvisionnement des logiciels: ce n'est plus une explosion isolée mais une tactique intégrée qui combine le sous-implantation des recruteurs, la publication de paquets malveillants dans de multiples écosystèmes et l'utilisation abusive des outils de développement pour exécuter le code dans les équipes de développeurs. Le phénomène - détecté par diverses équipes de recherche comme Socket et OpenSourceMalware et baptisé dans leurs différentes itérations telles que PolinRider, Contagious Interview ou TaskJacker - montre comment les attaquants mélangent l'ingénierie sociale, les comptes de détention et les modifications furtives des dépôts pour atteindre la persistance et la distribution de masse.

Le vecteur technique qui rend cette opération particulièrement dangereuse est l'exploitation des itinéraires d'exécution automatique dans l'environnement de développement: Les fichiers de tâches VS Code qui incluent l'option runOn: 'folderOpen' permettent à un développeur d'ouvrir son projet et, sans plus, d'exécuter le code distant. Dans le même temps, les attaquants insèrent des chargeurs JavaScript dans des fichiers de configuration communs (par exemple, postcs.config.mjs, Thai wind.config.js, eslint.config.mjs, next.config.mjs, babel.config.js ou app.js), permettant à l'engagement de diffuser et les paquets légitimes pour publier des versions infectées dans npm, Compositeur, aller modules et extensions Chrome. La sophistication comprend Réécriture de l'historique Git, engagements et mécanismes antidatés pour cacher le code (patage des espaces vides, faux fichiers .woff2), ce qui complique la détection de la page de GitHub.

Les implications pour les projets open source et les entreprises qui dépendent de dépendances externes sont profondes. Un paquet apparemment inoffensif d'extension de l'éditeur peut devenir une porte arrière qui vole les identifiants, les clés API et les portefeuilles critiques; dans ce cas particulier, les chargeurs obtiennent à commander les deuxièmes étapes de l'infrastructure blockchain et mènent à RAT et des outils de voleur comme DEV # POPPER et OmniStealer. Cela redéfinit le périmètre : maintenant le point d'échec le plus sensible peut être sur l'équipe du développeur, pas seulement sur les serveurs de production.

Pour les opérateurs de développement et l'équipement, la première règle devrait être de présumer que toute dépendance ou environnement qui a interagi avec les versions touchées peut être compromis. Si une installation de paquet compromise est suspectée, les secrets devraient être tournés à partir d'une machine propre, les versions touchées retirées et les unités reconstruites à partir d'un fichier de verrouillage vérifié ou, mieux, une construction jouable bien connue. En plus de cette réaction immédiate, il est essentiel d'auditer les dépôts pour des changements inhabituels dans .vscode / tasks.json, config.js, vite.config.js et eslint.config.js, d'examiner les métadonnées de lancement dans les dossiers et de consulter le journal de l'activité du dépôt (ne pas se fier exclusivement à l'historique visible de la page d'atterrissage GitHub).

Les mesures préventives opérationnelles comprennent le renforcement de l'hygiène des comptes et des domaines : activer 2FA dans tous les responsables, protéger et renouveler les domaines associés aux comptes pour éviter les rachats en fin de vie, restreindre les itinéraires de récupération des comptes, et utiliser les signatures d'engagement (GPP ou SSH) et les politiques des succursales protégées qui empêchent les puzzles et les réécritures indésirables. Au niveau de l'IC / CD, il convient de valider les artefacts publiés par rapport aux comptes de vérification prévus, de fixer des limites pour l'exécution des tâches automatisées et d'exiger des examens explicites pour les changements de scripts ou les configurations de construction qui pourraient exécuter le code.

Depuis le fonctionnement des postes de travail, la surface d'attaque doit être minimisée : éviter d'installer des extensions éditoriales sans revoir leur réputation et leur code, vérifier la liste des extensions installées dans les équipes de développement, et les environnements segmentés de sorte que les machines qui manipulent des secrets ou se déploient à la production ne soient pas utilisées pour naviguer ou tester des unités sans conteneurs/bureaux éphémères. Les outils de détection et de prévention de la chaîne d'approvisionnement doivent être intégrés au flux : scanners unitaires, signatures de paquets, politiques de déni d'anomalies et alertes sur les publications des responsables exceptionnellement actifs.

Il est également nécessaire d'envisager des changements organisationnels : adopter des pratiques comme la génération des SBOM et la traçabilité des SLSA pour la construction, exiger un bâtiment reproductible et valider le binaire par rapport aux artefacts attendus. La collectivité peut collaborer en signalant les colis suspects aux dossiers et en tenant des listes d'indicateurs, mais la responsabilité première incombe à chaque équipe pour durcir les comptes, protéger les domaines et traiter toute dépendance compromise comme un incident de sécurité.

Si vous souhaitez approfondir des contre-mesures spécifiques et des guides techniques, la documentation de GitHub sur la sécurité de la chaîne d'approvisionnement offre de bonnes pratiques pour le dépôt et la publication de paquets https: / / docs.github.com / fr / code-security / supply-chain-security, et la documentation de Visual Studio Code explique comment les tâches fonctionnent et pourquoi l'exécution Sur option peut être exploité s'il n'est pas contrôlé https: / / code.visualstudio.com / docs / éditeur / tâches. Pour les organisations qui veulent progresser vers des protections structurelles, les principes de la SLSA (niveaux de chaîne d'approvisionnement pour les artistes logiciels) sont un cadre utile pour accroître la confiance dans le renforcement et la diffusion https: / / slsa.dev /.

Bref, nous sommes confrontés à une campagne qui combine ingénierie sociale, abus des infrastructures publiques de développement et techniques de dissimulation avancées. Une défense efficace exige de supposer que le poste de travail du développeur est un objectif critique, de traiter les unités avec une méfiance calculée, et d'appliquer des contrôles techniques et organisationnels qui empêchent à la fois la prise de responsables et l'exécution non remarquée de code malveillant. Agir rapidement à tout signe d'engagement et prévoir des mesures de protection au niveau des comptes, des domaines et des processus de construction sont des étapes obligatoires pour contenir ce type de menace.