O threat actor por trás do ataque à cadeia de suprimentos GhostAction ampliou suas ações. Além de injetar fluxos de trabalho maliciosos do GitHub Actions em projetos comprometidos, passou a enviar phishing a desenvolvedores de código aberto e a distribuir um malware ladrão de dados disfarçado de arquivo de fonte.
A evolução mais recente, detalhada pela OpenSourceMalware, indica que os invasores estão aprimorando suas táticas em resposta às medidas adotadas pelo GitHub para impedir a execução dos fluxos de trabalho maliciosos.
Segundo a plataforma de inteligência de ameaças, o threat actor registrou o domínio “my-github[.]com” e o direcionou para o endereço “193.32.204[.]199”, o mesmo IP usado como ponto de exfiltração dos dados coletados pelo fluxo de trabalho malicioso.
O domínio foi registrado em 9 de outubro de 2026, 17 dias depois do registro de “my-gitlab[.]com”. Ainda não está claro se esse último domínio, que imita o nome de um serviço de hospedagem de código, é operado pelo mesmo threat actor.
“Ele segue o mesmo padrão de nomes my-<code-host>.com, o que o torna uma pista útil para investigação. No entanto, a infraestrutura atual não o relaciona diretamente à GhostAction”, afirmou o pesquisador de segurança Paul McCarty. “Os domínios usam registradores diferentes, dados de registro distintos, pares de servidores de nomes da Cloudflare, endereços IP, ASNs e configurações de DNS diferentes. Também não foi encontrado nenhum certificado ou artefato de conta em comum.”
Desde então, o domínio “my-github[.]com” foi usado em um e-mail de phishing que imitava um alerta de segurança do GitHub. A mensagem foi enviada a um mantenedor de código aberto no mesmo dia em que o domínio foi registrado. O e-mail, remetido de “noreply@my-github[.]com”, avisava sobre um novo acesso à conta do GitHub a partir de Moscou, na Rússia, e orientava a vítima a clicar em um link para proteger a conta.
De acordo com a OpenSourceMalware, a página fraudulenta funcionava como um proxy reverso, capturando a senha e o código de autenticação de dois fatores (2FA) da vítima. Ela também injetava JavaScript para autorizar um aplicativo OAuth com permissão para alterar fluxos de trabalho, facilitando um ataque no estilo GhostAction.
A página falsa de acesso também continha JavaScript para autorizar silenciosamente um fluxo de dispositivo OAuth do GitHub com os escopos repo, workflow e read:org. Isso concedia permissões amplas para ler e gravar em repositórios, modificar arquivos de fluxo de trabalho do Actions e acessar informações sobre integrantes de organizações e outros dados relacionados.
A estratégia é semelhante ao phishing por código de dispositivo: o objetivo final é obter um token de acesso do GitHub e exfiltrá-lo para “my-github[.]com” pela porta TCP/8443.
“O script recebe um código de dispositivo e um código de usuário, carrega /login/device, extrai os formulários do GitHub do HTML retornado e os envia automaticamente”, explicou McCarty. “Ele insere o código de usuário, localiza um formulário de autorização, adiciona authorize=1 e envia a aprovação pela sessão autenticada da vítima, que passa pelo proxy reverso.”
“A vítima não precisa digitar o código de dispositivo nem aprovar conscientemente o aplicativo OAuth. Esse kit vai além e automatiza as etapas de inserção do código de usuário e autorização pela sessão encaminhada pelo proxy reverso.”
Ao roubar um token OAuth com escopo para repositórios, o invasor obtém uma credencial de API reutilizável. Além disso, as permissões concedidas pela autorização OAuth furtiva são compatíveis com a capacidade da GhostAction de listar repositórios e injetar arquivos de fluxo de trabalho maliciosos em “.github/workflows/”.
“Agora, o operador pode combinar automação em escala de repositórios com engenharia social direcionada a pessoas cujas contas dão acesso a projetos, organizações, registros de pacotes e usuários de serviços derivados”, afirmou a OpenSourceMalware.
Para agravar a situação, a campanha também passou a incluir um componente de segunda etapa que permanece nos computadores dos desenvolvedores mesmo depois da remoção do fluxo de trabalho malicioso.
A abordagem se inspira nas táticas da Coreia do Norte e envolve o envio de três arquivos:
- Um arquivo tasks.json do Microsoft Visual Studio Code (VS Code), com o acionador “runOn: folderOpen”, que permite que o código seja executado automaticamente quando a pasta é aberta no aplicativo.
- Um arquivo “public/fonts/fa-solid-400.woff2” que contém uma carga útil de roubo de dados. Ela busca chaves da AWS, tokens do PyPI e do npm, credenciais de acesso ao Git, credenciais de clusters do Kubernetes, chaves privadas SSH e credenciais de provedores de IA, como Anthropic Claude e Google Gemini. O nome do arquivo de fonte é o mesmo usado na campanha PolinRider da Coreia do Norte, em janeiro de 2026.
- Um segundo fluxo de trabalho do GitHub Actions, ativado caso o infostealer não seja executado.
Com isso, o VS Code executa automaticamente o ladrão de credenciais. Além de coletar dados, ele instala uma tarefa cron que executa código fornecido pelo invasor a cada cinco minutos. Os dados coletados são enviados ao mesmo servidor por HTTP sem criptografia, na porta 8080. Foram identificados 94 repositórios comprometidos com esse componente de segunda etapa.
O segundo fluxo de trabalho de CI é igual ao fluxo malicioso original, mas procura formatos adicionais de credenciais e inclui uma alternativa: se a solicitação POST falhar, os dados encontrados são enviados para um GitHub Gist privado. O segundo fluxo de trabalho aparece com os seguintes nomes:
- lint.yml
- ci-check.yml
- build-check.yml
- repo-health.yml
- audit.yml
- code-review.yml
- test-suite.yml
- cache-cleanup.yml
Segundo a OpenSourceMalware, os 94 repositórios pertencem a 66 proprietários. Desde então, 15 foram excluídos, tiveram o nome alterado ou se tornaram privados. Entre os repositórios ainda acessíveis, a maioria parece estar praticamente abandonada. Um deles, por exemplo, não recebe alterações há mais de nove anos. Ao todo, 65 dos 79 repositórios acessíveis não recebiam atualizações havia mais de um ano.
“A primeira etapa depende da execução do fluxo de trabalho pelo GitHub. Em 9 de outubro, o GitHub começou a impedir a execução do fluxo malicioso, e as ondas de ataque de 10 e 12 de outubro não extraíram nenhum segredo. A segunda etapa adiciona um mecanismo de execução que não depende de um executor e surgiu seis dias depois do bloqueio. Não podemos afirmar que o bloqueio causou essa mudança. Podemos dizer que o operador migrou para uma área que os controles do GitHub não alcançam”, afirmou a OpenSourceMalware.
Para reduzir o risco, os desenvolvedores devem revogar o acesso ao GitHub e os tokens a partir de um dispositivo limpo, trocar as senhas, auditar os repositórios, substituir todas as credenciais que poderiam ser acessadas pelos fluxos de trabalho e avisar os usuários que clonaram os repositórios.
“Não sabemos quem é o operador, mas o trabalho indica pouca experiência”, disse Jenn Gile, cofundadora da OpenSourceMalware, segundo reportagem do The Hacker News. “O filtro de variáveis de ambiente do ladrão de dados não identifica a maioria das chaves de API, a busca no diretório pessoal pode exceder o tempo limite e descartar os próprios resultados, e um único IP é usado para exfiltração, phishing e varreduras ruidosas na internet. Esse último erro é o motivo pelo qual uma busca pelo IP ainda encontra infecções.”
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...