ForceMemo la campagne qui réécrit l'histoire de GitHub vole des jetons et diffuse des logiciels malveillants à travers les paquets Python

Publié 6 min de lectura 100 lecture

Il y a quelques mois, la communauté des développeurs a commencé à remarquer quelque chose de troublant : des paquets et des projets à GitHub qui, sans changements visibles apparents, incorporent des fragments de code nuisibles. La recherche a révélé une campagne sophistiquée qui prend des techniques bien connues du groupe GlassWorm, mais fonctionne maintenant avec une variante axée sur forcer l'historique du dépôt à insérer des charges utiles malveillantes dans les projets Python. Rapports techniques publiés par les équipes de recherche Sécurité des étapes et l'analyse complémentaire de groupes tels que Socket dessine une image inquiétante de l'intégrité de la source ouverte.

Le vecteur initial de cette opération n'est pas une attaque directe contre GitHub, mais l'infiltration d'environnements de développement. En utilisant des extensions malveillantes pour des éditeurs comme VS Code et des outils auto-complétés, un composant est installé qui cherche et exfilter les identifiants: Des jetons GitHub qui leur permettent d'agir comme s'ils étaient les développeurs eux-mêmes. Avec ces références en main, l'acteur supprime les barrières normales de workflow. Au lieu de créer une requête de tirage ou d'ajouter un commit visible, l'intrusion réécrit l'histoire du dépôt au moyen d'une rebase et d'une force--pousser, de sorte que les métadonnées - l'auteur, la date et le message du commit - semblent authentiques et il n'y a aucune trace évidente sur l'interface publique.

ForceMemo la campagne qui réécrit l'histoire de GitHub vole des jetons et diffuse des logiciels malveillants à travers les paquets Python
Image générée avec IA.

Une fois la porte ouverte, les attaquants cherchent des fichiers spécifiques qui sont généralement exécutés ou emballés dans des projets Python - noms communs tels que configuration.py, Main.py ou app.py- et ajouter à la fin du fichier une charge injectée codée dans Base64. Ce code osfusqué n'est pas un script simple : il contient des vérifications pour détecter les environnements qui utilisent l'emplacement russe et, si cette configuration est détectée, évite l'exécution, une technique régulière pour échapper à l'analyse dans certaines juridictions. Dans tous les autres cas, le fragment décode les instructions qui pointent vers une adresse dans le réseau Solana; le champ mémo d'une transaction agit comme un canal pour l'attaquant de mettre à jour dynamiquement l'URL à partir de laquelle les logiciels malveillants téléchargeront des composants supplémentaires, y compris JavaScript crypté conçu pour supprimer cryptomonedas et les données du système infecté.

La chronologie rapportée par les chercheurs montre que l'infrastructure de contrôle fonctionnait depuis des mois avant la détection des premières insertions de dépôt. Les enregistrements dans la chaîne de blocs indiquent des transactions dans cette direction de Solana datant de la fin novembre 2025, tandis que les premières injections à GitHub ont été identifiées à partir du 8 mars 2026. En outre, le modèle d'exploitation révèle que l'acteur change souvent l'URL de la charge utile, ce qui complique la défense si seule une adresse spécifique est bloquée.

Ce qui rend cette variante unique - surnommée par certains chercheurs comme ForceMemo - est la combinaison de plusieurs techniques : utiliser des extensions malveillantes pour voler des secrets, exploiter des jetons valides pour réécrire l'historique git en préservant des métadonnées légitimes, et utiliser la chaîne de blocs comme canal de commande et de contrôle. Socket a également souligné que la campagne a amélioré sa capacité de survie en distribuant des logiciels malveillants transitoires au moyen de métadonnées de paquets d'extension, c'est-à-dire en s'appuyant sur des mécanismes d'emballage et des dépendances pour diffuser la charge malveillante dans l'écosystème d'extension.

Pour ceux qui gardent le logiciel ouvert ou dépendent de librairies tierces, les implications sont claires : un développeur infecté peut, sans laisser de traces évidentes, diffuser du code malveillant aux projets consommés par des milliers d'utilisateurs. Toute opération qui fait une pip installer à partir d'un dépôt compromis ou ce clone et exécuter le code sans vérification appropriée peut déclencher l'exécution de malware. Face à ce risque, les bonnes pratiques de sécurité de GitHub - comme la rotation des jetons, l'examen des applications et l'activation de l'authentification multi-facteurs - récupèrent toute sa valeur; GitHub conserve une documentation utile sur la façon de gérer et de protéger les jetons personnels sur sa plate-forme leurs guides officiels.

En outre, la prévention au niveau du dépôt devrait inclure des politiques qui rendent difficile une poussée non autorisée. La protection des succursales, l'examen obligatoire des codes et les flux d'intégration continus qui valident l'intégrité de l'historique et la signature du commit constituent des obstacles efficaces à la détection des altérations indésirables; GitHub fournit des conseils pour la mise en place de succursales protégées dans votre documentation. Dans le domaine de l'emballage Python, il est prudent de supposer que l'exécution directe de scripts téléchargés à partir de dépôts non vérifiés comporte des risques; la communauté et PyPI ont renforcé les pratiques de sécurité qui peuvent être consultées à Lignes directrices PyPI.

ForceMemo la campagne qui réécrit l'histoire de GitHub vole des jetons et diffuse des logiciels malveillants à travers les paquets Python
Image générée avec IA.

Si votre organisation développe ou consomme des paquets Python, il convient d'examiner les jetons et les sessions actives liés aux comptes de maintenance, de vérifier les engagements récents à la recherche d'insertions suspectes et d'établir des règles qui empêchent de réécrire l'historique de la branche principale sans autres révisions. Les mesures réactives comprennent la révocation des titres de compétence engagés, la rotation des jetons et l'analyse médico-légale des environnements de développement pour détecter des extensions ou des processus atypiques. Même avec les contrôles techniques en cours, la sensibilisation de l'équipe - ne pas ouvrir des extensions d'origine douteuse, vérifier la réputation des paquets et éviter de faire tourner le code aveugle - reste une défense essentielle.

Sur un plan plus large, ForceMemo met en évidence quelque chose que la sécurité des logiciels avertit depuis des années : la chaîne d'approvisionnement des logiciels est aussi faible que son lien le plus vulnérable. Un développeur unique avec l'environnement compromis peut transformer un projet fiable en vecteur d'attaque distribué. La communauté doit combiner les contrôles techniques - protection des succursales, vérification des permis, balayage automatique des dépôts - avec des processus organisationnels qui réduisent l'exposition des secrets et améliorent la détection précoce.

Pour les personnes curieuses qui veulent approfondir les résultats techniques, les analyses publiées par les équipes de réponse et de détection sont des ressources recommandées: Le rapport de StepSecurity sur cette campagne est disponible sur votre blog, et les travaux de Socket décrivant la distribution transitoire par extension peuvent être consultés à votre article technique. Se tenir informé et mettre en œuvre des contrôles préventifs est, aujourd'hui plus que jamais, le meilleur outil pour protéger les projets et les utilisateurs des campagnes qui combinent l'ingénierie sociale, l'abus des plates-formes et les techniques d'utilisation de plus en plus matures.

Couverture

Autres

Plus de nouvelles sur le même sujet.