Shai-Hulud expõe a fraqueza da cadeia de fornecimento de npm e PyPI ao roubar credenciais com assinaturas aparentes

A campanha conhecida como Shai-Hulud voltou a bater o ecossistema de pacotes: centenas de artefatos em npm e PyPI foram publicados com código malicioso projetado para roubar credenciais e espalhar-se entre projetos de desenvolvedores. O mais preocupante não é apenas o volume, mas a técnica: os atacantes aproveitaram Tokens OpenID Connect (OIDC) legítimos para assinar e publicar versões maliciosas com attestações de procedência válidas (SLSA Build Level 3), o que faz com que as peças comprometidas pareçam “criptograficamente autênticas”. Para entender a magnitude, basta repassar pesquisas como as de Endor Labs e análise Snyk, que documentam centenas de versões e artefatos comprometidos e explicam como os atacantes acorreram falhas em fluxos de CI/CD para subir pacotes maliciosos.

O ataque, atribuído ao grupo TeamPCP, começou afetando ecossistemas como TanStack e Mistral AI e se estendeu rapidamente a projetos populares como Guardrails AI, UiPath e OpenSearch, inclusive atingindo pacotes oficiais como alguns de SAP e a CLI de Bitwarden. Segundo o post-mortem de TanStack, os operadores encadearam três vetores: um fluxo de trabalho inseguro de pull_request-target, envenenamento de cache do GitHub Actions e o roubo de tokens OIDC desde a memória dos runners. Além disso, abusaram de um truque com commits órfãos em forks para forçar o npm a baixar e executar código controlado pelo atacante através de uma dependência opcional.

Estas técnicas têm consequências muito claras: quando a pipeline de CI publica pacotes maliciosos com assinaturas e attestações legítimas, a confiança automática na proveniência deixa de ser suficiente. Os desenvolvedores que instalaram versões afetadas devem assumir que seus segredos podem ter sido exfiltrados. A amostra de malware detectada extrai tokens e credenciais (GitHub OIDC e PATs, tokens npm, credenciais AWS, segredos de Vault, tokens de contas de serviço Kubernetes, SSH keys, arquivos .env e configurações de IDE) lendo a memória de processos e arquivos conhecidos, e usa a rede P2P de Session para camuflar o tráfego de exfiltração, o que complica bloqueios e derribos.

Além de roubar segredos, o malware persiste dentro do ambiente de desenvolvimento: escreve hooks em ferramentas como Claude Code e tarefas auto-ejecutáveis em VS Code, de modo que desinstalar o pacote malicioso não apaga a infecção. A operação também é auto-propaga: com credenciais roubadas modificam tarballs, injetam payloads e republicam versões infectadas nos pacotes que mantém o usuário comprometido.

Em termos práticos para equipamentos e responsáveis pela segurança, a recomendação inicial é tajante: Se você baixar uma versão afetada, trátala como uma fuga de credenciais. Você deve rodar imediatamente todos os tokens e segredos relevantes - incluindo tokens CI/CD, tokens npm, chaves de nuvem, tokens de Vault e contas de serviço Kubernetes - e rever os logs e configurações de CI para detectar publicações não autorizadas. É imprescindível auditar as máquinas de desenvolvimento e CI em busca de arquivos persistentes ou hooks maliciosos (por exemplo, arquivos como roteador_runtime.js ou setup.mjs que tenham sobrevivido a instalações), e eliminar qualquer tarefa ou configuração de IDE que não reconheças.

No plano organizacional, convém rever e endurecer os fluxos de CI/CD: evitar workflows que permitam que um pull request não confiável execute processos com permissões de publicação, reduzir o alcance e a duração dos tokens OIDC e usar credenciais efímeras e com o mínimo privilégio. Também é recomendável forçar instalações com lockfile-only para prevenir atualizações automáticas silenciosas, e complementar a verificação de provenance (SLSA) com análise de comportamento em tempo de instalação e assinaturas adicionais que verifiquem identidade do builder e rota do workflow, não só a assinatura do artefato.

Para mitigar campanhas semelhantes no futuro, convém implementar controlos técnicos e operacionais: restringir o acesso dos runners, esvaziar ou assegurar a memória crítica após execuções sensíveis, desativar caches que possam ser envenenados para ações de publicação, usar runners efêmeros e automatizar a rotação de credenciais após indícios de exposição. A nível de rede, bloquear a nível DNS/proxy a infra-estrutura de comando e controlo conhecida associada a esta campanha (por exemplo domínios documentados pelas análises) pode conter a exfiltração e as comunicações dos atacantes.

A comunidade de segurança publicou listas e guias para identificar versões afetadas e limpar ambientes: além das notas de pesquisa citadas, revisa os avisos do próprio TanStack e de provedores de segurança que rastrearam os artefatos comprometidos. Consulta o relatório do TanStack para detalhes do fluxo explorado e das versões publicadas, e segue as recomendações operacionais de resposta e rotatividade de credenciais. Evitar a complacência face a attestações válidas e combinar controlos de identidade, análise dinâmica e boas práticas na CI será fundamental para reduzir a janela de exposição a este tipo de campanhas de cadeia de abastecimento.