Next.js malveillant : vols d’environnement via VS Code

Introduction: pourquoi c’est important

Les postes de travail des développeurs et les environnements de build sont des cibles à forte valeur, car ils contiennent souvent du code source, du matériel de signature et des secrets (tokens d’API, identifiants cloud) dans des variables d’environnement. Microsoft Defender Experts signale une campagne qui sème des dépôts Next.js malveillants—souvent présentés comme des « devoirs à emporter » liés à un recrutement—conçus pour se fondre dans des workflows de développement normaux et déclencher de manière fiable l’exécution de code.

Quoi de neuf / principaux constats

Microsoft a observé plusieurs dépôts liés partageant des conventions de nommage et réutilisant une logique de loader. Si l’appât initial varie, l’état final reste constant : récupération à l’exécution et exécution en mémoire de JavaScript contrôlé par l’attaquant, suivies d’un C2 par étapes.

1) Exécution de l’espace de travail VS Code à l’ouverture du dossier

Certains dépôts incluent un fichier .vscode/tasks.json configuré avec runOn: "folderOpen". Si un développeur ouvre (et approuve) le projet, une tâche s’exécute automatiquement et lance un script Node qui récupère un loader JavaScript (observé hébergé par étapes sur Vercel) et l’exécute.

2) Exécution à la phase de build lors du lancement de l’app

D’autres variantes se déclenchent lorsqu’un développeur démarre le projet (par exemple, npm run dev). Ces dépôts intègrent une logique malveillante dans des assets en apparence normaux (p. ex., un jquery.min.js trojanisé). L’asset décode une URL en base64, récupère le loader (là encore, fréquemment depuis Vercel) et l’exécute en mémoire.

3) Exécution au démarrage du backend avec exfiltration d’env + RCE dynamique

Un troisième scénario s’active lors de l’initialisation du serveur / de l’import de module. Les dépôts peuvent contenir une valeur .env comme AUTH_API=<base64>. Au démarrage, le code backend décode l’endpoint, publie process.env vers l’attaquant, puis exécute le JavaScript renvoyé via compilation dynamique (p. ex., new Function("require", response.data)(require)). Cela peut divulguer des configurations sensibles et permet une livraison de payloads de suivi pilotée par l’opérateur.

Enregistrement Stage 1 → command-and-control par étapes

Sur l’ensemble des voies, l’exécution converge vers une étape initiale de « registrar » qui dresse le profil de l’hôte et interroge un endpoint d’enregistrement, recevant un instanceId pour corréler l’activité ultérieure. La télémétrie a également relevé des rappels persistants vers une infrastructure contrôlée par l’attaquant (dont du trafic HTTP sur le port 300) après la mise en place initiale.

Impact pour les administrateurs IT et les équipes de sécurité

• Risque accru sur les endpoints développeurs : l’ouverture d’un dépôt peut suffire à exécuter du code si les tâches d’espace de travail sont approuvées.
• Exposition d’identifiants : le chemin de démarrage backend peut exfiltrer des variables d’environnement (clés cloud, identifiants de base de données, tokens CI).
• Détection plus difficile : l’exécution en mémoire et les loaders par étapes peuvent réduire les artefacts évidents sur disque.

Actions / prochaines étapes

• Sensibilisation des développeurs : traiter les évaluations techniques et les dépôts inconnus comme non fiables ; éviter de cliquer sur « Trust » dans VS Code avant revue.
• Inspection des dépôts : signaler/inspecter .vscode/tasks.json (en particulier runOn: "folderOpen"), les scripts Node inattendus sous .vscode/, et les bibliothèques minifiées qui ne correspondent pas à des hashes de référence.
• Hygiène des secrets : réduire la dépendance aux secrets longue durée dans .env ; utiliser des managed identities / des tokens à courte durée de vie lorsque possible et faire tourner tout identifiant exposé.
• Détection & contrôles : surveiller les processus Node.js pour des connexions sortantes inhabituelles (p. ex., des outils dev contactant des domaines de staging suivis d’un C2 inconnu), et envisager des restrictions d’egress depuis les appareils développeurs et les agents de build.
• Hunting : rechercher dans les plateformes d’hébergement de code et les miroirs internes des « familles » de nommage et des schémas de réutilisation structurelle décrits par Microsoft (dépôts quasi dupliqués, loaders similaires, endpoints de staging répétés).