FakeGit revient avec 17 610 dépôts GitHub malveillants
L'opération malveillante FakeGit a repris du service sur GitHub, et elle est désormais plus vaste qu'auparavant. Les chercheurs recensent 17 610 faux dépôts qui diffusent le malware SmartLoader. La campagne avait refait surface plus tôt ce mois-ci pour propager l'infostealer StealC.
Ces résultats proviennent d'Apiiro, une entreprise spécialisée dans la sécurité de la chaîne d'approvisionnement logicielle. Selon ses chercheurs, FakeGit a repris ses activités le 4 octobre.
La plupart des comptes à l'origine de ces dépôts ressemblent à des profils jetables créés pour l'occasion. Les chercheurs ont toutefois identifié au moins 700 comptes qui semblent appartenir à de vrais développeurs.
Un loader déguisé en téléchargement
Le dispositif est simple. Chaque dépôt malveillant contient un fichier README avec des instructions soignées et un bouton de téléchargement. Ce bouton mène à une archive ZIP contenant SmartLoader, la charge utile de premier niveau. Le rôle de SmartLoader est de récupérer et d'installer d'autres malwares sur la machine de la victime.
Une activité de ce type, avec différentes charges utiles, est observée depuis au moins janvier. Le nom FakeGit a été attribué à l'opération en juillet, lorsque Island, éditeur d'une plateforme de navigateur pour entreprises, a signalé 7 600 faux dépôts GitHub diffusant SmartLoader.
Dans ce rapport, Island relevait que 800 de ces dépôts se faisaient passer pour des compétences d'IA (AI skills) ou des serveurs MCP. Les serveurs MCP sont des composants qui permettent aux assistants d'IA de se connecter à des outils et à des données externes. Ces fausses entrées apparaissaient dans des registres et catalogues publics d'IA, où les développeurs cherchent des extensions.
13 000 dépôts redirigés en 34 heures
Selon Apiiro, la dernière vague a été très rapide. En 34 heures, FakeGit a modifié plus de 13 000 dépôts. Au plus fort de l'opération, l'attaquant touchait 2 999 dépôts par heure.
Les modifications étaient limitées et ciblées. "Dans les commits que nous avons échantillonnés, 97 % ne touchaient que le README, et 88 % faisaient pointer son bouton 'Download' vers un ZIP qui installe SmartLoader", indique Apiiro.
Ce détail a son importance. L'attaquant n'a pas eu besoin de mettre en place une nouvelle infrastructure pour cette vague.
"Personne n'a eu à créer un seul nouveau dépôt. La flotte était déjà là. Il a simplement suffi de la réorienter", expliquent les chercheurs.
Pourquoi les suppressions n'ont pas fonctionné
Apiiro attribue la longévité de FakeGit à la manière dont les suppressions sont gérées. Les dépôts sont supprimés sur la base de listes, et ces listes ne couvrent qu'une partie de la flotte malveillante.
Bloquer les charges utiles ne suffit pas non plus. Les fichiers placés sur liste noire et leurs copies de secours restent souvent accessibles, si bien que l'opérateur peut mettre à jour le lien de téléchargement et garder le même dépôt en ligne.
Les flux de renseignement sur les menaces étaient eux aussi en retard. "71 % de la flotte était absente d'URLhaus avant notre rapport, et une liste de blocage DNS au niveau du domaine ne peut pas bloquer un seul fichier sur GitHub sans bloquer GitHub", souligne Apiiro. URLhaus est une base de données publique qui recense les URL utilisées pour diffuser des malwares.
Les archives malveillantes étaient stockées à de nombreux endroits sur GitHub. Les chercheurs les ont retrouvées dans des forks, d'anciens fichiers, des ressources de versions (release assets), des pièces jointes d'issues et des dépôts dédiés servant uniquement à héberger des téléchargements. Supprimer les liens un par un ne sert pas à grand-chose face à une telle dispersion.
"Supprimez un fichier, et l'opérateur peut faire pointer l'appât vers une copie de rechange : un fork, un ancien ZIP, une ressource de version ou une pièce jointe d'issue", ont déclaré les chercheurs.
Les recommandations d'Apiiro
Les chercheurs conseillent aux utilisateurs de vérifier à qui appartient un dépôt avant d'y télécharger quoi que ce soit. Les compétences d'IA et les serveurs MCP ne doivent provenir que de registres officiels ou des dépôts de l'éditeur lui-même.
Toute personne qui soupçonne que SmartLoader s'est exécuté sur son système doit considérer qu'il s'agit d'une possible compromission de son compte GitHub. Cela implique de révoquer les sessions actives et les jetons d'accès, et de passer aux passkeys pour se connecter.
Notre analyse
FakeGit montre que le point faible n'est plus seulement le malware lui-même, mais la confiance que les développeurs accordent à une plateforme familière. Une page GitHub avec un README soigné et un bouton de téléchargement semble tout à fait banale, et c'est précisément sur cela que compte l'opérateur. Les travaux en cours sur les défenses côté plateforme, comme les fonctions de protection des push de GitHub, visent d'autres risques et ne semblent pas s'attaquer aux appâts logés dans les fichiers README.
La campagne s'inscrit aussi dans une tendance plus large : les attaquants se servent des écosystèmes de développement comme canaux de distribution, à l'image des paquets npm malveillants conçus pour atteindre directement les développeurs. Le recours à de fausses compétences d'IA et à de faux serveurs MCP laisse penser que les attaquants suivent les développeurs vers des catalogues plus récents et moins matures, où les vérifications sont peut-être plus légères.
Les 700 comptes qui semblent appartenir à de vrais développeurs retiennent l'attention. Si ces comptes ont été piratés, des identifiants volés alimentent peut-être la croissance de l'opération. Les conseils sur la révocation des jetons et l'adoption des passkeys n'en deviennent que plus urgents, alors même que l'adoption des passkeys reste à la traîne chez les professionnels de la sécurité.
Reste à voir si GitHub modifiera sa façon de supprimer ce type de contenu, en passant de suppressions fondées sur des listes à un nettoyage conjoint des forks, des ressources de versions et des pièces jointes. D'ici là, la flotte pourrait tout simplement être réorientée une nouvelle fois.
