Campanha Gheist usa tokens roubados do GitHub para extrair secrets, mas esbarra nos controles de aprovação

A Wiz Research rastreia desde 15 de setembro de 2026 a campanha Gheist, que abusa em massa de tokens comprometidos do GitHub. O ataque commita um workflow chamado sync-check em todo repositório acessível pelo token, numa branch ci-sync- mais seis caracteres aleatórios. O workflow imprime os secrets no próprio log, o atacante baixa o log pela API e apaga a execução segundos depois. Foram recuperadas mais de 13.500 branches plantadas, em mais de 850 contas.

O truque técnico é simples. O GitHub só mascara secrets nos logs quando aparecem literalmente, e um valor codificado em base32 passa direto. Além disso, permissions: {} limita o GITHUB_TOKEN do job, mas não o contexto de secrets. Com ambientes de deployment, os secrets de produção também saem. Como tudo trafega 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 execuções suspeitas em repositórios públicos até a aprovação de um colaborador, e todas as execuções públicas verificadas pela Wiz ficaram em action_required. Essa trava não vale para repositórios privados nem para GitHub Enterprise Server. Lá, os logs de auditoria mostram execuções concluídas e apagadas pelo user agent gheist, e o CloudTrail registrou workflows assumindo roles na AWS. Em ambiente corporativo, a Wiz viu clonagem de repositórios privados e, horas depois, enumeração do AWS Secrets Manager com credenciais da mesma organização.

Gheist não é o primeiro episódio do tipo no histórico do CEVIU. Em 22 de maio de 2026, a matéria "Backdooring em Massa de Repositórios GitHub via CI Workflows" tratou de uma campanha que injetou 5.718 commits maliciosos em 5.561 repositórios com workflows de GitHub Actions para exfiltrar segredos de CI e credenciais de nuvem. A mecânica é parecida, mas a Gheist troca o payload em base64 por um dump de secrets em log. Em 12 de outubro de 2026, o CEVIU noticiou a campanha GhostAction; a Wiz esclarece que a Gheist é distinta dela, com outros arquivos de workflow e outro destino de exfiltração.

Para quem opera TI corporativa, a leitura é que a proteção de repositórios públicos não cobre o ambiente privado. Se sua organização depende de repositórios privados ou GitHub Enterprise Server, a trava de aprovação não ajuda. O ponto de controle passa a ser o token: tokens pessoais de longa duração, OIDC sem escopo por branch e runners self-hosted persistentes ampliam o dano. Rotacionar secrets depois do incidente é obrigatório, porque apagar a branch não desfaz a exposição.