Radar Tech: vazamento na CrowdSec nasceu de um ataque a pacote npm — e o novo malware não usa install script
Causa raiz de um vazamento de ~170 repositórios privados foi uma credencial roubada meses antes via ataque a registry npm. Em paralelo, análise mostra pacote malicioso que escapa do bloqueio de lifecycle scripts escondendo o loader em runtime.
Nesta sexta-feira (18/09) o CEO da CrowdSec publicou o relatório pós-incidente do vazamento de cerca de 170 repositórios privados da empresa. A causa raiz é o ponto que interessa a qualquer time de engenharia: não houve invasão da infraestrutura. O acesso veio de uma credencial de um ex-funcionário cujo notebook havia sido comprometido meses antes, em maio de 2026, por um ataque de cadeia de suprimentos no registry npm.
E, no domingo (20/09), uma segunda análise — da Checkmarx, reportada pela BleepingComputer — mostrou a evolução do outro lado: um pacote npm malicioso que não usa lifecycle script nenhum.
O encadeamento que produziu o vazamento
A linha do tempo relatada pela CrowdSec:
- 11/05/2026 — um grupo de ameaça compromete o repositório de pacotes npm de um projeto de bibliotecas JavaScript amplamente usado, backdooredando 42 pacotes com um malware especializado em colher credenciais e tokens.
- 22/05/2026 — o mesmo grupo reivindica o comprometimento de repositórios de outra empresa de IA.
- 22/05/2026, entre 05:52 e 06:01 UTC — alguém baixa o conteúdo de aproximadamente 170 repositórios privados da CrowdSec, de um IP no Canadá.
- 25/05/2026 — a empresa revoga o acesso da conta envolvida.
O dado que vale sublinhar: segundo o relatório, a conta comprometida foi usada exclusivamente para clonar os repositórios. Não houve commit, alteração de código, mudança de infraestrutura ou de CI. Um único segredo de acesso, roubado meses antes por um canal totalmente diferente, foi suficiente para exfiltrar um codebase privado inteiro.
O outro lado: quando não existe script para bloquear
O caso do pacote malicioso analisado pela Checkmarx ataca exatamente a defesa que a maioria das empresas instalou em 2026. Depois de uma sequência de ataques de registry, o npm passou a bloquear lifecycle scripts (preinstall, install, postinstall) por padrão, a menos que explicitamente aprovados.
O pacote malicioso simplesmente não usa script. Ele esconde o loader dentro de um método legítimo da própria biblioteca, que qualquer aplicação chama constantemente em produção. A instalação fica limpa, não dispara nenhum dos mecanismos de aprovação, e a maioria dos scanners estáticos não vê. O código malicioso só executa quando a aplicação legítima o invoca.
Detalhes técnicos que o relatório destaca:
- O coletor de comandos e controle não usa servidor próprio: consulta um contrato inteligente em rede de teste Ethereum, usando troca de chaves X25519 para derivar a chave AES que decifra o segundo estágio.
- A exfiltração de dados do host passa por canais de mensageria com endpoints embutidos no código.
- O atacante construiu um repositório de aparência legítima, com histórico de commits populado e conta curada.
- O malware consegue se apagar: remove seus arquivos e o gatilho malicioso do código do pacote para eliminar rastros.
- Nove pacotes adicionais ligados à mesma operação foram identificados e removidos.
Por que isso reposiciona o problema de arquitetura
As duas histórias apontam para a mesma conclusão: o controle que resolve não está no registry, está na credencial. Enquanto uma dependência maliciosa puder executar no mesmo contexto onde vive uma chave de nuvem de vida longa, o bloqueio de install scripts é uma barreira parcial contra um vetor que já migrou.
Três movimentos que endereçam a causa raiz:
- Eliminar material de credencial em repouso. Trocar tokens de publicação e chaves de nuvem por identidade de workload — credencial efêmera, emitida por job, com escopo restrito e expiração automática. Não há token de longa duração para roubar seis meses depois.
- Isolar por missão do job. Um job de teste não deve conseguir publicar, e um job de publicação não deve conseguir ler produção. O raio de explosão deve ser um artefato, não uma organização.
- Cobrir a execução em runtime, não só a instalação. Bloqueio de script e scanner estático não alcançam um loader escondido em método legítimo. O que alcança é restrição de tráfego de saída (incluindo protocolos além de HTTP, como DNS) e telemetria de processo no ambiente de execução, capaz de detectar comportamento anômalo depois do deploy.
Leitura recomendada
- Relatório pós-incidente da CrowdSec (18/09/2026) — linha do tempo completa e causa raiz.
- Análise da Checkmarx, reportada pela BleepingComputer (20/09/2026) — detalhes do loader em runtime.
O ponto prático do dia: vale rodar uma pergunta simples no seu próprio ambiente. Se uma das 300 dependências transitivas virar maliciosa amanhã, qual credencial ela alcança e em quanto tempo eu descubro? Se a resposta for "todas" e "não sei", o problema não é a dependência.
