Campanha Gheist usa tokens roubados do GitHub para coletar segredos de repositórios em massa

A empresa de segurança em nuvem Wiz vem rastreando uma campanha de ataque automatizada, chamada Gheist, que usa tokens de acesso roubados do GitHub para extrair sistematicamente segredos de repositórios privados e ambientes corporativos do GitHub. A Wiz recuperou mais de 13.500 branches maliciosos plantados em mais de 850 contas comprometidas desde que começou a rastrear a campanha em 15 de setembro de 2026, e até 24 de outubro a operação ainda estava ativa e evoluindo.

O nome vem da string de user agent «gheist» que a ferramenta automatizada dos atacantes envia com cada requisição à API do GitHub, segundo o relatório publicado em 26 de outubro pelo The Hacker News.

Como o ataque extrai segredos sem um servidor de comando

O mecanismo do Gheist é construído para não deixar nada que os atacantes possam bloquear. Usando um token roubado, a ferramenta enumera cada repositório que esse token pode acessar. Para cada um, cria um branch com um nome como ci-sync- seguido de seis caracteres aleatórios, depois faz commit de um único arquivo — .github/workflows/sync-check.yml — com a mensagem de commit inócua «ci: sync config». O commit permanece sem assinatura.

Fazer push desse branch aciona automaticamente o workflow, que simplesmente imprime cada variável de ambiente e segredo que o job tem permissão de ler. Para contornar o mascaramento automático de logs do GitHub para padrões de segredos conhecidos, a ferramenta codifica a saída em base32 antes de imprimi-la. O atacante então baixa o log resultante através da própria API do GitHub — o que significa que os dados roubados nunca precisam saír por um servidor externo que um defensor possa detectar ou bloquear — e apaga a execução do workflow segundos após recuperá-lo.

Escala e consequências reais

A Wiz não revelou quantas organizações tiveram segredos realmente expostos, mas confirma que a campanha teve sucesso tanto contra repositórios privados quanto implantações completas do GitHub Enterprise Server, não apenas projetos pessoais públicos.

A proteção existente do GitHub cobre apenas metade do problema

Desde 28 de julho, o GitHub exige que um colaborador com acesso de escrita aprove manualmente execuções de workflow marcadas como suspeitas — uma mudança que a Wiz confirmou ter parado todas as tentativas do Gheist testadas contra repositórios públicos. No entanto, essa exigência de aprovação não se estende a repositórios privados ou ao GitHub Enterprise Server, que é exatamente onde o Gheist teve seus sucessos documentados.

Resposta recomendada

A Wiz recomenda que as organizações busquem em seus logs de auditoria branches que correspondam ao padrão de nomenclatura ci-sync- e revisem quaisquer assunções de papel OIDC vinculadas a esses branches. Qualquer segredo acessível a partir de um repositório afetado deve ser tratado como comprometido e rotacionado imediatamente.