Ataque GlassWorm usa tokens roubados do GitHub para injetar malware em projetos Python e React Native
A campanha maliciosa conhecida como GlassWorm entrou em uma nova fase e passou a explorar tokens roubados do GitHub para comprometer em massa repositórios de software, com foco especial em projetos Python. O resultado é um ataque de cadeia de suprimentos com grande alcance, capaz de afetar desde aplicações web em Django até soluções de machine learning, dashboards em Streamlit e pacotes distribuídos em registries como o PyPI.
O método é direto e perigoso: o invasor insere trechos de código malicioso, altamente ofuscados, em arquivos comuns de projetos Python, como `setup.py`, `main.py` e `app.py`. A partir desse momento, qualquer desenvolvedor ou usuário que execute um simples `pip install` a partir de um repositório comprometido, ou que faça o clone e rode a aplicação localmente, acaba ativando o malware sem perceber, transformando ações rotineiras de desenvolvimento em um gatilho de infecção.
Pesquisadores rastreiam essa onda específica de atividade desde 8 de março de 2026. Após se apoderar das contas de desenvolvedores, o grupo por trás do GlassWorm emprega uma técnica sofisticada de manipulação do histórico Git. Eles reaplicam commits aparentemente legítimos sobre a branch principal, inserindo o código malicioso no meio do processo, e finalizam com um `force push`. Assim, mensagens de commit, autor e datas permanecem coerentes, dando a falsa impressão de continuidade e dificultando a identificação de qualquer adulteração visualmente no histórico do repositório.
Essa vertente da campanha, apelidada de ForceMemo, segue uma cadeia de ataque bem definida em quatro etapas. Tudo começa com o comprometimento da máquina do desenvolvedor. Para isso, os criminosos se valem de extensões maliciosas para editores populares como VS Code e Cursor. Essas extensões trazem, embutidos, módulos especializados para roubar credenciais, incluindo tokens de acesso ao GitHub e possivelmente outros segredos usados em pipelines de CI/CD ou automações internas.
Com o token em mãos, os atacantes passam à segunda fase: a modificação em massa de todos os repositórios associados à conta comprometida. O código malicioso, geralmente codificado em Base64, é adicionado ao final de arquivos Python estratégicos. O payload inclui mecanismos para checar o idioma do sistema operacional e evita rodar em ambientes configurados em russo, um padrão já visto em outras campanhas, possivelmente para reduzir risco de atrito com certas jurisdições ou grupos locais.
Um dos elementos mais inusitados do GlassWorm é a forma como ele estrutura seu comando e controle (C2). Em vez de recorrer a servidores dedicados e facilmente rastreáveis, o malware busca instruções no campo “memo” de transações ligadas a uma carteira na blockchain Solana. É ali que ele encontra a URL ou dados necessários para baixar o payload atualizado. Essa abordagem baseada em blockchain oferece resiliência: o operador consegue alterar dinamicamente os pontos de controle apenas movimentando pequenas quantias ou atualizando mensagens nessas transações, sem depender de uma infraestrutura central que possa ser derrubada por autoridades ou bloqueada por listas de reputação.
Uma vez ativado no ambiente da vítima, o código inicial baixa cargas adicionais. Entre elas, aparecem scripts JavaScript criptografados, desenhados para roubar criptomoedas, coletar dados sensíveis e exfiltrar informações da máquina comprometida. Há indícios de que o mesmo endereço de carteira usado para o C2 vem apresentando atividade desde novembro de 2025, o que aponta para um planejamento de longo prazo e um operador experiente, disposto a manter a campanha ativa e evolutiva.
As investigações sugerem também que o grupo responsável está diversificando seus vetores de entrega. Em uma variação mais recente, a distribuição do malware aproveita dependências transitivas em extensões de desenvolvimento. Dessa forma, mesmo que o usuário não instale diretamente um componente malicioso, ele pode ser impactado por uma biblioteca que entra “de carona” em outra dependência aparentemente confiável, aumentando significativamente a superfície de ataque sem exigir interação consciente do alvo.
Outro ponto alarmante é o uso extensivo de técnicas de camuflagem de código. Mais de 150 repositórios no GitHub foram identificados com alterações maliciosas escondidas por meio de caracteres Unicode invisíveis. Esses caracteres podem alterar a forma como o código é interpretado pelo compilador ou interpretador, sem mudar a aparência visual para quem lê no editor. Isso torna a revisão manual extremamente difícil, mesmo para desenvolvedores experientes e para mantenedores atentos.
Em todas essas variantes, a infraestrutura baseada em Solana surge como fio condutor, conectando diferentes ondas da campanha e reforçando a hipótese de um único grupo ou operador por trás da operação. A reutilização de padrões – como a leitura de memos na blockchain e a exclusão de sistemas em russo – sugere uma família de ferramentas mantida e adaptada de forma contínua.
O `force push` aparece como um vetor particularmente crítico nesse contexto. Ao reescrever completamente o histórico do repositório, sem criar pull requests nem eventos claramente visíveis na interface web do GitHub, o invasor contorna fluxos tradicionais de revisão, que costumam depender de PRs, diffs explícitos e pipelines ativados por merges. Em muitos times, alterações diretas na branch principal são raramente auditadas com o mesmo rigor, o que abre espaço para esse tipo de ataque silencioso.
A ofensiva não se limita ao ecossistema Python. A cadeia de suprimentos JavaScript também foi afetada, em especial o universo npm e React Native. Dois pacotes populares – `react-native-international-phone-number` e `react-native-country-select` – tiveram versões maliciosas publicadas diretamente no registro npm, sem que o fluxo normal de release via repositório GitHub fosse seguido. Isso indica que os atacantes, em alguns casos, conseguiram acesso direto às credenciais de publicação no registro de pacotes.
Nessas versões adulteradas, o código malicioso era executado ainda durante o processo de instalação, por meio de scripts `preinstall`. Assim como nas variantes voltadas a projetos Python, o malware fazia checagens de localidade para ignorar sistemas de idioma russo, consultava dados associados a uma carteira Solana para obter instruções atualizadas e, a partir daí, baixava malwares específicos para o sistema operacional em questão.
Um detalhe técnico que demonstra o nível de sofisticação do GlassWorm é a forma como o payload principal é executado em memória. Em sistemas macOS e Linux, o código JavaScript adicional é rodado usando `eval()`, sem gravação de arquivos maliciosos permanentes em disco. Em outros ambientes, é utilizado o `vm.Script` do Node.js como sandbox para interpretação dinâmica. Isso reduz drasticamente os rastros deixados no sistema de arquivos, tornando ineficazes muitas ferramentas de antivírus que se baseiam em varredura estática.
Além disso, o malware implementa um mecanismo de persistência “leve”: ele cria um pequeno arquivo local, usado apenas como marcador, que impede a reexecução do payload por um período de até 48 horas. Essa estratégia diminui a chance de que múltiplas execuções em sequência chamem a atenção de ferramentas de monitoramento comportamental ou de analistas de segurança que estejam examinando logs e eventos anômalos.
No conjunto, a campanha GlassWorm revela uma evolução marcante nos ataques à cadeia de suprimentos de software. Ela combina roubo de credenciais, exploração de confiança entre desenvolvedores, manipulação inteligente do histórico de código, uso criativo de blockchain como backend de comando e controle e técnicas avançadas de ofuscação e evasão. O alvo não é apenas o usuário final, mas todo o ecossistema que confia em bibliotecas, extensões e automações integradas.
Para equipes de segurança e times de desenvolvimento, o caso acende um alerta sobre a necessidade de adotar uma postura mais rigorosa em relação a vários pontos: monitoramento contínuo de repositórios, validação de integridade de código, proteção rígida de tokens e credenciais, além de revisões mais criteriosas de dependências. Ferramentas de análise estática, scanners de supply chain e sistemas de detecção de atividade suspeita em contas de desenvolvedores (como logins anômalos, uso incomum de `force push` e alterações massivas em repositórios) tornam-se peças essenciais na defesa.
Como desenvolvedores podem se proteger na prática
Para reduzir o risco de ser alvo – ou vetor – de campanhas como o GlassWorm, algumas medidas práticas são fundamentais:
1. Proteção de tokens e credenciais
– Habilitar autenticação em dois fatores (2FA) em contas de GitHub e registries de pacotes.
– Usar tokens de acesso com escopo mínimo necessário, e preferir tokens temporários quando possível.
– Rotacionar periodicamente tokens e chaves de publicação, revogando credenciais que não sejam mais utilizadas.
2. Controle rigoroso de extensões e ferramentas
– Instalar extensões de IDE apenas de fornecedores conhecidos e com histórico confiável.
– Revisar permissões e comportamento de plugins de VS Code, Cursor e outros editores, removendo qualquer extensão que não seja estritamente necessária.
– Manter o sistema operacional e o próprio editor sempre atualizados para reduzir superfícies de ataque conhecidas.
3. Boas práticas de Git e revisão de código
– Restringir o uso de `force push` em branches principais, exigindo aprovação e auditoria para esse tipo de operação.
– Habilitar proteções de branch (branch protection rules), impedindo commits diretos na main e exigindo pull requests com revisão obrigatória.
– Utilizar ferramentas que alertem sobre reescrita de histórico, alterações suspeitas em arquivos sensíveis e inclusão de código ofuscado.
4. Verificação de dependências e cadeia de suprimentos
– Adotar soluções de Software Composition Analysis (SCA) para mapear dependências diretas e transitivas, identificando versões maliciosas ou comprometidas.
– Fixar versões (pinning) de dependências críticas e evitar atualizações automáticas sem revisão prévia, especialmente em ambientes de produção.
– Monitorar changelogs, comportamento e reputação de pacotes utilizados, principalmente quando aparecem novas versões “inesperadas” ou mudanças radicais no tamanho do pacote.
5. Auditoria de código e detecção de ofuscação
– Incluir checagens para caracteres invisíveis e manipulações de Unicode em revisões de segurança.
– Adotar scripts ou ferramentas que identifiquem padrões de ofuscação (como longas cadeias Base64, uso excessivo de `eval`, funções anônimas encadeadas, entre outros).
– Criar políticas internas que desencorajem ou restrinjam o uso de ofuscação em código de produção, tornando mais fácil detectar inserções estranhas.
6. Monitoramento comportamental e resposta a incidentes
– Configurar alertas para atividades incomuns em contas de desenvolvedores: logins de regiões diferentes, picos inesperados de commits, mudanças simultâneas em muitos repositórios.
– Manter um plano de resposta a incidentes que inclua: revogação imediata de tokens, rollback de repositórios para versões confiáveis, comunicação com usuários afetados e revisão de pipelines de CI/CD.
– Realizar exercícios periódicos de simulação de incidente (tabletop exercises) para garantir que a equipe saiba o que fazer ao detectar um comprometimento.
Impacto para empresas e para o ecossistema open source
Empresas que dependem intensamente de bibliotecas de terceiros, sejam elas Python, JavaScript ou de outras linguagens, precisam encarar esses ataques como risco estratégico. Um único pacote comprometido em uma dependência crítica pode abrir caminho para roubo de dados, sabotagem de serviços, desvio de ativos digitais (como criptomoedas) e perda de confiança de clientes e parceiros.
Para o ecossistema open source, campanhas como o GlassWorm expõem a fragilidade do modelo de confiança implícita: muitos projetos são mantidos por poucas pessoas, frequentemente sem recursos dedicados à segurança. Isso torna essencial incentivar práticas como: múltiplos mantenedores por pacote crítico, uso de assinaturas digitais para releases, validação automatizada de integridade e documentação clara de processos de publicação.
Caminho adiante
O caso GlassWorm mostra que ataques à cadeia de suprimentos deixaram de ser exceção e se tornaram parte do arsenal padrão de grupos avançados. A combinação de técnicas – desde extensões maliciosas de IDE até uso criativo de blockchain como canal de comando – evidencia que não basta proteger apenas o ambiente de produção: é preciso olhar com a mesma seriedade para o desktop do desenvolvedor, para o pipeline de CI/CD e para cada elo de confiança que conecta código, dependências e distribuição.
Fortalecer esse ecossistema passa por medidas técnicas, culturais e organizacionais: treinar desenvolvedores em segurança, adotar processos de revisão robustos, investir em ferramentas de monitoramento e, sobretudo, assumir que qualquer ponto de confiança pode ser explorado. A partir dessa consciência, fica mais fácil construir defesas em camadas capazes de reduzir o impacto de campanhas complexas como a GlassWorm e aumentar a resiliência de toda a cadeia de software.