GhostAction sequestra 790 repositórios do GitHub com workflow malicioso
Uma campanha chamada GhostAction comprometeu pelo menos 790 repositórios públicos do GitHub por meio de fluxos de automação maliciosos. O levantamento considerou projetos que ainda podiam ser identificados e recuperados publicamente até 9 de outubro. O total não significa que todos os repositórios tiveram credenciais roubadas ou que essas credenciais foram usadas de forma indevida: a exposição precisa ser confirmada caso a caso.
Uma contagem anterior, feita pela GitGuardian, identificou 772 repositórios entre 31 de agosto e 30 de setembro. Os números foram obtidos em períodos e conjuntos de evidências diferentes, portanto não devem ser somados. Em 8 de outubro, outro episódio relacionado atingiu 346 repositórios vinculados a duas contas de mantenedores, incluindo um projeto associado à Uber.
A operação explora contas de desenvolvedores legítimas. Quando invasores conseguem permissão para escrever em repositórios de um mantenedor, podem inserir neles um workflow do GitHub Actions – recurso que automatiza tarefas durante o desenvolvimento. O código malicioso pode ser configurado para executar a cada envio de alterações ou após uma ativação manual.
Durante a execução, o workflow acessa os segredos disponíveis para aquela automação. A campanha procura valores que se pareçam com credenciais em arquivos do projeto e tenta ler segredos selecionados do Actions. Entre os tipos de dados procurados estão chaves da AWS e tokens associados a serviços como GitHub, GitLab, Google, Slack, SendGrid, OpenAI, Anthropic e OpenRouter. A lista descreve os alvos da busca, não comprova que todos esses dados tenham sido obtidos.
O código também pode copiar o histórico completo do Git. Assim, credenciais removidas dos arquivos atuais ainda podem ser encontradas em commits antigos. Em alguns casos, a automação recolhe linhas próximas a identificadores de chaves da AWS, que podem conter informações necessárias para localizar a chave secreta correspondente. Os dados são enviados sem criptografia para uma infraestrutura controlada pelos atacantes.
O alcance da campanha incluiu projetos ativos, forks e repositórios que estavam sem manutenção havia bastante tempo. Essa distribuição sugere uma busca automatizada por todos os projetos que as contas comprometidas podiam modificar, em vez de uma seleção restrita a um único tipo de software.
Apagar o workflow suspeito é uma medida necessária, mas não suficiente. Se ele já foi executado, uma credencial pode ter sido exposta; além disso, remover o arquivo não invalida tokens roubados nem elimina segredos preservados no histórico do Git. A resposta deve incluir a revogação da credencial da conta comprometida, a troca de todos os segredos acessíveis à automação e a análise de atividades suspeitas no período do incidente.
Também é importante revisar registros de releases, alterações recentes no código e ações realizadas em serviços de nuvem. Em ambientes AWS, por exemplo, a equipe deve procurar chamadas incomuns, novas credenciais, mudanças de permissões e recursos criados sem autorização. A investigação ajuda a entender se houve apenas exposição ou se os dados foram efetivamente usados.
Para reduzir riscos, mantenedores devem limitar as permissões concedidas a cada workflow e evitar disponibilizar segredos a tarefas que não precisam deles. Configurações como permissões mínimas para tokens, revisão de alterações antes da execução e proteção de branches podem dificultar a instalação de automações maliciosas. Também convém examinar workflows recém-adicionados ou modificados, principalmente quando a mudança ocorre em uma conta com acesso amplo.
Segredos não devem ser armazenados diretamente no código, e sua remoção do arquivo não basta se já foram incluídos em um commit. Quando isso acontecer, a credencial precisa ser substituída, e o histórico deve ser tratado como potencialmente exposto. A rotação periódica e o uso de credenciais temporárias reduzem o impacto de uma eventual invasão.
Por fim, equipes que mantêm projetos devem estabelecer um procedimento de resposta a incidentes para contas de desenvolvedores e pipelines de CI/CD. Saber quem pode revogar tokens, trocar credenciais e verificar logs acelera a contenção. Em ataques desse tipo, agir rapidamente é essencial: cada workflow executado pode ampliar o conjunto de dados e serviços acessíveis aos invasores.