Campanha no Open VSX combina clones de extensões legítimas, pacotes adormecidos e instalação de um VSIX secundário para infectar IDEs e coletar dados sensíveis.
| Componente | Extensões para Microsoft Visual Studio Code publicadas no repositório Open VSX, incluindo clones maliciosos e pacotes adormecidos associados ao GlassWorm v2. |
| Vetor | Instalação voluntária de extensões clonadas que imitam nomes, ícones e descrições de pacotes legítimos; após ativação ou atualização, o carregador baixa um VSIX hospedado no GitHub e usa --install-extension. |
| Impacto | Execução de malware em ambientes de desenvolvimento, instalação em VS Code, Cursor, Windsurf e VSCodium, implantação de RAT e extensão Chromium maliciosa para coletar credenciais, favoritos e outras informações. |
| Prioridade | Auditar extensões instaladas a partir do Open VSX, remover clones suspeitos, bloquear instalação automatizada de VSIX não aprovado e revisar endpoints de desenvolvedores com IDEs afetadas. |
| Artefatos | Foram identificadas 73 extensões no cluster recente, seis delas confirmadas como maliciosas, além de mais de 320 artefatos associados desde 21 de dezembro de 2025. |
| Técnica | Uso de pacotes adormecidos, dependências transitivas, JavaScript ofuscado, droppers em Zig e carga VSIX secundária hospedada no GitHub. |
A campanha GlassWorm v2 explora a confiança operacional depositada em extensões de IDE para atingir desenvolvedores por meio do ecossistema Open VSX. O conjunto recente envolve 73 extensões falsas ligadas a clones de pacotes legítimos do Microsoft Visual Studio Code. Dentro desse grupo, seis extensões foram confirmadas como maliciosas, enquanto as demais aparecem como pacotes aparentemente inofensivos, usados para criar histórico de instalação, ganhar reputação e reduzir suspeitas antes de uma eventual atualização maliciosa. A técnica desloca parte do risco para o fluxo cotidiano de trabalho de engenharia: a instalação de extensões, muitas vezes tratada como atividade de baixa criticidade, passa a funcionar como ponto inicial de execução de código em estáções de desenvolvimento.
O componente central da operação é um carregador disfarçado como extensão legítima. Esses clones reutilizam sinais visuais dos pacotes originais, como ícone e descrição, e aplicam typosquatting no nome para confundir usuários que pesquisam extensões conhecidas. Um exemplo citado no contexto compara CEINTL.vscode-language-pack-tr com Emotionkyoseparate.turkish-language-pack, ilustrando como a campanha tenta se aproximar de nomes reais sem precisar comprometer o pacote original. A finalidade descrita é instalar e executar uma carga VSIX secundária hospedada no GitHub, propagar essa carga para IDEs encontradas na máquina e, no estágio final, executar malware com coleta de dados sensíveis, instalação de RAT e implantação de uma extensão Chromium fraudulenta.
O fluxo começa na distribuição pelo Open VSX, repositório usado por ambientes compatíveis com extensões do Visual Studio Code. A campanha não depende apenas de um binário entregue diretamente ao usuário; ela usa extensões como camada de confiança e ativação. Depois que o desenvolvedor instala uma extensão falsa, o pacote atua como carregador aparentemente simples. A lógica de entrega pode permanecer em JavaScript ofuscado, reduzindo a exposição direta do payload principal no pacote inicial. Após a ativação, a extensão busca um VSIX secundário no GitHub e aciona a instalação nas IDEs detectadas por meio do comando --install-extension, ampliando o alcance local da infecção sem exigir que o usuário instale manualmente cada componente.
A campanha também foi descrita com evolução de modus operandi, incluindo pacotes adormecidos, dependências transitivas e droppers baseados em Zig. Esses elementos aumentam a dificuldade de triagem porque a extensão inicial pode não conter todas as capacidades maliciosas no momento da publicação, e parte da execução pode ser transferida para dependências ou cargas recuperadas posteriormente. A instalação do VSIX secundário em VS Code, Cursor, Windsurf e VSCodium indica uma abordagem orientada ao ambiente de desenvolvimento como um todo, não apenas a uma única aplicação. O malware ainda evita sistemas russos, condição que deve ser tratada como lógica de ambiente presente na campanha, e busca coletar dados sensíveis, instalar acesso remoto e posicionar uma extensão Chromium maliciosa para capturar credenciais, favoritos e outras informações armazenadas ou acessíveis pelo navegador.
A superfície principal está nas estáções de desenvolvedores que aceitam extensões de fontes externas ao marketplace padrão ou que utilizam o Open VSX como origem de pacotes. O risco é maior quando a instalação de extensões é deixada a critério individual, sem allowlist, revisão de publicador, verificação de similaridade de nomes ou controle de versões. Como os clones procuram reproduzir aparência e descrição dos pacotes legítimos, a decisão visual do usuário deixa de ser um controle confiável. O uso de typosquatting torna especialmente sensíveis os fluxos de instalação feitos por busca textual, scripts de bootstrap de ambiente, documentação interna desatualizada ou listas copiadas entre projetos.
A presença de IDEs compatíveis amplia a exposição porque a carga secundária é instalada em todos os ambientes identificados na máquina. Isso inclui VS Code, Cursor, Windsurf e VSCodium. Em organizações com múltiplas ferramentas de engenharia no mesmo endpoint, uma instalação inicial pode resultar em persistência operacional em mais de uma IDE. A existência de pacotes adormecidos também altera a janela de risco: uma extensão hoje inofensiva pode se tornar relevante após atualização futura, principalmente quando atualizações automáticas estão habilitadas e quando não há comparação entre o conteúdo publicado originalmente e versões subsequentes.
- Desenvolvedores que instalaram extensões do Open VSX com nomes semelhantes a pacotes legítimos de VS Code.
- Endpoints com VS Code, Cursor, Windsurf ou VSCodium nos quais
--install-extensionpossa ser usado por processos locais. - Ambientes que aceitam atualizações automáticas de extensões sem revisão de mudança, origem, dependências e comportamento pós-ativação.
- Máquinas nas quais extensões Chromium possam ser instaladas ou modificadas sem controle administrativo centralizado.
A investigação deve começar pelo inventário de extensões instaladas nas IDEs afetadas. O objetivo é comparar nomes, identificadores, publicadores, datas de instalação e descrições com pacotes legítimos esperados. Clones com ícones e textos idênticos, mas publicadores estranhos, nomes levemente alterados ou baixa reputação, devem ser tratados como suspeitos. A presença de extensões publicadas no início do mês da publicação e associadas ao cluster de 73 pacotes aumenta a prioridade de análise. Como o contexto descreve mais de 320 artefatos desde 21 de dezembro de 2025, a investigação não deve se limitar ao conjunto mais recente quando houver histórico de instalações anteriores em endpoints de engenharia.
Na telemetria de endpoint, procure processos de IDE executando instalação de extensão por linha de comando, especialmente uso de --install-extension iniciado por extensões ou scripts não documentados. Também é relevante revisar conexões de saída para GitHub realizadas logo após ativação de extensão, criação de novos diretórios de extensão, alterações simultâneas em múltiplas IDEs e instalação de componentes Chromium sem ação explícita do usuário. A presença de JavaScript ofuscado em pacotes de extensão deve ser avaliada em conjunto com comportamento de rede e execução local, pois ofuscação isolada não confirma malícia, mas é consistente com o modelo de carregador descrito para a campanha.
- Instalações recentes de extensões do Open VSX com nomes visualmente parecidos com pacotes conhecidos, mas com identificadores ou publicadores divergentes.
- Execução de IDEs com o argumento
--install-extension, principalmente quando acionada após ativação de extensão recém-instalada. - Download de arquivos VSIX a partir do GitHub imediatamente antes de novas extensões aparecerem em VS Code, Cursor, Windsurf ou VSCodium.
- Criação ou alteração de extensões Chromium sem solicitação do usuário, especialmente em endpoints que também receberam extensões suspeitas de IDE.
- Código JavaScript ofuscado dentro de extensões que deveria apenas fornecer recursos simples, como idioma, tema ou integração de baixo privilégio.
A resposta deve priorizar contenção de estáções de desenvolvimento com extensões suspeitas, porque esses endpoints frequentemente concentram credenciais, acesso a repositórios, ferramentas de build e sessões autenticadas em serviços internos. Remova extensões clonadas ou não aprovadas, desative atualização automática quando não houver revisão centralizada e bloqueie a instalação de VSIX por caminhos não autorizados. Em seguida, revise todas as IDEs presentes na máquina, não apenas aquela usada no momento da descoberta, já que a carga descrita tenta instalar o componente secundário em várias aplicações compatíveis.
Depois da remoção, valide se houve instalação de RAT ou extensão Chromium maliciosa. A simples exclusão da extensão inicial pode não desfazer cargas instaladas posteriormente. É necessário revisar diretórios de extensões das IDEs, perfis de navegador Chromium, processos persistentes e conexões de rede recentes. Credenciais usadas no endpoint devem ser avaliadas conforme exposição real: se houver indício de execução do malware, trate tokens de desenvolvimento, sessões de navegador e credenciais armazenadas como material potencialmente acessado. A mitigação de longo prazo exige governança de extensões, allowlist de publicadores e inspeção de atualizações, porque o uso de pacotes adormecidos reduz a eficácia de uma avaliação feita apenas no momento da primeira instalação.
- Criar inventário centralizado de extensões instaladas em VS Code, Cursor, Windsurf e VSCodium, incluindo origem, publicador, versão e data de instalação.
- Remover extensões com typosquatting, metadados clonados ou comportamento de carregador, e bloquear reinstalação por política local.
- Monitorar e restringir o uso de
--install-extensionquando executado por processos não interativos ou por extensões já instaladas. - Inspecionar perfis Chromium em busca de extensões não autorizadas implantadas no mesmo período da instalação suspeita.
- Revisar tokens, credenciais e sessões presentes em endpoints com execução confirmada ou provável do GlassWorm v2.
0 Comentários