Uma campanha de ataque à cadeia de suprimentos de software conseguiu distribuir 53 pacotes maliciosos pelos repositórios RubyGems e npm, transformando uma ação aparentemente comum — instalar uma biblioteca de desenvolvimento — em uma porta de entrada para roubo de informações.
A operação, identificada como StubMaker, foi descoberta em 15 de agosto de 2026 pela OpenSourceMalware. A investigação encontrou inicialmente 16 pacotes no RubyGems e, posteriormente, relacionou outros 37 pacotes publicados no npm à mesma infraestrutura e ao mesmo responsável.
O malware foi desenvolvido para atacar principalmente computadores Windows e buscar informações de alto valor, incluindo credenciais armazenadas em navegadores, carteiras de criptomoedas, seed phrases, informações do Telegram, dados de cartões e informações sobre o próprio sistema infectado.
O episódio reforça uma preocupação crescente para empresas de tecnologia: criminosos não precisam necessariamente atacar diretamente servidores corporativos quando podem tentar comprometer os componentes utilizados pelos próprios desenvolvedores.
Ataque explorou erros de digitação nos nomes
Um dos principais mecanismos utilizados pela campanha é conhecido como typosquatting.
A técnica consiste em publicar pacotes com nomes visualmente semelhantes aos de bibliotecas legítimas e populares, esperando que um desenvolvedor cometa um erro de digitação ou não perceba a diferença antes da instalação.
No RubyGems, por exemplo, foram identificados nomes como activesupmport, brumdler, brundlef, ubnuler, ubnlder, ri18nr, reaker e outras variações.
Segundo a OpenSourceMalware, os 16 pacotes identificados nesse ecossistema tentavam se passar por dependências conhecidas do universo Ruby. Os pacotes já foram removidos do repositório.
No npm, a estratégia foi semelhante.
Os criminosos criaram nomes que imitavam bibliotecas amplamente utilizadas, incluindo Axios, Chalk, Commander, Lodash, TypeScript e React. Entre as falsificações estavam axois-http, axious-core, comander-cli, loadashjs, typescirpt-cli e raectjs.
Uma única letra fora do lugar poderia, portanto, colocar uma estação de desenvolvimento em risco.
Como o StubMaker infectava os computadores
Apesar de RubyGems e npm fazerem parte de ecossistemas diferentes, os criminosos adaptaram a cadeia de infecção às características de cada plataforma.
Nos pacotes RubyGems, o ataque utilizava o arquivo extconf.rb.
Esse arquivo normalmente participa do processo de instalação de gems que possuem extensões nativas. Como ele pode ser executado automaticamente durante a instalação, os invasores o transformaram em um mecanismo para iniciar a cadeia maliciosa.
O código baixava um loader de aproximadamente 22 MB desenvolvido em Rust, que estava hospedado em uma release do GitHub.
Depois disso, o loader executava um infostealer desenvolvido em Go identificado como wincfg.
Nos pacotes npm, a lógica era semelhante, mas os criminosos utilizaram um hook postinstall, capaz de executar código depois que uma dependência é instalada.
Ou seja, o simples processo de adicionar uma biblioteca ao projeto poderia iniciar a infecção.
Malware atacava Chrome, Edge, Brave e outros navegadores
Uma das partes mais relevantes da operação é a capacidade de roubar dados armazenados em navegadores.
O malware incorpora uma biblioteca chamada abe_payload.dll, utilizada para extrair credenciais de navegadores baseados em Chromium e contornar mecanismos relacionados à App-Bound Encryption (ABE).
Entre os navegadores citados na investigação estão:
- Google Chrome;
- Microsoft Edge;
- Brave;
- Opera e Opera GX;
- Vivaldi;
- Yandex;
- Avast Browser;
- AVG Browser;
- CCleaner Browser.
Além de credenciais, o malware procurava histórico de navegação, extensões instaladas e informações relacionadas a cartões de pagamento.
O objetivo, portanto, não era apenas comprometer um ambiente de desenvolvimento. A máquina do próprio desenvolvedor se tornava uma fonte potencial de dados para os criminosos.
Carteiras de criptomoedas e seed phrases estavam na mira
O StubMaker também buscava informações relacionadas a criptomoedas.
Os pesquisadores identificaram mecanismos para localizar carteiras digitais e seed phrases, além de dados de outros aplicativos presentes no computador.
Seed phrases são especialmente críticas porque funcionam como uma espécie de chave mestra para recuperação de determinadas carteiras de criptomoedas.
Caso um criminoso consiga obtê-las, pode potencialmente assumir o controle dos ativos associados à carteira.
O malware também extraía informações do Telegram Desktop, coletava detalhes sobre o computador e consultava um serviço externo para identificar o endereço IP público da vítima.
Informações roubadas eram enviadas para infraestrutura externa
Depois da coleta, os dados eram reunidos e compactados em um arquivo ZIP protegido por senha.
O material era então enviado ao serviço de hospedagem de arquivos Gofile.
Segundo a investigação, o endereço resultante para acesso ao arquivo era posteriormente encaminhado aos operadores da campanha por meio de uma conexão HTTP para uma infraestrutura associada ao domínio dresslee.com.
Esse processo permitia separar a coleta dos dados do mecanismo utilizado pelos criminosos para recuperá-los.
37 pacotes npm foram publicados em apenas oito minutos
A velocidade de distribuição da campanha também chama atenção.
Enquanto os pacotes do RubyGems foram distribuídos durante dois dias, os 37 pacotes relacionados ao npm foram publicados em apenas oito minutos, utilizando cinco contas diferentes.
A estratégia aumenta a dificuldade de reação.
Mesmo que uma conta seja detectada e bloqueada rapidamente, outras podem continuar publicando pacotes.
Segundo a investigação, os pacotes npm foram publicados em 16 de agosto de 2026 e posteriormente removidos.
O episódio demonstra como ataques à cadeia de suprimentos podem ser automatizados e distribuídos em escala em períodos extremamente curtos.
RubyGems também revelou um problema de namespace
A investigação encontrou ainda uma característica específica do RubyGems que foi aproveitada pelos invasores.
Em pelo menos dois casos — brumdler e brundlef — os criminosos conseguiram utilizar nomes anteriormente associados a outros pacotes depois que suas versões antigas haviam sido removidas.
A possibilidade de reutilização do namespace, combinada à flexibilidade existente no preenchimento do campo de autor, ajudava os pacotes maliciosos a aparentar origens diferentes.
Isso evidencia outro aspecto importante dos ataques à cadeia de suprimentos: a segurança não depende somente do código utilizado pelo desenvolvedor, mas também dos mecanismos de identidade, publicação e confiança dos próprios repositórios.
Desenvolvedores se tornaram alvos estratégicos
O StubMaker integra um cenário mais amplo de ataques contra ecossistemas de desenvolvimento.
Em junho, por exemplo, pesquisadores identificaram uma campanha envolvendo 11 pacotes npm maliciosos ou altamente suspeitos direcionados a desenvolvedores blockchain, projetos Web3 e operadores de carteiras de criptomoedas. Esses pacotes acumularam mais de 2,72 milhões de downloads.
Em agosto, a Sonatype também encontrou seis pacotes npm utilizando transações da blockchain Ethereum como parte do mecanismo para localizar infraestrutura responsável pela entrega de cargas maliciosas adicionais.
Os casos possuem características diferentes, mas apontam para o mesmo problema: repositórios de software são uma superfície de ataque extremamente atraente porque uma única dependência pode alcançar muitos computadores e projetos.
O que empresas e desenvolvedores devem fazer
Organizações que utilizam npm, RubyGems ou outros gerenciadores de dependências precisam tratar a instalação de pacotes como parte de sua estratégia de segurança.
Entre as medidas importantes estão revisar cuidadosamente nomes e mantenedores antes da instalação, utilizar lockfiles, controlar novas dependências, analisar scripts executados durante instalação, empregar ferramentas de Software Composition Analysis e restringir credenciais disponíveis nas máquinas e pipelines de desenvolvimento.
No caso específico do StubMaker, a recomendação para quem instalou algum dos pacotes identificados em uma máquina Windows enquanto eles estavam disponíveis é mais severa: o equipamento potencialmente comprometido deve ser isolado e as credenciais que poderiam ter sido acessadas precisam ser substituídas, além da remoção das bibliotecas maliciosas.
Também é importante verificar sessões autenticadas, tokens de desenvolvimento, credenciais de repositórios e carteiras digitais utilizadas no dispositivo.
Ataques à cadeia de software exigem mudança de confiança
O caso StubMaker mostra que a segurança do desenvolvimento moderno não termina no código produzido internamente.
Projetos atuais podem depender de dezenas ou centenas de bibliotecas externas. Cada dependência adiciona código que, em algum momento, poderá ser executado em computadores de desenvolvedores, servidores de integração ou ambientes de produção.
Isso transforma o ecossistema open source em uma infraestrutura fundamental — mas também em um alvo extremamente valioso.
Para empresas brasileiras, o episódio não significa que organizações do país tenham necessariamente sido comprometidas pela campanha. Serve, porém, como alerta para equipes de desenvolvimento e segurança que utilizam os mesmos repositórios globais.
A regra passa a ser simples: um pacote disponível em um repositório conhecido não deve ser automaticamente considerado confiável.
