Los hackers norcoreanos convierten las pruebas de Terraform para puestos de trabajo en una vía hacia las redes de desarrolladores

Jade Sleet vulneró a un pequeño proveedor tecnológico indio

SentinelOne ha atribuido el compromiso de un proveedor de servicios de TI con sede en India a Jade Sleet, un grupo norcoreano conocido por atacar empresas de criptomonedas y a sus proveedores. La intrusión se centró en un MacBook con Apple Silicon asignado a un ingeniero de DevOps.

La víctima era considerablemente más pequeña que las organizaciones asociadas anteriormente con este actor. Esta diferencia es importante porque demuestra que Jade Sleet no limita sus operaciones a las principales plataformas de blockchain. Los proveedores pequeños pueden ofrecer acceso indirecto a clientes, infraestructuras de desarrollo y relaciones técnicas privilegiadas.

Jade Sleet también aparece identificado como PUKCHONG, Slow Pisces, TraderTraitor y UNC4899. Históricamente, sus operaciones se han centrado en el robo de criptomonedas, pero los desarrolladores y los proveedores externos son objetivos recurrentes porque sus sistemas pueden contener credenciales o permitir el acceso a entornos de mayor valor.

Los atacantes desplegaron dos backdoors para macOS basados en Rust: FLATROOF y ROOFDECK. FLATROOF también se conoce como Gaslight. Ambos implantes ya habían aparecido durante el compromiso del puente LayerZero de KelpDAO entre marzo y abril de 2026, y SentinelOne identificó a la víctima india mientras buscaba ese mismo malware.

Este incidente no tiene asociado ningún identificador CVE ni una puntuación formal de gravedad. Se trata de una campaña de intrusión basada en ingeniería social y contenido malicioso para desarrolladores, no de una vulnerabilidad divulgada en Terraform, Cursor o macOS.

Proyectos de contratación falsos ocultan la trampa inicial

La campaña se dirige a desarrolladores y solicitantes de empleo mediante ejercicios técnicos de selección aparentemente legítimos. Los repositorios de GitHub están diseñados para parecer pruebas de programación o proyectos de ingeniería de infraestructuras relacionados con la empresa suplantada.

Entre los nombres de repositorio observados se incluyen:

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

Los temas se eligen para adaptarse al perfil profesional del objetivo. Por ello, un candidato de DevOps o de infraestructuras puede encontrarse con configuraciones de Terraform, automatización de servicios en la nube o tareas de despliegue que parecen normales en una evaluación técnica.

El elemento malicioso es un archivo de bloqueo de dependencias de Terraform llamado .terraform.lock.hcl. Este archivo apunta a infraestructuras controladas por los atacantes, entre ellas registry.hashicorp-aws[.]com. Cuando el objetivo ejecuta terraform init, Terraform puede recuperar módulos controlados por los atacantes.

Esta técnica explota la confianza depositada en la prueba, no un fallo confirmado de Terraform. El desarrollador abre voluntariamente el proyecto y realiza un paso de inicialización estándar, mientras la configuración de dependencias del repositorio redirige parte de ese proceso hacia una infraestructura maliciosa.

SentinelOne descubrió que los paquetes estaban personalizados para víctimas concretas y se utilizaban en entornos de desarrollo preparados para un único ingeniero cada vez. Este nivel de adaptación reduce la eficacia de las detecciones generales basadas únicamente en hashes de archivos comunes o en contenidos de repositorio idénticos.

Los investigadores no han determinado con precisión cómo llegó el malware al MacBook del ingeniero de DevOps. El mecanismo malicioso de Terraform forma parte de la campaña más amplia, pero las pruebas disponibles no establecen la secuencia exacta de entrega en el caso de esta víctima.

Implantes inactivos activados desde el espacio de trabajo de un desarrollador

FLATROOF y ROOFDECK ya estaban presentes en el sistema del ingeniero el 18 de marzo de 2026. Permanecieron inactivos hasta el 29 de marzo, cuando comenzaron a enviar beacons e interactuar con el equipo.

Los primeros lanzamientos registrados procedieron de Cursor, pocos segundos después de que el desarrollador abriera un espacio de trabajo llamado cloudshield en:

~/DevOps-Automation/cloudshield

Esta coincidencia temporal vincula la ejecución con el flujo de trabajo habitual del desarrollador. Sin embargo, no demuestra qué componente del espacio de trabajo, dependencia o acción automatizada inició los implantes.

El 20 de abril de 2026 se instaló una versión más reciente de ROOFDECK, un día después de que LayerZero reconociera públicamente el incidente de KelpDAO. El implante actualizado eliminó del MacBook los binarios existentes de ROOFDECK y FLATROOF.

Además, llegó sin símbolos ni información de depuración. Eliminar esos elementos proporciona a los defensores menos contexto forense y dificulta la ingeniería inversa, lo que sugiere que los operadores estaban perfeccionando activamente sus herramientas después de que la operación anterior quedara expuesta públicamente.

La secuencia también respalda la evaluación de que ROOFDECK es un implante de seguimiento. En lugar de proporcionar necesariamente el acceso inicial, parece desplegarse después de que el atacante ha establecido una posición en el sistema y busca un control más persistente.

FLATROOF roba datos mientras ROOFDECK amplía el control

FLATROOF es un backdoor para sistemas macOS basados en ARM escrito en Rust. Se comunica mediante Telegram y permite ejecutar comandos de forma remota, así como cargar y descargar archivos.

