Jade Sleet utilise FLATROOF et ROOFDECK pour attaquer les développeurs macOS via Terraform

Une campagne d'intrusion attribuée au groupe nord-coréen connu sous le nom de Jade Sleet a de nouveau révélé comment les acteurs étatiques priorisent les développeurs et les environnements de développement pour accéder à des réseaux de grande valeur. Sentinelle Un chercheur a publié que l'adversaire a utilisé des portes arrière pour macOS - identifié comme FLATROOF et ROUTIER- dans une intrusion contre une organisation indienne de services informatiques et dans des incidents antérieurs liés à l'écosystème Web3, y compris l'attaque contre l'infrastructure du pont LayerZero qui a touché KelpDAO entre mars et avril 2026.

Faits confirmés : SentinelOn a déterminé que les opérations incluaient des dépôts GitHub créés sous forme d'entretiens de travail, des fichiers de blocs Terraform (".terraform.lock.hcl") manipulés vers des domaines cibles contrôlés par les attaquants, et l'implémentation de deux portes arrière écrites dans Rust pour ARM macos. FLATROOF utilise Telegram comme canal de commande et de contrôle (C2) et peut exécuter des commandes à distance, transmettre et recevoir des fichiers et extraire des données sensibles du système et des navigateurs. ROOFECK, pour sa part, utilise le protocole Nost décentralisé pour C2, effectue la reconnaissance du système, la gestion des fichiers, le shell distant, le mouvement latéral et persiste par l'intermédiaire des agents de lancement; en outre, ses commandes sont signées et vérifiées par des clés cryptographiques embarquées, selon SentinelOne.

La société de sécurité a également documenté que les artefacts malveillants étaient présents dans au moins un MacBook avec Apple Silicon appartenant à l'ingénieur DevOps d'une entreprise indienne à partir du 18 mars 2026, bien qu'ils soient restés inactifs jusqu'au 29 mars, lorsque les communications de balises et d'autres activités d'hôte ont commencé. Les chercheurs ont noté que l'exécution initiale a eu lieu « secondes après » un dossier de travail lié à un projet appelé champ nuage a été ouvert. Une variante mise à jour de ROOFDECK a été déployée sur cette équipe le 20 avril 2026; ce binaire a enlevé des symboles et débogage des données pour rendre la détection difficile.

Contexte et contexte vérifiable: Jade Sleet (également mentionné dans des rapports tels que PUKCHONG, Slow Poissons, TraderTraitor ou UNC4899) a une histoire documentée de ciblage des projets et des entreprises liées à cryptomonedas et Web3. En 2025, il a été lié à un vol majeur - environ 1,5 milliard de dollars - contre Bybit après une chaîne d'approvisionnement engagée dans l'environnement de développeur Safe {Wallet}. GitHub et les analystes de sécurité ont souligné depuis au moins 2023 que ces types d'acteurs tendent à supplanter des offres d'emploi ou des projets techniques pour attirer les développeurs.

Là où l'attaque s'adapte techniquement : le vecteur initial confirmé dans cette campagne est social et orienté référentiel. Les attaquants créent des dépôts avec des problèmes techniques liés à la cible et placent un fichier malveillant .terraform.lock.hcl qui se réfère à un faux fournisseur ou module (par exemple des noms de domaine qui imitent l'enregistrement officiel de HashiCorp). Lorsque le développeur exécute "terraform init" dans un environnement de travail compromis, Terraform télécharge et installe des modules à partir des emplacements contrôlés par l'attaquant, permettant l'exécution de code distant et le déploiement ultérieur de backdoors. Ce modèle convertit la machine du développeur en pivot pour accéder au code, aux identifiants de cloud et aux pipelines.

Conséquences réelles et risques immédiats: un poste de travail de développement compromis peut exposer des secrets (API, clés cloud, jetons CI / CD), modifier l'infrastructure comme code, injecter des portes dans les pipelines et faciliter les mouvements latéraux aux dépôts et environnements productifs. Dans le cas documenté, en plus du risque de navigateur et d'exfiltration de clé (login.keychain-db), la présence d'outils avec des capacités de persistance et d'exécution à distance augmente la fenêtre d'accès de l'agresseur.

La différenciation des confirmés de l'incertitude: il est démontré que FLATROOF et ROOFDECK ont été utilisés et que les leurres inclus .terraform.lock.hcl malveillant. Il est crédible - mais pas entièrement confirmé publiquement dans tous les détails - que la livraison initiale était exclusivement via Terraform chez chaque victime; SentinelOne indique que le mécanisme de livraison exact dans le cas du Mac commis n'est pas encore entièrement déterminé. Il n'existe pas non plus de preuve publique complète de la portée finale de toute infiltration dans l'organisation indienne susmentionnée.

Ce que les entreprises et les développeurs devraient faire aujourd'hui: les mesures doivent être pratiques et hiérarchisées par risque, car la protection des paramètres de développement est désormais essentielle.

- Évitez d'exécuter des commandes d'initialisation dans des dépôts non vérifiés: avant "terraform init", inspect .terraform.lock.hcl et code source. Il confirme que les fournisseurs et les modules proviennent de documents officiels. La documentation officielle de Terraform explique comment fonctionne "terraform init" et les origines des modules: https: / / developer.hashicorp.com / terraform / cli / commands / init.

- Limiter l'utilisation de comptes avec privilèges dans les stations de développement : utiliser des comptes avec moins de privilèges pour le travail quotidien et réserver des titres à impact élevé aux environnements contrôlés. Mettre en œuvre des politiques d'accès fondées sur le rôle et de séparation de l'environnement.

- Renforcer la sécurité des paramètres macOS avec la détection du comportement et l'EDR qui comprennent les binaires rouilleux et les techniques communes de persistance dans macOS (agents de launch, suppression des symboles, etc.). Maintenez la télémétrie réseau pour détecter les balises inhabituelles vers Telegram, Nost ou d'autres canaux décentralisés.

- Protéger les secrets et les faire pivoter après toute suspicion de fiançailles : révoquer et régénérer les clés cloud, les jetons CI / CD et les identifiants liés à la station touchée. Tailler et prévoir la machine engagée avant de la réutiliser.

- Contrôle des dépôts et des flux de travail : permettre la signature des commits et des artefacts, la vérification de l'intégrité dans les pipelines et la limitation de l'exécution automatique des scripts à partir des PR ou des fourches tiers. Les plateformes d'hébergement de code offrent des configurations pour examiner les contributions de sources externes.

- Surveiller les indicateurs observés : vérifier les journaux de connexion à l'infrastructure associée aux nœuds Telegram et Nost, l'activité de terraform init dans les environnements de développement, les changements dans les agents de lancement et la lecture des clés du système. De plus, le trafic sortant limite la capacité de C2 à communiquer sans autorisation.

Pour une lecture et un contexte supplémentaires sur ce modèle d'attaque et la priorité croissante de protéger les paramètres des développeurs, vous pouvez consulter les ressources et l'analyse des fournisseurs de sécurité et des plateformes techniques, y compris les blogs de réponse incidente et la documentation officielle des outils d'infrastructure: https: / / www.sentinelone.com / blog / et la page d'accueil du blog de GitHub où des avertissements sur les menaces pour les développeurs sont publiés: https: / / github.blog /.

En bref, cet incident est un autre exemple clair que compromettre la chaîne d'approvisionnement ou l'environnement d'un seul développeur peut être une porte d'entrée à beaucoup plus de dommages. Les défenses déjà connues - moins de privilèges, vérification des origines, rotation des secrets et détection axée sur les développeurs - restent les contre-mesures les plus efficaces si elles sont appliquées avec discipline et rapidité.