Um ataque de cadeia de suprimentos em larga escala colocou desenvolvedores de software em alerta após hackers comprometerem mais de 170 pacotes npm e dois pacotes PyPI em uma campanha coordenada de roubo de credenciais. Os pacotes infectados são coletivamente baixados mais de 200 milhões de vezes por semana, tornando o potencial de explosão enorme.
O grupo de ameaças por trás da campanha, rastreado como TeamPCP, injetou carregadores maliciosos e payloads de JavaScript ofuscados em pacotes de desenvolvedor amplamente utilizados. Esses payloads foram construídos para executar silenciosamente dentro de máquinas de desenvolvedor e pipelines de CI/CD, colher credenciais sensíveis e usar essas credenciais para se espalhar ainda mais.
Escopo e mecanismo da campanha
Pesquisadores da JFrog descobriram o escopo completo desta campanha, nomeando-a "Shai-Hulud: Here We Go Again" após reconhecerem marcas de ataques anteriores do mesmo grupo. Sua análise revelou que esta não foi uma intrusão simples de uma única vez, mas uma operação auto-replicante projetada para continuar crescendo com cada nova infecção bem-sucedida.
O ataque começou dentro de um ambiente de lançamento do GitHub confiável. Os atacantes exploraram um padrão de workflow que permitia que código controlado por fork fosse executado em um contexto de repositório privilegiado, ganhando um ponto de apoio sem levantar bandeiras vermelhas imediatas.
A partir daí, eles envenenaram uma entrada de cache de build, que um workflow de lançamento posterior restaurou durante o que parecia ser uma atividade de build rotineira. Uma vez dentro, o malware extraiu tokens de identidade do GitHub Actions da memória do runner e os trocou por credenciais de publicação do npm.
Comportamento de verme e roubo de credenciais
O que torna esta campanha especialmente alarmante é seu comportamento de verme. Em vez de roubar segredos de uma máquina e parar, o malware continua se movendo. Após coletar tokens do npm ou credenciais de publicação confiável, o payload escaneia todos os pacotes que a conta da vítima pode publicar, reescreve esses pacotes com código malicioso e publica novas versões infectadas no registro público.
O malware também pode solicitar um token OIDC para o registro do npm e trocá-lo por um token de publicação, tudo enquanto se esconde atrás da mesma identidade de workflow confiável que os desenvolvedores reais usam. Isso significa que pacotes infectados podem parecer vir de fontes verificadas e confiáveis, mesmo ainda carregando malware dentro.
O payload do npm visa uma ampla gama de segredos, incluindo tokens do GitHub, credenciais do npm, chaves de acesso da AWS de variáveis de ambiente e serviços de metadados da nuvem, tokens de conta de serviço do Kubernetes, tokens do HashiCorp Vault, chaves SSH, credenciais do Docker e chaves de API genéricas.
Gatilho de homem morto e exfiltração
O malware usa o próprio GitHub como canal de exfiltração. Ele cria um repositório público sob um token roubado, commita pacotes de credenciais criptografados lá e marca o repositório com o nome da campanha como um rastreador. Commits contendo tokens roubados do GitHub carregam uma mensagem ameaçadora avisando defensores contra a revogação do acesso.
Essa ameaça é apoiada por um verdadeiro gatilho de homem morto. O malware instala um monitor de segundo plano que consulta o GitHub a cada 60 segundos e, se o token roubado for revogado, imediatamente dispara um comando de limpeza destrutiva na máquina afetada. Os defensores devem remover completamente toda a persistência antes de girar qualquer credencial, ou correm o risco de acionar o wiper eles mesmos.
A JFrog recomenda isolar todas as máquinas afetadas e os runners de CI/CD antes de revogar quaisquer tokens. Os arquivos de persistência e os serviços de segundo estágio devem ser removidos primeiro. Após a limpeza, as equipes devem girar tokens do GitHub, tokens do npm, credenciais da AWS, contas de serviço do Kubernetes, tokens do Vault e chaves SSH.
Recomendações para equipes de desenvolvimento
Os desenvolvedores também devem revisar repositórios para commits autorizados como "claude@users.noreply.github.com" e procurar por branches inesperados semelhantes ao Dependabot que não correspondem aos padrões de automação normais. A remoção completa da persistência é crítica antes de girar credenciais para evitar acionar o comando de limpeza destrutiva.
As equipes de segurança devem monitorar suas redes em busca de atividades suspeitas e revisar suas políticas de segurança. A implementação de medidas de mitigação adicionais, como a restrição de acesso administrativo e a implementação de autenticação multifator, pode ajudar a reduzir o risco de exploração.
A JFrog continuará a monitorar a situação e fornecerá atualizações conforme necessário. Os clientes devem permanecer vigilantes e seguir as recomendações da JFrog para proteger suas redes contra futuras explorações.
Perguntas frequentes
Qual é o principal vetor de ataque? O ataque começou dentro de um ambiente de lançamento do GitHub confiável, explorando um padrão de workflow que permitia que código controlado por fork fosse executado em um contexto de repositório privilegiado.
Como o malware se espalha? O malware continua se movendo, coletando tokens do npm ou credenciais de publicação confiável e publicando novas versões infectadas no registro público.
Quais são as recomendações imediatas para mitigação? Isolar máquinas afetadas, remover persistência, girar credenciais e monitorar solicitações de saída incomuns.