Resumen Técnico: Más allá de la eliminación: Midiendo la persistencia de módulos maliciosos de Go en el mundo real

Planteamiento del problema

El ecosistema de Go, una columna vertebral para la infraestructura de software moderna, es objeto de ataques a la cadena de suministro cada vez más frecuentes. A diferencia de otros ecosistemas tradicionales (por ejemplo, npm, PyPI) donde los ataques están bien documentados, Go presenta desafíos únicos debido a su modelo de ejecución e infraestructura de distribución. Los atacantes están empaquetando de nuevo módulos legítimos de Go bajo cuentas controladas por ellos, incrustando código ofuscado que se activa al importar el paquete.

Existe una brecha crítica entre las eliminaciones en la capa de alojamiento (eliminar repositorios de GitHub) y la remediación del ecosceso. El modelo de distribución de Go depende de proxy.golang.org e index.golang.org para garantizar la reproducibilidad. Una vez que una versión de un módulo malicioso es publicada y almacenada en caché por el proxy, esta permanece inmutable y recuperable incluso después de que el repositorio de origen original sea eliminado o suspendido. En consecuencia, confiar únicamente en la visibilidad centrada en GitHub impide capturar la totalidad del compromiso o asegurar una verdadera remediación.

Metodología

Los autores emplearon un enfoque de medición de dos etapas y complementario para capturar la huella de la campaña tanto en la capa de alojamiento como en la capa de distribución.

Etapa 1: Descubrimiento manual (Dataset M)

• Alcance: Una búsqueda manual en repositorios de GitHub realizada entre marzo y junio de 2025.
• Técnica: Los investigadores partieron de un conjunto semilla de repositorios conocidos como maliciosos y lo expandieron mediante el "pivotaje basado en stargazers", identificando cuentas que coordinadamente otorgaron estrellas a múltiples módulos maliciosos.
• Verificación: Los candidatos fueron filtrados mediante prefiltros basados en palabras clave (por ejemplo, exec.Command, /bin/sh, .Start()) y verificados manualmente para asegurar que contenían cadenas ofuscadas que reconstruían comandos de descarga y ejecución (por ejemplo, wget o curl seguidos de ejecución).
• Resultado: Una línea base de alta confianza de 2,113 repositorios maliciosos ($|M| = 2,113$).

Etapa 2: Medición automatizada de la capa de distribución (Dataset G)

• Alcance: Un escaneo a gran escala de la infraestructura de distribución de Go utilizando index.golang.org y proxy.golang.org.
• Herramienta: Los autores desarrollaron GOAST (Go AST-based Scanner for Threat), un motor de análisis estático diseñado para detectar firmas específicas de la campaña en lugar de malware general.
  • GOAST analiza los archivos fuente de Go en Árboles de Sintaxis Abstracta (AST).
  • Identifica llamadas de generación de procesos (exec.Command combinada con Start, Run o Output).
  • Realiza una propagación de valores intraprocedimental ligera para reconstruir argumentos de cadenas ofuscadas.
  • Marca un módulo como malicioso solo si una llamada de ejecución reconstruida se empareja con una instrucción de descarga (por ejemplo, wget/curl hacia una URL HTTP(S)).
• Recolección de datos: El equipo recopiló un flujo cronológico de 12.3 millones de entradas de índice desde julio de 2024 hasta julio de 2025. Tras la deduplicación y el filtrado por comportamientos de compartir nombres (clonación de nombres de módulos legítimos), escanearon 60,232 candidatos sospechosos.
• Resultado: 2,289 versiones de módulos confirmados como maliciosos ($|G| = 2,289$).

Hallazgos clave

1. Caracterización de la campaña (RQ1)

La campaña opera mediante un pipeline automatizado y rígido con dos oleadas distintas:

• Oleada 1 (marzo de 2025): Dirigida a Linux, utilizando indexación de slices para reconstruir comandos.
• Oleada 2 (mayo de 2025): Se expandió a Windows, utilizando una mezcla de concatenación de literales e indexación de slices.
• Vector de ejecución: Ambas oleadas explotan los inicializadores de variables globales de Go, ejecutando código malicioso inmediatamente tras la importación del paquete.
• Infraestructura: La campaña depende de una huella estrecha de 20 dominios distintos. Los payloads de Linux sirven estagers ELF estáticos, mientras que los de Windows rotan binarios PE únicos en un ciclo estricto de 31 días.

2. Las limitaciones de las visiones centradas en GitHub (RQ2)

La comparación entre el conjunto manual de GitHub ($M$) y el conjunto del proxy ($G$) reveló dos puntos ciegos críticos:

• Brecha de alcance de descubrimiento (Fallo #1): El 83.0% de los módulos maliciosos encontrados en el proxy ($G \setminus M$) nunca fueron descubiertos por el flujo de trabajo manual centrado en GitHub. Estos módulos circularon en el proxy sin las señales sociales (estrellas) requeridas para el descubrimiento manual.
• Volatilidad de la capa de alojamiento (Fallo #2): Al momento del análisis, el 69.3% de los módulos en la huella del proxy ($G$) ya eran "inobservables desde GitHub" (repositorios eliminados o suspendidos).
• Doble fallo: El 64.3% del total de la huella del proxy caía en ambas categorías: fueron omitidos por el descubrimiento manual y sus repositorios de alojamiento ya habían desaparecido.

3. La brecha entre eliminación y remediación (RQ3)

El estudio cuantificó la persistencia de las amenazas tras la eliminación de la fuente:

• Evidencia A (Solapamiento): Para los 74 módulos en la intersección ($M \cap G$) que se confirmaron como inexistentes en GitHub durante el snapshot de junio, el 100% permanecía recuperable a través del proxy de Go en julio.
• Evencia B (Escala): Entre los 1,586 módulos en el conjunto del proxy ($G$) que eran inobservables desde GitHub en agosto, el 99.4% (1,577 módulos) se confirmó que eran recuperables a través de los registros del proxy en julio.
• Conclusión: Simplemente eliminar un repositorio de GitHub no remedia la amenaza; las versiones de los módulos maliciosos persisten en la capa de distribución.

Contribuciones y significancia

El artículo realiza tres contribuciones principales:

1. Medición a escala del ecosistema: Proporciona la primera medición exhaustiva de una campaña activa de cadena de suministro en Go, caracterizando su automatización, la evolución de sus dos oleadas y la estructura rígida de su ofuscación.
2. Cuantificación de las brechas de visibilidad: Demuestra que las visiones centradas en GitHub subestiman sistemáticamente la huella real de la amenaza debido a los límites de alcance del descubrimiento y la volatilidad de la capa de alojamiento.
3. Evidencia de la brecha de remediación: Prueba empíricamente que "la eliminación $\neq$ la remediación" en el ecosistema de Go, mostrando que los módulos almacenados en caché por el proxy permanecen disponibles mucho después de que sus repositorios de origen sean eliminados.

Significancia:
Los autores argumentan que la respuesta a incidentes y la remediación en el ecosistema de Go no pueden depender únicamente de las señales de la capa de alojamiento. Debido a que la infraestructura de proxy garantiza la reproducibilidad, esta inadvertidamente sostiene artefactos maliciosos. La remediación efectiva requiere la coordinación tanto de la capa de alojamiento (GitHub) como de la capa de distribución (Proxy/Índice de Go). Tras la divulgación responsable, GitHub eliminó 684 repositorios y el equipo de Go de Google remedió 1,377 versiones de módulos, validando la necesidad de este enfoque de capas cruzadas.