Jade Sleet usa FLATROOF y ROOFDECK para atacar desarrolladores macOS vía Terraform

Una campaña de intrusión atribuida al grupo norcoreano conocido como Jade Sleet volvió a exponer cómo actores estatales priorizan a desarrolladores y entornos de desarrollo para ganar acceso a redes de alto valor. Investigadores de SentinelOne han publicado que el adversario empleó puertas traseras para macOS —identificadas como FLATROOF y ROOFDECK— en una intrusión contra una organización india de servicios de TI y en incidentes previos ligados al ecosistema Web3, incluido el ataque a la infraestructura del puente de LayerZero que afectó a KelpDAO entre marzo y abril de 2026.

Hechos confirmados: SentinelOne determinó que las operaciones incluyeron repositorios de GitHub creados como señuelos de entrevistas de trabajo, archivos de bloqueo de Terraform (".terraform.lock.hcl") manipulados para apuntar a dominios controlados por los atacantes, y la implantación de dos backdoors escritos en Rust para macOS ARM. FLATROOF utiliza Telegram como canal de comando y control (C2) y está capacitado para ejecutar comandos remotos, transmitir y recibir archivos y extraer datos sensibles del sistema y navegadores. ROOFDECK, por su parte, usa el protocolo descentralizado Nostr para C2, realiza reconocimiento del sistema, manipulación de archivos, shell remoto, movimiento lateral y persiste mediante Launch Agents; además sus comandos están firmados y verificados por claves criptográficas embebidas, según SentinelOne.

La compañía de seguridad también documentó que los artefactos maliciosos estuvieron presentes en al menos un MacBook con Apple Silicon propiedad de un ingeniero DevOps de la firma india desde el 18 de marzo de 2026, aunque permanecieron inactivos hasta el 29 de marzo, cuando comenzaron las comunicaciones de beacon y otra actividad de host. Los investigadores notaron que la ejecución inicial ocurrió “segundos después” de que se abriera una carpeta de trabajo relacionada con un proyecto llamado cloudshield. Una variante actualizada de ROOFDECK fue desplegada en ese equipo el 20 de abril de 2026; ese binario eliminó símbolos y datos de depuración para dificultar la detección.

Contexto y antecedentes comprobables: Jade Sleet (también referenciado en informes como PUKCHONG, Slow Pisces, TraderTraitor o UNC4899) tiene un historial documentado de apuntar a proyectos y empresas vinculadas a criptomonedas y Web3. En 2025 fue vinculado a un robo importante —aproximadamente 1.500 millones de dólares— contra Bybit tras una cadena de suministro comprometida en el entorno de desarrolladores de Safe{Wallet}. GitHub y analistas de seguridad han señalado desde al menos 2023 que este tipo de actores suelen suplantar ofertas de trabajo o proyectos técnicos para atraer a desarrolladores.

Dónde encaja técnicamente el ataque: el vector inicial confirmado en esta campaña es social y repositorio-orientado. Los atacantes crean repositorios con temática técnica relacionada al objetivo y colocan un archivo .terraform.lock.hcl malicioso que referencia un proveedor o módulo falso (por ejemplo, nombres de dominio que imitan el registro oficial de HashiCorp). Cuando el desarrollador ejecuta "terraform init" en un entorno de trabajo comprometido, Terraform descarga e instala módulos desde esas ubicaciones controladas por el atacante, permitiendo la ejecución de código remoto y el despliegue posterior de backdoors. Este patrón convierte la máquina del desarrollador en pivot para acceder a código, credenciales en la nube y pipelines.

Consecuencias reales y riesgos inmediatos: una estación de trabajo de desarrollo comprometida puede exponer secretos (APIs, claves de nube, tokens de CI/CD), modificar infraestructura como código, inyectar puertas traseras en pipelines y facilitar movimientos laterales hacia repositorios y entornos productivos. En el caso documentado, además del riesgo de exfiltración de navegadores y llaveros (login.keychain-db), la presencia de herramientas con capacidades de persistencia y de ejecución remota incrementa la ventana de acceso del atacante.

Diferenciando lo confirmado de lo incierto: está demostrado que FLATROOF y ROOFDECK fueron empleados y que los señuelos incluían .terraform.lock.hcl maliciosos. Es verosímil —pero no totalmente confirmado públicamente en todos los detalles— que la entrega inicial fuese exclusivamente vía Terraform en cada víctima; SentinelOne indica que el mecanismo exacto de entrega en el caso del Mac comprometido aún no está totalmente determinado. Tampoco hay evidencia pública completa sobre el alcance final de cualquier exfiltración en la organización india mencionada.

Qué deben hacer las empresas y los desarrolladores hoy: las medidas deben ser prácticas y priorizadas por riesgo, porque la protección de endpoints de desarrollo es ahora crítica.

- Evitar ejecutar comandos de inicialización en repositorios no verificados: antes de "terraform init", inspeccione .terraform.lock.hcl y el código fuente. Confirme que los proveedores y módulos provienen de registros oficiales. La documentación oficial de Terraform explica cómo funciona "terraform init" y los orígenes de módulos: https://developer.hashicorp.com/terraform/cli/commands/init.

- Restringir el uso de cuentas con privilegios en estaciones de desarrollo: utilice cuentas con menor privilegio para trabajo diario y reserve las credenciales de alto impacto a entornos controlados. Aplique políticas de acceso basado en roles y separación de entornos.

- Reforzar la seguridad de endpoints macOS con detección de comportamiento y EDR que entienda binaries Rust y técnicas comunes de persistencia en macOS (Launch Agents, eliminación de símbolos, etc.). Mantenga telemetría de red para detectar beacons inusuales hacia Telegram, Nostr u otros canales descentralizados.

- Proteger secretos y rotarlos tras cualquier sospecha de compromiso: revoque y regenere claves de nube, tokens de CI/CD y credenciales vinculadas a la estación afectada. Aísle y forensee la máquina comprometida antes de reutilizarla.

- Control de repositorios y flujos de trabajo: habilite firmas de commits y de artefactos, verificación de integridad en pipelines, y limitación de la ejecución automática de scripts provenientes de PRs o forks de terceros. Las plataformas de hosting de código ofrecen configuraciones para revisar contribuciones provenientes de fuentes externas.

- Monitorizar indicadores observados: verifique logs en busca de conexiones a infraestructura asociada a Telegram y a nodos Nostr, actividad de terraform init en entornos de desarrollo, cambios en Launch Agents y lecturas del llavero del sistema. Adicionalmente, segmente el tráfico saliente para limitar la capacidad de C2 de comunicarse sin autorización.

Para lecturas adicionales y contexto sobre este patrón de ataque y la creciente prioridad de proteger endpoints de desarrolladores, puede consultar los recursos y análisis de proveedores de seguridad y plataformas técnicas, incluyendo los blogs de respuesta a incidentes y documentación oficial de herramientas de infraestructura: https://www.sentinelone.com/blog/ y la página principal del blog de GitHub donde se publican advertencias sobre amenazas a desarrolladores: https://github.blog/.

En resumen, este incidente es otro ejemplo claro de que comprometer la cadena de suministro o el entorno de un solo desarrollador puede ser una puerta de entrada a daños mucho mayores. Las defensas ya conocidas —menos privilegios, verificación de orígenes, rotación de secretos y detección centrada en desarrolladores— siguen siendo las contramedidas más efectivas si se aplican con disciplina y rapidez.