O malware no npm voltou a expor os riscos dos ataques à cadeia de suprimentos de software. Desta vez, o alvo foi o pacote oficial @injectivelabs/sdk-ts, utilizado por desenvolvedores para integrar aplicações à blockchain Injective. O incidente chamou a atenção da comunidade de segurança porque o código malicioso foi distribuído por meio de um pacote legítimo e amplamente utilizado no ecossistema Web3, transformando uma biblioteca confiável em uma ferramenta para roubo de credenciais de carteiras de criptomoedas.
A campanha foi identificada por pesquisadores da Socket, Ox Security e StepSecurity, que rapidamente analisaram o comportamento do pacote comprometido e alertaram a comunidade. Embora a versão maliciosa tenha permanecido disponível por um curto período, o episódio demonstra como ataques à cadeia de suprimentos continuam sendo uma das maiores ameaças para desenvolvedores e empresas que dependem de bibliotecas de terceiros.
A gravidade do caso vai além do número de downloads. O pacote afetado faz parte do ecossistema da Injective Labs, uma blockchain voltada para aplicações de finanças descentralizadas (DeFi), exchanges descentralizadas e soluções Web3. Isso significa que muitos projetos manipulam diretamente carteiras, chaves privadas e frases mnemônicas, justamente os dados que o malware tentava capturar.
Como o ataque à cadeia de suprimentos aconteceu com o malware no npm
Segundo as investigações, o incidente começou após o comprometimento da conta do GitHub de um colaborador legítimo do projeto. Com acesso autorizado ao repositório, o invasor conseguiu inserir alterações aparentemente legítimas no código-fonte, dificultando a identificação imediata da ameaça.
O ataque ilustra uma característica preocupante dos ataques modernos contra a cadeia de suprimentos: em vez de explorar vulnerabilidades no código da biblioteca, os criminosos exploram a confiança depositada nos próprios mantenedores do projeto.
A linha do tempo mostra a rapidez da operação. Em 8 de junho, foram realizados os commits contendo o código malicioso. Pouco depois, foi publicada a versão 1.20.21 do pacote @injectivelabs/sdk-ts, que passou a distribuir a funcionalidade maliciosa para quem atualizasse a dependência.
Após a identificação do problema pelos pesquisadores de segurança, a equipe responsável removeu rapidamente a versão comprometida e publicou a versão 1.20.23, considerada limpa. Mesmo assim, o curto intervalo foi suficiente para expor diversos desenvolvedores e aplicações.
O impacto em números e dependências
Embora o pacote malicioso tenha registrado aproximadamente 310 downloads diretos antes de sua remoção, os pesquisadores da Ox Security destacam que o verdadeiro impacto pode ser muito maior.
O pacote fazia parte da cadeia de dependências de diversos projetos, acumulando cerca de 87 dependências diretas e mais de 112 mil instalações transitivas. Isso significa que muitos desenvolvedores podem ter sido afetados sem sequer instalar diretamente o SDK da Injective.
Esse tipo de propagação é justamente o que torna o malware no npm tão perigoso. Em projetos modernos de Node.js e TypeScript, centenas de bibliotecas são instaladas automaticamente, tornando praticamente impossível acompanhar manualmente todas as dependências presentes em uma aplicação.
Anatomia do malware: Como o malware no npm executava o roubo de chaves
Um dos aspectos mais sofisticados do ataque foi seu comportamento discreto.
Ao contrário de diversos pacotes npm maliciosos, o código comprometido não executava nenhuma ação durante a instalação da biblioteca. Isso reduzia significativamente as chances de detecção por ferramentas de monitoramento focadas apenas em scripts de instalação.
Em vez disso, o malware permanecia adormecido até que o desenvolvedor utilizasse funções específicas relacionadas à criação ou importação de carteiras digitais.
Quando essas funções eram chamadas, o código interceptava informações extremamente sensíveis, incluindo:
- Frase mnemônica (seed phrase);
- Chave privada da carteira;
- Outros dados utilizados durante o processo de inicialização da carteira.
Depois da captura, os dados eram convertidos para Base64, facilitando sua transmissão e reduzindo a possibilidade de inspeção superficial do conteúdo.
Na sequência, o malware realizava uma requisição HTTP POST, enviando silenciosamente as informações para um servidor controlado pelos invasores.
Outro detalhe chamou atenção dos pesquisadores.
Em vez de utilizar um domínio estranho ou claramente suspeito, os criminosos utilizaram endpoints pertencentes à infraestrutura pública da própria Injective Labs como parte do fluxo de comunicação. Esse disfarce aumentava a credibilidade do tráfego gerado e poderia dificultar a identificação por soluções tradicionais de monitoramento.
Além disso, o código implementava um pequeno atraso de aproximadamente dois segundos antes de transmitir os dados capturados. Esse enfileiramento tornava o comportamento menos evidente durante testes rápidos realizados pelos desenvolvedores.
O resultado era um ataque altamente direcionado, silencioso e eficiente, focado exclusivamente em obter acesso às carteiras de criptomoedas das vítimas.
O que desenvolvedores e administradores devem fazer agora diante do malware no npm
Mesmo com a remoção da versão comprometida, qualquer desenvolvedor que tenha utilizado a versão 1.20.21 deve considerar que suas credenciais podem ter sido expostas.
A principal recomendação é agir imediatamente caso exista qualquer possibilidade de comprometimento.
Entre as medidas mais importantes estão:
- Migrar imediatamente todos os ativos para uma nova carteira, utilizando uma nova frase mnemônica e uma nova chave privada.
- Auditar cuidadosamente o arquivo package-lock.json para verificar se a versão comprometida foi instalada direta ou indiretamente.
- Atualizar todas as dependências para versões consideradas seguras.
- Rotacionar credenciais, tokens de acesso e demais segredos utilizados pelo ambiente de desenvolvimento.
- Revisar variáveis de ambiente que possam conter informações sensíveis.
O incidente também reforça a importância de fortalecer a segurança das contas utilizadas na manutenção de projetos de código aberto.
A adoção obrigatória de MFA (Autenticação Multifator) ou 2FA, especialmente para mantenedores de pacotes populares, reduz significativamente o risco de comprometimento de contas que possam resultar em ataques semelhantes.
Além disso, ferramentas modernas de análise de dependências, monitoramento de comportamento e auditoria contínua tornam-se cada vez mais essenciais para identificar alterações inesperadas em bibliotecas utilizadas em produção.
A comunidade Node.js vem enfrentando um crescimento constante de ataques à cadeia de suprimentos, especialmente nos ecossistemas npm, PyPI e Cargo. Em praticamente todos os casos recentes, o objetivo é semelhante: aproveitar a confiança dos desenvolvedores para distribuir código malicioso de maneira silenciosa.
O ataque ao @injectivelabs/sdk-ts demonstra que nem mesmo projetos amplamente utilizados no universo Web3 estão imunes a esse tipo de ameaça. Mais do que atualizar dependências, o episódio serve como um lembrete de que a segurança de software depende de processos contínuos de auditoria, verificação e resposta rápida a incidentes.
Para equipes que trabalham com criptomoedas, DeFi e aplicações financeiras descentralizadas, a proteção das chaves privadas deve ser tratada como prioridade absoluta. Afinal, uma única biblioteca comprometida pode ser suficiente para transformar uma atualização rotineira em um prejuízo irreversível.