Muck and Load: operacao com 222 repositorios no GitHub distribui malware via pacotes Go

Pesquisadores da Socket mapearam uma operacao maliciosa de supply-chain no GitHub que envolve 222 repositorios em 190 contas, todos desenhados para parecerem projetos legitimos, ativos e recentemente mantidos. Batizada de Muck and Load, a campanha distribui trojan loaders, Vidar infostealer, drozones de spyware e cryptominers Monero via XMRig, e usa modulos falsos em Go como estagio inicial de infeccao em Windows. O disparador da investigacao foi um unico modulo, o github[.]com/kaleidora/dnsub-scanning-tool, que se apresentava como utilitario de enumeracao de subdominios DNS.

O que aconteceu

A equipe de pesquisa da Socket comecou puxando o fio de um unico pacote suspeito e terminou expondo um ecossistema paralelo de repositorios falsos. Os 222 projetos identificados nao formavam paginas vazias de isca: parte deles distribuia diretamente malware, enquanto outros serviam de camada de credibilidade, criando uma teia de referencias cruzadas que fazia cada projeto parecer parte de uma comunidade viva de desenvolvimento.

O nome da operacao vem de dois elementos observados na infraestrutura: a tematica Muck usada em diversos artefatos e a cadeia de staged loading pela qual os payloads sao entregues em fases. A tatica lembra campanhas anteriores de typosquatting e dependency confusion, mas com um agravante: em vez de tentar enganar caracteres em nomes de pacotes populares, os operadores construiram identidades independentes com aparencia legitima, mais dificeis de detectar por listas de bloqueio baseadas em correspondencia por similaridade.

Segundo a Socket, o conjunto de payloads confirmado inclui trojan loaders, o infostealer Vidar, droppers com funcionalidades de spyware e cryptominers de Monero baseados em XMRig. A diversidade sugere que o operador esta menos interessado em uma monetizacao especifica e mais em maximizar o retorno por instalacao, revendendo acesso ou dados conforme a conta comprometida.

Como o ataque funciona

O modulo dnsub-scanning-tool foi o alvo original da analise. Ao ser importado, ele executa uma cadeia de comandos PowerShell com a flag -ExecutionPolicy Bypass. Essa flag por si so nao explora nada no PowerShell, mas em conjunto com execucao oculta e a decodificacao de um script externo em memoria, revela intencao clara: o modulo em Go atua como first-stage Windows loader.

A carga final e um loader PowerShell multi-camadas chamado L.ps1, que combina codificacao Base64 com decriptacao XOR para atravessar varias fases antes de entregar seu payload real. E um padrao classico de evasao de antivirus baseados em assinatura estatica: cada camada precisa ser decodificada em runtime, e nenhum dos artefatos intermediarios corresponde a uma amostra publica conhecida.

A anomalia mais reveladora, no entanto, apareceu antes mesmo da execucao. O modulo tinha mais de 1200 versoes publicadas, sendo mais de 700 explicitamente maliciosas, em uma ferramenta criada havia poucos meses. Esse volume nao corresponde a nenhuma pratica normal de release engineering. Era resultado de um workflow do proprio GitHub Actions do atacante, gerando commits com timestamps para fabricar atividade de desenvolvimento e passar por um projeto vivo aos olhos de dependency scanners.

Essa flag nao explora o PowerShell por si so, mas e comumente usada por malware para contornar restricoes de politica local de execucao de scripts. Neste caso, ela e combinada com execucao oculta e um script recem-decodificado de fonte externa, o que torna a intencao clara: o modulo Go esta atuando como um loader de primeiro estagio para Windows.

Socket

Quem esta em risco

• Desenvolvedores Go que dependem de pacotes de terceiros para tarefas de red team, reconhecimento ou administracao de infra, categoria de ferramentas em que a operacao concentrou suas iscas
• Equipes de seguranca e pentest que buscam utilitarios de subdominio, enumeracao DNS e scanning em repositorios recem-publicados
• Ambientes CI que puxam automaticamente dependencias sem lockfile pinning ou verificacao de checksum
• Redes corporativas com endpoints sem controle de execucao de scripts PowerShell ou sem AMSI habilitado
• Organizacoes que confiam em atividade de repositorio (commits, versoes, stars) como sinal de legitimidade sem inspecao mais profunda do codigo

Analise

A Muck and Load se soma a uma linhagem crescente de operacoes de supply-chain que exploram sinais sociais em ecossistemas open source. Casos como Shai-Hulud (npm), PolinRider (npm/Go/Chrome), Shuffle (PyPI) e o cluster GitDoubleTake (2025) mostraram que o vetor de entrada nao precisa mais ser um pacote muito baixado. Basta ser um pacote que pareca real: com README plausivel, README traduzido, atividade regular de commits e uma rede de contas cruzando estrelas e forks.

O uso de GitHub Actions para fabricar historico de commits e o ponto mais interessante do relatorio. Ate 2024, era comum defensores pesarem a idade e a atividade de um repositorio como proxy de confianca. Ferramentas de anti-malware para dependencias comecaram entao a incorporar heuristicas de release cadence. A Muck and Load mostra que essas heuristicas ja estao sendo derrotadas em escala industrial: 1200 versoes em poucos meses e o teto inverso, o sinal de que a atividade e sintetica, nao autentica.

Para o ecossistema Go, o timing e sensivel. Modulos em Go sao imutaveis por design apos publicados, o que teoricamente reduz o espaco para injecao de codigo malicioso em versoes existentes. Porem, o mecanismo de descoberta ainda depende fortemente de indices publicos e de metadata em GitHub. O Muck and Load ataca justamente essa camada de descoberta, e nao a camada de execucao, deixando o hardening de dependencias como responsabilidade do consumidor final.

Recomendacoes praticas

• Nunca incluir modulos Go recem-publicados em pipelines de producao sem revisao manual do codigo e do historico do maintainer
• Auditar dependencias em pipelines CI com scanners como Socket, Snyk ou Sonatype Nexus IQ, e configurar politicas de release age minimum de pelo menos 30 dias para pacotes novos
• Pin de versoes exatas (via go.sum, package-lock.json, poetry.lock, etc.) e revisao ativa antes de bumps de versao
• Habilitar AMSI e Constrained Language Mode no PowerShell em endpoints corporativos, bloqueando execucao de scripts fora de allowlist
• Monitorar chamadas a powershell.exe com flags -ExecutionPolicy Bypass e -w hidden, especialmente originadas de processos de build
• Restringir o download de binarios externos por processos filhos de compiladores (go build, npm install, pip install) via EDR ou Windows Defender ASR rules
• Trocar heuristica de reputacao de repositorio: em vez de olhar apenas idade e volume de commits, comparar cadencia de release com padroes normais do projeto e do autor
• Nao confiar em ativity graphs do GitHub como sinal isolado de legitimidade, e sim combinar com verificacao de identidade do maintainer (email verificado, chave GPG assinando releases, presenca externa)

Fonte: Security Affairs