Descoberta e panorama
Pesquisadores e relatórios agregados identificaram uma nova iteração da campanha conhecida como "Shai Hulud" — referida nas análises como "Shai Hulud v2" — que comprometeu 834 pacotes distribuídos nos repositórios npm e Maven. A campanha diferencia-se por usar automações de CI/CD como vetor primário: fluxos de trabalho do GitHub Actions são modificados ou abusados para executar código malicioso durante builds e publicações.
Abordagem técnica e vetor de exploração
O ataque explora gatilhos do tipo pull_request_target em GitHub Actions para injetar código em bibliotecas muito utilizadas. A cadeia de infecção descrita nas fontes inclui um instalador em duas etapas iniciado por um script pré-instalação chamado setupbun.js, que instala o runtime Bun para executar um payload ofuscado chamado bunenvironment.js. O instalador suprime a saída padrão para reduzir a visibilidade nos logs de build.
Uma vez com execução no ambiente de CI, o malware coleta credenciais disponíveis nas variáveis de ambiente, com foco explícito em GITHUB_TOKEN, NPM_TOKEN e AWS_ACCESS_KEY_ID. Complementarmente, a campanha emprega um binário TruffleHog para vasculhar o sistema de arquivos local em busca de segredos embutidos em código e artefatos.
Os operadores também implementaram mecanismos de persistência e reprovisionamento: as análises citam o uso de uma frase beacon — “Sha1-Hulud The Second Coming” — que permite aos atacantes localizar repositórios que ainda contêm artefatos da campanha e reativar a infecção mesmo após limpezas pontuais.
Propagação, exfiltração e ações destrutivas
Com credenciais exfiltradas, os atacantes conseguem modificar código-fonte, incrementar versões de pacote e re-publicar pacotes infectados em registries públicos, contaminando cadeias de dependência. O exfiltratamento de dados usa um repositório GitHub criado aleatoriamente dentro da conta da vítima como canal de saída. As informações roubadas são ofuscadas com três camadas de Base64 antes da exfiltração, conforme descrito nas fontes.
Além da movimentação lateral para outros repositórios e serviços em nuvem, a campanha busca escalar privilégios em runners Linux por meio de manipulações em sudoers ou executando contêineres com docker run --privileged. Quando credenciais válidas não são encontradas para facilitar propagação, o código inclui uma rotina destrutiva que apaga arquivos localmente.
Escopo e impacto
As fontes relatam que a campanha expôs credenciais e segredos de dezenas de milhares de repositórios, um sinal de evolução preocupante nas técnicas de supply chain automation. Projetos amplamente usados — citados pelas reportagens — incluem PostHog, Zapier e AsyncAPI, o que indica risco de contaminação em cadeias de dependência que atingem múltiplos ecossistemas.
Limites das informações
As reportagens compiladas descrevem em detalhes o mecanismo técnico observado, mas não fornecem um mapa completo de todas as organizações afetadas nem identificam atores por trás da campanha. Também não há dados públicos nas fontes sobre contingência de registries específicos, taxas de sucesso de re-infectação, ou métricas precisas de impacto por setor — as fontes descrevem o alcance em termos gerais (número de pacotes comprometidos e escala de repositórios afetados).
Mitigações e recomendações práticas
- Rever o uso de gatilhos sensíveis como pull_request_target e limitar permissões de tokens usados em workflows.
- Rotacionar e restringir escopo de tokens (GITHUB_TOKEN, NPM_TOKEN, chaves cloud) e evitar armazenar segredos em variáveis acessíveis a runners de terceiros.
- Adicionar varreduras de secrets detection em pipelines e monitoramento de alterações atípicas em pacotes e versões publicadas.
- Inspecionar pré-instalação e scripts de build em dependências de alto uso, e preferir builds reproducíveis/consistentes em runners controlados.
As fontes base citadas das reportagens incluem análises de segurança que detalham o mecanismo e a persistência (Socket.dev e Cyber Security News). As informações públicas não permitem, neste momento, atribuição do ataque a grupos específicos nem um inventário completo de vítimas; qualquer investigação adicional deve partir de varreduras em repositórios e auditoria de tokens e acessos em CI.