Microsoft Warns Developers of Fake Next.js Job Repos Delivering In-Memory Malware

Campagne de Ciblage des Développeurs par des Dépôts Malveillants

Une campagne malveillante vise les développeurs en utilisant des dépôts de code déguisés en projets légitimes ou en évaluations techniques. L’objectif est de pousser les victimes à exécuter du code arbitraire qui s’installe en mémoire, permettant ainsi un accès persistant aux machines compromises.

Ces attaques exploitent des leurres liés aux offres d’emploi pour s’intégrer aux flux de travail des développeurs. Des dépôts frauduleux sont créés sur des plateformes comme Bitbucket, portant des noms leurres tels que “Cryptan-Platform-MVP1”, pour inciter les développeurs à les exécuter dans le cadre d’un processus d’évaluation.

Plusieurs méthodes d’exécution malveillante ont été identifiées :

• Exécution via l’espace de travail Visual Studio Code : L’ouverture d’un projet malveillant dans VS Code, configuré avec l’automatisation d’espace de travail, déclenche l’exécution de code malveillant récupéré à distance via la configuration runOn: "folderOpen".
• Exécution lors de la compilation : L’exécution du serveur de développement standard (npm run dev) peut activer du code malveillant intégré dans des bibliothèques JavaScript altérées (ex: jquery.min.js), qui télécharge et exécute ensuite un chargeur JavaScript en mémoire via Node.js.
• Exécution au démarrage du serveur : Le lancement du backend d’une application peut exécuter une logique de chargeur dissimulée dans un module backend, qui exfiltre l’environnement du processus et exécute du JavaScript reçu en réponse, toujours en mémoire.

Le résultat final de ces différentes méthodes est l’obtention d’un code d’exécution côté serveur permettant de profiler la machine hôte, d’établir une connexion à un serveur de commande et de contrôle (C2), et potentiellement de télécharger et d’exécuter des charges utiles supplémentaires en mémoire pour garantir la persistance et le vol de données sensibles (code source, identifiants, secrets).

Bien que l’attribution spécifique ne soit pas faite, l’utilisation de tâches VS Code et de domaines Vercel pour le staging de malware rappelle les tactiques des groupes de pirates liés à la Corée du Nord, impliqués dans la campagne “Contagious Interview”. Des évolutions observées incluent l’utilisation de scripts hébergés sur GitHub Gists, des raccourcisseurs d’URL, des paquets npm malveillants (comme “eslint-validator” distribuant le malware BeaverTail), et des chaînes d’infection Windows utilisant certutil pour exécuter du code Python obfusqué.

Points Clés:

• Méthode d’attaque : Utilisation de dépôts de code malveillants déguisés en offres d’emploi ou projets d’évaluation.
• Exécution en mémoire : Le malware est principalement exécuté en mémoire pour minimiser les traces sur le disque.
• Persistance : Objectif d’établir un accès persistant aux systèmes compromis.
• Ciblage : Développeurs de logiciels, visant des données sensibles.
• Évolution des tactiques : Utilisation de services cloud variés pour le staging, de scripts obfusqués, et de chaînes d’infection complexes.
• Liens possibles : Attribution préliminaire à des groupes liés à la Corée du Nord.

Vulnérabilités :

L’article ne mentionne pas de CVE spécifiques mais décrit des vulnérabilités exploitées au niveau de la confiance accordée aux dépôts de code externes et aux mécanismes d’exécution automatique dans les environnements de développement.

• La vulnérabilité réside dans la confiance implicite accordée aux projets trouvés sur des plateformes de développement et dans les fonctionnalités qui permettent une exécution de code automatique lors de l’ouverture ou de la compilation de projets.

Recommandations :

• Renforcer les limites de confiance des flux de travail des développeurs : Évaluer rigoureusement la provenance et la sécurité des projets avant de les intégrer.
• Mettre en œuvre une authentification forte et un accès conditionnel : Pour limiter les accès non autorisés.
• Maintenir une hygiène stricte des identifiants : Gérer les secrets et les clés d’accès avec précaution.
• Appliquer le principe du moindre privilège : Accorder uniquement les permissions nécessaires aux comptes de développeurs et aux identités de build.
• Séparer l’infrastructure de build lorsque possible : Pour isoler les processus critiques.
• Soyez vigilant face aux offres d’emploi suspectes : Vérifier l’authenticité des offres et des entreprises.
• Auditer les dépendances et les bibliothèques : S’assurer qu’elles proviennent de sources fiables et qu’elles n’ont pas été altérées.

Source