GlassWorm retorna: a campanha da cadeia de fornecimento que oculta malware com Unicode invisível em repos, pacotes e extensões

A campanha de comprometimento da cadeia de abastecimento conhecida como GlassWorm reapareceu com uma onda coordenada muito mais ampla que a observada inicialmente. Pesquisadores de várias comunidades e empresas de segurança — entre eles Aikido, Socket, Step Security e a comunidade OpenSourceMalware — identificaram centenas de pacotes, repositórios e extensões afetados em plataformas como GitHub, npm e marketplaces de extensões para editores.

Nesta nova fase o alcance é notável: centenas de repositórios Python e JavaScript foram documentados no GitHub, dezenas de extensões em VSCode/OpenVSX e vários pacotes publicados no npm que contêm código troceado ou ofuscado por caracteres Unicode “invisíveis”. A técnica de inserir caracteres não imprimíveis facilita que o código malicioso passe despercebido para revisões superficiais e filtros automáticos, porque o arquivo pode ser aparentemente legítimo para olhos humanos e scanners que não normalizem o texto.

A pesquisa conjunta aponta para um mesmo operador por trás das diversas ondas: os relatos ressaltam o uso reiterado de uma direção na blockchain de Solana como canal de comando e controle, a reutilização de infra-estruturas e payloads com funcionalidade equivalente, e padrões de ofuscação e persistência comparáveis entre projetos afetados. Estes detalhes são os que permitem aos analistas correlacionar incidentes e sugerir que não se trata de ataques isolados, mas de uma campanha centralizada.

Tecnicamente, a infecção costuma começar com a tomada de controle de contas no GitHub e a introdução de commits maliciosos mediante force-push. A partir daí os atacantes publicam pacotes ou extensões a registries como npm ou OpenVSX. O malware inclui uma rotina que consulta a blockchain de Solana a cada poucos segundos em busca de instruções codificadas em transações - os pesquisadores de Step Security documentaram cerca de 50 transações relevantes entre finais de novembro de 2025 e meados de março de 2026 - e essas instruções dirigem a descarga e execução de um runtime de Node.js que exibe um ladrão de informações escrito em JavaScript.

Os objetivos do software espião são claros: extração de dados de carteiras de criptomoedas, credenciais, tokens de acesso, chaves SSH e artefatos do ambiente de desenvolvimento que permitem pivotar e roubar repositórios ou credenciais adicionais. Em algumas campanhas anteriores também foram observados binários macOS trojanizados - por exemplo clientes falsificados de carteiras de hardware - e extensões comprometidas que chegavam a IDEs não suportados através do OpenVSX, como descreveu um pesquisador em Análise do OpenVSX.

As análises do código apontam autores que comentam em russo e uma lógica que evita executar em sistemas configurados nessa língua; no entanto, Esse dado por si só não basta para atribuir com certeza a responsabilidade a uma nação ou um grupo específico. A atribuição requer mais evidência operacional e corroboração por múltiplas fontes.

Se você trabalha com dependências instaladas diretamente desde repositórios ou geralmente clonar projetos para executá-los, convém rever indicadores técnicos que os analistas compartilharam. Um deles é a presença de uma variável marcador identificada como “lzcdrtfxyqiplpd”, que serviu como sinal revelador em vários repositórios comprometidos. Foi também detectada persistência por um ficheiro de configuração local (~/ init.json) e instalação silenciosa de versões de Node.js em diretórios de usuário (como ~/node-v22*), além de arquivos suspeitos com nomes como nomes i.js em projetos recém- clonados e commits cujos metadados mostram diferenças estranhas entre a data do autor e a do committer.

Diante desse cenário, as medidas de contenção e mitigação passam por rotar chaves e tokens que puderam estar expostos, auditar o histórico de commits e os pacotes publicados por contas próprias, e buscar artefatos mencionados em sistemas de desenvolvimento. Também é recomendável ativar controles adicionais nas contas de repositórios: ativar a autenticação de dois fatores, revisar sessões ativas e chaves SSH autorizadas, e limitar tokens com permissões mínimas. O GitHub e outros fornecedores publicam guias para garantir contas e repositórios; por exemplo, a documentação sobre 2FA do GitHub é um bom ponto de partida: https://docs.github.com/.../two-factor-authentication-2fa.

Para equipes de desenvolvimento e administradores de plataformas, é crítico tentar as dependências como código potencialmente não confiável: validar assinaturas quando existam, fixar versões nos arquivos de lock, revisar mudanças em pacotes transitórios e aproveitar ferramentas de análise da cadeia de fornecimento que digitalizam repositórios e registros de pacotes. Os mantenedores de registries e marketplaces também devem melhorar a detecção de padrões de ofuscação Unicode e reforçar os processos de verificação de contas e publicações.

Quanto à resposta a incidentes, convém manter evidências (logs, builds, cópias de arquivos comprometidos), desconectar máquinas infectadas de redes de desenvolvimento e realizar um inventário de segredos que poderiam ter sido exfiltrados. As organizações que dependem de código aberto em produção devem considerar controlos de prevenção adicionais, como ambientes de build isolados, assinaturas reprodutíveis e pipelines que não executem código de terceiros sem revisão prévia.

GlassWorm nos lembra que a segurança do software moderno não se limita ao código que escrevemos, mas que se estende à enorme superfície que formam repositórios, pacotes e extensões de terceiros. A cadeia de fornecimento do software é tão forte ou tão fraca quanto o elo menos protegido, e esta campanha demonstra como atores com prática e recursos podem se mover lateralmente através de ferramentas e serviços legítimos para alcançar objetivos valiosos.

Se você quiser aprofundar os relatórios técnicos e rever os indicadores publicados pelas equipes que analisaram esta ameaça, você pode consultar os artigos de Aikido sobre o retorno de GlassWorm ( aqui), a análise do OpenVSX por Socket ( aqui), e a repartição de Step Security sobre a campanha e os sinais de compromisso ( aqui). Para entender como as transações de Solana podem levar memos com instruções, a documentação oficial de Solana sobre o programa Memo é uma referência útil: https://docs.solana.com/.../programs#memo-program.

A comunidade de segurança e os desenvolvedores devem manter-se alerta e compartilhar indicadores e mitigações para conter esta e outras campanhas semelhantes. A colaboração entre os responsáveis pelas infra-estruturas, os proprietários de projectos de código aberto e os fornecedores de registries é essencial para reduzir a janela de exposição e aumentar a barra de protecção para todos.