A campanha de ataque à cadeia de suprimentos liderada pelo grupo GlassWorm atingiu um novo patamar de sofisticação com a descoberta de 73 novas extensões dorminhocas no marketplace Open VSX. Identificadas em abril de 2026, essas extensões representam uma mudança perigosa na forma como atores de ameaças distribuem malware para desenvolvedores de software, evoluindo táticas para evadir varreduras de segurança automatizadas.
Esta atividade segue uma onda significativa descoberta em março de 2026, onde pesquisadores documentaram 72 extensões maliciosas do Open VSX vinculadas à operação GlassWorm. As variantes anteriores abusavam de recursos de dependência de extensão para instalar carregadores maliciosos silenciosamente. No entanto, o novo cluster de abril de 2026 demonstra uma evolução tática clara, focada em persistência e evasão.
Estratégia da extensão dorminhoca
Uma extensão dorminhoca é um pacote falso publicado por atores de ameaças antes de ser armamentizado. Essas extensões aparecem inicialmente inofensivas para construir confiança visual, ganhar credibilidade e coletar downloads. Os atacantes utilizam contas recém-criadas no GitHub para publicar versões clonadas de ferramentas populares.
Por exemplo, os atacantes criaram um pacote falso de idioma turco para o Visual Studio Code que imitava de perto a versão legítima. Eles copiaram o ícone do globo e a descrição, trocando apenas o nome do editor. Uma vez que os desenvolvedores instalam essas ferramentas clonadas, os atacantes aguardam antes de enviar uma atualização de software que entrega o malware. Pelo menos seis das 73 novas extensões já foram ativadas para entregar payloads.
Mecanismos de entrega evoluídos
Na última onda, a extensão atua apenas como um carregador fino para buscar payloads externos. O código malicioso não é mais visível diretamente no código-fonte da extensão, aumentando a probabilidade de evasão de detecção. A campanha utiliza dois métodos primários de execução:
- Binários Nativos: Arquivos .node embutidos são escondidos dentro do código da extensão. Um arquivo JavaScript simples executa o binário, que contém URLs embutidas que baixam arquivos .vsix maliciosos para IDEs como VS Code e Cursor.
- JavaScript Ofuscado: A lógica maliciosa é fortemente ofuscada e não depende de arquivos binários embutidos. O código se decodifica em tempo de execução, recupera um payload .vsix malicioso de um lançamento do GitHub e o instala através de caminhos de linha de comando.
Análise técnica detalhada
A técnica de usar extensões legítimas como vetores de entrega é particularmente preocupante para equipes de DevSecOps. A extensão dorminhoca explora a confiança inerente que os desenvolvedores depositam em pacotes populares. Ao clonar ferramentas como pacotes de idioma ou temas, os atacantes reduzem a fricção para a instalação inicial. A ofuscação do JavaScript e o uso de binários nativos escondidos (.node) dificultam a análise estática tradicional.
Os arquivos .node são compilados para C++ e podem executar código nativo diretamente no ambiente do desenvolvedor, contornando muitas restrições de sandbox do Node.js. Isso permite que o malware acesse o sistema de arquivos local, capture credenciais de desenvolvimento e estabeleça conexões de comando e controle (C2) persistentes.
Indicadores de comprometimento
Equipes de segurança devem monitorar os seguintes indicadores para identificar infecções relacionadas a esta campanha:
- Binários de Instalador Nativo (SHA256): 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168.
- Payload VSIX Baixado (SHA256): 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd.
- Hospedagem Maliciosa do GitHub: github[.]com/SquadMagistrate10/wnxtgkih.
- Extensões Maliciosas Confirmadas: outsidestormcommand, monochromator-theme, boulderzitunnel, vscode-buddies.
Recomendações para equipes de segurança
De acordo com a Socket Research Team, os desenvolvedores devem verificar namespaces de editor e inspecionar contagens de download cuidadosamente antes de instalar extensões do marketplace Open VSX. Para CISOs e líderes de segurança, as seguintes medidas são recomendadas:
- Implementar políticas de aprovação de extensões de terceiros em ambientes corporativos.
- Utilizar ferramentas de análise de software (SCA) que verifiquem a integridade de pacotes de extensão.
- Monitorar tráfego de rede para conexões a domínios suspeitos ou IPs associados a hospedagem maliciosa.
- Capacitar desenvolvedores sobre os riscos de cadeias de suprimentos de software e a importância de verificar editores de pacotes.
Implicações para governança de segurança
Este incidente reforça a necessidade de uma governança de segurança de software mais rigorosa. A confiança cega em repositórios de pacotes abertos é uma vulnerabilidade sistêmica. Organizações devem considerar a criação de repositórios privados de pacotes (proxies) onde apenas extensões aprovadas e verificadas são permitidas.
Perguntas frequentes
Como saber se uma extensão é legítima? Verifique o nome do editor, o número de downloads e a data de publicação. Extensões recém-criadas com nomes genéricos ou que imitam ferramentas populares são suspeitas.
Devo desinstalar todas as extensões do Open VSX? Não necessariamente, mas revise as que foram instaladas recentemente e verifique se o editor corresponde ao esperado. Remova as extensões listadas nos indicadores de comprometimento imediatamente.