Campanha Gheist usa tokens roubados do GitHub em escala, mas esbarra em bloqueio de aprovação

A Wiz Research rastreia a Gheist desde 15 de setembro de 2026. A campanha usa tokens do GitHub comprometidos para criar, em cada repositório acessível pelo token, uma branch ci-sync- mais seis caracteres aleatórios. Nela vai um commit não assinado, com a mensagem "ci: sync config", que adiciona o workflow sync-check.yml. O push dispara o job, que imprime os secrets no log. Depois a ferramenta baixa o log pela API do GitHub e apaga a execução segundos depois. Foram recuperadas mais de 13.500 branches plantadas, de mais de 850 contas.

O truque está no encoding. O GitHub só mascara um secret no log quando ele aparece literalmente, então um valor em base32 sai por inteiro. Com permissions: {} o GITHUB_TOKEN do job fica restrito, mas isso não limita o contexto de secrets. Em repositórios com ambientes de deploy, uma matriz de ambientes também despeja os secrets de produção. Como a exfiltração passa pela API do GitHub, não há domínio do atacante nem conexão de saída para bloquear.

Desde 28 de julho de 2026, o GitHub segura em repositórios públicos as execuções potencialmente maliciosas até um colaborador aprovar. Todas as execuções públicas verificadas pela Wiz ficaram em action_required e o payload não rodou. Essa retenção não vale para repositórios privados nem para o GitHub Enterprise Server, onde os logs de auditoria e o CloudTrail mostram execuções concluídas e assunção de funções AWS a partir das branches. Em ambientes corporativos, a Wiz viu tokens de vários usuários e contas de automação alternados em minutos, clonagem de repositórios privados e, horas depois, uso de credenciais de cloud para enumerar o AWS Secrets Manager.

Há duas variantes. A Tool A usa sufixo hexadecimal e payload simples. A Tool B usa sufixo base36, timeout de 6 minutos e matriz de ambientes. Em 19 de outubro, a B ganhou um job chamado sync-host, em self-hosted runners. Ele varre 31 formatos de token (inclusive chaves de provedores de IA como Anthropic, Hugging Face, Groq e NVIDIA), lê o ambiente dos processos, monta o sistema de arquivos do host via socket do Docker e coleta credenciais de instância AWS e o token de service account do Kubernetes. O job tem bugs: procura o arquivo de chave do runner errado, tem uma regex de credenciais em URL quebrada e não coleta tokens de GCP nem de Azure. Até 24 de outubro, o ataque seguia em andamento e cerca de dois terços das contas já não estavam disponíveis no GitHub.

Para quem opera segurança em organizações com repositórios privados ou GitHub Enterprise Server, o bloqueio de aprovação não protege. O que decide o estrago é o token roubado, então a higiene de credenciais de desenvolvedores (infostealers, PATs de longa duração) pesa mais que qualquer regra de rede. Como não há egress para monitorar, a detecção vai para auditoria do GitHub e logs de cloud, em especial assunções de função OIDC vindas de branches ci-sync-*. Segundo a fonte, apagar a branch ou a execução não desfaz a exposição: é preciso rotacionar tudo que o repositório alcançava.