A campanha de malware GlassWorm ressurgiu nesta segunda-feira (27/04) com uma nova ofensiva direcionada ao ecossistema OpenVSX, utilizando 73 extensões “dormentes” para comprometer desenvolvedores. A descoberta, detalhada pela empresa de segurança Socket e divulgada pelo BleepingComputer, revela uma evolução tática em que agentes de ameaças publicam complementos inicialmente inofensivos que ativam o código malicioso apenas após uma atualização posterior.
A tática das extensões dormentes
O método utilizado nesta nova onda, identificada como GlassWorm v2, baseia-se no conceito de “confiança visual”. Os atacantes clonam extensões legítimas e populares, replicando ícones, descrições e metadados para induzir programadores ao erro. Uma vez instaladas, essas ferramentas permanecem em estado latente (sleeper), passando sem detecção pelos escâneres automatizados do repositório OpenVSX, que atende IDEs como Cursor, Windsurf e VSCodium.
Após um período de maturação, os criminosos enviam uma atualização que introduz um carregador (loader) leve. Esse componente não contém o malware final, mas atua como uma ponte para buscar o payload real em servidores externos, frequentemente hospedados no GitHub. Essa separação entre o instalador e a ameaça final dificulta a análise estática e aumenta a longevidade da campanha nos marketplaces.
Impacto técnico e dados da operação
O objetivo central do GlassWorm é a exfiltração de dados sensíveis do ambiente de desenvolvimento. O malware final é capaz de colher segredos do sistema, chaves SSH, cookies de sessão e dados armazenados no Apple Notes (em dispositivos macOS). Um detalhe técnico relevante é que o malware interrompe sua execução se detectar um sistema configurado com o idioma russo, o que sugere uma possível origem geográfica dos operadores.
Evolução da cadeia de suprimentos
Esta ofensiva representa uma mudança em relação às ondas anteriores de março de 2026, onde o grupo abusava de dependências transitivas para esconder código malicioso. Agora, ao focar em clones diretos e atualizações retardadas, os atacantes exploram uma falha sistêmica na forma como desenvolvedores gerenciam plugins de produtividade. Para profissionais que utilizam o OpenVSX, o risco é amplificado, pois o registro depende fortemente da supervisão comunitária em comparação ao VS Code Marketplace oficial.
Os pesquisadores observaram o uso de droppers escritos em Zig e a comunicação com servidores de comando e controle (C2) que utilizam a blockchain Solana para recuperar endereços de infraestrutura. Essa técnica de C2 descentralizada torna a interrupção da rede criminosa extremamente difícil para as autoridades de cibersegurança.
Para mitigar o risco, recomenda-se que desenvolvedores auditem imediatamente as extensões instaladas em suas IDEs, priorizando apenas editores verificados e evitando ferramentas com baixo número de instalações ou nomes ligeiramente alterados (typosquatting). Embora a fundação responsável pelo OpenVSX tenha iniciado a remoção das extensões sinalizadas, a persistência de máquinas já infectadas exige uma varredura completa por malwares e a rotação imediata de todas as credenciais de acesso a repositórios e serviços de nuvem.
