Des hackers nord-coréens transforment des tests Terraform de recrutement en voie d’accès aux réseaux des développeurs

Jade Sleet a compromis un fournisseur indien de technologies de taille modeste

SentinelOne attribue la compromission d’un fournisseur indien de services informatiques à Jade Sleet, un groupe nord-coréen connu pour cibler les entreprises de cryptomonnaie et leurs fournisseurs. L’intrusion s’est concentrée sur un MacBook Apple Silicon attribué à un ingénieur DevOps.

La victime était nettement plus petite que les organisations précédemment associées à cet acteur. Cette différence est importante, car elle montre que Jade Sleet ne limite pas ses opérations aux grandes plateformes blockchain. Les fournisseurs de plus petite taille peuvent offrir un accès indirect à leurs clients, à leurs infrastructures de développement et à des relations techniques privilégiées.

Jade Sleet est également suivi sous les noms de PUKCHONG, Slow Pisces, TraderTraitor et UNC4899. Ses opérations ont historiquement porté sur le vol de cryptomonnaies, mais les développeurs et les fournisseurs tiers sont des cibles récurrentes, car leurs systèmes peuvent contenir des identifiants ou permettre d’accéder à des environnements de plus grande valeur.

Les attaquants ont déployé deux portes dérobées macOS basées sur Rust, FLATROOF et ROOFDECK. FLATROOF est également connu sous le nom de Gaslight. Les deux implants étaient déjà apparus lors de la compromission de la passerelle LayerZero de KelpDAO, en mars-avril 2026, et SentinelOne a identifié la victime indienne en recherchant ce même malware.

Aucun identifiant CVE ni score de gravité officiel n’est associé à cet incident. Il s’agit d’une campagne d’intrusion fondée sur l’ingénierie sociale et sur du contenu malveillant destiné aux développeurs, et non d’une vulnérabilité publiée dans Terraform, Cursor ou macOS.

De faux projets de recrutement dissimulent le piège initial

La campagne approche les développeurs et les candidats à un emploi avec des exercices techniques de recrutement apparemment légitimes. Les dépôts GitHub sont conçus pour ressembler à des devoirs de programmation ou à des projets d’ingénierie des infrastructures liés à l’employeur usurpé.

Les noms de dépôts observés comprennent :

• gtn-candidate-repo
• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

Les thèmes sont choisis en fonction du rôle professionnel de la cible. Un candidat DevOps ou spécialisé dans les infrastructures peut ainsi trouver une configuration Terraform, une automatisation cloud ou des tâches de déploiement qui semblent parfaitement normales dans le cadre d’une évaluation technique.

L’élément malveillant est un fichier de verrouillage des dépendances Terraform nommé .terraform.lock.hcl. Celui-ci pointe vers une infrastructure contrôlée par les attaquants, notamment registry.hashicorp-aws[.]com. Lorsqu’une cible exécute terraform init, Terraform peut récupérer des modules contrôlés par les attaquants.

Cette technique exploite la confiance accordée à l’exercice plutôt qu’une faille avérée de Terraform. Le développeur ouvre volontairement le projet et exécute une étape d’initialisation standard, tandis que la configuration des dépendances du dépôt redirige une partie de ce processus vers une infrastructure hostile.

SentinelOne a constaté que les paquets étaient personnalisés pour chaque victime et utilisés dans des environnements de développement préparés pour un seul ingénieur à la fois. Cette personnalisation réduit l’efficacité des détections générales fondées uniquement sur des hachages de fichiers courants ou sur un contenu de dépôt identique.

Les enquêteurs n’ont pas déterminé précisément comment le malware est arrivé sur le MacBook de l’ingénieur DevOps. Le mécanisme Terraform malveillant s’inscrit dans le cadre plus large de la campagne, mais les éléments disponibles ne permettent pas d’établir la séquence exacte de livraison dans le cas de cette victime.

Des implants dormants activés depuis un espace de travail de développeur

FLATROOF et ROOFDECK étaient présents sur le système de l’ingénieur au 18 mars 2026. Ils sont restés inactifs jusqu’au 29 mars, date à laquelle ils ont commencé à émettre des balises et à interagir avec l’hôte.

Les premiers lancements enregistrés provenaient de Cursor, quelques secondes après que le développeur a ouvert un espace de travail nommé cloudshield à l’emplacement suivant :

~/DevOps-Automation/cloudshield

Cette chronologie relie l’exécution au flux de travail habituel du développeur. Elle ne permet toutefois pas de déterminer quel composant de l’espace de travail, quelle dépendance ou quelle action automatisée a lancé les implants.

Une version plus récente de ROOFDECK a été installée le 20 avril 2026, soit un jour après la reconnaissance publique par LayerZero de l’incident touchant KelpDAO. L’implant mis à jour a supprimé les binaires ROOFDECK et FLATROOF présents sur le MacBook.

Il a également été livré sans symboles ni informations de débogage. La suppression de ces éléments laisse aux défenseurs moins de contexte pour l’analyse forensique et complique la rétro-ingénierie, ce qui laisse penser que les opérateurs perfectionnaient activement leurs outils après l’exposition publique de l’opération précédente.

Cette séquence confirme également l’évaluation selon laquelle ROOFDECK est un implant déployé dans un second temps. Au lieu de fournir nécessairement l’accès initial, il semble être déployé après qu’un attaquant a établi un point d’appui et cherche à conserver un contrôle plus durable.

FLATROOF vole des données tandis que ROOFDECK étend le contrôle

FLATROOF est une porte dérobée en Rust conçue pour les systèmes macOS basés sur ARM. Elle communique via Telegram et prend en charge l’exécution de commandes à distance, ainsi que l’envoi et le téléchargement de fichiers.

