Campanha GhostAction compromete contas de mantenedores e insere workflows para exfiltrar segredos

Pesquisadores de segurança voltaram a detectar uma campanha massiva de roubo de credenciais que exploram contas de manutenção de projetos open source para inserir fluxos de trabalho maliciosos em repositórios do GitHub. Segundo vários relatórios técnicos — incluindo os de StepSecurity, Socket e GitGuardian —, atacantes ligados à campanha conhecida como GhostAction Eles prometeram contas de mantenedores reputados e empurraram um arquivo de workflow que extrai segredos a um servidor controlado pelo operador. Os fatos confirmados incluem compromissos documentados em múltiplas janelas temporais (por exemplo, 27 repositórios às 13:20 UTC pela conta de Takashi Kitao e 318 repositórios em 16 minutos pela conta de Henry Wu) e a detecção de centenas de contas e milhares de segredos exfiltrados no período relatado.

A técnica não é uma vulnerabilidade no GitHub em si mesma, mas um abuso das credenciais de manutenção (provavelmente tokens de acesso pessoal, PAT) para modificar o ramo por defeito de projetos e adicionar um workflow que é executado com as permissões do repositório. O arquivo malicioso é apresentado com nomes legítimos como "security-audit.yml" ou "github_actions_security.yml" e realiza quatro tarefas-chave durante sua passagem "Audit": agrega os segredos nomeados do repositório, busca na árvore de trabalho padrões de credenciais (13 padrões associados à AWS, fornecedores de IA, registries e serviços na nuvem), digitaliza todo o histórico git para credenciais previamente comprometidas e emparelha IDs de acesso da AWS com seus secret access keys. Os dados coletados são enviados por HTTP para um IP dura (193.32.204[.]199), o que confirma exfiltração de segredos sem criptografia.

O que está comprovado: múltiplas assinaturas de segurança têm observado o mesmo fluxo de ataque; os workflows maliciosos ativam workflow_dispatch e são executados após pushes sem filtros, usam fetch-depth: 0 para acessar o histórico, e exfiltran tokens e chaves de serviços como PyPI, npm, DockerHub, AWS, OpenAI, Anthropic, OpenRouter e tokens do GitHub/GitLab. Relatórios públicos apontam números concretos: Socket detectou mais de 500 contas que fizeram commits do workflow desde 7 de outubro de 2026 e, em um barrido prévio, GitGuardian informou de 772 repositórios públicos afetados entre 31 de agosto e 30 de setembro de 2026; outra contagem cita 817 repositórios comprometidos e 3.325 segredos exfiltrados.

O que se infere mas não está totalmente comprovado: A fonte exata das credenciais usadas para tomar as contas — a análise aponta para Tokens filtrados em logs de info-stealers ou dump de credenciais —; embora esta hipótese se encaixa com padrões anteriores de GhostAction, não há um rastreamento público que demonstre a cadeia completa desde o roubo inicial do PAT até o commit malicioso em cada conta afetada. Também não há evidência pública, por agora, de pacotes maliciosos publicados em registries com credenciais roubadas — embora tenha sido documentada a modificação de uma imagem Docker para incluir um miner em pelo menos um caso.

O impacto prático para projetos e organizações é direto: qualquer segredo presente no repositório (já seja em variáveis de Actions, em arquivos da árvore de trabalho ou em commits antigos) pode ser lido e exfiltrado, e com isso se abrem vetores para comprometer infraestruturas de CI/CD, registries, serviços cloud e contas de desenvolvedores. Além disso, o uso da própria identidade do mantenedor para inserir a carga torna mais difícil distinguir a atividade maliciosa de mudanças legítimas em revisões superficiais, e a presença do workflow em forks e espelhos (incluindo forks privados) amplifica a superfície de exposição. Socket alertou que muitos forks no namespace de uma das contas afetadas continuavam portando a definição maliciosa, o que permite execução adicional se Actions estiver habilitado.

Para desenvolvedores e administradores de repositórios a resposta deve ser imediata e prática. Primeiro, verificar se existe em qualquer ramo (incluindo o padrão) um ficheiro chamado "security-audit.yml" ou "github_actions_security.yml" ou qualquer workflow suspeito adicionado desde 31 de agosto de 2026; se aparecer, assumir compromisso. Remover o arquivo malicioso de todos os ramos não é suficiente por si só: é necessário revogar a credencial comprometida (PAT), rodar qualquer chave ou token que pudesse ter estado no repositório (PyPI, npm, DockerHub, AWS, serviços de IA, GitHub/GitLab, e outros listados nos relatórios) e regenerar acessos. Também convém inspeccionar forks e mirrors – os forks públicos e privados podem herdar o workflow e executar remessas posteriores – e desactivar o GitHub Actions em repositórios que não o exijam.

Em termos operacionais, rever o histórico de Actions runs para identificar execuções invulgares (workflow_dispatch invocados externamente, execuções provocadas por pushes de contas comprometidas), e auditar os registros de rede e de CI para detectar conexões salientes para endereços suspeitos (por exemplo, o IP observado 193.32.204[.]199) ajudará a acotar alcance. Executar pesquisas de padrões de credenciais na árvore e no histórico git é crítico: dado que o workflow faz fetch-depth: 0, o adversário teve acesso ao histórico completo. Para procurar segredos involuntários, podem ser usadas ferramentas de digitalização como as que o GitHub oferece (secret scanning) e produtos de terceiros especializados em detecção de segredos em repositórios; o GitHub documenta suas capacidades de secret scanning em seu site oficial.

Medidas específicas recomendadas: 1) Revocar e rotar imediatamente PATs, chaves de serviços e tokens listados; 2) remover o workflow malicioso em todos os ramos e forks, e desactivar a Actions até confirmar limpeza; 3) ativar ou revisar políticas de aprovação para workflows externos e bloquear execução automática de workflows não verificados; 4) activar secret scanning e alerts de segurança na organização; 5) revisar e auditar logs de CI/CD e tráfego saliente para IPs/hosts não reconhecidos; 6) forçar 2FA e revisar sessões e aplicações autorizadas nas contas de manutenção; 7) tratar como comprometidos os repositórios privados que possam conter credenciais e rotar chaves associadas.

Para orientar incidentes e mitigações, documentação oficial sobre Actions e secret scanning pode ser consultada nos recursos do GitHub (https://docs.github.com/en/actions e https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning). Também é útil seguir análises de terceiros como os de GitGuardian, que centralizam indicadores e detecções públicas (https://www.gitguardian.com/). Ter esses procedimentos padronizados em runbooks de resposta a incidentes reduz o tempo de exposição e facilita a revogação ordenada de credenciais.

A verdade é que este episódio sublinha um princípio recorrente em segurança da cadeia de abastecimento: as contas humanas com permissões amplas são vetores de alto impacto. Enquanto se investiga a escala total e a procedência dos tokens usados, os mantenedores de projetos devem assumir que a mera presença de um workflow suspeito implica exfiltração possível e atuar com rotação de credenciais e revogação de acessos. As defesas eficazes combinam prevenção (limitação de permissões, políticas de revisão de workflows), detecção (secret scanning, monitoramento de Actions) e resposta rápida (rotação e limpeza), e neste caso concreto são as únicas medidas que cortam o acesso do atacante aos segredos já replicados.