O Open VSX, principal repositório aberto de extensões utilizado por projetos como VSCodium e IDEs baseadas no Eclipse Theia, removeu 77 extensões maliciosas que imitavam complementos legítimos para espionar desenvolvedores e coletar informações de ambientes de desenvolvimento. O incidente reforça um cenário preocupante: os ataques à cadeia de suprimentos de software estão migrando cada vez mais para ferramentas usadas diariamente por programadores, administradores de sistemas e equipes de DevOps.
As extensões faziam parte de uma campanha baseada na técnica Evil Twin, na qual criminosos publicam cópias quase idênticas de projetos legítimos, alterando apenas partes do código para executar ações maliciosas sem levantar suspeitas. Em vez de distribuir ransomware ou roubar senhas imediatamente, o objetivo era reconhecer o ambiente da vítima, identificar ativos valiosos e coletar informações que poderiam ser usadas em ataques mais sofisticados no futuro.
Para a comunidade Linux e de código aberto, o caso merece atenção especial. O Open VSX é uma alternativa livre ao marketplace oficial do Visual Studio Code e integra diversas ferramentas amplamente utilizadas por desenvolvedores. Isso significa que um ataque bem-sucedido contra esse ecossistema pode atingir desde projetos pessoais até ambientes corporativos responsáveis por desenvolver aplicações críticas.
Neste artigo, você entenderá como funcionava a campanha, quais dados eram coletados pelas extensões falsas, por que ela foi associada ao ataque ChainDrop no ecossistema npm e quais práticas ajudam a reduzir os riscos de comprometimento do ambiente de desenvolvimento.
Como funcionava a campanha das extensões falsas no Open VSX
Os pesquisadores descobriram que os invasores publicaram 77 extensões desenvolvidas para parecerem legítimas. Elas reproduziam nomes, descrições, ícones e até os namespaces de projetos conhecidos, tornando difícil diferenciá-las das versões autênticas durante uma instalação rápida.
A principal alteração estava no arquivo extension.js. Embora a extensão mantivesse a funcionalidade esperada para não despertar desconfiança, o código incluía rotinas adicionais responsáveis por coletar informações do sistema e transmiti-las para servidores controlados pelos atacantes.
Essa abordagem é conhecida como Evil Twin, uma técnica que explora a confiança do usuário ao distribuir uma versão adulterada de um software legítimo. Como o complemento aparentava funcionar normalmente, muitos desenvolvedores dificilmente perceberiam que seus ambientes estavam sendo monitorados.
Outro aspecto importante é que a campanha não buscava causar impacto imediato. O foco era realizar reconhecimento do ambiente para identificar vítimas de maior interesse, principalmente organizações com infraestrutura de desenvolvimento complexa.
Como as extensões identificavam ambientes de maior valor
A análise das extensões revelou dois níveis distintos de coleta de informações.
A variante mais simples realizava um reconhecimento básico da máquina comprometida, reunindo dados como hostname, sistema operacional e outras informações suficientes para identificar o perfil do dispositivo.
Já uma segunda variante possuía recursos muito mais avançados e demonstrava claramente que os verdadeiros alvos eram equipes profissionais de desenvolvimento e operações.
Espionagem de ambientes de desenvolvimento e CI/CD
A versão mais sofisticada ampliava significativamente o volume de informações coletadas.
Entre os dados monitorados estavam:
- Repositórios Git locais;
- Arquivos .git;
- Configuração de usuários do Git;
- Histórico recente de commits;
- Branches ativos;
- Endereços de e-mail configurados;
- Caminhos dos projetos armazenados na máquina;
- Configurações de proxy;
- Variáveis de ambiente.
O malware também procurava referências a plataformas amplamente utilizadas em processos de integração e entrega contínua, incluindo:
- Azure DevOps;
- CircleCI;
- GitHub Codespaces;
- Gitpod.
Essas informações permitem aos invasores compreender como uma organização desenvolve, testa e distribui seus softwares. Mesmo quando nenhuma credencial é obtida diretamente, esse mapeamento facilita ataques futuros, campanhas de phishing direcionadas e tentativas de invasão contra serviços utilizados pela empresa.
Em outras palavras, as extensões funcionavam como ferramentas de inteligência, preparando o terreno para operações mais complexas.
Persistência e mecanismos de evasão do malware
Além da coleta de informações, os pesquisadores identificaram mecanismos que aumentavam a resistência da campanha contra tentativas de bloqueio.
Caso o servidor principal não estivesse disponível, o malware continuava tentando restabelecer comunicação durante aproximadamente sete dias, reduzindo as chances de perder contato com a infraestrutura controlada pelos criminosos.
Outro recurso identificado foi o uso de consultas DNS TXT para recuperar instruções alternativas. Essa técnica permite contornar determinadas restrições de rede e dificulta a interrupção da campanha quando os domínios principais são bloqueados.
As extensões também verificavam configurações relacionadas à telemetria, adaptando seu comportamento para reduzir a possibilidade de detecção em ambientes monitorados.
Esses recursos mostram que a campanha foi planejada para permanecer ativa pelo maior tempo possível, mesmo diante de medidas defensivas implementadas pelas organizações.
O que o ataque tem em comum com o caso ChainDrop no npm
A descoberta das extensões falsas coincidiu com outra campanha de grande impacto na cadeia de suprimentos de software.
Conhecida como ChainDrop, ela comprometeu aproximadamente 450 pacotes npm, resultando na distribuição de cerca de 2.244 artefatos contaminados. Segundo os pesquisadores, a operação apresenta características semelhantes às observadas em variantes do malware Mini Shai-Hulud, voltado para comprometer ambientes de desenvolvimento.
O objetivo dos invasores deixou de ser apenas infectar bibliotecas JavaScript. Eles passaram a atacar todo o ecossistema utilizado pelos desenvolvedores, incluindo editores de código, gerenciadores de dependências, pipelines automatizados e ferramentas baseadas em Inteligência Artificial.
As análises indicam que alguns componentes da campanha também tentavam modificar configurações utilizadas por agentes de codificação com IA, incluindo soluções compatíveis com Claude, além de alterar arquivos de configuração do Visual Studio Code.
Essa convergência mostra uma tendência preocupante: os criminosos estão concentrando esforços em comprometer a origem do software, onde uma única infecção pode afetar diversos projetos simultaneamente.
Por que ataques à cadeia de suprimentos preocupam tanto
Ataques contra a cadeia de suprimentos são considerados especialmente perigosos porque exploram componentes nos quais desenvolvedores já confiam.
Extensões, bibliotecas, imagens de contêineres e pacotes publicados em repositórios oficiais costumam ser instalados automaticamente ou com pouca verificação. Quando um desses componentes é comprometido, o código malicioso entra na organização utilizando um canal considerado legítimo.
Além disso, ambientes modernos de desenvolvimento concentram uma enorme quantidade de informações estratégicas, como repositórios privados, tokens de acesso, configurações de infraestrutura, pipelines automatizados e integrações com serviços em nuvem.
Para um invasor, comprometer o computador de um desenvolvedor pode ser muito mais valioso do que atacar diretamente um servidor em produção.
Como proteger seu ambiente contra extensões maliciosas
Embora nenhum ambiente esteja totalmente imune, algumas práticas reduzem significativamente o risco de comprometimento.
Antes de instalar qualquer extensão, verifique cuidadosamente o publisher, o identificador oficial e o histórico do projeto. Pequenas diferenças no nome do autor costumam ser um dos principais indícios de ataques do tipo Evil Twin.
Também é recomendável revisar regularmente o arquivo .vscode/extensions.json, garantindo que apenas extensões aprovadas façam parte do ambiente de desenvolvimento.
Outras medidas importantes incluem:
- Auditar extensões e dependências utilizadas pelos projetos;
- Utilizar ferramentas de análise estática para identificar comportamentos suspeitos;
- Limitar permissões concedidas a complementos sempre que possível;
- Revisar periodicamente variáveis de ambiente utilizadas em pipelines de CI/CD;
- Monitorar alterações inesperadas em arquivos de configuração do editor;
- Implementar processos internos de validação antes da adoção de novas extensões.
Organizações que mantêm equipes de desenvolvimento também devem investir em políticas formais para gerenciamento de extensões, reduzindo a instalação indiscriminada de componentes obtidos em repositórios públicos.
O caso reforça a necessidade de proteger o ambiente de desenvolvimento
A remoção das 77 extensões maliciosas do Open VSX evidencia que os ataques à cadeia de suprimentos continuam evoluindo e acompanhando a transformação do desenvolvimento de software. Em vez de buscar apenas servidores vulneráveis, os criminosos agora concentram esforços nas ferramentas utilizadas diariamente por quem escreve, testa e distribui aplicações.
Casos como este e a campanha ChainDrop mostram que o ambiente de desenvolvimento passou a ser um dos principais alvos da cibercriminalidade. Extensões aparentemente inofensivas, pacotes publicados em repositórios populares e integrações com plataformas de automação podem servir como ponto de entrada para operações muito mais amplas.
Para desenvolvedores, administradores Linux e profissionais de DevOps, a principal lição é clara: a segurança deve começar antes mesmo da primeira linha de código. Auditar extensões, validar a procedência de dependências e acompanhar alertas de segurança são medidas essenciais para proteger projetos, credenciais e toda a cadeia de desenvolvimento.