Un composant Python permet d’élargir la collecte sur l’hôte. Le malware peut récupérer des données depuis Chrome, Brave, Firefox et Safari, voler l’historique des commandes du Terminal, recenser les applications installées, collecter des informations sur le matériel et les logiciels, et capturer une vue instantanée des processus en cours d’exécution.

Il peut également copier login.keychain-db. Sur un poste de travail de développeur, ces capacités pourraient exposer des éléments d’authentification, des sessions de navigateur, des accès cloud, des informations sur des services internes et des commandes précédemment utilisées pour l’administration.

ROOFDECK est également écrit en Rust et cible les Mac basés sur ARM, mais il utilise le protocole Nostr pour assurer un contrôle et une commande décentralisés. Il fournit des fonctions de reconnaissance, un accès à distance au shell, des fonctions de manipulation de fichiers, de déplacement latéral et de persistance via les Launch Agents de macOS.

Les commandes envoyées à ROOFDECK sont signées avec la clé privée de l’opérateur. L’implant contient une clé publique qu’il utilise pour vérifier l’intégrité des commandes avant d’agir, ce qui limite la capacité de parties non autorisées à transmettre des instructions via le même canal de communication.

Ses fonctions sont réparties entre plusieurs gestionnaires de commandes. ROOFDECK implémente également en interne de nombreuses opérations sur les répertoires et les fichiers, au lieu de dépendre entièrement des utilitaires shell standard installés sur le Mac. SentinelOne a rapproché cette approche de conception des outils LightlessCan de Lazarus.

Ensemble, les deux implants offrent des capacités complémentaires : FLATROOF privilégie la collecte et le vol de données, tandis que ROOFDECK fournit un environnement durable pour l’accès au shell, la persistance et les déplacements au-delà du point d’accès initial.

Un Mac de développeur peut exposer bien plus qu’un seul poste de travail

La victime directe est l’ingénieur dont le MacBook Apple Silicon a été compromis. Le risque plus large s’étend à tous les environnements qui accordaient leur confiance à cet appareil.

Les postes DevOps interagissent couramment avec des systèmes de gestion du code source, des consoles d’administration cloud, des plateformes CI/CD, des registres de paquets et des dépôts d’infrastructure as code. Ils peuvent également contenir des jetons de déploiement, des éléments SSH, des sessions de navigateur et des fichiers de configuration qui ne sont pas accessibles aux utilisateurs ordinaires de l’entreprise.

La compromission d’un fournisseur informatique introduit un risque supplémentaire pour la chaîne d’approvisionnement. L’accès obtenu auprès d’un fournisseur pourrait potentiellement être utilisé contre ses clients en aval, même si aucune compromission de client précise n’a été divulguée dans ce cas.

L’historique de Jade Sleet permet de comprendre le choix de la cible. GitHub a indiqué en juillet 2023 que l’acteur ciblait les utilisateurs de cryptomonnaies et de blockchain, ainsi que les fournisseurs au service de ces organisations. Au début de 2025, le groupe a été associé au vol d’environ 1,5 milliard de dollars depuis l’infrastructure de cold wallets de Bybit, à la suite de la compromission de l’environnement de développement de Safe{Wallet}.

L’intrusion récemment attribuée à un fournisseur indien de services informatiques obéit à la même logique stratégique : atteindre des actifs de valeur en compromettant d’abord les personnes et les systèmes qui participent à leur conception, à leur exploitation ou à leur support.

Ce que les équipes de développement et de sécurité doivent vérifier

Les organisations doivent commencer par examiner les fichiers .terraform.lock.hcl et les modules Terraform afin d’y rechercher des dépendances inattendues, des sommes de contrôle modifiées et des références à des registres non fiables. Toute présence de registry.hashicorp-aws[.]com doit faire l’objet d’une investigation.

Les équipes de sécurité doivent mettre en corrélation les exécutions de terraform init avec les connexions sortantes depuis les postes de travail des développeurs. Les dépôts transmis dans le cadre d’entretiens ou de conversations de recrutement non sollicités doivent être examinés dans un environnement isolé avant toute exécution de commande de build, d’initialisation ou d’installation de dépendances.

Sur les systèmes Apple Silicon, les défenseurs doivent rechercher :

• des artefacts liés à FLATROOF ou Gaslight et à ROOFDECK ;
• une activité inattendue de contrôle et de commande via Telegram ;
• du trafic Nostr incompatible avec l’utilisation habituelle de l’entreprise ;
• des Launch Agents macOS non reconnus ;
• des processus suspects lancés par Cursor ;
• des accès aux profils de navigateur, à l’historique du Terminal ou à login.keychain-db ;
• la collecte d’inventaires d’applications et de vues instantanées des processus ;
• des binaires de porte dérobée supprimés ou remplacés de manière inattendue ;
• des exécutables inconnus dépourvus de symboles et de données de débogage.

Si un poste de développeur est susceptible d’avoir été compromis, les organisations doivent renouveler les identifiants et les jetons accessibles depuis ce système. La réponse doit couvrir les comptes cloud, la gestion du code source, les services CI/CD, les registres de paquets et les systèmes liés aux cryptomonnaies, et ne pas se limiter au mot de passe macOS local.

Les réseaux de développement doivent également être segmentés de la production, et les accès latéraux limités à ce qui est nécessaire pour chaque rôle. Des registres de confiance, des contrôles d’intégrité indépendants, des builds reproductibles et un examen obligatoire des modifications de dépendances peuvent réduire l’exposition aux exercices techniques malveillants.

L’hypothèse défensive centrale doit évoluer : un exercice de programmation est un contenu exécutable fourni par un tiers. Il doit faire l’objet du même niveau de contrôle que n’importe quel autre logiciel non fiable.