La campagne qui transforme les tests techniques en portes arrières et lance le code en mémoire dans les environnements de développement

Publié 7 min de lectura 117 lecture

Les développeurs sont devenus une cible stratégique pour les acteurs malveillants qui cherchent non seulement à voler des références, mais aussi à planter un accès persistant sur des machines avec des informations sensibles. Un récent rapport de Microsoft décrit une campagne coordonnée qui profite de projets ou de faux tests techniques - principalement prétendant être des projets Next.js ou des exercices d'entretien - pour inciter les développeurs à exécuter du code qui charge et exécute des scripts contrôlés par des attaquants. Le but final est très clair : obtenir l'exécution à distance du code en mémoire et, à partir de là, étendre le contrôle sans laisser de traces sur le disque. Vous pouvez lire l'analyse Microsoft ici: Microsoft Defender Recherche sur la sécurité.

La menace repose sur la confiance que les équipes de développement placent dans les outils et les flux quotidiens. Trois modes d'exécution, différents dans son activateur mais convergent dans son résultat, ont été décrits par les chercheurs. Dans la première, un fichier de configuration de Visual Studio Code profite de l'automatisation de l'espace de travail pour invoquer des tâches lors de l'ouverture du dossier de projet; la configuration utilise un déclencheur qui exécute des commandes à distance en confiant le projet, vous permettant de télécharger un chargeur enregistré sur les plateformes publiques et de l'exécuter à chaud.

La campagne qui transforme les tests techniques en portes arrières et lance le code en mémoire dans les environnements de développement
Image générée avec IA.

Le deuxième vecteur est celui qui se produit pendant le développement: il suffit de lancer le serveur avec la commande de développement classique - par exemple, npm run dev- activer le code caché dans les bibliothèques JavaScript modifiées qui semblent être des dépendances inoffensives, comme un fichier minifié de jQuery. Ce code malveillant télécharge un chargeur depuis un domaine de mise en scène (souvent Vercel) qui exécute ensuite les instructions directement dans le processus Node.js.

La troisième méthode est déclenchée lorsque vous démarrez le moteur d'application : des modules ou des routes apparemment légitimes peuvent contenir une logique qui, lorsque vous démarrez, envoie l'environnement de processus (variables environnementales, par exemple) à un serveur externe et exécute la réponse JavaScript en mémoire. Dans tous les cas, la même charge utile JavaScript fait un profil machine et contacte régulièrement un point final d'enregistrement pour obtenir un identifiant unique (« instanceId ») qui sert à corréler et gérer la session.

L'importance technique de l'exécution du code en mémoire est qu'il réduit l'impression médico-légale sur disque et facilite la livraison d'une deuxième étape qui agit comme un contrôleur : une "étape 2" capable de exécuter des tâches sur demande, de découvrir des actifs dans l'environnement et d'exfilter des informations. Microsoft souligne que le contrôleur intègre la télémétrie d'erreur, réessayer la logique et la capacité de gérer les processus enfants - c'est-à-dire qu'il se comporte comme un outil d'accès à distance bien conçu. Plus de détails dans le rapport original de Microsoft: rapport technique.

Ce n'est pas seulement Vercel: les attaquants ont également commencé à utiliser des serveurs de scène alternatifs pour accueillir les étapes ultérieures. Sécurité abstraite a documenté un changement de tactique vers l'utilisation de GitHub gists et de raccourcis URL pour cacher la véritable origine des charges utiles. Ils ont également identifié un paquet de npm malveillant appelé « slint-validator » qui récupère une charge utile parlée de Google Drive: cette charge utile correspond à une famille de logiciels malveillants JavaScript connue sous le nom BeaverTail.

Dans Windows, des chaînes d'infection encore plus élaborées ont été observées : une tâche VS Code peut lancer un script batch que Node.js télécharge s'il n'est pas présent, utilise des utilitaires natifs comme certutile pour décoder des blocs de code intégrés et, avec le Node runtime, déploie un malware dans Python protégé avec PyArmor. D'autres analyses mettent en évidence des techniques créatives de résilience : injecter du code dans des contrats NFT dans des blockchains comme Polygon pour que la charge utile se rétablisse, ce qui rend difficile le retrait et l'augmentation de sa disponibilité.