Un componente en Python permite recopilar más información del equipo. El malware puede obtener datos de Chrome, Brave, Firefox y Safari; robar los historiales de comandos de Terminal; enumerar las aplicaciones instaladas; recopilar información de hardware y software; y capturar una instantánea de los procesos en ejecución.

También puede copiar login.keychain-db. En una estación de trabajo de un desarrollador, estas capacidades podrían exponer material de autenticación, sesiones del navegador, acceso a la nube, detalles de servicios internos y comandos utilizados anteriormente para tareas de administración.

ROOFDECK también está escrito en Rust y ataca Mac con arquitectura ARM, pero utiliza el protocolo Nostr para establecer un canal descentralizado de comando y control. Proporciona funciones de reconocimiento, acceso remoto al shell, manipulación de archivos, movimiento lateral y persistencia mediante macOS Launch Agents.

Los comandos enviados a ROOFDECK están firmados con la clave privada del operador. El implante contiene una clave pública que utiliza para verificar la integridad de los comandos antes de ejecutarlos, lo que limita la capacidad de terceros no autorizados para enviar instrucciones a través del mismo canal de comunicaciones.

Sus funciones están divididas en distintos controladores de comandos. ROOFDECK también implementa internamente numerosas operaciones sobre directorios y archivos, en lugar de depender por completo de las utilidades estándar del shell instaladas en el Mac. SentinelOne comparó este enfoque de diseño con la herramienta LightlessCan de Lazarus.

En conjunto, los implantes ofrecen capacidades complementarias: FLATROOF se centra en la recopilación y el robo de datos, mientras que ROOFDECK proporciona un entorno persistente para acceder al shell, mantener la persistencia y desplazarse más allá del endpoint original.

Un Mac de desarrollo puede exponer mucho más que una sola estación de trabajo

La víctima inmediata es el ingeniero cuyo MacBook con Apple Silicon fue comprometido. El riesgo general se extiende a todos los entornos que confiaban en ese dispositivo.

Los endpoints de DevOps suelen interactuar con sistemas de control de código fuente, consolas de gestión de la nube, plataformas de CI/CD, registros de paquetes y repositorios de infraestructura como código. También pueden contener tokens de despliegue, material SSH, sesiones del navegador y archivos de configuración que no están disponibles para los usuarios corporativos habituales.

El compromiso de un proveedor de TI introduce un riesgo adicional para la cadena de suministro. El acceso obtenido desde un proveedor podría utilizarse potencialmente contra clientes posteriores, aunque en este caso no se ha divulgado el compromiso de ningún cliente concreto.

La trayectoria de Jade Sleet ayuda a explicar la elección del objetivo. GitHub afirmó en julio de 2023 que el actor perseguía a usuarios de criptomonedas y blockchain, así como a proveedores que prestaban servicios a esas organizaciones. A principios de 2025, el grupo fue relacionado con el robo de aproximadamente 1,5 mil millones de dólares de la infraestructura de cold wallets de Bybit tras el compromiso del entorno de desarrollo de Safe{Wallet}.

La intrusión recientemente atribuida al proveedor de TI indio sigue la misma lógica estratégica: llegar a activos valiosos comprometiendo primero a las personas y los sistemas implicados en su creación, operación o soporte.

Qué deben revisar los equipos de desarrollo y seguridad

Las organizaciones deben comenzar revisando los archivos .terraform.lock.hcl y los módulos de Terraform en busca de dependencias inesperadas, sumas de comprobación modificadas y referencias a registros que no sean de confianza. Cualquier aparición de registry.hashicorp-aws[.]com requiere una investigación.

Los equipos de seguridad deben correlacionar las ejecuciones de terraform init con las conexiones salientes desde las estaciones de trabajo de los desarrolladores. Los repositorios recibidos a través de entrevistas o conversaciones de contratación no solicitadas deben examinarse en un entorno aislado antes de ejecutar cualquier comando de compilación, inicialización o instalación de dependencias.

En sistemas Apple Silicon, los defensores deben buscar:

• Artefactos de FLATROOF o Gaslight y ROOFDECK
• Actividad inesperada de comando y control basada en Telegram
• Tráfico de Nostr incompatible con el uso empresarial habitual
• macOS Launch Agents no reconocidos
• Procesos sospechosos iniciados por Cursor
• Accesos a perfiles del navegador, historiales de Terminal o login.keychain-db
• Recopilación de inventarios de aplicaciones e instantáneas de procesos
• Binarios de backdoors eliminados o sustituidos de forma inesperada
• Ejecutables desconocidos despojados de símbolos y datos de depuración

Si existe la posibilidad de que un endpoint de desarrollo haya sido comprometido, las organizaciones deben rotar las credenciales y los tokens disponibles desde ese sistema. La respuesta debe abarcar las cuentas en la nube, el control de código fuente, los servicios de CI/CD, los registros de paquetes y los sistemas relacionados con criptomonedas, no limitarse únicamente a la contraseña local de macOS.

Las redes de desarrollo también deben estar segmentadas de la producción, con el acceso lateral restringido a lo que requiera cada función. El uso de registros de confianza, comprobaciones de integridad independientes, compilaciones reproducibles y revisiones obligatorias de los cambios en las dependencias puede reducir la exposición a asignaciones técnicas maliciosas.

La premisa defensiva central debe cambiar: un ejercicio de programación es contenido ejecutable de terceros. Debe someterse al mismo escrutinio que cualquier otro software que no sea de confianza.