GhostAction amplia o ataque: phishing para roubar credenciais e persistência em VS Code

Um grupo por trás da campanha GhostAction - conhecido por infiltrar fluxos de trabalho do GitHub Actions em projetos de código aberto - expandiu seu arsenal: além de implantar workflows maliciosos em repositórios comprometidos, agora envia e-mails de suplantação para capturar credenciais e entrega um carregador de informações disfarçado como fonte (.woff2) que atua como infostealer com persistência em equipamentos de desenvolvedores. Esta evolução, relatada pelo OpenSourceMalware e reproduzida por meios de segurança, mostra uma transição desde a exploração pura da execução automática na CI para uma combinação de engenharia social, abuso de OAuth e persistência no ambiente de desenvolvimento.

Atos confirmados: Pesquisadores do OpenSourceMalware identificaram um domínio registrado como my-github[.]com que aponta para o IP 193.32.204[.]199 — a mesma IP usada pela campanha para exfiltrar dados — e observaram que o domínio foi usado em um e-mail phishing que imitava um aviso de segurança do GitHub para capturar senhas e códigos 2FA. A página fraudulenta atuou como um proxy inverso: roubou credenciais e executou JavaScript que autorizou automaticamente uma aplicação OAuth e completou o fluxo de dispositivo do GitHub para obter um token com permissões de repo, workflow e read:org. Esse token permite modificar arquivos sob .github/workflows/ e voltar a injetar workflows maliciosos. Além disso, foi detectada uma segunda etapa em 94 repositórios: inclusão de um .vscode/tasks.json com trigger runOn: folderOpen, um arquivo de fonte public/fonts/fa-solid-400.woff2 que contém o payload para roubar credenciais (AWS, PyPI, npm, Kubernetes, SSH, tokens de fornecedores de IA) e um workflow de apoio que, se a primeira via não executar o ladrão, lança a extração e instala um cron que executa código atacante a cada cinco minutos; a exfiltração ocorre para a mesma infraestrutura por HTTP/8080.

Como funciona tecnicamente a cadeia de ataque: A sequência combinada relatada pode ser resumida assim. Primeiro, o ator compromete repositórios e adiciona um workflow malicioso que, se executado no GitHub Actions, recolhe segredos acessíveis (tokens do GitHub, credenciais no repo) e envia-os para um servidor controlado. Para sortear bloqueios na execução de workflows, o atacante usa phishing dirigido: um domínio similar ao GitHub é registrado e usado para enviar um falso aviso de início de sessão. A página 'proxy' rouba credenciais e, por meio de scripts, automatiza o fluxo de dispositivo do GitHub para obter um token reuseável sem interação consciente do usuário. Com esse token o ator pode escrever novos workflows ou arquivos em repositórios. Se o controle de execução de Actions for limitado pelo GitHub, o adversário adiciona componentes que são executados localmente na máquina do desenvolvedor (VS Code tasks e arquivos binários disfarçados de fontes) para persistir e roubar segredos locais, instalando também um cron para manter acesso periódico.

Quem ficam afetados e por que é relevante: O principal alvo são mantenedores de projetos de código aberto e desenvolvedores com acesso a repositórios vulneráveis ou abandonados. OpenSourceMalware contabilizou 94 repositórios afetados pertencentes a 66 proprietários; muitos repositórios estavam inactivos (a maioria sem commits em mais de um ano). A combinação de repositórios pouco vigiados e permissões excessivas em Tokens do GitHub facilita a expansão lateral: com um token de repositório o atacante pode afetar integrações, pacotes e usuários downstream que confiam nesses repositórios.

As consequências práticas incluem perda de tokens reutilizáveis que permitem modificar código e fluxos de CI, exposição de credenciais da nuvem e registros de fornecedores (AWS, npm, PyPI), roubo de chaves SSH e segredos de APIs de IA — todos dados que permitem desde o abuso de infraestrutura à distribuição de malware através de artefatos legítimos. Além disso, a persistência local através de um ficheiro que se ativa ao abrir o projeto em VS Code aumenta o risco: desenvolver com um repositório comprometido pode converter a estação de trabalho numa porta traseira.

Confirmado vs. incerto: é um fato verificado, segundo os relatórios, que o domínio my-github[.]com foi usado para phishing e que a IP mencionada serviu como ponto de exfiltração. Também está confirmado o design técnico da automação do fluxo de dispositivo para obter tokens. Não está claro — segundo os próprios pesquisadores — se outros domínios com nomes similares (por exemplo, my-gitlab[.]com) pertencem ao mesmo operador: registros, registradores e artefatos CRYPTO/DNS não mostram uma conexão direta. A atribuição do ator permanece sem confirmar e a motivação exata (financeira, espionagem, provas de conceito) não foi estabelecida publicamente.

Interpretação e contexto: A tática revela duas tendências conhecidas mas combinadas de forma mais agressiva: a) abuso do mecanismo OAuth/device flow para obter credenciais persistentes sem intervenção explícita do usuário, e b) uso de vetores de persistência em ferramentas de desenvolvimento (VS Code) que nem sempre são auditadas por controles de CI. A resposta do GitHub -bloquear a execução do workflow malicioso - reduziu a eficácia da primeira etapa, mas o ator respondeu em questão de dias com um desenho que evita a dependência do runner. Isto ilustra a dinâmica ofensiva-defensiva em que os atacantes adaptam sua infraestrutura após cada medida de mitigação.

Medidas concretas que devem tomar desenvolvedores e administradores hoje mesmo: revogar todos os tokens e autorizações do GitHub a partir de um dispositivo limpo e rodar todas as credenciais que poderiam ter sido acessíveis aos workflows (chaves de nuvem, tokens de pacotes, credenciais de registries). Rever e retirar aplicativos OAuth desconhecidos na página de settings > authorized OAuth apps e na gestão de tokens da organização. Auditar repositórios por ficheiros suspeitos (.github/workflows com nomes de CI comuns, .vscode/tasks.json, fontes incomuns em public/fonts) e por qualquer cron ou tarefa programada em estações de trabalho de desenvolvedores. Procurar ligações salientes a 193.32.204[.]199 e domains my-github[.]com e bloqueá-las a nível de rede. Activar políticas que limitem as permissões de workflows ao estritamente necessário e exigir revisões manuais para mudanças em .github/workflows; usar ferramentas de proteção como GitHub Actions security hardening e Require approval for third-party access em organizações. Para credenciais de alto valor (cloud, fornecedores de IA) considerar a rotatividade imediata e o uso de credenciais de curta duração e serviços de gestão de segredos. Finalmente, para elevar a proteção contra phishing de OAuth, promover mecanismos de autenticação resistentes a phishing (chaves de segurança FIDO) e educação específica sobre a engenharia social que usa páginas proxied e fluxos automáticos.

Para mais informações técnicas sobre como o fluxo de dispositivo funciona e medidas preventivas em Actions, consulte a documentação oficial do GitHub sobre o Device Flow e as recomendações de endurecimento de Actions: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow e https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions. Também pode seguir pesquisas e amostras no repositório de análise do OpenSourceMalware: https://opensourcemalware.org/.

Em resumo: a operação GhostAction demonstrou capacidade para se adaptar rapidamente e misturar técnicas de supply-chain, phishing de OAuth e persistência local. Os desenvolvedores de código aberto e organizações mantenedoras devem assumir que qualquer repositório com história de commits inativos ou sem auditoria recente poderia ser um vetor e agir com prioridade na revogação, rotação e endurecimento de permissões.