Operação CrowdStrike, Google e Shadowserver derruba infraestrutura do GlassWorm e expõe escala da ameaça contra desenvolvedores

A CrowdStrike, em operação coordenada com a Google e a Shadowserver Foundation, derrubou simultaneamente toda a infraestrutura de comando e controle do GlassWorm, campanha de supply chain ativa desde o início de 2025 que comprometeu extensões do VS Code Marketplace e do Open VSX, além de pacotes npm e Python, para roubar credenciais de desenvolvedores, tokens de GitHub, NPM e OpenVSX e carteiras de criptomoedas em uma operação atribuída a cibercriminosos provavelmente baseados na Rússia.

O que aconteceu

A ação coordenada desmantelou todos os canais de comando e controle (C2) associados ao GlassWorm, encerrando uma campanha persistente que utilizava o ecossistema de extensões e pacotes como vetor de entrega contra desenvolvedores de software. Segundo a CrowdStrike, os operadores miravam de forma sistemática uma população com acesso privilegiado a repositórios de código-fonte, plataformas em nuvem, pipelines de CI/CD e registries de pacotes — o que amplifica drasticamente o potencial de propagação de qualquer compromisso bem-sucedido.

O movimento ilustra uma tendência crescente: ataques que partem de uma única estação de trabalho comprometida para impactar milhares de organizações downstream. Ao subverter componentes legítimos do ecossistema de desenvolvimento, o GlassWorm transformou ferramentas confiáveis em vetores de entrega de malware, em uma estratégia que mistura engenharia social, persistência e abuso de infraestrutura pública de distribuição.

A operação envolveu a Shadowserver Foundation, organização sem fins lucrativos que historicamente atua em sinkholing de botnets, e a Google, cujo programa de inteligência de ameaças vem ganhando protagonismo em derrubadas conjuntas com vendors privados nos últimos anos.

Como o ataque funciona

O GlassWorm opera como uma campanha multifacetada. A principal porta de entrada são extensões trojanizadas do Visual Studio Code publicadas tanto no Microsoft VS Code Marketplace quanto no Open VSX — o registry alternativo usado por forks do VS Code. Essa abordagem permite atingir não apenas usuários do editor da Microsoft, mas também ambientes como Cursor, Positron, Windsurf e VSCodium, ampliando consideravelmente a superfície de ataque.

Em paralelo, os operadores introduziram código malicioso em pacotes npm e Python, transformando a cadeia de dependências em mais um canal de entrega. Em iterações mais recentes, o malware passou a implantar um RAT em JavaScript baseado em WebSocket batizado de GlassWormRAT, capaz de roubar dados do navegador e executar código arbitrário no host comprometido — incluindo a instalação de uma extensão maliciosa para o Google Chrome que coleta capturas de tela, teclas digitadas e conteúdo da área de transferência.

Uma vez ativo, o malware varre a máquina em busca de credenciais de desenvolvedor que possam ser usadas para escalar a invasão e perpetuar o ciclo: tokens do GitHub, do NPM e do OpenVSX, além de carteiras de criptomoedas. Esses tokens permitem que o atacante publique novas versões maliciosas de pacotes e extensões em nome do desenvolvedor comprometido, em um movimento de propagação tipicamente associado a worms.

“A barreira para envenenar um pacote ou uma extensão é baixa; o potencial raio de impacto é enorme. Enquanto ambientes de desenvolvimento, pipelines de build e repositórios de código permanecerem subprotegidos, toda organização que consome software herda o risco de todos os que produzem software.”

CrowdStrike, em comunicado sobre a operação

Quem é afetado

Embora o alvo direto seja a comunidade de desenvolvedores, o impacto efetivo se estende a praticamente qualquer organização que consuma bibliotecas open source ou utilize extensões de IDE em ambientes corporativos. Os pontos críticos de exposição incluem:

• Equipes de engenharia que instalam extensões do VS Code ou de seus forks sem revisão prévia.
• Pipelines de CI/CD que executam código de pacotes npm ou Python de forma automatizada.
• Organizações que utilizam tokens de longa duração para automação em GitHub, NPM e OpenVSX.
• Projetos de Web3 e cripto que armazenam carteiras em estações de trabalho de desenvolvimento.
• Empresas que distribuem software downstream, podendo se tornar vetores involuntários.

Análise

A derrubada do GlassWorm chega em um momento simbólico para a discussão sobre supply chain security. Nos últimos anos, casos como SolarWinds, 3CX, Codecov, XZ Utils e os incidentes recorrentes envolvendo pacotes npm maliciosos transformaram a cadeia de software em uma das superfícies de ataque mais consequentes da computação moderna. O GlassWorm reforça duas tendências já bem documentadas: a profissionalização dos operadores e a convergência entre ferramentas de desenvolvimento e infraestrutura crítica.

A atribuição preliminar à Rússia, baseada em pistas como o término de execução em países da CIS e comentários em russo no código, é coerente com o padrão observado em outras campanhas voltadas para ecossistemas open source. Vale notar, no entanto, que a derrubada de infraestrutura raramente significa o fim da ameaça. Operadores resilientes costumam recompor C2s e voltar a operar em semanas — o que torna a higiene contínua de credenciais e a revisão de extensões ações tão importantes quanto a remoção da infraestrutura.

Outro ponto relevante é a evolução técnica do GlassWorm. O uso de um RAT baseado em WebSocket e a instalação de uma extensão maliciosa do Chrome para capturar telas e teclas mostram que o foco deixou de ser apenas o roubo pontual de tokens. A campanha mira persistência prolongada no endpoint do desenvolvedor, com coleta de telemetria capaz de mapear hábitos, projetos sensíveis e acessos privilegiados em nuvem.

Recomendações práticas

• Revise todas as extensões instaladas em VS Code, Cursor, Windsurf, Positron e VSCodium; remova qualquer extensão suspeita ou pouco utilizada.
• Rotacione imediatamente tokens de GitHub, NPM e OpenVSX em estações de trabalho de desenvolvedores que tenham instalado extensões nos últimos meses.
• Adote tokens de curta duração e escopo mínimo, preferindo OIDC ou GitHub Apps a personal access tokens.
• Implemente allowlists de extensões e pacotes em ambientes corporativos, com revisão centralizada.
• Habilite verificação de integridade de pacotes (npm provenance, lockfiles imutáveis) nos pipelines de CI/CD.
• Monitore conexões WebSocket suspeitas saindo de máquinas de desenvolvimento e implemente egress filtering.
• Considere carteiras de cripto em hardware dedicados, fora das estações de desenvolvimento.

Fonte: The Hacker News