Botnet Glassworm desativada após derrubada de infraestrutura C2 resiliente

A botnet Glassworm chamou atenção por uma característica técnica incomum: em vez de depender de um único servidor de comando e controle (C2), seus operadores distribuíram as instruções por quatro canais diferentes e legítimos. Eram eles os campos de memo da blockchain Solana, a rede BitTorrent DHT, títulos de eventos do Google Calendar com caminhos codificados em Base64 e conexões diretas a servidores VPS. Essa arquitetura permitia que, se um canal fosse bloqueado, os hosts infectados fizessem failover automático para os demais.

A operação conjunta de CrowdStrike, Google e The Shadowserver Foundation só funcionou porque os quatro canais foram cortados de forma simultânea e coordenada. Uma derrubada parcial não bastaria, já que as camadas de indireção criadas pelos operadores foram projetadas justamente para sobreviver a ações isoladas. Com a infraestrutura desativada, as máquinas comprometidas não conseguem mais receber novas instruções nem novos payloads.

A Glassworm representa uma tendência preocupante: malware que mira diretamente o ambiente de desenvolvedores. Ativa desde outubro de 2025, ela usava extensões maliciosas de OpenVSX e VS Code, repositórios no GitHub e pacotes npm para roubar carteiras de criptomoedas e credenciais. Comprometer um desenvolvedor pode abrir caminho para a cadeia de suprimentos de software inteira, atingindo muito além da vítima inicial.

O caso também mostra como atacantes estão abusando de serviços legítimos (blockchain, calendários, redes P2P) como canais de comando e controle, dificultando a detecção por filtros tradicionais de rede. A derrubada bem-sucedida demonstra que esse tipo de resiliência só é vencido com cooperação entre múltiplas organizações agindo ao mesmo tempo.

Para quem desenvolve, a recomendação prática é verificar se há máquinas fazendo beaconing para o sinkhole operado pela CrowdStrike no endereço 164.92.88.210, sinal claro de infecção. As regras YARA publicadas devem ser aplicadas para confirmar comprometimentos antes de remediar.

A remediação envolve remover as extensões e pacotes maliciosos dos endpoints afetados. Vale revisar com cuidado as extensões instaladas no editor, auditar dependências npm e tratar qualquer credencial ou carteira que tenha passado por uma máquina suspeita como potencialmente vazada, rotacionando segredos quando necessário.