GhostAction compromete 94 repositórios no GitHub e mira credenciais de desenvolvedores
A campanha GhostAction ampliou seus métodos de ataque à cadeia de suprimentos de software. Além de explorar automações do GitHub Actions, os operadores passaram a usar mensagens de phishing e um malware disfarçado de arquivo de fonte para roubar dados de desenvolvedores. A investigação da plataforma de inteligência de ameaças OpenSourceMalware identificou a operação em 94 repositórios pertencentes a 66 proprietários.
Na fase inicial, os invasores manipulavam arquivos de automação para extrair informações confidenciais dos projetos atingidos. Depois que o GitHub adotou medidas para bloquear a execução desses workflows maliciosos, a campanha ganhou uma nova frente: comprometer contas de mantenedores e instalar mecanismos que continuassem ativos nos computadores das vítimas.
Phishing simulava alerta de segurança do GitHub
Em 9 de outubro de 2026, foi registrado o domínio my-github[.]com, associado ao endereço IP 193.32.204[.]199. O mesmo endereço já havia sido utilizado para receber dados extraídos durante ataques. Na data do registro, o domínio serviu para enviar uma mensagem fraudulenta a um mantenedor de projeto de código aberto.
O e-mail, enviado por noreply@my-github[.]com, imitava uma notificação oficial do GitHub. A mensagem alegava que a conta havia sido acessada de forma suspeita a partir de Moscou, na Rússia, e orientava o destinatário a abrir uma página para proteger as credenciais.
O site não se limitava a registrar a senha. Segundo a investigação, funcionava como um proxy reverso, capaz de capturar também o código de autenticação de dois fatores (2FA). Com isso, os criminosos podiam tentar assumir a conta mesmo quando ela estava protegida por uma camada adicional de segurança.
Um script malicioso na página também automatizava a autorização de um aplicativo OAuth do GitHub pelo fluxo de código de dispositivo. O aplicativo solicitava permissões para acessar repositórios, alterar workflows e consultar informações de organizações. O código obtinha os identificadores necessários e enviava a aprovação usando a sessão já autenticada da vítima, sem exigir que ela digitasse o código ou confirmasse conscientemente a autorização.
O objetivo era gerar um token reutilizável para acessar a API do GitHub e encaminhá-lo ao domínio controlado pelos invasores pela porta TCP 8443. Com esse token, os atacantes poderiam examinar os repositórios disponíveis para a conta e inserir novas automações maliciosas na pasta `.github/workflows/`.
Arquivos aparentemente legítimos instalavam malware
A campanha também introduziu componentes destinados a manter a operação mesmo depois da remoção dos workflows comprometidos. Um deles era um arquivo `tasks.json` do Visual Studio Code (VS Code), configurado para iniciar uma tarefa automaticamente quando a pasta do projeto fosse aberta no editor.
Outro componente se apresentava como uma fonte: `public/fonts/fa-solid-400.woff2`. Apesar da aparência de arquivo usado pela aplicação, ele continha um malware desenvolvido para localizar e roubar credenciais armazenadas no computador.
O nome coincide com um arquivo empregado em uma campanha chamada Fake Font/PolinRider, associada a operadores norte-coreanos e documentada em janeiro de 2026. Essa semelhança, por si só, não comprova que os responsáveis pela GhostAction sejam os mesmos.
Entre os dados procurados pelo malware estavam chaves de acesso da AWS, tokens do PyPI e do npm, credenciais do GitHub, dados de acesso a clusters Kubernetes, chaves privadas SSH e credenciais de serviços de inteligência artificial, como Anthropic Claude e Google Gemini.
Quando executado pelo VS Code, o programa também criava uma tarefa cron para rodar código fornecido pelos invasores a cada cinco minutos. Esse recurso permitia manter a persistência no sistema. As informações coletadas eram enviadas por HTTP, sem criptografia, a um servidor dos criminosos pela porta 8080.
Um segundo workflow do GitHub Actions atuava como alternativa caso o malware local não fosse executado. Essa automação procurava uma variedade maior de credenciais e, se o envio por HTTP falhasse, podia armazenar os dados em um GitHub Gist secreto. Entre os nomes usados nos arquivos maliciosos estavam `lint.yml`, `ci-check.yml`, `build-check.yml`, `repo-health.yml`, `audit.yml`, `code-review.yml`, `test-suite.yml` e `cache-cleanup.yml`.
Domínios parecidos não confirmam ligação entre campanhas
O domínio my-github[.]com apresenta semelhanças com my-gitlab[.]com, registrado 17 dias antes. No entanto, o pesquisador Paul McCarty apontou que não há evidências suficientes para atribuir os dois domínios ao mesmo grupo. Eles utilizam registradores, configurações de DNS e infraestruturas diferentes, fatores que impedem uma conclusão segura sobre uma ligação entre as operações.
Como equipes e desenvolvedores podem reduzir o risco
Projetos afetados devem revisar os históricos de alterações e os workflows do GitHub Actions, verificando arquivos adicionados ou modificados sem autorização. Também é importante examinar tarefas de inicialização do VS Code e arquivos de fonte que tenham sido incorporados recentemente, especialmente quando sua origem não puder ser confirmada.
Se houver suspeita de comprometimento, as credenciais devem ser revogadas e substituídas. Isso inclui tokens do GitHub, chaves de nuvem, credenciais de registros de pacotes, acessos a Kubernetes, chaves SSH e segredos de serviços de IA. A troca da senha, isoladamente, pode não ser suficiente se um token OAuth ou uma chave de acesso continuar válida.
As organizações devem revisar os aplicativos OAuth autorizados nas contas e remover aqueles que não reconhecem ou que solicitam permissões excessivas. Permissões capazes de modificar repositórios ou workflows merecem atenção especial, pois podem permitir que um invasor altere o código e propague novas etapas do ataque.
Também é recomendável exigir autenticação multifator resistente a phishing sempre que possível e treinar equipes para desconfiar de alertas inesperados que peçam acesso por links externos. Mensagens que alegam logins suspeitos devem ser verificadas diretamente nas configurações da conta, sem utilizar os botões ou endereços fornecidos no e-mail.
Por fim, a revisão de código deve incluir arquivos de automação, configurações do editor e recursos aparentemente inofensivos, como fontes. A GhostAction demonstra que a proteção de um repositório não depende apenas do código-fonte: workflows, tokens, configurações locais e permissões de aplicativos também podem se tornar pontos de entrada para uma invasão.