GhostAction invade 94 repositórios GitHub com phishing e malware

Segurança Digital

Grupo GhostAction utiliza e-mails falsos e malware via VS Code para comprometer repositórios e roubar credenciais no GitHub.

Leia também: Ataque cibernético afeta refrigeração de supermercados na França

O grupo de ameaças GhostAction ampliou seu ataque à cadeia de suprimentos no GitHub ao combinar um falso alerta de segurança por e-mail com um malware acionado pelo VS Code, já identificado em 94 repositórios comprometidos de 66 proprietários. A nova fase busca roubar senhas, códigos 2FA e tokens OAuth para manter acesso persistente a projetos, mesmo após a remoção de workflows maliciosos.

Phishing com domínio falso imita alerta de segurança do GitHub

Nos últimos dias, os operadores do GhostAction registraram o domínio “my-github[.]com” e o apontaram para o IP 193.32.204[.]199, o mesmo servidor usado para receber dados extraídos pelos workflows maliciosos. A partir desse domínio, enviaram um e-mail de phishing que imita um alerta oficial de segurança do GitHub para um mantenedor de código aberto.

A mensagem, enviada do endereço “noreply@my-github[.]com”, alegava um login suspeito a partir de Moscou e orientava o desenvolvedor a clicar em um link para proteger a conta. A página falsa funciona como um proxy reverso: captura a senha, o código de autenticação em duas etapas (2FA) e ainda injeta JavaScript para autorizar silenciosamente um aplicativo OAuth com amplas permissões.

Esse app OAuth ganha escopos de acesso a repositórios, workflows e dados de organizações, permitindo ler e escrever código, alterar arquivos em “.github/workflows/” e enxergar a estrutura de organizações inteiras. O objetivo é obter um token de acesso reutilizável, que passa a ser enviado para o domínio falso em uma porta dedicada.

Segundo o pesquisador de segurança Paul McCarty, o kit automatiza todo o fluxo de autorização. “O script recebe um código de dispositivo e código de usuário, carrega /login/device, extrai formulários do GitHub do HTML retornado e os submete automaticamente”, explicou. O processo insere o código de usuário, localiza o formulário de autorização, adiciona o parâmetro de aprovação e envia tudo através da sessão autenticada da vítima.

Na prática, o usuário não precisa digitar o código de dispositivo nem clicar em “autorizar”: o JavaScript faz isso em nome dele, enquanto a interface imita um fluxo comum de login. Ao final, os operadores saem com um token OAuth que lhes dá poder para enumerar repositórios e implantar workflows maliciosos no estilo GhostAction.

Entenda o contexto

O GhostAction ficou conhecido por explorar workflows do GitHub Actions para injetar código malicioso em projetos open source. O ataque se apoia na confiança que mantenedores e usuários têm em repositórios hospedados em grandes plataformas: um simples arquivo em “.github/workflows/” pode acionar uma automação aparentemente legítima, mas que coleta segredos, chaves e tokens usados em pipelines de desenvolvimento.

Diante das primeiras ondas de ataques, o GitHub passou a bloquear a execução do workflow malicioso a partir de 9 de outubro. Isso reduziu a eficácia do estágio inicial da campanha, que dependia da plataforma para rodar o código de exfiltração. A reação do GhostAction foi mover parte da operação para fora do controle direto do provedor, apostando em phishing e persistência local nas máquinas dos desenvolvedores.

Como o malware é acionado pelo VS Code e mantém persistência

Além do roubo de credenciais via página falsa, os operadores do GhostAction passaram a distribuir um segundo estágio de ataque: um ladrão de credenciais disfarçado de arquivo de fonte, que é acionado automaticamente pelo VS Code quando o repositório comprometido é aberto.

Pesquisadores identificaram que três arquivos específicos são adicionados ou alterados nos repositórios afetados, de forma a fazer o editor disparar o código malicioso sem interação explícita do usuário. Uma vez executado, o stealer vasculha variáveis de ambiente, diretórios domésticos e outros pontos sensíveis em busca de chaves, tokens e credenciais.

Esse componente ainda instala uma tarefa cron que roda a cada cinco minutos, garantindo persistência mesmo depois que o workflow malicioso é removido do GitHub. A cron chama periodicamente código controlado pelo atacante e envia os dados coletados para o servidor no IP 193.32.204[.]199, usando HTTP simples na porta 8080.

De acordo com a plataforma de inteligência OpenSourceMalware, 94 repositórios já foram identificados com esse segundo estágio, pertencentes a 66 donos. Desses, 15 repositórios foram deletados, renomeados ou tornados privados após a descoberta.

