Escalada de Ataques à Cadeia de Suprimentos
A campanha de malware GlassWorm deu um salto significativo em sua sofisticação, utilizando uma nova tática de cadeia de suprimentos para infectar ambientes de desenvolvedores. Em 13 de março de 2026, a Socket Research Team reportou a identificação de pelo menos 72 novas extensões maliciosas no registro Open VSX vinculadas a esta campanha.
Diferente das abordagens anteriores, os atores maliciosos agora não colocam o payload diretamente na extensão inicial. Em vez disso, eles disfarçam o malware puxando-o através de atualizações secundárias após a confiança ser estabelecida. Essa técnica de "ataque transitivo" explora dois campos legítimos do manifesto da extensão: extensionPack e extensionDependencies.
Mecanismo de Infecção e Escopo
Os operadores do GlassWorm publicam extensões aparentemente benignas no registro Open VSX primeiro. Conforme detalhado pela Socket Research Team, uma vez que os desenvolvedores instalam e confiam nessas extensões, os atacantes lançam uma atualização posterior que modifica os arquivos de manifesto. Essa atualização introduz secretamente um link para um carregador GlassWorm oculto separado.
Como resultado, o editor de código instala automaticamente a dependência maliciosa em segundo plano, tornando as revisões de código iniciais completamente ineficazes. Para maximizar seu alcance, os atacantes se passam pesadamente por utilitários de desenvolvedor populares e inflam as contagens de download para milhares.
Os 72 pacotes maliciosos imitam linters amplamente utilizados, formadores de código como Prettier e ESLint, e ferramentas de linguagem populares para Python, Vue, Angular e Flutter. Notavelmente, a campanha também visa desenvolvedores que utilizam ferramentas de inteligência artificial. Os atores criaram extensões que imitam assistentes de desenvolvimento de IA como Claude Code, Codex e Antigravity.
Capacidades Técnicas Avançadas
Embora o objetivo principal do GlassWorm permaneça o roubo de credenciais locais, dados de configuração e segredos de ambiente de estações de trabalho de desenvolvedores, o malware em si tornou-se mais resiliente. As variantes mais recentes demonstram várias capacidades técnicas avançadas:
- Rotação de infraestrutura: Os atacantes mudaram sua infraestrutura de carteira Solana para um novo endereço (6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ) enquanto adicionavam novos endereços IP de comando e controle (45.32.151.157 e 70.34.242.255).
- Ofuscação avançada: O carregador AES estático foi substituído por técnicas de ofuscação mais pesadas RC4, base64 e string-array.
- Decodificação remota: As chaves de decodificação não são mais armazenadas dentro da própria extensão; agora são recuperadas dinamicamente de cabeçalhos de resposta HTTP controlados pelo atacante, como ivbase64 e secretkey.
- Guardrails de execução: O malware continua a utilizar execução JavaScript em estágios, execução de código follow-on na memória, memos de transação Solana para dead drops e geofencing de localidade e fuso horário russo para evadir análise.
Mitigações de Defesa
Porque esses pacotes maliciosos aparecem completamente benignos na publicação inicial, as equipes de desenvolvimento devem ajustar suas práticas de segurança. Revisar o código de uma extensão em sua primeira publicação não é mais suficiente para garantir a segurança.
Para proteger seus ambientes contra infecções transitivas do GlassWorm, implemente as seguintes mitigações:
- Audite o histórico de versão de suas extensões instaladas para quaisquer novos relacionamentos extensionPack ou extensionDependencies introduzidos.
- Revise as cadeias de instalação e atualização completas, em vez de apenas escanear o código da extensão atual.
- Caçe indicadores conhecidos de comprometimento do GlassWorm, como consultas de memo Solana ou carregadores em estágios contendo gateamento de localidade russa.
- Imediatamente bloqueie e remova pacotes vinculados ao GlassWorm conhecidos de estações de trabalho de desenvolvedores e verifique tokens de ambiente expostos.
A evolução do GlassWorm destaca a necessidade crítica de monitoramento contínuo de dependências de software, especialmente em ambientes de desenvolvimento onde a confiança é frequentemente concedida com base na reputação inicial de um pacote.