Des chercheurs indépendants comme Réseau Asgard ont suivi cette activité et le lient aux tactiques utilisées dans les campagnes précédentes connues pour sa sophistication. Alors que Microsoft évite d'attribuer la campagne à un acteur particulier, les modèles correspondent à une famille d'opérations qui, dans le passé, ont été liées à des groupes nord-coréens sous le label "Contagious Interview" dans certains rapports publics.

Les plateformes de collaboration et les dépôts publics n'ont pas été immunisés : GitLab a signalé l'élimination de plus de 100 comptes responsables de la distribution de projets malveillants liés à cette campagne. Son équipe de renseignement a également trouvé des preuves internes qui indiquent une structure organisée derrière ces opérations, avec des dossiers financiers et le contrôle du rendement de l'équipement, suggérant une activité soutenue et axée sur les avantages économiques. Plus de contexte dans l'analyse de GitLab: GitLab Recherche de menaces.

Pour ceux qui travaillent dans le développement, cela devrait sonner l'alarme: les dépôts de "test technique" ou les modèles d'entrevue sont des vecteurs idéaux parce qu'ils correspondent aux tâches quotidiennes. Lancer un serveur local, ouvrir un espace de travail ou faire confiance à un projet par défaut peut suffire à déclencher une chaîne d'exécution malveillante. Des outils et services légitimes qui hébergent du contenu externe (Vercel, Render, Railway, JSON Keeper, npoint.io, entre autres) ont été réutilisés par les attaquants pour stocker et servir des charges utiles.

Les recommandations pratiques ne sont pas radicales, mais elles exigent une discipline : limiter les privilèges des comptes de développement, séparer les environnements de construction et de CI / CD de l'équipe de développement, appliquer une authentification forte et un accès conditionnel, et filtrer ou vérifier les tâches et les automatisations incluses dans les projets avant leur mise en œuvre. Il est également approprié d'analyser les dépendances, d'éviter d'exécuter des scripts tiers sans révision et de ne pas se fier automatiquement aux instructions de confiance de VS Code ou aux tâches avec exécuter Sur configuré pour ouvrir des dossiers.

La campagne qui transforme les tests techniques en portes arrières et lance le code en mémoire dans les environnements de développement
Image générée avec IA.

En outre, les entreprises et les responsables de la sécurité devraient mettre en place une détection pour les processus Node.js qui téléchargent et évaluent JavaScript en mémoire, surveillent les connexions sortantes aux services d'hébergement public et utilisent des listes blanches si possible. Les fournisseurs de dépôts et de plateformes prennent déjà des mesures : la suppression des comptes et la coordination entre les équipes de sécurité font partie de la réponse. Pour comprendre la dimension humaine du problème et comment l'"emploi" est exploité comme appât, le rapport d'Okta offre une perspective intéressante sur la façon dont certains faux candidats passent les contrôles et sont utilisés dans ces programmes: Analyse Okta.

Le message pour la communauté technique est simple et urgent : ne baissez pas votre garde. La combinaison de l'ingénierie sociale et de l'automatisation des flux de développement devient apparemment inoffensive Projet Git dans une porte arrière efficace. Revoir les fonctions.json, les dépendances d'audit et traiter avec suspicion tout projet qui demande à exécuter des commandes automatiques lors de l'ouverture sont des mesures qui peuvent arrêter ces chaînes avant qu'ils n'exécutent leur première charge utile en mémoire.

Cette campagne rappelle que la sécurité du développement devrait comprendre des contrôles spécifiques des flux quotidiens et des outils. Il ne s'agit pas seulement de protéger les serveurs en production : protéger le "client" - l'équipe du développeur - est tout aussi critique lorsque ce client contient des clés, des jetons et un accès à une infrastructure qui peut être pivotée en quelques secondes. Le maintien de bonnes pratiques en matière d'hygiène des lettres de créance, de segmentation et de révision du code est maintenant une défense essentielle.

Couverture

Autres

Plus de nouvelles sur le même sujet.