Pacotes npm maliciosos com payload Shai-Hulud roubam credenciais de desenvolvedores e ameaçam pipelines de CI/CD
Uma nova campanha de ataque à cadeia de suprimentos de software está abusando do repositório npm para furtar credenciais de desenvolvedores que atuam com infraestrutura em nuvem e ambientes serverless. O ataque, que utiliza o payload conhecido como Shai-Hulud, também amplia seu alcance ao ecossistema Leo/RStreams – um conjunto de bibliotecas amplamente usado para processamento de dados e streaming de eventos em ambientes nativos da AWS.
De acordo com a equipe de pesquisa em segurança da JFrog, os pacotes comprometidos acumularam cerca de 45 mil downloads em apenas um mês. Isso significa que milhares de desenvolvedores podem ter sido expostos sem qualquer suspeita, instalando o que acreditavam ser dependências legítimas para seus projetos. O pesquisador Yair Benamou destaca que não se trata de uma ameaça totalmente inédita, mas de uma evolução de uma campanha já conhecida, que reaproveita a mesma infraestrutura de roubo de credenciais, atualizando apenas o conjunto de alvos e alguns indicadores técnicos.
Como funciona o truque de entrega do payload
Um dos pontos mais perigosos dessa campanha é a forma como os pacotes maliciosos driblam controles de segurança básicos. Em vez de injetar o código malicioso diretamente nos scripts tradicionais de instalação do npm – como o `preinstall` ou `postinstall` -, o atacante esconde a execução em um arquivo chamado `binding.gyp`.
O comportamento padrão do npm é importante aqui: quando encontra um pacote contendo `binding.gyp` e não há scripts de instalação explícitos, o gerenciador dispara automaticamente o `node-gyp`. Esse utilitário, usado normalmente para compilar add-ons nativos para Node.js, é forçado pelo invasor a processar comandos shell embutidos no próprio `binding.gyp`. Assim, o payload malicioso é executado sem levantar suspeitas óbvias em scanners simplificados que apenas analisam scripts de instalação declarados no `package.json`.
O que o Shai-Hulud coleta das máquinas comprometidas
Uma vez acionado, o Shai-Hulud inicia uma varredura agressiva em busca de qualquer dado sensível que possa ser explorado posteriormente. Entre os tipos de informações coletadas estão:
– Credenciais armazenadas em arquivos de configuração locais
– Variáveis de ambiente que contenham chaves, tokens ou segredos
– Histórico do shell (bash, zsh e similares) que possa revelar comandos com credenciais em linha
– Tokens do GitHub CLI presentes na máquina
– Chaves de acesso a provedores de nuvem
– Segredos utilizados em pipelines de CI/CD e sistemas de build
Todos esses dados são reunidos, empacotados em arquivos criptografados e preparados para exfiltração. Em vez de recorrer a canais tradicionais, o atacante usa uma técnica conhecida como “GitHub dead drop”: são criados repositórios em contas GitHub controladas por tokens roubados, e os dados furtados são enviados para lá, misturados a conteúdo aparentemente legítimo. Na prática, o repositório GitHub passa a funcionar como um canal discreto de comando e controle e como depósito de credenciais roubadas.
Persistência além da instalação inicial
O ataque não se limita ao momento da instalação do pacote. O payload estabelece mecanismos de persistência, garantindo que o código malicioso continue rodando mesmo após o término da instalação e eventuais reinicializações do sistema.
Em sistemas Linux, o Shai-Hulud registra-se como um serviço `systemd` no contexto do usuário, por meio de um arquivo de serviço localizado em:
– `~/.config/systemd/user/gh-token-monitor.service`
No macOS, a persistência é concretizada como um `LaunchAgent`, com o payload sendo carregado automaticamente no login do usuário, usando o arquivo:
– `~/Library/LaunchAgents/com.user.gh-token-monitor.plist`
Além disso, o malware altera arquivos de configuração de ferramentas de desenvolvimento assistido por IA, como Cursor, Copilot e Gemini, de forma a manter-se presente ou explorar tokens e segredos gerenciados por esses ambientes. Esse detalhe é particularmente preocupante, pois mostra que os atacantes já identificam o valor das integrações entre IDEs, IA e plataformas de código hospedado.
Movimento lateral e ataque a pipelines de CI/CD
Quando chaves SSH são encontradas na máquina comprometida, o Shai-Hulud tenta utilizá-las para movimento lateral, conectando-se a outros servidores e estações aos quais o desenvolvedor tenha acesso. Isso amplia significativamente a superfície de ataque, possibilitando que o invasor salte de um laptop de desenvolvedor para servidores internos, ambientes de staging ou até mesmo instâncias de produção, dependendo dos privilégios dessas chaves.
A campanha também mira diretamente em pipelines automatizados. O payload injeta-se em workflows do GitHub Actions, adicionando passos ou modificando arquivos YAML para capturar segredos de pipeline, como tokens de publicação de pacotes, credenciais de deploy em nuvem, segredos de build e chaves de acesso a registries privados. Esse tipo de comprometimento é extremamente perigoso, pois transforma o pipeline de CI/CD em um vetor de disseminação de código malicioso para todo o ciclo de desenvolvimento e entrega.
Recomendação da JFrog: isolamento antes de rotacionar credenciais
A JFrog enfatiza que a primeira reação a uma possível infecção não deve ser simplesmente trocar senhas e chaves. A orientação é clara: máquinas de desenvolvimento suspeitas, bem como runners de CI/CD, devem ser isolados imediatamente da rede antes de qualquer ação de rotação de credenciais.
Se o ambiente comprometido continuar ativo durante a troca de chaves e tokens, o atacante pode capturar as novas credenciais assim que forem utilizadas, anulando completamente o esforço de resposta. Por isso, o passo inicial adequado é:
1. Isolar máquinas e runners potencialmente afetados
2. Identificar e remover todos os artefatos de persistência (serviço `gh-token-monitor`, LaunchAgents, scripts estranhos, modificações em IDEs e ferramentas de IA)
3. Verificar e limpar workflows de CI/CD adulterados ou suspeitos
4. Somente então, realizar a rotação de todas as credenciais impactadas
Entre os segredos que devem ser rotacionados após a limpeza, a JFrog cita: tokens e senhas do GitHub, credenciais de npm, chaves de acesso à nuvem, chaves SSH, tokens do Docker e credenciais de registries de pacotes privados.
Auditoria de contas e repositórios
Outro ponto crítico é a revisão detalhada das contas GitHub e npm ligadas ao desenvolvedor ou à organização. É recomendado verificar:
– Repositórios desconhecidos ou inesperados criados recentemente
– Releases de pacotes que não foram autorizadas pela equipe
– Mudanças suspeitas em workflows do GitHub Actions
– Branches ou commits que possam ter introduzido payloads maliciosos
Como a técnica de “GitHub dead drop” depende da criação de repositórios a partir de tokens roubados, encontrar repositórios estranhos sob a sua conta ou na conta da organização é um forte indicativo de comprometimento.
Indicadores de comprometimento conhecidos
A campanha afeta, entre outros, os seguintes pacotes e versões do ecossistema Leo/RStreams:
– `leo-auth` versão 4.0.6 (maliciosa)
– `leo-aws` versão 2.0.4 (maliciosa)
– `leo-streams` versão 2.0.1 (maliciosa)
– Além de pelo menos outros 15 pacotes relacionados à família Leo/RStreams
No tráfego de rede, foram observados padrões envolvendo o uso de APIs de grandes plataformas – como endpoints da Anthropic e do próprio GitHub – empregados para comunicação e exfiltração de dados. Isso dificulta o bloqueio puro e simples por domínio, já que se trata de serviços amplamente usados em ambientes corporativos legítimos.
Por que esse ataque é especialmente perigoso para a cadeia de suprimentos
Ataques a gerenciadores de pacotes como npm, PyPI e outros têm se tornado uma das formas mais eficientes de atingir diretamente a cadeia de suprimentos de software. Em vez de tentar invadir uma empresa específica, o atacante contamina bibliotecas populares usadas por milhares de organizações.
Quando um pacote malicioso é publicado com um nome parecido com o original, ou quando compromete um projeto já estabelecido, o invasor ganha acesso a ambientes de desenvolvimento e build de inúmeras empresas ao mesmo tempo. No caso do Shai-Hulud, o foco em bibliotecas ligadas ao ecossistema AWS e a workloads serverless torna o potencial de dano ainda maior, pois as credenciais roubadas frequentemente têm privilégios elevados em ambientes de nuvem.
Boas práticas para mitigar riscos em ambientes npm
Para reduzir a probabilidade de ser vítima desse tipo de ataque, equipes de desenvolvimento e segurança podem adotar algumas práticas estruturais:
– Restringir o uso de dependências apenas a fontes conhecidas e mantidas por equipes confiáveis
– Habilitar políticas de aprovação para inclusão de novas bibliotecas em projetos críticos
– Utilizar ferramentas de análise de dependências e scanners de segurança mais avançados, capazes de inspecionar arquivos como `binding.gyp` e não apenas scripts declarados no `package.json`
– Implementar bloqueios de versões (lockfiles) e repositórios internos de pacotes (proxies ou mirrors) para reduzir a exposição a versões maliciosas recém-publicadas
– Minimizar o uso de tokens e chaves com privilégios amplos em máquinas de desenvolvimento, adotando o princípio de mínimo privilégio e rotação periódica de segredos
Protegendo pipelines de CI/CD contra exfiltração
Nos pipelines de CI/CD, é essencial tratar os workflows como código sensível. Algumas medidas práticas incluem:
– Revisar regularmente arquivos de workflow, especialmente quando novos contribuidores são adicionados ao projeto
– Evitar que segredos críticos sejam expostos em variáveis de ambiente globais; preferir mecanismos de segredos específicos para cada job ou etapa
– Isolar runners de CI em ambientes altamente controlados, com acesso mínimo ao restante da infraestrutura
– Implementar monitoramento contínuo de atividades suspeitas em pipelines, como execuções inesperadas, alterações de workflows fora do fluxo de revisão padrão ou acesso incomum a segredos
O papel da detecção e resposta rápida
Mesmo com boas práticas, nenhum ambiente é imune a campanhas sofisticadas de supply chain. Por isso, a capacidade de detecção precoce e resposta coordenada é determinante. Log centralizado, monitoramento de integridade de arquivos, alertas de criação de novos repositórios e auditoria de tokens são ferramentas importantes para encurtar o tempo entre a infecção e a remediação.
No contexto do Shai-Hulud, perceber rapidamente a presença de serviços como `gh-token-monitor`, alterações em ferramentas de IA de desenvolvimento ou mudanças atípicas em workflows do GitHub Actions pode significar a diferença entre um incidente contido e uma violação massiva de credenciais em toda a organização.
Conclusão: fortalecer a segurança de desenvolvimento é urgente
A campanha com pacotes npm maliciosos e payload Shai-Hulud mostra, mais uma vez, como desenvolvedores se tornaram alvos centrais na “pandemia” de fraudes digitais e ataques à cadeia de suprimentos. Ao combinar engenharia de software, abuso de comportamentos padrão do npm e exploração de tokens de serviços amplamente usados, os atacantes conseguem atingir um volume enorme de vítimas com pouco esforço incremental.
Fortalecer a segurança do ecossistema de desenvolvimento – do laptop do programador ao pipeline de produção – deixou de ser uma opção e passou a ser requisito básico de sobrevivência digital. Revisar dependências, monitorar pacotes, proteger credenciais e tratar workflows como ativos críticos são passos indispensáveis para reduzir o impacto de ameaças como o Shai-Hulud e de futuras campanhas que, inevitavelmente, surgirão.