Un développeur reçoit un message sur LinkedIn. Le recruteur est convaincant : un poste senior dans une société de cryptomonnaie, une évaluation technique courte, un accès en lecture à un dépôt GitHub partagé pour "mieux comprendre la base de code." Le dépôt est réel. Les commits sont récents. Le nom de l'auteur dans l'historique Git correspond à un vrai développeur open source. Ce que le candidat ne voit pas, c'est que l'historique a été réécrit, que le dépôt a été compromis des semaines plus tôt, et que le moment où il ouvrira ce projet dans VS Code déclenchera une tâche automatique qui exécutera du code malveillant.
C'est le modèle opératoire de PolinRider, une campagne attribuée aux acteurs nord-coréens de Contagious Interview, documentée en détail par les chercheurs de Socket Security en juillet 2026. À ce stade, la campagne avait compromis 1 951 dépôts GitHub appartenant à 1 047 propriétaires distincts, publié 108 paquets et extensions malveillants sur quatre registres différents, et fusionné avec un autre cluster d'attaque appelé TaskJacker. Elle reste active.
Contagious Interview est le nom donné à une activité nord-coréenne qui arme les processus de recrutement pour cibler les développeurs de logiciels et les professionnels du secteur des cryptomonnaies. Active depuis au moins 2023, elle repose sur un principe simple : les développeurs font confiance aux dépôts de code qu'on leur demande d'évaluer dans le cadre d'un entretien technique. Cette confiance est le vecteur.
Les attaquants se font passer pour des recruteurs ou des collaborateurs sur LinkedIn, GitHub, et des plateformes de freelance. Ils créent de toutes pièces des sociétés fictives avec des profils d'employés générés par intelligence artificielle pour asseoir leur crédibilité. L'entretien technique mène inévitablement à l'exécution de code malveillant, que ce soit via un dépôt partagé, un paquet npm à installer, ou un lien vers un projet en téléchargement. La cible pense faire une démonstration de ses compétences. En réalité, elle exécute du code de l'attaquant sur sa propre machine.
PolinRider est la dernière évolution de cette campagne. Le chercheur Karlo Zanki de Socket Security en a publié l'analyse en juillet 2026, après que l'équipe OpenSourceMalware l'a initialement signalée en mars 2026. La nouveauté par rapport aux précédentes itérations de Contagious Interview est l'échelle : quatre registres de paquets ciblés simultanément, des centaines de dépôts GitHub compromis, et une fusion avec TaskJacker qui élargit encore la surface d'infection.
PolinRider a publié 162 artefacts malveillants correspondant à 108 paquets et extensions uniques répartis sur quatre plateformes : 19 bibliothèques npm, 10 paquets Composer pour PHP, 61 modules Go, et une extension Google Chrome. Plusieurs versions du même paquet peuvent coexister sur le registre, chacune comptant comme un artefact distinct.
Le choix des quatre registres n'est pas aléatoire. npm est le registre le plus utilisé par les développeurs JavaScript et Node.js, le langage de prédilection de la communauté que Contagious Interview cible depuis des années. Composer et Go élargissent le champ aux développeurs PHP et Go, deux langages fréquents dans les infrastructures de backend liées aux services financiers et aux échanges de cryptomonnaies. L'extension Chrome, un vecteur moins classique pour ce type de campagne, vise directement le navigateur du développeur et tout ce qu'il contient : cookies, tokens, historique d'authentification.
Les paquets malveillants contiennent des charges utiles JavaScript obfusquées qui installent une nouvelle variante de BeaverTail, un malware JavaScript documenté dans les précédentes campagnes de Contagious Interview. Une fois déployé, BeaverTail exfiltre des données sensibles et ouvre la voie à des charges supplémentaires selon le profil de la victime.
À partir d'avril 2026, PolinRider a fusionné avec un cluster parallèle appelé TaskJacker, qui utilise une technique distincte : l'injection de fichiers de tâches VS Code malveillants dans des dépôts GitHub existants. TaskJacker ne crée pas de nouveaux dépôts. Il modifie des dépôts légitimes auxquels l'acteur a obtenu un accès en tant que contributeur ou mainteneur, en y ajoutant un fichier de configuration de tâche VS Code.
La clé de cette technique est une option de configuration VS Code peu connue : runOn: 'folderOpen'. Quand cette option est activée dans une définition de tâche, VS Code exécute automatiquement la commande associée dès que l'utilisateur ouvre le dossier comme espace de travail dans son IDE, que ce soit VS Code ou Cursor. Aucun clic n'est nécessaire. L'ouverture du projet suffit.
L'acteur se défend également dans des environnements Windows en utilisant un script batch qui modifie discrètement le dernier commit tout en faisant apparaître les modifications comme si elles avaient été effectuées par l'auteur original. Cela signifie que l'historique Git du dépôt compromis ne révèle aucun commit suspect : les modifications malveillantes s'affichent sous le nom et l'adresse email d'un contributeur légitime. Il est probable que des techniques similaires soient utilisées sur Linux et macOS.
La question centrale est la suivante : comment un acteur externe prend-il le contrôle de comptes GitHub appartenant à de vrais développeurs ? L'équipe OpenSourceMalware est explicite sur ce point. L'acteur ne vole pas directement les identifiants GitHub. À la place, il compromet les machines des développeurs via une extension VS Code ou un paquet npm malveillant installé lors d'une session de recrutement fictive. Une fois la machine compromise, l'acteur récupère les tokens d'authentification stockés localement par l'IDE ou le navigateur, et les utilise pour accéder au compte GitHub depuis leur propre infrastructure.
Une voie complémentaire consiste à exploiter le système de récupération de compte via des domaines expirés. Certains développeurs ont configuré une adresse email personnalisée comme adresse de récupération de compte. Si ce domaine expire et que l'attaquant l'achète, il peut déclencher une réinitialisation de mot de passe et prendre le contrôle du compte sans jamais toucher à la machine de la victime.
Au 11 avril 2026, 1 951 dépôts publics GitHub appartenant à 1 047 propriétaires uniques avaient été compromis dans le cadre de PolinRider. Ces chiffres ne représentent que les dépôts que les chercheurs ont pu identifier et associer à la campagne. Le nombre réel est probablement plus élevé.
Une fois exécuté sur la machine d'une victime, le malware BeaverTail injecté par PolinRider recherche des fichiers spécifiques qui indiquent la présence d'un projet JavaScript actif : postcss.config.mjs, tailwind.config.js, eslint.config.mjs, next.config.mjs, babel.config.js, et app.js. Si ces fichiers sont présents, le malware y ajoute du code JavaScript malveillant.
Cette stratégie de ciblage est particulièrement efficace pour deux raisons. D'abord, ces fichiers sont des fichiers de configuration que les développeurs modifient rarement une fois qu'ils fonctionnent, ce qui rend l'injection difficile à détecter lors d'une revue de code ordinaire. Ensuite, ils sont exécutés automatiquement par les outils de build lors de chaque compilation, ce qui assure à l'attaquant une exécution persistante à chaque lancement du projet, y compris dans les environnements d'intégration continue.
L'objectif final est le vol de credentials cryptomonnaies, les tokens d'authentification, les clés SSH, et tout matériel de valeur présent sur la machine du développeur. Les développeurs travaillant sur des projets de finance décentralisée ou des échanges de cryptomonnaies sont des cibles particulièrement attrayantes car ils ont souvent accès à des portefeuilles chauds, à des clés de signature de transactions, et à des environnements de déploiement qui contrôlent des actifs réels.
Pour les équipes de sécurité, plusieurs indicateurs permettent de détecter une compromission PolinRider. Le premier est l'apparition de tâches VS Code avec l'option runOn: 'folderOpen' dans des dépôts qui n'en avaient pas auparavant. Cette configuration est rare dans des projets légitimes et devrait toujours être examinée attentivement. Le deuxième est la présence de code obfusqué dans les fichiers de configuration JavaScript listés ci-dessus, en particulier du code ajouté en fin de fichier sans correspondre aux modifications récentes de l'historique Git.
Le troisième signal est plus difficile à détecter : des commits apparaissant sous le nom d'un contributeur légitime mais depuis une adresse IP inhabituellement différente de ses commits habituels. GitHub ne rend pas ces informations directement visibles dans l'interface publique, mais les équipes de sécurité ayant accès aux logs d'organisation peuvent les corréler.
Pour les développeurs individuels, la règle fondamentale reste de ne jamais exécuter de code fourni dans le cadre d'un entretien technique sans l'avoir examiné dans un environnement isolé, idéalement une machine virtuelle jetable sans accès à leurs comptes réels. Un recruteur qui insiste pour que vous testiez leur code sur votre machine de développement principale est un signal d'alarme, quelle que soit la légitimité apparente de l'entreprise.
Les équipes de sécurité gérant des environnements de développement devraient également surveiller les accès inhabituels aux tokens d'authentification stockés dans les gestionnaires de credentials des IDE, en particulier les accès effectués par des processus de build ou des extensions récemment installées. La compromission via PolinRider laisse des traces dans les logs système si ceux-ci sont collectés et analysés.
Le chiffre de 1 951 dépôts GitHub compromis au 11 avril 2026 mérite d'être mis en perspective. GitHub héberge plus de 420 millions de dépôts publics. 1 951 représente moins de 0,0005% du total. Mais ce n'est pas la bonne façon de lire ce chiffre. Ce qui compte, c'est que ces 1 951 dépôts appartiennent à 1 047 développeurs actifs qui contribuent à des projets JavaScript, Go, et PHP dans le secteur des cryptomonnaies et des services numériques. Ce sont 1 047 machines de développeur potentiellement compromises, 1 047 accès aux registres npm ou Go, et 1 047 portes d'entrée vers les organizations pour lesquelles ces développeurs travaillent.
L'impact n'est pas limité aux machines individuelles. Un développeur qui maintient un paquet npm populaire avec des centaines de milliers de téléchargements hebdomadaires représente un point d'amplification extraordinaire. Si son compte npm est compromis et qu'une version malveillante du paquet est publiée, tous les projets qui mettent à jour leurs dépendances automatiquement recevront la charge malveillante. C'est exactement le modèle d'attaque supply chain qui a produit l'incident SolarWinds en 2020 et l'attaque 3CX en 2023. PolinRider ne cherche peut-être pas explicitement cet effet d'amplification, mais la compromission de mainteneurs de paquets avec un accès aux registres crée cette possibilité.
Ce qui distingue PolinRider des campagnes de phishing générique, c'est la précision de l'ingénierie sociale. Les attaquants ne ciblent pas des utilisateurs au hasard. Ils ciblent des développeurs spécifiques qui travaillent sur des technologies précises, en particulier dans l'écosystème JavaScript et les projets liés aux cryptomonnaies. Cette précision est rendue possible par l'exploitation de données publiques : les dépôts GitHub d'un développeur révèlent ses compétences, les projets auxquels il contribue, et les technologies qu'il utilise quotidiennement.
Un profil de recruteur fictif sur LinkedIn créé spécifiquement pour cette campagne sera cohérent avec le secteur ciblé : une photo générée par IA convaincante, un historique de poste plausible dans une société de services financiers décentralisés, des connexions communes avec de vrais professionnels du secteur. BI.ZONE a documenté que ces profils peuvent rester actifs pendant des mois avant d'être utilisés dans une campagne, accumulant des connexions et de la crédibilité sans déclencher d'alertes automatiques sur les plateformes de réseaux sociaux.
La demande d'évaluation technique elle-même est conçue pour être plausible. Le dépôt partagé contient un vrai projet open source ou une application réelle, pas un script vide. Les commits récents montrent de l'activité. Les tests unitaires sont présents. L'invitation à contribuer est formulée dans un langage que les développeurs reconnaissent : "on aimerait avoir votre avis sur notre approche du state management" ou "voici notre repo, tu peux regarder comment on gère l'authentification?" Ces formulations sont celles d'un vrai entretien technique, et elles abaissent les défenses d'une cible même expérimentée.
BeaverTail est le malware JavaScript qui constitue la charge principale de la campagne PolinRider. Il est actif depuis au moins 2023 dans les opérations de Contagious Interview, ce qui lui vaut un corpus d'analyse publicly accessible. La variante déployée dans PolinRider est une évolution des versions précédentes, mais son architecture fondamentale reste consistante.
BeaverTail est distribué sous forme de code JavaScript obfusqué intégré dans des fichiers de configuration ou des dépôts GitHub. Son exécution initiale se déclenche soit lors du lancement d'une commande de build standard, soit via une tâche VS Code avec l'option runOn: 'folderOpen'. Une fois actif, il effectue plusieurs actions en parallèle. Il établit une communication avec le serveur de commande et contrôle de l'attaquant. Il collecte des informations sur l'environnement : système d'exploitation, chemins des répertoires utilisateur, présence de wallets de cryptomonnaies. Selon les instructions reçues, il peut télécharger et exécuter des charges supplémentaires, dont un stealer plus complet et un RAT pour l'accès persistent.
Le comportement d'injection dans les fichiers de configuration, en particulier dans next.config.mjs et babel.config.js, est particulièrement insidieux. Ces fichiers sont exécutés dans le processus de build Node.js, ce qui signifie que le code malveillant s'exécute à chaque compilation, potentiellement dans des environnements d'intégration continue où la surveillance est moins fine que sur un poste de développement. Un pipeline CI compromis peut exécuter BeaverTail des dizaines de fois par jour sans que personne ne le remarque dans les logs de build.
La résilience de BeaverTail aux outils antivirus traditionnels repose sur l'obfuscation JavaScript. Les moteurs antivirus basés sur des signatures sont généralement efficaces contre des exécutables binaires compilés, mais les scripts JavaScript obfusqués contournent facilement ces signatures car la transformation syntaxique du code ne modifie pas sa sémantique tout en rendant la détection par pattern-matching très difficile. Les outils de détection comportementale (EDR) sont plus efficaces pour détecter BeaverTail à l'exécution, mais leur déploiement dans les environnements de développement est souvent moins systématique que sur les postes de travail standard.
La réponse à PolinRider nécessite des mesures à plusieurs niveaux. Au niveau individuel, la règle la plus importante pour les développeurs est de ne jamais exécuter de code inconnu sur une machine qui contient des credentials ou des tokens d'authentification réels. Les entretiens techniques peuvent être conduits dans des machines virtuelles dédiées, créées spécifiquement pour l'occasion et détruites après, sans connexion aux comptes GitHub, npm, ou AWS de l'évaluateur. Cette approche est légèrement plus contraignante, mais elle réduit à zéro la surface d'attaque de tout malware qui pourrait être intégré dans le code évalué.
Au niveau organisationnel, les équipes de sécurité devraient surveiller les nouveaux paquets npm ou modules Go ajoutés aux dépendances des projets, en particulier les paquets peu connus avec peu de téléchargements et des noms qui imitent des bibliothèques populaires. PolinRider publie ses paquets malveillants avec des noms proches de bibliothèques JavaScript légitimes, exploitant la typosquatting au niveau du registre. Des outils d'audit de dépendances comme npm audit ne capturent pas ce type d'attaque car les paquets malveillants ne contiennent pas de vulnérabilités connues, ils sont simplement malveillants par conception.
La rotation régulière des tokens GitHub et la révocation des tokens anciens ou inutilisés réduit la fenêtre d'exploitation dans les cas de compromission via credential theft. Un attaquant qui obtient un token GitHub via BeaverTail voit sa valeur diminuer rapidement si l'organisation a une politique de rotation des tokens à 90 jours. La même logique s'applique aux clés d'API pour les services cloud et aux tokens npm pour les mainteneurs de paquets.
Enfin, les organisations dont les développeurs publient des paquets sur des registres publics devraient activer l'authentification à deux facteurs obligatoire sur leurs comptes de registre, surveiller les nouvelles publications effectuées depuis leurs comptes, et activer les alertes de connexion depuis de nouvelles adresses IP. Ces mesures ne stoppent pas la compromission initiale via ingénierie sociale, mais elles réduisent significativement la probabilité qu'une compromission d'un poste de développeur se transforme en attaque supply chain contre les utilisateurs aval des paquets maintenus par ce développeur. La sécurité des registres de paquets est une responsabilité partagée entre les mainteneurs individuels et les équipes de sécurité des organisations qui les emploient.
PolinRider reste active. Les chercheurs de Socket Security ont été explicites sur ce point : de nouveaux paquets malveillants continueront d'apparaître tant que l'acteur conservera ou obtiendra des accès aux registres. La vigilance sur les nouvelles dépendances ajoutées aux projets doit être permanente, pas réactive. Un outil d'audit de dépendances intégré dans le pipeline CI qui signale les paquets nouvellement ajoutés peu connus avec peu de téléchargements est la mesure préventive la plus directement applicable pour les équipes de développement qui opèrent dans les secteurs ciblés par cette campagne.
Les campagnes comme PolinRider, Avalon, Armored Likho ou ARToken ont toutes un point commun : elles ciblent les identifiants, les tokens d'authentification et les données d'entreprise avant que les victimes ne s'aperçoivent de la compromission. Defendis surveille en continu les marchés souterrains, les forums criminels et les sites de fuite où ces données apparaissent après une exfiltration. Si des credentials appartenant à votre organisation sont mis en vente ou publiés, vos équipes en sont informées avant que l'attaquant ne les exploite. Comprendre pourquoi la détection précoce change l'issue d'un incident ou demandez une démonstration adaptée à votre contexte.
