Pacotes npm maliciosos com payload Shai‑Hulud miram credenciais de desenvolvedores em nuvem
Uma nova campanha de ataque à cadeia de suprimentos de software está explorando o ecossistema npm para roubar credenciais de desenvolvedores que trabalham com infraestrutura em nuvem e ambientes serverless. O payload, conhecido como Shai‑Hulud, foi identificado em diversos pacotes maliciosos que também atingem o ecossistema Leo/RStreams, um conjunto de bibliotecas amplamente adotado para processamento de dados e streaming de eventos nativos da AWS.
De acordo com pesquisa da equipe de segurança da JFrog, esses pacotes comprometidos chegaram a registrar cerca de 45 mil downloads em apenas um mês. Na prática, isso significa que milhares de desenvolvedores podem ter sido expostos sem qualquer suspeita, uma vez que a instalação ocorre de forma aparentemente legítima. O pesquisador Yair Benamou destaca que não se trata de uma ameaça completamente inédita, mas da evolução de uma campanha já em andamento, que reaproveita a mesma “máquina” de roubo de credenciais, apenas ajustando o alvo e atualizando seus indicadores.
Truque de entrega: usando o `binding.gyp` para burlar scanners
Um dos pontos mais preocupantes da campanha é o mecanismo de entrega do código malicioso. Em vez de inserir o payload diretamente nos scripts padrão de instalação do npm (como `preinstall`, `install` ou `postinstall`), algo que muitos scanners já conseguem inspecionar, os atacantes optaram por um caminho menos óbvio: o arquivo `binding.gyp`.
Quando o npm identifica um pacote que contém um `binding.gyp` e não possui scripts de instalação explícitos, ele aciona automaticamente o `node-gyp`. Essa ferramenta, usada para compilar extensões nativas, processa comandos de shell declarados no arquivo, e é justamente nesse ponto que o payload Shai‑Hulud é executado. Assim, o malware consegue driblar verificações mais superficiais, passando como um pacote aparentemente legítimo, principalmente em ambientes de automação e CI/CD.
O que o Shai‑Hulud rouba: foco em credenciais e segredos
Uma vez acionado, o payload inicia uma coleta agressiva de informações confidenciais presentes no ambiente do desenvolvedor ou do runner de CI. Entre os dados visados estão:
– Credenciais armazenadas em arquivos de configuração e perfis locais;
– Variáveis de ambiente que guardam chaves, tokens e segredos temporários;
– Histórico de comandos do shell, onde muitas vezes aparecem chaves e comandos sensíveis;
– Tokens do GitHub CLI, que podem abrir acesso direto a repositórios;
– Chaves de acesso a provedores de nuvem;
– Segredos utilizados em pipelines de CI/CD.
Todos esses dados são reunidos, empacotados em arquivos criptografados e, em seguida, exfiltrados de maneira furtiva.
Exfiltração via “GitHub dead drop”
Para levar as informações roubadas para fora do ambiente atacado sem chamar atenção, a campanha utiliza uma técnica apelidada de “GitHub dead drop”. Em vez de enviar os dados diretamente para um servidor de comando e controle óbvio, o payload cria ou modifica repositórios utilizando um token do GitHub previamente roubado.
Os arquivos criptografados com as credenciais são carregados nesses repositórios, muitas vezes sob nomes e estruturas que se misturam a projetos legítimos. Como a comunicação ocorre com a própria infraestrutura do GitHub, o tráfego tende a passar despercebido por boa parte das soluções de segurança tradicionais, que normalmente consideram esse domínio confiável.
Persistência: continuando ativo após a instalação
A atividade do Shai‑Hulud não se restringe ao momento em que o pacote npm é instalado. O payload cuida de se manter presente e ativo no sistema, configurando diversos mecanismos de persistência.
Nos sistemas Linux, ele se registra como um serviço systemd, através do arquivo:
– `~/.config/systemd/user/gh-token-monitor.service`
Já no macOS, utiliza um LaunchAgent para garantir execução recorrente:
– `~/Library/LaunchAgents/com.user.gh-token-monitor.plist`
Além disso, o malware modifica arquivos de configuração de ferramentas de desenvolvimento assistido por IA, como Cursor, Copilot e Gemini, adicionando hooks que permitem acompanhar e potencialmente capturar novos segredos à medida que o desenvolvedor trabalha. Essa integração maliciosa com ferramentas de produtividade torna a ameaça ainda mais insidiosa.
Movimento lateral e impacto em pipelines
Chaves SSH presentes na máquina comprometida são aproveitadas para movimento lateral, permitindo que o atacante acesse outros servidores e estações. Se o desenvolvedor possui acesso privilegiado à infraestrutura, o impacto pode se espalhar rapidamente por toda a organização.
O payload também se integra a workflows do GitHub Actions, inserindo código malicioso ou capturando variáveis de ambiente sensíveis utilizadas em pipelines. Dessa forma, segredos de automação – como tokens de implantação, chaves de registro de containers ou credenciais de serviços de nuvem – podem ser continuamente drenados, mesmo depois da instalação inicial do pacote comprometido.
Recomendações da JFrog: como reagir a uma possível infecção
Diante da suspeita de comprometimento por Shai‑Hulud, a orientação da JFrog é clara: o primeiro passo é isolar. Máquinas de desenvolvimento afetadas e runners de CI que possam ter executado os pacotes maliciosos devem ser desconectados da rede ou isolados em segmentos controlados, para evitar que a ameaça continue se propagando ou exfiltrando dados.
Antes de rotacionar qualquer credencial, é fundamental remover todos os artefatos de persistência:
– Eliminar o serviço `gh-token-monitor.service` em sistemas Linux;
– Remover o LaunchAgent `com.user.gh-token-monitor.plist` em macOS;
– Revogar ou limpar hooks e integrações suspeitas em ferramentas de IA;
– Revisar e limpar workflows do GitHub Actions para remover scripts injetados ou suspeitos.
Somente após essa higienização é que se deve partir para a troca de segredos.
Rotação de credenciais e auditoria de contas
Concluída a limpeza dos artefatos, a recomendação é rotacionar todas as credenciais potencialmente impactadas, incluindo:
– Tokens e senhas do GitHub;
– Autenticação do npm;
– Chaves e segredos de nuvem;
– Chaves SSH;
– Credenciais de Docker e de registros de containers;
– Segredos associados a registros de pacotes internos.
Em paralelo, as contas de GitHub e npm devem ser auditadas cuidadosamente. É importante verificar:
– Criação de repositórios desconhecidos;
– Publicação de versões de pacotes que o time não reconhece;
– Modificações suspeitas em workflows e pipelines;
– Atividades de login em horários ou locais inusitados.
Qualquer anomalia deve ser tratada como potencial evidência de comprometimento contínuo.
Indicadores de comprometimento (IoCs) conhecidos
Entre os principais IoCs já mapeados estão versões maliciosas de pacotes amplamente utilizados no ecossistema Leo/RStreams, como:
– `leo-auth` v4.0.6
– `leo-aws` v2.0.4
– `leo-streams` v2.0.1
Além desses, há outros 15 pacotes associados à mesma família. Organizações que utilizam essas bibliotecas devem revisar suas dependências com cuidado, verificando histórico de versões e confirmando se apenas releases legítimos foram integrados.
Do ponto de vista de rede, URLs relacionadas às APIs de provedores de IA e do próprio GitHub são usadas como canal de comunicação e exfiltração. Por se tratar de destinos comuns em ambientes de desenvolvimento, o desafio está em diferenciar o tráfego benigno do tráfego malicioso associado ao Shai‑Hulud.
Boas práticas para proteger projetos npm contra ataques à cadeia de suprimentos
Para reduzir o risco de exposição a campanhas como a do Shai‑Hulud, equipes de desenvolvimento podem adotar um conjunto de práticas de segurança específicas para o ecossistema npm:
– Fixar versões e revisar mudanças: sempre que possível, usar versões fixas em vez de intervalos amplos e revisar changelogs antes de grandes atualizações.
– Confiar apenas em fontes conhecidas: evitar pacotes recém-criados com poucos downloads ou manutenção obscura, principalmente se tiverem nomes muito parecidos com bibliotecas populares.
– Usar registries privados e proxies de segurança: espelhar dependências em repositórios internos, permitindo escaneamento e aprovação antes da distribuição interna.
– Habilitar ferramentas de SCA (Software Composition Analysis): automatizar a detecção de pacotes suspeitos e vulneráveis na pipeline de CI/CD.
– Revisar scripts de instalação: inspecionar arquivos como `package.json`, `binding.gyp` e scripts complementares em bibliotecas críticas.
Essa camada de higiene básica frequentemente impede a instalação automática de pacotes maliciosos ou, ao menos, torna mais fácil identificá-los precocemente.
Segurança em CI/CD: endurecendo os runners e pipelines
Como o Shai‑Hulud tem foco especial em pipelines e runners de CI/CD, é essencial tratar esses ambientes como ativos de alta criticidade:
– Isolamento de runners: usar runners efêmeros, destruídos ao fim de cada job, reduzindo superfície de persistência para malwares.
– Segregação de permissões: evitar que pipelines tenham acesso irrestrito a todos os segredos ou repositórios; aplicar o princípio do menor privilégio.
– Segredos gerenciados: utilizar cofres de segredos e injetar credenciais apenas quando estritamente necessário e com validade limitada.
– Auditoria contínua: monitorar logs de workflows, criação de novos jobs e modificações em arquivos de pipeline.
– Assinatura de artefatos: assinar builds e imagens de containers para garantir integridade em todo o fluxo de entrega.
Ao blindar o ambiente de CI/CD, a capacidade de um payload como o Shai‑Hulud de se propagar e de capturar segredos valiosos diminui consideravelmente.
Cultura de segurança para desenvolvedores
Ataques como esse deixam claro que desenvolvedores são alvo direto, não apenas infraestruturas. Por isso, além de ferramentas e processos, é necessário investir em cultura e treinamento:
– Consciência sobre segredos: nunca armazenar chaves em plain text em repositórios ou em histórico de shell.
– Uso de tokens de curta duração: preferir tokens temporários a credenciais estáticas de longa validade.
– Rotina de rotação: instituir políticas de rotação periódica de credenciais, mesmo na ausência de incidentes aparentes.
– Ambientes de desenvolvimento segmentados: manter separação entre máquinas pessoais, ambientes corporativos e acessos de produção.
Quando equipes inteiras incorporam boas práticas de segurança ao dia a dia, campanhas de roubo de credenciais encontram muito mais obstáculos.
Monitoramento e resposta a incidentes
Mesmo com todas as precauções, nenhum ambiente é 100% imune. Ter um plano estruturado de monitoramento e resposta a incidentes é essencial:
– Coleta centralizada de logs: incluir atividades de npm, GitHub CLI, systemd, LaunchAgents e ferramentas de IA.
– Alertas por comportamento anômalo: detectar padrões fora do usual, como criação repentina de múltiplos repositórios, scripts de build alterados ou acessos de locais incomuns.
– Playbooks de resposta: documentar passo a passo o que fazer ao detectar IoCs como os serviços `gh-token-monitor` ou versões maliciosas de pacotes.
– Simulações periódicas: realizar exercícios de mesa e testes controlados para validar se o time consegue reagir rapidamente em caso de ataque real.
Um processo de resposta bem definido pode transformar um incidente grave em um evento contido, com impacto muito menor.
Tendência crescente: malware explorando ecossistemas de desenvolvimento
A campanha do Shai‑Hulud reflete um movimento mais amplo: atacantes estão cada vez mais interessados em atingir diretamente as ferramentas e fluxos de trabalho de desenvolvimento. Repositórios de pacotes, IDEs com recursos de IA, serviços de integração contínua e plataformas de colaboração de código tornaram-se vetores preferenciais, já que oferecem um atalho para credenciais, código proprietário e acesso a infraestruturas de produção.
Diante desse cenário, organizações que dependem de nuvem, serverless e pipelines automatizados precisam tratar a segurança da cadeia de suprimentos de software como prioridade estratégica. Monitorar dependências, endurecer ambientes de desenvolvimento e aplicar continuamente as boas práticas recomendadas por especialistas torna-se, mais do que uma recomendação, um requisito para reduzir a superfície de ataque.
Ao entender em detalhes como campanhas como a do Shai‑Hulud operam – dos truques em `binding.gyp` até a exfiltração via GitHub e a persistência em systemd e LaunchAgents – equipes de segurança e desenvolvimento podem se antecipar, ajustando seus controles e minimizando as chances de que o próximo pacote malicioso encontre um caminho fácil até a produção.