Entre os 79 repositórios ainda acessíveis, 65 não recebem um commit há mais de um ano e um deles está sem alterações por mais de nove anos. O foco em projetos abandonados ou pouco mantidos reduz a chance de alguém notar as mudanças rapidamente, ao mesmo tempo em que preserva a cadeia de confiança: muitas empresas e desenvolvedores continuam a baixar essas dependências sem auditoria detalhada.

Para os pesquisadores, essa mudança de foco é estratégica. “O ator agora pode combinar automação em escala de repositório com engenharia social individual contra pessoas cujas contas fornecem acesso a projetos, organizações, registros e usuários downstream”, avaliou a OpenSourceMalware.

O que mudou após o bloqueio de workflows pelo GitHub

O bloqueio da execução do workflow malicioso pelo GitHub, implementado a partir de 9 de outubro, limitou o chamado estágio 1 da campanha, que dependia dos runners da plataforma para extrair segredos diretamente dos pipelines.

“O estágio 1 precisa que o GitHub execute o workflow”, resumiu a OpenSourceMalware. Após essa barreira, novas ondas de ataque não conseguiram mais extrair segredos pelo mecanismo original. Seis dias depois, porém, surgiu o estágio 2, com o launcher local via VS Code e a tarefa cron, que já não dependem dos controles da plataforma para funcionar.

Ao mover parte da lógica de ataque para o ambiente do desenvolvedor, o operador escapa das proteções centralizadas e aumenta a superfície de ataque, alcançando não só tokens usados nos workflows, mas também chaves e credenciais armazenadas na máquina do usuário.

Entenda o contexto

A campanha expõe um ponto sensível da cadeia de suprimentos de software: a combinação entre plataformas de hospedagem de código, ferramentas de automação (como o GitHub Actions) e ambientes locais de desenvolvimento (como o VS Code). Ao comprometer qualquer elo, o atacante pode afetar bibliotecas e aplicativos que servem de base para milhares de outros projetos.

Mesmo projetos aparentemente “parados” no GitHub continuam sendo baixados via gerenciadores de pacotes e incluídos em sistemas em produção. Ao tomar controle de um repositório antigo e inserindo código malicioso em atualizações discretas ou em artefatos de build, o atacante ganha um canal eficiente para distribuir malware em larga escala.

Quais são os riscos para desenvolvedores e organizações?

O risco imediato é o comprometimento de contas de desenvolvedores e tokens OAuth ligados a repositórios e organizações no GitHub. Uma única credencial roubada pode permitir ao GhostAction alterar código, criar novos workflows, ler segredos armazenados em pipelines e chegar a registros de pacotes e usuários finais.

Como muitos dos repositórios afetados são open source e usados como dependências, o ataque pode se propagar para a base de usuários desses projetos, inclusive empresas que confiam nos pacotes para compilar e rodar sistemas críticos. A persistência no ambiente local via VS Code amplia o impacto, pois o malware passa a enxergar não apenas um repositório, mas todos os projetos e credenciais presentes na máquina do desenvolvedor.

Há ainda o risco reputacional para mantenedores e organizações: repositórios comprometidos podem ser usados para distribuir backdoors, miners, ransomwares ou outros malwares, minando a confiança da comunidade e de clientes. Mesmo após a limpeza, o histórico de comprometimento tende a pesar na adoção de bibliotecas afetadas.

Como reduzir o impacto do GhostAction no GitHub?

A orientação de pesquisadores é que quem suspeitar de comprometimento revogue acessos e tokens do GitHub a partir de um dispositivo limpo, altere a senha da conta e revise com atenção os apps OAuth autorizados — especialmente aqueles com permissão para gerenciar repositórios, workflows e dados de organização.

Também é recomendada uma auditoria completa dos repositórios: checar arquivos em “.github/workflows/”, procurar por tarefas cron estranhas, scripts desconhecidos ligados ao VS Code e arquivos de fonte ou configuração adicionados recentemente sem explicação. Qualquer credencial à qual os workflows tenham acesso deve ser rotacionada.

Para organizações, passos adicionais incluem alertar desenvolvedores sobre e-mails de phishing que imitam alertas de segurança do GitHub, reforçar o treinamento sobre 2FA e autorizações OAuth, revisar políticas de acesso mínimo a repositórios sensíveis e monitorar mudanças em workflows automatizados.

Em paralelo, reforçar o monitoramento de rede para conexões suspeitas com o IP 193.32.204[.]199 e portas atípicas pode ajudar a identificar máquinas já comprometidas. A expectativa de especialistas é que o GhostAction tente escalar a campanha para outros repositórios e organizações, inclusive explorando domínios parecidos com outras plataformas de hospedagem de código.

Fonte: matéria original