Un módulo Go malicioso que se hacía pasar por un escáner DNS y de subdominios fue usado como cargador inicial para distribuir RATs, info-stealers y mineros, y apareció en más de 200 repositorios de GitHub, según la investigación publicada por la empresa de seguridad Socket.
La importancia del hallazgo no es sólo la diversidad de cargas útiles: la pieza de código entraba en cadenas de suministro de software legítimas y usaba servicios públicos como Pastebin y YouTube para ocultar la ubicación del payload final.
Cómo operaba el módulo Go malicioso
El componente principal se publicó como un supuesto utilitario en Go y su archivo main.go ejecutaba una secuencia muy concreta: lanzar un comando PowerShell oculto que descargaba contenido desde muckcoding.com, decodificaba esa descarga con certutil y ejecutaba el resultado con políticas de ejecución sorteadas.
Socket describe el flujo técnico como un loader multinivel. El primer stage no apuntaba directamente a un ejecutable malicioso: resolvía la URL de la carga útil leyendo texto público en plataformas como Pastebin, Rlim (otro servicio de paste), YouTube, Instagram, Telegram, Google Docs y GitCode, buscando una marca concreta—la cadena «LastW»—y descifrando el bloque posterior con una clave incrustada para descubrir la ubicación real.
Ese enfoque de resolver dinámicamente la URL en plataformas públicas tiene dos ventajas para el atacante: evita hardcoding de dominios finales y permite actualizar la ubicación de la carga útil sin modificar el primer stage que reside en GitHub.
La URL resultante llevaba a un archivo 7-Zip protegido por contraseña alojado como asset de un release en GitHub. El loader extraía el contenido en una ruta diseñada para parecerse a una instalación legítima de Microsoft Photos y ejecutaba un binario llamado Microsoft.exe en una ventana oculta.
Las muestras analizadas incluyeron detecciones para AsyncRAT, Quasar, Remcos-style RATs, Vidar (infostealer), dropper/spyware y módulos relacionados con XMRig para minado de Monero. Socket confirmó al menos 14 archivos maliciosos distintos y observó binarios idénticos replicados en múltiples repositorios.
Distribución y abuso de GitHub
Socket atribuye la expansión masiva a una combinación de repositorios desechables y una workflow de GitHub Actions que el propio actor configuró para automatizar commits temporizados. El resultado fue que el módulo acumuló más de 1.200 versiones, de las cuales más de 700 eran maliciosas.
La mecánica técnica del incidente se apoya en una característica del ecosistema Go: cuando un commit no tiene etiqueta semántica, el sistema genera una pseudo-versión a partir de la marca temporal y el hash del commit. Al programar commits frecuentes, el actor logró inflar la historia de releases y camuflar su actividad maliciosa como si fuesen múltiples versiones legítimas.
Socket rastreó el módulo hasta 222 repositorios en 190 cuentas, contando sólo aquellos que compartían tanto la identidad del email de commit [email protected] como el workflow malicioso. Ese correo ya había sido asociado por otros investigadores a campañas previas; Sophos llevó a cabo un rastreo similar el año anterior y vinculó 141 repositorios a esa dirección.
En los repositorios confirmados Socket encontró un patrón repetido en la workflow: el script ajustaba el email de Git a [email protected], fijaba como autor visible al propietario del repositorio y forzaba un push de un log reescrito cada minuto. La técnica permite distribuir actividad atribuida a múltiples cuentas desechables, pero deja una huella única reutilizable.
Tras el reporte, el equipo de seguridad del ecosistema Go bloqueó el módulo desde el proxy de módulos de Go. GitHub, por su parte, no ofreció declaraciones públicas más allá de las acciones que pueda haber tomado internamente.
Temas de cebo y vectores de compromiso
Los repositorios usados como señuelos cubrían temas atractivos para usuarios de tecnología y jugadores: integraciones y utilidades para MetaMask y Trust Wallet, automatizaciones para Binance y PayPal, bots para Telegram y Discord, y trampas o cheats para juegos como PUBG, Valorant y Escape from Tarkov.
Un ejemplo revelador fue un repositorio que se hacía pasar por un cheat para PUBG, con instrucciones de instalación y, al mismo tiempo, alojando un Loader.exe vinculado a Vidar en su árbol de código.
En la práctica, esto significa que un desarrollador o un jugador que clonara un proyecto aparentemente útil podía ejecutar sin saber un código que, a su vez, descargaba y ejecutaba cargas útiles sofisticadas.
Qué significa para desarrolladores y equipos de seguridad
El incidente subraya varios riesgos concretos: primero, la confianza implícita en repositorios públicos y en módulos de terceros. Un módulo con buena pinta puede ser solo la puerta de entrada a una cadena de ejecución que desemboca en herramientas de control remoto o robo de credenciales.
Segundo, la técnica de resolver payloads desde servicios públicos revela la necesidad de monitorizar no solo el código en el repositorio, sino también las llamadas de red que realiza en tiempo de ejecución y los artefactos asociados a releases en plataformas como GitHub.
Tercero, los mecanismos de versionado y la automatización (GitHub Actions) pueden ser manipulados para camuflar actividad maliciosa. El uso de commits temporizados para generar pseudo-versiones es un recordatorio de que los procesos automáticos deben revisarse y limitarse en entornos de producción.
Recomendaciones prácticas para equipos incluyen auditar dependencias, revisar las firmas y procedencia de binarios en releases, restringir la ejecución de workflows en repositorios de terceros y mantener controles de integridad en las rutas de despliegue.
Lo que Socket y otros equipos de respuesta han dejado claro es que la superficie de ataque no está limitada al código fuente: también incluye los metadatos de repositorio, las acciones automatizadas y las plataformas públicas usadas como dead drops.
El bloqueo del módulo en el proxy de módulos de Go es una medida necesaria, pero no elimina el riesgo retroactivo: proyectos que ya integraron el módulo antes del bloqueo pueden seguir comprometidos si no se revisan. Además, el actor ya fue identificado con aliases y dominios asociados a la campaña—información que puede facilitar búsquedas defensivas y bloqueos proactivos.
En resumen, la campaña bautizada como Operation Muck and Load vuelve a poner en primer plano la amenaza de la cadena de suministro en software y la capacidad de actores para explotar mecanismos legítimos de colaboración y automatización para distribuir malware.
