ForceMemo a campanha que reesscreve a história do GitHub rouba Tokens e difunde malware através de pacotes Python

Há alguns meses, a comunidade de desenvolvedores começou a notar algo inquietante: pacotes e projetos no GitHub que, sem aparentes mudanças visíveis, estavam incorporando fragmentos de código prejudicial. A pesquisa tem evidenciado uma campanha sofisticada que fornece técnicas já conhecidas do grupo GlassWorm, mas que agora opera com uma variante centrada em forçar o histórico de repositórios para inserir cargas úteis maliciosas em projetos Python. Os relatórios técnicos publicados por equipes de pesquisa como StepSecurity e análise complementar de grupos como Socket Eles desenham um panorama preocupante para a integridade do código aberto.

O vetor inicial desta operação não é um ataque direto ao GitHub, mas a infiltração dos ambientes de desenvolvimento. Mediante extensões maliciosas para editores como o VS Code e ferramentas de auto-completado, instala-se um componente que busca e exfiltra credenciais: tokens do GitHub que permitem atuar como se fossem os próprios desenvolvedores. Com essas credenciais em mão, o ator remove as barreiras normais do fluxo de trabalho. Em vez de criar um pull request ou adicionar um commit visível, a intrusão reesscreve a história do repositório através de um rebase e um force-push, de modo que os meta- dados - o autor, a data e a mensagem do commit - parecem genuínos e não há vestígios evidentes na interface pública.

Uma vez conseguida a porta aberta, os atacantes buscam arquivos concretos que normalmente são executados ou embalados em projetos Python —nomes habituais como setup.py, main.py ou app.py — e acrescentam ao final do arquivo uma carga injetada codificada em Base64. Esse código ofuscado não é um simples script: contém verificações para detectar ambientes que utilizem a localização russa e, se essa configuração for detectada, evita executar, uma técnica habitual para evitar análises em determinadas jurisdições. Em qualquer outro caso, o fragmento descodifica instruções que apontam para um endereço na rede de Solana; o campo memo de uma transação atua como canal para que o atacante atualize dinâmicamente o URL a partir da qual o malware irá baixar componentes adicionais, incluindo JavaScript criptografada desenhada para sustrair criptomoedas e dados do sistema infectado.

A cronologia que reportam os pesquisadores mostra que a infraestrutura de controle levava operando meses antes de serem detectadas as primeiras inserções em repositórios. Os registros na cadeia de blocos indicam transações nessa direção de Solana que datam do final de novembro de 2025, enquanto as primeiras injeções no GitHub foram identificadas a partir de 8 de março de 2026. Além disso, o padrão de operação revela que o ator vai mudando frequentemente o URL da carga útil, o que complica a defesa se apenas se bloqueia uma direção concreta.

O que faz singular a esta variante — apoiado por alguns pesquisadores como ForceMemo — é a combinação de várias técnicas: uso de extensões maliciosas para roubar segredos, exploração de tokens válidos para reescrever a história git preservando metadados legítimos, e o emprego da cadeia de blocos como canal de comando e controle. Socket também destacou que a campanha melhorou sua capacidade de sobrevivência ao distribuir malware de forma transitiva por metadados de pacotes de extensões, ou seja, apoiando-se em mecanismos de empacotamento e dependências para propagar a carga maliciosa através do ecossistema de extensões.

Para aqueles que mantêm software aberto ou dependem de livrarias de terceiros, as implicações são claras: um desenvolvedor infectado pode, sem deixar traços óbvios, propagar código malicioso a projetos consumidos por milhares de usuários. Qualquer operação que faça um pip install a partir de um repositório comprometido ou que clone e execute código sem as devidas verificações pode desencadear a execução do malware. Diante deste risco, as boas práticas de segurança do GitHub – como a rotação de tokens, a revisão de permissões concedidas a aplicações e a ativação de autenticação multifator – recuperam todo o seu valor; o GitHub mantém documentação útil sobre como gerenciar e proteger tokens pessoais em sua plataforma em sua plataforma seus guias oficiais.

Além disso, a prevenção no plano do repositório deve incluir políticas que dificultem um force-push não autorizado. A proteção de ramos, revisões obrigatórias de código e fluxos de integração contínua que valdem a integridade do histórico e as assinaturas de commit são barreiras eficazes para detectar alterações indesejadas; o GitHub oferece orientações para configurar ramos protegidos em sua documentação. No âmbito do empacotamento em Python, é prudente assumir que executar diretamente programas baixados de repositórios não verificados implica risco; a comunidade e o PyPI têm vindo a reforçar práticas de segurança que podem ser consultadas em os regimes PyPI.

Se a sua organização desenvolver ou consumir pacotes Python, convém rever tokens e sessões ativas ligados a contas de manutenção, auditar commits recentes à procura de inserções suspeitas e estabelecer regras que impeçam reescrever a história do ramo principal sem revisões adicionais. As medidas reativas incluem revogar credenciais comprometidas, forçar rotação de tokens e realizar análise forense dos ambientes de desenvolvimento para detectar extensões ou processos atípicos. Mesmo com controles técnicos em andamento, a consciência da equipe - não abrir extensões de procedência duvidosa, verificar a reputação de pacotes e evitar executar código às cegas - continua sendo uma defesa essencial.

Em um plano mais amplo, a ForceMemo mostra algo que a segurança do software tem alertado há anos: a cadeia de fornecimento do software é tão fraca quanto o seu elo mais vulnerável. Um único desenvolvedor com o ambiente comprometido pode converter um projeto confiável em um vetor de ataque distribuído. A comunidade precisa de combinar controlos técnicos —proteção de ramos, auditoria de permissões, digitalização automática de repositórios — com processos organizacionais que reduzam a exposição de segredos e melhorem a detecção precoce.

Para os curiosos que queiram aprofundar os achados técnicos, as análises publicadas pelos equipamentos de resposta e detecção são recursos recomendados: o relatório de StepSecurity sobre esta campanha está disponível em seu blog, e o trabalho de Socket que descreve a distribuição transitiva através de extensões pode ser consultado em seu artigo técnico. Manter-se informado e aplicar controlos preventivos é, hoje mais do que nunca, a melhor ferramenta para proteger projetos e usuários frente a campanhas que combinam engenharia social, abuso de plataformas e técnicas de ofuscação cada vez mais maduras.