Categories: AMEAÇAS ATUAIS

GlassWorm ressurge e compromete mais de 430 repositórios, pacotes e extensões em nova ofensiva supply chain

A campanha GlassWorm voltou em uma nova onda muito mais ampla e preocupante. Pesquisadores de múltiplas empresas identificaram 433 componentes comprometidos em março, espalhados entre repositórios Python e JavaScript no GitHub, extensões para VSCode/OpenVSX e pacotes publicados no npm.

O ponto mais crítico é o encadeamento do ataque: o comprometimento começa em contas e repositórios do GitHub, evolui para a publicação de componentes contaminados em ecossistemas amplamente usados por desenvolvedores e termina com a execução de um stealer em JavaScript capaz de coletar carteiras de criptomoedas, credenciais, tokens de acesso, chaves SSH e dados do ambiente de desenvolvimento.

O que torna esta onda diferente

Desta vez, os pesquisadores correlacionaram a atividade em diferentes plataformas por meio do mesmo endereço na blockchain Solana usado para comando e controle, além de payloads e infraestrutura semelhantes. Segundo os levantamentos divulgados, a ofensiva alcançou:

  • 200 repositórios Python no GitHub
  • 151 repositórios JavaScript/TypeScript no GitHub
  • 72 extensões no ecossistema VSCode/OpenVSX
  • 10 pacotes publicados no npm

Outro elemento relevante é o uso de código ofuscado com caracteres Unicode invisíveis, uma técnica pensada para dificultar inspeção manual e detecção simples durante revisão de código.

Impacto para equipes de desenvolvimento

Na prática, o caso reforça um risco recorrente no supply chain de software: confiar apenas na reputação de um repositório, pacote ou extensão não basta. Uma vez que o componente malicioso seja instalado, a cadeia pode levar ao roubo de segredos, persistência local, comprometimento de pipelines e movimentação lateral a partir do ambiente do desenvolvedor.

Equipes que instalam pacotes diretamente de repositórios clonados ou que dependem de extensões menos auditadas devem revisar históricos de commit, verificar alterações forçadas em branches, procurar por instalações inesperadas do Node.js no diretório do usuário e investigar artefatos suspeitos usados para persistência.

Medidas imediatas recomendadas

  • Revisar projetos clonados e dependências recentemente adicionadas
  • Auditar histórico de commits em busca de force-pushes e datas incoerentes
  • Procurar indicadores de comprometimento e arquivos suspeitos no ambiente do desenvolvedor
  • Rotacionar credenciais, tokens e chaves caso haja qualquer indício de exposição
  • Reforçar validação de origem antes de instalar pacotes, extensões e forks de terceiros

O caso mostra que ataques contra supply chain continuam migrando rapidamente entre registries, marketplaces e repositórios de código, explorando exatamente o ponto em que confiança e velocidade de desenvolvimento costumam se encontrar.

Fonte: BleepingComputer

TheNinja

Recent Posts

Agentes de código escrevem os próprios jogadores e vencem

Em vez de jogar turno a turno, o agente escreve um programa que joga sozinho.…

1 semana ago

Google troca raciocínio por difusão para acelerar busca com IA

Em vez de gastar centenas de tokens de raciocínio a cada consulta, o Google treina…

1 semana ago

Cisco Secure Email Gateway: falha 9.8 sob exploração ativa

Um e-mail comum, processado por um appliance desatualizado, basta para executar comandos como root. A…

1 semana ago

Infostealer AMOS mira credenciais de nuvem no macOS

Análise da Unit 42 mostra o AMOS instalado por páginas que prometem um kit para…

1 semana ago

ClickFix no navegador usa Google Sheets como C2 para roubar cripto

A Cisco Talos rastreou por meses uma operação que convence a própria vítima a injetar…

2 semanas ago

Rootkit PoisonedRefresh injeta web shell na memória do BIG-IP

A Sophos X-Ops dissecou um implante Linux que altera como o Apache enxerga arquivos PHP…

2 semanas ago