Des joueurs et des chercheurs indépendants ont constaté que des fichiers CDN officiels chargés par le lanceur PC de Goddess of Victory: NIKKE ont été altérés. Un rapport d’analyse publié sur GitHub le 3 novembre affirme que le chargeur implanté télécharge et exécute un cheval de Troie d’accès à distance, et que la machine touchée doit être considérée comme entièrement compromise.
Au moment de la publication d’InvenGlobal, ni le développeur SHIFT UP ni l’éditeur Level Infinite n’avaient réagi publiquement. Toutes les dates et heures ci-dessous proviennent d’analyses externes, sans communiqué officiel permettant de les recouper.
Chronologie et deux points qui ne concordent pas
La chronologie établie par InvenGlobal est la suivante : le 27 septembre, du code de l’attaquant entre dans trois fichiers JavaScript officiels du CDN, que le lanceur charge à chaque ouverture ; le 28 octobre, le troisième fichier est nettoyé à la source ; au plus tard à partir du 1er novembre, l’ouverture du lanceur pouvait télécharger et exécuter un programme de contrôle à distance, sans que cela se produise à chaque fois ; le 3 novembre, deux fichiers sont remplacés à 17 h 04 et 17 h 21 (heure GMT), à 18 h 31 le serveur de l’attaquant cesse de répondre, et à 18 h 59 deux nœuds du CDN servaient encore des copies modifiées.
Le rapport GitHub s’écarte légèrement de cette version. Il évoque quatre ressources officielles, dont FeedList et vue-bucket sont confirmées, et indique que lors du contrôle du 4 novembre les quatre étaient revenues à une version saine. Le 27 septembre qu’il donne correspond au jour où le domaine de contrôle insightjs.com a été de nouveau enregistré après environ cinq ans d’inactivité. Le rapport précise aussi que le chargeur n’a exécuté sa charge utile qu’environ 37 jours après sa mise en place ; pendant ce temps, les joueurs qui ouvraient le lanceur n’ont pas forcément remarqué d’anomalie.
Pourquoi un trojan de jeu vole-t-il la configuration de Claude Code
Selon le rapport, le trojan dispose de 19 commandes, couvrant l’exécution de commandes arbitraires, un shell interactif, le transfert de fichiers, la capture d’écran et la collecte d’identifiants. Ses chemins de collecte sont au nombre d’environ 1 790, et parmi les outils d’IA et de développement nommément visés figurent Claude Code, Gemini CLI, Cursor, Windsurf et les configurations MCP. Il cible aussi les clés d’API et jetons OAuth de fournisseurs d’IA, les clés de services cloud, les jetons de dépôts de paquets, les identifiants CI et Kubernetes, les clés SSH et GPG, les sessions de navigateur ainsi que les données de 28 extensions de portefeuilles de cryptomonnaies.
Cette liste ressemble beaucoup à l’empoisonnement de LiteLLM le mois dernier. Le 21 octobre, LiteLLM 1.107.0 a été altéré puis publié sur PyPI ; le logiciel voleur visait lui aussi les identifiants de navigateur et les clés cloud, et Wiz a révélé que quelques heures plus tard seulement, les attaquants commençaient à vérifier les identifiants AWS dérobés. Les points d’entrée des deux incidents diffèrent fortement, l’un dans les dépendances des développeurs, l’autre dans le lanceur de jeu des joueurs, mais ce qu’il s’agit de récupérer se recoupe largement. Les fichiers de configuration locaux des développeurs contiennent souvent des clés en clair, qui se convertissent directement en quotas de calcul et en ressources cloud ; dans l’affaire LiteLLM, une fois les identifiants validés, les attaquants sont allés lister les modèles sur Bedrock.
Le rapport indique explicitement ce qui n’est pas confirmé : la manière dont l’attaquant a obtenu un accès en écriture au CDN, l’ampleur réelle de l’infection et la question de savoir si d’autres ressources ont été contaminées durant la même période. L’auteur précise aussi n’avoir pas reconstitué de manière indépendante le script malveillant de seconde étape, et que la marque K2F et les informations de certificat présentes dans le code ne peuvent servir de base à une attribution. Aucun élément ne permet pour l’instant de relier cet incident à l’affaire LiteLLM.
Vérification et mesures à prendre
Les utilisateurs qui ont joué à la version PC peuvent vérifier ainsi :
- Ouvrir le fichier
debug.logdansLauncher/intl_service, au sein du dossier d’installation de NIKKE, et y chercherk2f_chan. Si cette chaîne apparaît, le programme de contrôle à distance a peut-être été exécuté. - Tant que la correction n’est pas confirmée officiellement, ne pas lancer le lanceur PC pour le moment, et vider son cache avant toute nouvelle utilisation.
- En cas de traces, isoler d’abord la machine et conserver les preuves, puis, depuis un appareil sain, changer les mots de passe, fermer toutes les sessions et révoquer les jetons d’API et les clés SSH.
- Les phrases de récupération de portefeuille ne peuvent pas être sauvées par une rotation ; il faut créer un nouveau portefeuille et y transférer les actifs.
Le rapport rappelle également que le trojan peut réinstaller son propre chargeur, si bien que se fier uniquement aux empreintes de fichiers n’est pas fiable, et qu’il ne faut pas supprimer directement tout le dossier de Chrome.
Sources : rapport d’analyse indépendant sur GitHub, InvenGlobal, CocoLoop ; les deux versions divergent sur le nombre de fichiers contaminés, l’ampleur de l’infection et le point d’entrée de l’attaque ne sont pas confirmés, et aucune réponse officielle n’a été donnée.