A segurança no GitHub Actions tornou-se um ponto crítico para empresas que utilizam automação no desenvolvimento, na integração contínua e na entrega de software. A campanha maliciosa Gheist, identificada pela empresa de segurança Wiz, chama a atenção para um problema especialmente preocupante: criminosos podem aproveitar tokens de acesso comprometidos e os próprios mecanismos de automação do GitHub para extrair credenciais armazenadas em repositórios privados, ampliando o alcance de uma invasão sem depender de uma vulnerabilidade tradicional na plataforma.
O ataque explora uma combinação de permissões excessivas, fluxos de trabalho maliciosos e técnicas de codificação capazes de contornar o mascaramento automático de informações sensíveis nos registros de execução. Dependendo da configuração do ambiente, o comprometimento pode ultrapassar o repositório original e alcançar infraestrutura corporativa, serviços de nuvem e máquinas utilizadas para executar tarefas de integração contínua.
O aspecto mais importante é que as proteções do GitHub Actions não oferecem a mesma resposta em todos os cenários. Mecanismos destinados a interromper execuções suspeitas em repositórios públicos não devem ser interpretados como uma garantia de proteção equivalente para repositórios privados e instalações do GitHub Enterprise Server. Para equipes de desenvolvimento e administradores de infraestrutura, compreender essa diferença é essencial para identificar possíveis comprometimentos e reduzir o impacto de credenciais roubadas.
Como opera a campanha Gheist no GitHub Actions
A campanha Gheist utiliza credenciais válidas para interagir com a infraestrutura do GitHub de maneira aparentemente legítima. Em vez de depender exclusivamente da exploração de uma falha de software, os operadores abusam das permissões concedidas aos tokens comprometidos para modificar repositórios e introduzir tarefas automatizadas capazes de acessar informações sensíveis.
Essa abordagem representa um desafio para as equipes de segurança porque as operações maliciosas podem se misturar às atividades normais de desenvolvimento. A criação de branches, a alteração de arquivos de configuração e a execução de pipelines são tarefas comuns em projetos que utilizam integração contínua. A diferença está no conteúdo das alterações e na finalidade das execuções.
Na sequência atribuída à campanha, os invasores criam branches com nomes que seguem o padrão ci-sync- e introduzem um arquivo de fluxo de trabalho chamado .github/workflows/sync-check.yml. Esse arquivo permite acionar o GitHub Actions para executar comandos no contexto do repositório comprometido.
O fluxo de trabalho malicioso busca acessar variáveis de ambiente e informações sensíveis disponíveis durante a execução. Dependendo das permissões e da configuração do pipeline, esses dados podem incluir tokens, credenciais de serviços externos e outros segredos utilizados pela automação.
Outro comportamento relevante é a exclusão rápida dos registros de execução. Ao tentar remover os logs logo após a atividade, os operadores dificultam a investigação posterior e reduzem a quantidade de evidências imediatamente disponíveis na interface do GitHub.
A exclusão de registros, entretanto, não deve ser considerada uma forma garantida de apagar todos os vestígios. Eventos de auditoria, registros externos, alertas de segurança e telemetria de infraestrutura podem preservar informações úteis para reconstruir a sequência do ataque.
Como o base32 contorna o mascaramento de segredos
Um dos aspectos mais importantes dessa operação envolve o mecanismo de ocultação de informações sensíveis do GitHub Actions. A plataforma procura identificar determinados valores confidenciais e substituí-los por marcadores como *** nos registros de execução, reduzindo a possibilidade de exposição acidental de credenciais.
Esse recurso, porém, não equivale a um sistema completo de prevenção contra exfiltração. O mascaramento depende do reconhecimento dos valores que devem permanecer ocultos e não impede que um processo malicioso leia, transforme ou envie esses dados para outro destino.
Na técnica atribuída à campanha, os segredos são convertidos para base32, uma representação textual que transforma os dados em uma sequência diferente da credencial original. Como o valor exibido já não corresponde necessariamente à string cadastrada para mascaramento, o mecanismo pode deixar de reconhecê-lo e permitir que a representação codificada apareça nos logs.
A diferença é importante: base32 é uma codificação, não uma criptografia. Ela não protege o conteúdo contra quem consegue decodificar a sequência. Quando uma credencial é transformada dessa maneira, sua representação pode continuar permitindo a recuperação do valor original.
O problema não significa que o GitHub Actions seja incapaz de mascarar segredos em qualquer circunstância. Significa que o mascaramento não deve ser tratado como uma fronteira de segurança capaz de impedir um invasor que já controla um processo autorizado a acessar as credenciais.
Por isso, equipes de DevSecOps precisam evitar a impressão desnecessária de variáveis sensíveis, limitar os dados disponibilizados a cada tarefa e monitorar o comportamento dos fluxos de trabalho. Um segredo que aparece em um log deve ser considerado potencialmente comprometido, mesmo que o registro tenha sido removido posteriormente.
Por que repositórios privados e o GitHub Enterprise Server exigem atenção
A distinção entre repositórios públicos e privados é central para compreender o risco. O GitHub aplica controles de segurança e mecanismos de proteção que podem interromper determinadas execuções suspeitas em repositórios públicos. Esses mecanismos, entretanto, não representam uma barreira universal contra fluxos de trabalho maliciosos.
Em ambientes privados, a presença de uma credencial com permissão de escrita pode ampliar significativamente o impacto de um comprometimento. Se o invasor consegue modificar arquivos de workflow e iniciar execuções que têm acesso aos segredos do projeto, ele pode transformar uma permissão aparentemente limitada em um caminho para extrair informações mais valiosas.
Isso não significa que qualquer token de escrita tenha acesso irrestrito a todos os segredos de uma organização. O alcance depende das permissões efetivas, das configurações do repositório, dos ambientes de implantação e das restrições aplicadas aos fluxos de trabalho. O risco surge quando essas camadas permitem que uma alteração maliciosa seja executada com acesso a credenciais que deveriam estar protegidas.
O GitHub Enterprise Server merece atenção especial porque instalações corporativas podem apresentar diferenças de configuração, versão, políticas e controles em relação ao serviço hospedado pelo GitHub. Organizações que administram suas próprias instâncias precisam verificar quais proteções estão disponíveis e efetivamente habilitadas, sem presumir que os mecanismos de detecção de ambientes públicos também funcionarão de maneira idêntica em sua infraestrutura.
A medida preventiva mais importante é reduzir a capacidade de um único token comprometido de alterar código, executar tarefas privilegiadas e acessar segredos simultaneamente. Permissões mínimas, revisão de alterações e separação entre desenvolvimento e implantação diminuem a possibilidade de uma credencial roubada se transformar em um incidente de maior escala.
O risco de invasão lateral na nuvem e em runners auto-hospedados
O roubo de segredos armazenados no GitHub pode ser apenas a primeira etapa de uma invasão mais ampla. Em ambientes corporativos, pipelines de CI/CD frequentemente possuem permissões para publicar aplicações, acessar bancos de dados, consultar serviços internos e interagir com provedores de nuvem.
A campanha Gheist demonstra como credenciais extraídas de um repositório podem servir de ponto de partida para movimentação lateral. A pesquisa da Wiz identificou atividades posteriores nas quais credenciais de uma organização foram utilizadas para consultar o AWS Secrets Manager, indicando que o impacto pode ultrapassar o ambiente de desenvolvimento.
Como o OpenID Connect pode ampliar o impacto
Muitas organizações utilizam OpenID Connect (OIDC) para permitir que o GitHub Actions obtenha credenciais temporárias da Amazon Web Services (AWS). Essa abordagem é geralmente preferível ao armazenamento de chaves permanentes, pois reduz a necessidade de manter credenciais de longa duração em segredos do repositório.
Entretanto, o OIDC não elimina os riscos quando um fluxo de trabalho malicioso consegue solicitar um token e atende às condições de confiança configuradas na nuvem. Se a política de confiança da AWS aceitar solicitações originadas de branches não protegidas, repositórios inadequados ou contextos excessivamente abrangentes, um invasor poderá tentar assumir uma função autorizada.
O risco aumenta quando essa função possui acesso a serviços sensíveis, como o AWS Secrets Manager, buckets do S3 ou recursos administrativos. Uma credencial temporária também pode causar danos significativos se suas permissões forem excessivas.
As equipes devem examinar os eventos do AWS CloudTrail para identificar tentativas de assumir funções associadas a fluxos de trabalho suspeitos. A presença de referências a branches com o padrão ci-sync- nos dados de identidade disponíveis pode ajudar a relacionar uma operação na AWS a uma execução maliciosa no GitHub.
As políticas de confiança precisam restringir o acesso a identidades, repositórios, branches e ambientes autorizados. Quando aplicável, funções destinadas à produção devem exigir ambientes protegidos e aprovação antes da implantação.
Por que os self-hosted runners são especialmente sensíveis
A evolução observada na campanha acrescenta outra preocupação: a tentativa de executar tarefas em self-hosted runners, ou executores auto-hospedados. Diferentemente dos executores hospedados pelo GitHub, essas máquinas pertencem ou são administradas pela organização e podem ter acesso direto à rede interna.
Segundo a análise da Wiz, uma variante do ataque introduziu um segundo trabalho, identificado como sync-host, direcionado a esses executores. A rotina procurava informações sobre o sistema, arquivos de configuração, variáveis de ambiente, históricos de comandos e credenciais armazenadas em diretórios acessíveis.
A pesquisa também identificou tentativas de localizar chaves privadas, arquivos .env, estados do Terraform, credenciais de provedores de inteligência artificial e arquivos de autenticação de ferramentas de automação. Outros alvos incluíam tokens de contas de serviço do Kubernetes e credenciais associadas a funções de instância da AWS.
O acesso ao socket do Docker representa um agravante. Quando um executor permite que processos não confiáveis controlem o daemon do Docker, essas tarefas podem obter privilégios muito superiores aos previstos, dependendo da configuração do host.
A campanha também criou arquivos auxiliares com os nomes .gdmp_pat, .gdmp_patg e .gdmp_sweep, além de registrar marcadores que começam com ===== gdmp-pivot:. Esses elementos são indicadores relevantes para a investigação.
A Wiz identificou problemas de implementação nessa variante, incluindo falhas em algumas rotinas de coleta. Isso não torna o ataque inofensivo: versões posteriores podem corrigir esses problemas.
Se uma branch maliciosa chegou a executar tarefas em um runner auto-hospedado, considere o host potencialmente comprometido. O procedimento de resposta deve incluir o isolamento da máquina, a investigação de credenciais acessíveis e a avaliação de possíveis acessos à rede corporativa.
Como detectar e auditar um possível comprometimento
A identificação da campanha exige correlacionar eventos do GitHub com informações de infraestrutura. Como os operadores tentam apagar rapidamente os registros das execuções, a ausência de um workflow na interface não comprova que ele nunca existiu.
A Wiz informou ter recuperado mais de 13.500 branches maliciosas associadas a mais de 850 contas comprometidas. Esses números demonstram a escala da operação, mas não representam necessariamente o total de vítimas ou o número de organizações afetadas.
A campanha estava em evolução na data de publicação da análise, em 25 de outubro de 2026. Por isso, os indicadores conhecidos devem ser utilizados em conjunto, e não como uma lista definitiva de todas as variantes possíveis.
Indicadores de comprometimento para investigar
A equipe de segurança deve começar pelos seguintes sinais:
- Branches suspeitas: procure nomes que correspondam ao padrão
^ci-sync-[0-9a-z]{6}$. O sufixo contém seis caracteres alfanuméricos, mas a ausência desse padrão não exclui outras variantes. - Arquivo de workflow: investigue a inclusão inesperada de
.github/workflows/sync-check.yml, principalmente quando for a única alteração em uma branch recém-criada. - Mensagem de commit: procure commits com a mensagem
ci: sync config, especialmente quando não houver solicitação legítima correspondente. - Agente de usuário: pesquise registros de API que contenham o identificador
gheistno campo de agente de usuário, quando essa informação estiver disponível. - Execuções apagadas: identifique workflows que foram concluídos e excluídos em um intervalo muito curto, particularmente quando executados em branches suspeitas.
- Marcadores de coleta: procure a string
===== gdmp-pivot:nos registros de tarefas e os arquivos.gdmp_pat,.gdmp_patge.gdmp_sweepnos sistemas que executam pipelines.
A investigação também pode utilizar os identificadores de conteúdo dos arquivos maliciosos divulgados pela Wiz. Os seguintes hashes SHA-1 correspondem a variantes conhecidas do workflow:
| Variante identificada | Hash do conteúdo |
|---|---|
| Versão inicial | f3da2b8b357dcda02fd455d314be2a95007516a6 |
| Versão com limite de execução | d09535857a741bbb976bdc084a9a021713133291 |
| Versão com separador adicional | 1dc5af9cce950aad1eb1546ecce8565b117540c4 |
| Versão com tarefa para runner auto-hospedado | c665b778b2d822453293003e7ca0bbb2cb08e39d |
Esses identificadores ajudam a encontrar arquivos conhecidos, mas não devem ser usados isoladamente. Variantes que incluem configurações específicas dos ambientes de implantação podem apresentar hashes diferentes.
Auditoria no GitHub e na infraestrutura de nuvem
Nos registros de auditoria do GitHub, procure a criação de branches suspeitas, commits não reconhecidos, alterações em arquivos de workflow, execuções inesperadas e exclusões rápidas de registros. Correlacione esses eventos com a identidade responsável pela alteração e verifique se a atividade corresponde a uma tarefa autorizada.
Se a organização utiliza AWS, examine o CloudTrail em busca de chamadas incomuns para assumir funções e consultar o Secrets Manager. Verifique especialmente operações que possam ter ocorrido depois de uma execução suspeita do GitHub Actions.
Também é importante revisar os registros de autenticação de contas humanas e de automação. Uma mesma credencial comprometida pode ser utilizada em diversos repositórios, e a atividade de outros agentes maliciosos pode coincidir com a campanha Gheist.
Nos executores auto-hospedados, examine os arquivos e marcadores descritos anteriormente, os processos executados, os acessos ao Docker e as credenciais que estavam disponíveis durante o job.
Por fim, verifique se houve alterações não autorizadas no código, nos arquivos de configuração e nas dependências dos projetos. O roubo de segredos não é o único risco: uma credencial comprometida também pode ser usada para preparar futuras alterações maliciosas na cadeia de fornecimento de software.
Ações imediatas de contenção e mitigação de segurança
Se a auditoria encontrar indicadores associados à campanha Gheist, a organização deve tratar o caso como um incidente de segurança, priorizando a contenção e a invalidação das credenciais potencialmente expostas. Excluir a branch maliciosa ou apagar os registros de execução não elimina o risco de utilização dos segredos já extraídos.
As medidas a seguir ajudam a reduzir o impacto e evitar novas explorações.
1. Revogue tokens comprometidos e investigue as contas
Identifique os tokens de acesso pessoal (PATs) utilizados para criar as branches e introduzir os workflows suspeitos. Revogue as credenciais comprometidas e examine a atividade recente das contas associadas.
Se houver suspeita de que o token foi roubado por um malware do tipo infostealer, investigue também o dispositivo do usuário. Revogar a credencial sem verificar a origem do comprometimento pode deixar outras sessões, tokens ou segredos expostos.
Sempre que possível, substitua PATs de longa duração por credenciais de menor privilégio e curta duração, como tokens de instalação de aplicativos do GitHub, adequados à necessidade operacional.
2. Faça a rotação de todos os segredos acessíveis
Considere comprometidos os segredos de repositório, organização e ambientes de implantação que poderiam ter sido acessados pelo workflow malicioso.
A rotação deve abranger, conforme o ambiente, chaves de API, credenciais de banco de dados, tokens de serviços externos, chaves privadas e credenciais utilizadas em implantações. Se uma credencial foi compartilhada entre vários projetos, avalie todos os sistemas que dependem dela.
Não se limite a substituir o valor armazenado no GitHub. Revogue a credencial antiga no serviço que a emitiu, confirme que a nova está em uso e verifique os registros de utilização da anterior.
3. Isole e reconstrua os runners afetados
Se uma execução suspeita ocorreu em um self-hosted runner, retire o executor da operação e preserve as evidências necessárias para a investigação.
Avalie o acesso a arquivos locais, credenciais de nuvem, tokens de Kubernetes e sockets do Docker. Quando houver indícios de comprometimento do host, prefira reconstruí-lo a partir de uma imagem confiável, em vez de simplesmente reiniciar os serviços.
Também é recomendável utilizar executores efêmeros, destruídos após cada tarefa, separar jobs confiáveis de tarefas que processam código não confiável e evitar que workflows tenham acesso irrestrito à rede interna.
4. Reforce as permissões e a proteção dos fluxos de trabalho
Revise as permissões dos tokens, as regras de proteção de branches e as condições necessárias para modificar arquivos em .github/workflows/.
A permissão de escrita em um repositório não deve implicar, sem avaliação adicional, a possibilidade de executar código privilegiado ou acessar segredos de produção. Exija revisão das alterações relevantes e restrinja a execução de tarefas de implantação a branches e ambientes autorizados.
Para segredos de produção, configure ambientes protegidos com revisores obrigatórios, quando disponíveis, e restrições explícitas sobre quais branches podem iniciar implantações.
5. Endureça a integração entre GitHub Actions e AWS
Revise as políticas de confiança do OpenID Connect (OIDC) e as permissões das funções assumidas pelos workflows. Restringir o acesso a repositórios, branches e ambientes autorizados reduz o risco de que um pipeline introduzido por um invasor consiga obter credenciais de nuvem.
Aplique o princípio do menor privilégio às funções da AWS. Um workflow destinado a publicar uma aplicação não deve receber automaticamente permissões para administrar recursos ou consultar todos os segredos da organização.
Quando houver suspeita de uso indevido, examine os eventos do CloudTrail, identifique as sessões afetadas e revogue ou substitua as credenciais conforme os procedimentos do provedor. A contenção deve considerar tanto o acesso inicial quanto as possíveis atividades posteriores.
6. Não aprove execuções suspeitas e preserve as evidências
Se o GitHub mantiver uma execução suspeita aguardando aprovação, não autorize sua execução. Investigue a origem da alteração antes de permitir que o workflow continue.
A análise da Wiz indica que um mecanismo de aprovação introduzido pelo GitHub em julho de 2026 bloqueou as execuções da campanha examinadas em repositórios públicos. Essa proteção, entretanto, não deve ser presumida como disponível em condições equivalentes nos repositórios privados e no GitHub Enterprise Server.
Preserve os registros de auditoria, os metadados dos commits, as informações de autenticação e os eventos da infraestrutura de nuvem. Centralizar esses dados em uma plataforma de monitoramento externa ajuda a reduzir a dependência dos registros disponíveis no próprio repositório.
A segurança em pipelines CI/CD exige vigilância ativa
A campanha Gheist evidencia como credenciais roubadas podem transformar ferramentas legítimas de desenvolvimento em instrumentos de extração de dados. Em vez de depender exclusivamente de uma falha de software, os invasores exploram permissões existentes, introduzem workflows maliciosos e aproveitam o acesso concedido à automação para alcançar segredos que podem ter valor muito maior do que o token inicial.
O uso de base32 para contornar o mascaramento dos logs reforça uma lição fundamental: ocultar informações na interface não equivale a impedir sua extração. A proteção efetiva depende de limitar o acesso aos segredos, restringir a execução de código, monitorar alterações e estabelecer fronteiras claras entre repositórios, ambientes de implantação e infraestrutura corporativa.
O risco é ainda maior quando os pipelines possuem acesso a AWS, Kubernetes e runners auto-hospedados. Nesses cenários, uma invasão inicialmente restrita ao ambiente de desenvolvimento pode evoluir para o comprometimento de sistemas e serviços essenciais.
Para desenvolvedores, administradores de sistemas e equipes de DevSecOps, a prioridade deve ser revisar imediatamente os tokens de acesso, auditar branches recentes, verificar os registros de execução e reforçar as políticas de confiança entre o GitHub e os serviços de nuvem.
