Campaña de malware en Go se distribuye mediante módulos Go y proveedores de Terraform

Investigadores de seguridad han detectado una campaña que distribuye un malware escrito en Go a través de módulos de Go y, por primera vez documentada públicamente, mediante proveedores publicados en el registro de Terraform de HashiCorp. Lo que está confirmado por análisis técnicos de distintos equipos (Aikido, JFrog, SafeDep y otros) es que paquetes legítimos fueron troceados o publicados con dependencias maliciosas que, al incorporarse en proyectos, implantan un binario en Go que comparte infraestructura de comando y control con versiones previas observadas en npm y PyPI.

La muestra se ha hallado en al menos dos módulos de Go y dos proveedores de Terraform —vectores que permiten a los atacantes llegar tanto a desarrolladores como a entornos de infraestructura—, y la muestra reutiliza mecanismos sofisticados: dos canales de C2 simultáneos (uno basado en una cadena de bloques de testnet y otro sobre la API de Slack), criptografía asimétrica para proteger el payload y controles de ejecución que sólo activan la carga útil en condiciones concretas. Puede consultarse el registro de proveedores de HashiCorp aquí: https://registry.terraform.io/.

Cómo funciona técnicamente (confirmado por el análisis): al ejecutarse, el malware recolecta información del sistema (hardware, SO, hostname, disponibilidad de nodo) y la envía a un canal controlado por el atacante en Slack usando la API (la técnica aprovecha llamadas repetidas al endpoint conversations.history): https://api.slack.com/methods/conversations.history. Después genera una clave efímera y combina esa clave con dos claves públicas de los atacantes para derivar claves compartidas que protegen la comunicación entre cliente y operador. Paralelamente, el agente consulta cada pocos segundos un contrato inteligente en la red de pruebas de Ethereum (Arbitrum Sepolia, según los reportes) buscando comandos cifrados que pueda descifrar y ejecutar como código Go o JavaScript. La consulta al testnet puede verificarse desde exploradores como el de Sepolia: https://sepolia.etherscan.io/.

Características que complican el análisis: parte del payload está cifrado con clave asimétrica y solo se descifra bajo condiciones específicas (por ejemplo, la resolución de un sistema lineal concreto o la realización de una operación criptográfica determinada), lo que sugiere diseño para operaciones dirigidas o para entorpecer a los investigadores que encuentran la parte frontal sin los elementos contextuales que activan la carga útil. Los informes indican además que los atacantes usan mecanismos para inflar contadores de descargas mediante workers de GitHub Actions, buscando apariencia de legitimidad.

Los vectores de entrada documentados incluyen técnicas de ingeniería social: ofertas de trabajo falsas, entrevistas remotas y tareas de programación que obligan a la víctima a incluir una dependencia que introduce la puerta trasera. Equipos de seguridad han observado la misma táctica aplicada a repositorios y paquetes en npm, PyPI y ahora Terraform/Go, lo que muestra un patrón de reuso de la cadena de suministro del software.

A quién afecta y por qué importa: desarrolladores que incorporan dependencias de terceros sin suficiente auditoría, equipos que usan proveedores de Terraform de terceros y organizaciones con runners de CI/CD (GitHub Actions, etc.) son los más expuestos. Un proveedor de Terraform malicioso tiene potencial para alcanzar secretos de producción (por ejemplo, estados, credenciales y proveedores cloud) de forma más directa que una librería de usuario final, por lo que la aparición de proveedores manipulados eleva el riesgo operacional.

Impactos reales plausibles (confirmados vs. estimados): confirmado: exfiltración de inventario del sistema y establecimiento de canales de C2 duales; estimado: ejecución de módulos entregados dinámicamente por los operadores (los investigadores recuperaron el implant pero no siempre el código posterior, por lo que las acciones finales que ejecutaron los atacantes en máquinas comprometidas aún son inciertas). La combinación de un dead drop en blockchain y una segunda canalización por Slack reduce el riesgo para el operador, porque las órdenes pueden cifrarse de forma que solo ciertos clientes las interpreten, limitando además la capacidad de interferencia de terceros.

Varios equipos han señalado coincidencias con campañas atribuidas a actores vinculados a la RPDC, como Graphalgo o PolinRider. Esto es una atribución sugerida por analistas externos (ReversingLabs, Aikido y otros la han mencionado) pero, como siempre en informes de ciberamenazas, la atribución técnica no es una certificación absoluta y debe tratarse con cautela hasta que se reúnan más evidencias operacionales públicas y verificables.

Qué debe hacer el lector ahora (medidas concretas e inmediatas): audite y reduzca la superficie de dependencia y de CI de forma pragmática: 1) En proyectos críticos, evite aceptar cambios de dependencias sin revisión humana: haga SCA (software composition analysis) y compare firmas y hashes; 2) Revoque y rote tokens y credenciales que puedan haberse expuesto en repositorios o actions, y limite el alcance de los runners de CI; 3) Active MFA y preferiblemente claves de seguridad en cuentas de mantenedores y repositorios; 4) Bloquee o monitorice conexiones inusuales salientes desde build runners y entornos de ejecución hacia IPs y dominios sospechosos (por ejemplo la IP citada en algunos análisis), y limite el acceso a APIs como Slack para bots no verificados; 5) Audite y restrinja proveedores de Terraform: trate los providers externos como código de infraestructura crítica y aplique revisión de terceros antes de su uso; 6) Implemente políticas SLSA/firmado de artefactos y exigencia de builds reproducibles para evitar que Actions o credenciales comprometidas inyecten artefactos maliciosos.

Además, los mantenedores de paquetes deben revisar el historial de accesos a sus cuentas, comprobar si ha habido commits no autorizados, y rotar cualquier credencial con acceso a múltiples repositorios. Los equipos de seguridad deberían desplegar detección de anomalías (firmas de comportamiento, egress inesperado, accesos a APIs de mensajería y llamadas a testnets con patrones de polling frecuentes) y preparar playbooks para apagar canales de C2 (revocar tokens, bloquear contratos o direcciones implicadas en comunicaciones maliciosas).

Información aún incierta o pendiente de confirmación: las funciones exactas de las cargas útiles posteriores al implant recuperado no han sido completamente recuperadas por los investigadores —están cifradas y solo se descifran en contexto—, y la relación definitiva entre todas las campañas mencionadas y una atribución geopolítica firme sigue siendo materia de análisis. También es incierto hasta qué escala operan los atacantes con proveedores de Terraform: los hallazgos actuales muestran casos concretos, pero no hay aún evidencia pública de un abuso masivo y sostenido a gran escala.

Este episodio refuerza una lección clave: la cadena de suministro del software ya no es sólo código de librerías; incluye proveedores de infraestructura, runners de CI y cuentas de mantenedores. La mitigación efectiva exige controles técnicos, higiene de cuentas y vigilancia continua sobre dependencias y artefactos de infraestructura.