Jade Sleet piège un prestataire IT indien avec les backdoors macOS FLATROOF et ROOFDECK
SentinelOne relie l’acteur nord-coréen Jade Sleet au compromis d’un prestataire informatique indien via de faux entretiens d’embauche et des modules Terraform piégés. Traitez le poste de développeur comme un actif critique et auditez vos dépendances Terraform.
21 septembre 2026. SentinelOne publie une analyse qui relie Jade Sleet, un acteur aligné sur la Corée du Nord, au compromis d’un prestataire de services informatiques en Inde. 18 mars 2026. Les deux backdoors sont déjà présentes sur le MacBook d’un ingénieur DevOps, sans que personne ne le sache. 29 mars. Elles s’activent, quelques secondes après l’ouverture d’un espace de travail dans l’éditeur Cursor. Pourquoi c’est important : le groupe qui a volé 1,5 milliard de dollars à Bybit début 2025 ne vise plus seulement la crypto, il cible les entreprises qui servent les entreprises.
Un acteur nord-coréen qui vise les développeurs
Jade Sleet est l’un des nombreux alias d’un même acteur, suivi aussi sous les noms PUKCHONG, Slow Pisces, TraderTraitor et UNC4899. Sa spécialité historique est le vol de cryptomonnaies. Début 2025, il est rattaché au vol d’environ 1,5 milliard de dollars dans le portefeuille froid de Bybit, après un compromis de la chaîne d’approvisionnement de l’environnement de développement de SafeWallet. En juillet 2023, GitHub décrivait déjà la cible : « Jade Sleet vise surtout les utilisateurs liés à la cryptomonnaie et à la blockchain, mais aussi les fournisseurs utilisés par ces entreprises. »
La nouveauté tient au déplacement de la cible. Le prestataire indien compromis est, selon SentinelOne, une organisation « beaucoup plus petite » du secteur des services informatiques. Ce n’est pas une bourse crypto ni un protocole Web3, c’est un sous-traitant dont le métier est de fournir du code, de l’infrastructure et des accès à d’autres entreprises. En le compromettant, Jade Sleet obtient un point d’entrée vers les clients du prestataire, pas seulement vers le prestataire lui-même.
Le mode opératoire repose sur un ressort humain simple : le faux entretien d’embauche. Des victimes sont approchées via des offres d’emploi fabriquées, ciblant des personnes travaillant dans le DevOps, la cryptomonnaie ou la fintech. L’entretien sert de prétexte pour faire cloner un dépôt GitHub « d’exercice », qui est en réalité piégé.
Deux backdoors Rust taillées pour macOS
Les charges utiles sont deux familles de logiciels malveillants écrites en Rust et ciblant les Mac à processeur ARM (Apple Silicon). Toutes deux ont déjà été observées lors de l’attaque de mars-avril 2026 contre le pont LayerZero de KelpDAO.
FLATROOF, aussi appelé Gaslight, est une backdoor qui utilise Telegram pour le command-and-control. Elle sait exécuter des commandes, téléverser et télécharger des fichiers, et exfiltrer des données via un module Python : historique de navigation de Chrome, Brave, Firefox et Safari, historique du terminal, liste des applications installées, profil matériel et logiciel de la machine, instantané des processus en cours et copie du fichier login.keychain-db.
ROOFDECK est plus ambitieuse. Elle utilise le protocole Nostr pour un C2 décentralisé, et sait faire de la reconnaissance système, manipuler des fichiers, ouvrir un shell distant, se déplacer latéralement et assurer sa persistance via des Launch Agents. Détail notable : ses commandes sont signées avec la clé privée de l’opérateur et vérifiées avec une clé publique embarquée avant exécution. Le code réimplémente aussi de nombreuses commandes shell classiques, une technique déjà vue dans les outils sophistiqués alignés sur la Corée du Nord, comme le LightlessCan de Lazarus.
Cette signature a une conséquence pour la défense : les deux implants ne ressemblent pas à du malware générique. Ils s’intègrent dans l’outillage normal d’un développeur, se camouflent en processus légitimes et ne déclenchent pas les détections fondées sur des signatures de shell classiques.
Des dépôts GitHub et un fichier Terraform piégés
Le vecteur initial combine deux pièges. Le premier est un dépôt GitHub d’apparence anodine, construit comme un exercice d’entretien. SentinelOne liste plusieurs dépôts observés : gtn-candidate-repo (déjà utilisé dans l’incident KelpDAO), Northwind-IAC, novacart-interview et terraform-candidate-repo.
Le second piège est plus sournois, car il se déclenche sans code malveillant évident. Ces dépôts contiennent un fichier de verrouillage de dépendances Terraform — un .terraform.lock.hcl — qui pointe vers des domaines contrôlés par l’attaquant, comme registry.hashicorp-aws[.]com. Quand le développeur exécute terraform init, la plateforme télécharge des modules contrôlés par l’attaquant. Le verrou de dépendances, censé figer des versions sûres, devient le vecteur de compromission.
L’élégance de l’attaque tient à sa discrétion : aucun binaire malveillant dans le dépôt, aucun script évident. C’est l’outillage d’infrastructure légitime — le gestionnaire de paquets de l’infra-as-code — qui va chercher le code hostile chez l’attaquant. Une revue rapide du dépôt ne voit rien d’anormal, parce qu’il n’y a rien d’anormal à voir dans le code source lui-même.
Un prestataire indien, victime collatérale
C’est en chassant les deux backdoors que SentinelOne a découvert une victime supplémentaire, sans lien avec la crypto : un prestataire de services informatiques basé en Inde. Le compromis est passé par le MacBook à puce Apple Silicon d’un ingénieur DevOps. Les backdoors y étaient présentes dès le 18 mars 2026, mais le vecteur d’infection exact reste inconnu à ce stade.
Elles sont restées dormantes jusqu’au 29 mars, date à laquelle l’activité réseau a commencé. Le détail le plus frappant : les implants ont été lancés par Cursor, l’éditeur de code, quelques secondes après l’ouverture de l’espace de travail cloudshield (~/DevOps-Automation/cloudshield). L’outil même avec lequel le développeur travaille au quotidien a servi de lanceur.
ROOFDECK est déployée comme outil de suivi une fois l’accès initial établi. Une version mise à jour a été installée le 20 avril 2026, le lendemain de la reconnaissance publique du piratage de KelpDAO par LayerZero. Cette variante supprime les anciens binaires de ROOFDECK et FLATROOF, et retire les symboles et informations de débogage pour échapper à la détection. Le groupe nettoie derrière lui et améliore ses implants en continu.
Le poste de développeur est devenu le périmètre
SentinelOne résume le déplacement du risque en une phrase : l’accès initial de ces groupes passe désormais par « les tiers et leur chaîne d’approvisionnement logicielle, ce qui place le poste du développeur au centre de la défense ». Un poste de développement porte des accès au cloud, aux pipelines CI/CD et au code source. Le compromettre ouvre plus de portes que le compromis d’un poste bureautique.
Pour un RSSI, plusieurs signaux doivent déclencher une alerte. D’abord, la chasse aux faux entretiens : les recruteurs légitimes n’envoient pas de dépôt à cloner avant une discussion vérifiée. Ensuite, la surveillance des dépendances : un fichier .terraform.lock.hcl qui pointe vers un domaine non officiel — jamais hashicorp-aws.com — est un signal d’alerte, pas un détail. Enfin, la détection sur les postes de développement : un éditeur de code qui lance des processus inattendus, des Launch Agents nouveaux sur un Mac, ou du trafic vers Telegram ou des relais Nostr depuis un poste d’ingénieur sont des signaux à corréler.
La réponse ne peut pas être purement préventive. Ces campagnes utilisent des environnements de développement construits sur mesure, un ingénieur à la fois, avec des builds Terraform piégés différents pour chaque victime. Une règle statique ne suffira pas ; il faut traiter chaque poste de développement comme un actif à privilèges élevés, segmenté et surveillé comme tel.
Verdict
Si vous employez des développeurs — et plus encore si vous êtes un prestataire de services IT — partez du principe que votre entreprise est une cible intermédiaire, pas seulement une victime finale. Vérifiez l’identité des recruteurs, interdisez le clonage de dépôts non sollicités sur les postes de travail, et auditez systématiquement les fichiers .terraform.lock.hcl pour tout domaine suspect. Si vous opérez du macOS en entreprise, ajoutez la surveillance des Launch Agents, des processus lancés par vos éditeurs de code et des connexions sortantes vers Telegram et Nostr — c’est là que ces implants se trahissent. Si vous maintenez des environnements de développement, traitez-les comme des cibles de choix et segmentez leurs accès : un poste d’ingénieur compromis ne doit jamais pouvoir atteindre la production sans une étape d’approbation distincte.