GhostAction altera workflows do GitHub para roubar credenciais de nuvem e tokens
Uma nova etapa da campanha GhostAction ampliou o alcance do roubo de credenciais em projetos hospedados no GitHub. Em 8 de outubro, duas contas de mantenedores que haviam sido comprometidas inseriram um workflow malicioso em 346 repositórios. Entre os projetos atingidos estavam uber/athenadriver e kitao/pyxel, que reúne mais de 18 mil estrelas.
A alteração foi apresentada como uma medida legítima de proteção. O arquivo, chamado `security-audit.yml`, chegou acompanhado de uma mensagem de commit que sugeria uma auditoria de segurança. Com aparência de rotina defensiva, a mudança poderia passar despercebida durante uma revisão rápida.
Depois de incluído no projeto, o workflow é executado automaticamente a cada envio de código. Sua função, porém, não é verificar a segurança do repositório: ele busca informações sensíveis disponíveis no ambiente e as transmite por uma requisição HTTP a um servidor controlado pelos invasores. A coleta ocorre sem exigir uma ação específica de quem mantém o projeto.
A principal mudança em relação a campanhas anteriores está na quantidade de lugares examinados. Antes, o foco estava nos secrets configurados para o GitHub Actions. Agora, o código também percorre os arquivos presentes na árvore de trabalho e o histórico completo do Git, procurando credenciais que possam ter sido esquecidas em versões antigas do projeto.
Essa busca pode revelar dados que já não aparecem na versão atual do código, mas continuam registrados em commits anteriores. Por isso, apagar uma chave de um arquivo não é suficiente para garantir que ela deixou de estar exposta: o histórico do repositório também precisa ser investigado, e a credencial deve ser substituída.
Entre os alvos estão chaves de acesso da AWS, tokens do GitHub e do GitLab, chaves de API do Google, credenciais da OpenAI e da Anthropic, além de tokens do Slack e do SendGrid. A lista também inclui senhas do PyPI e tokens do crates.io, usados em diferentes etapas de desenvolvimento e distribuição de software.
O episódio de 8 de outubro faz parte de uma operação mais ampla. Desde o dia 7 daquele mês, mais de 500 contas do GitHub teriam sido usadas para inserir workflows semelhantes. Em setembro de 2025, uma onda anterior alcançou 817 repositórios; entre agosto e setembro do mesmo ano, outra campanha atingiu mais 772.
A exposição de uma única credencial pode abrir caminho para novos ataques. Uma chave de nuvem, por exemplo, pode permitir acesso a recursos da empresa; um token de pacote pode ser usado para publicar versões adulteradas de uma biblioteca; e uma conta de colaboração comprometida pode servir para distribuir alterações maliciosas a outros projetos.
Como verificar se um repositório foi afetado
Equipes de desenvolvimento devem examinar alterações recentes na pasta `.github/workflows`, especialmente arquivos adicionados ou modificados com nomes associados a auditoria, segurança ou verificação automática. Também é importante revisar mensagens de commit suspeitas e confirmar se cada alteração foi solicitada e aprovada por uma pessoa autorizada.
A revisão não deve se limitar ao código atual. Uma varredura do histórico completo do Git pode identificar segredos que foram removidos posteriormente, mas permanecem em commits antigos. Caso uma credencial seja encontrada, a medida segura é considerá-la comprometida, revogá-la e gerar outra, em vez de apenas apagá-la do repositório.
Também é necessário conferir os registros de execução do GitHub Actions. Execuções inesperadas, workflows desconhecidos ou tentativas de acessar variáveis e arquivos sensíveis podem indicar atividade maliciosa. A análise deve abranger os repositórios relacionados, pois credenciais reutilizadas ou permissões compartilhadas podem ampliar o impacto.
Medidas para reduzir o risco
Como resposta imediata, recomenda-se revogar sessões do GitHub, tokens de acesso pessoal, concessões OAuth e chaves SSH potencialmente expostas. As credenciais de serviços conectados ao projeto – como plataformas de nuvem, ferramentas de comunicação e repositórios de pacotes – também devem ser avaliadas e substituídas quando houver possibilidade de comprometimento.
Para evitar novas alterações não autorizadas, organizações podem exigir revisão rigorosa de toda mudança em arquivos de workflow. Regras de proteção de branches, aprovação por mais de uma pessoa e permissões mínimas para ações automatizadas ajudam a dificultar que um invasor introduza código sem ser percebido.
Por fim, segredos não devem ser mantidos diretamente nos arquivos do projeto nem reutilizados entre diferentes serviços. O uso de credenciais com escopo limitado, prazos de validade curtos e armazenamento apropriado reduz o impacto caso um token seja encontrado. Monitoramento contínuo dos repositórios e auditorias periódicas do histórico completam a proteção.