Une commande Terraform courante devient un point d’entrée pour des hackers nord-coréens ciblant les développeurs. TraderTraitor, un acteur malveillant lié à la RPDC, utilise des projets d’infrastructure piégés, présentés comme des exercices d’entretien d’embauche, avec des fournisseurs malveillants qui peuvent s’exécuter lorsqu’un candidat lanceterraform init.
SentinelOne a également découvert les portes dérobées FLATROOF et ROOFDECK pour macOS sur un Mac Apple Silicon utilisé par un ingénieur DevOps d’un prestataire de services informatiques basé en Inde, sans lien avec les cryptomonnaies. La machine touchée contenait des identifiants cloud ainsi qu’un accès au contrôle de version, et était régulièrement utilisée avec AWS, OVH et OpenStack, offrant potentiellement aux attaquants un moyen d’aller au-delà du terminal.
Selon l’enquête de SentinelOne du 18 septembre, les deux portes dérobées se trouvaient déjà sur le Mac le 18 mars 2026 et ont commencé à émettre des balises le 29 mars, après que Cursor a ouvert uncloudshield espace de travail. Le développeur n’a cloné leterraform-candidate-repo dépôt identifié que le 13 avril, si bien que les chercheurs n’ont pas pu relier l’infection initiale au leurre Terraform.
Les leurres Terraform dissimulent des fournisseurs malveillants
Les faux dépôts d’entretien de TraderTraitor ressemblent à des évaluations d’ingénierie des infrastructures. SentinelOne a découvert des fichiers.terraform.lock.hcl piégés qui redirigent Terraform vers des domaines de fournisseurs contrôlés par les attaquants et conçus pour ressembler à l’infrastructure légitime de HashiCorp.
Lorsqu’un développeur exécuteterraform init, Terraform peut télécharger et exécuter le code du fournisseur malveillant spécifié par le projet. Cette technique n’exploite pas une vulnérabilité de Terraform ; elle détourne la gestion normale des dépendances et la confiance accordée au code fourni par les recruteurs.
Un incident distinct survenu en septembre a montré comment un registre compromis pouvait distribuer des modules Terraform malveillants qui exploraient les environnements des développeurs à la recherche d’identifiants cloud, CI/CD, SSH et autres. Les outils de développement et l’automatisation peuvent également détenir des accès privilégiés au code source, aux identifiants et aux systèmes de déploiement.
FLATROOF peut exécuter des commandes shell et collecter des données de navigateur, l’historique des terminaux, des informations système ainsi qu’une copie delogin.keychain-db. ROOFDECK ajoute des fonctions de reconnaissance, d’accès à distance par shell, de manipulation de fichiers et de persistance, ainsi que des capacités pouvant faciliter les déplacements latéraux.
Le vol d’environ 1,5 milliard de dollars attribué par le FBI à Bybit en février 2025 est lié à une activité nord-coréenne suivie sous la désignation TraderTraitor.
Couper la voie d’attaque entre le développeur et le cloud
Les organisations doivent considérer les dépôts et exercices de programmation fournis par les recruteurs comme du code non fiable, en particulier sur les systèmes pouvant accéder aux infrastructures cloud, aux dépôts de code source ou aux plateformes CI/CD.
- Isolez les exercices de programmation inconnus. Exécutez les projets d’entretien dans des machines virtuelles ou des environnements isolés jetables plutôt que sur des postes de travail d’entreprise ; Microsoft recommande des environnements isolés pour les tests de programmation inconnus.
- Vérifiez les dépendances avant exécution. Examinez les fichiers de verrouillage, les sources des fournisseurs, les domaines des registres, les tâches des dépôts et les commandes d’installation inattendues avant de lancer des projets inconnus.
- Réduisez l’exposition des identifiants. Appliquez le principe du moindre privilège et des accès à durée limitée aux systèmes cloud, de contrôle de version, CI/CD et d’administration. La récente compromission de la chaîne d’approvisionnement npm Shai-Hulud montre comment des flux de travail de développement compromis peuvent exposer des identifiants sur plusieurs services.
- Surveillez les terminaux des développeurs. Déclenchez une alerte lorsque des IDE lancent des shells, que des binaires inattendus apparaissent, que de nouveaux agents de lancement sont créés, que des connexions sortantes suspectes sont établies ou que des accès inhabituels au cloud ou aux dépôts sont observés.
- Segmentez les systèmes d’ingénierie et limitez les sorties réseau. Les recommandations de la CISA sur la chaîne d’approvisionnement logicielle préconisent de cloisonner les réseaux d’ingénierie, de réduire au minimum les comptes de service et de journaliser les accès aux pipelines de compilation.
- Testez les plans de réponse aux incidents. Les exercices doivent couvrir les dépôts malveillants, les identifiants cloud volés, la persistance et les déplacements latéraux, notamment l’isolement des terminaux, la révocation des sessions, la rotation des identifiants, l’examen des journaux et la chasse aux menaces.
Le vecteur d’infection initial de la victime indienne reste inconnu, mais les postes de travail des développeurs peuvent donner accès à bien plus que le seul terminal. L’isolement, des privilèges plus stricts, la surveillance et des procédures de réponse testées peuvent limiter cette exposition.
À lire aussi : les environnements de développement restent des cibles de grande valeur après l’accès initial ; la récente attaque contre Accenture montre comment le code source et les identifiants cloud peuvent créer un risque de sécurité longtemps après la première compromission.