Atacantes usam credenciais roubadas para inserir um secret stealer no GitHub Actions

Desde terça-feira, atacantes que dispunham de credenciais roubadas de 4.837 contas do GitHub introduziram um “secret stealer” Nos fluxos de integração contínua (CI) de repositórios aos quais essas contas podiam escrever, segundo a análise técnica publicada pela assinatura Aikido Security. O código malicioso foi projetado para exfiltrar qualquer segredo ou credencial no alcance das execuções do GitHub Actions e para pivotar para contas na nuvem usando tokens OIDC e outras credenciais que recuperavam do runner.

Os fatos confirmados por Aikido e outras assinaturas que publicaram análises complementares são claros em vários pontos: o atacante abriu testes iniciais mediante pull requests titulados “docs: dependency audit notes” desde ramos chamadas wfx-docs em pelo menos 61.764 repositórios públicos visíveis para Aikido; em 1.806 desses repositórios o stealer chegou a ser executado e presumivelmente exfiltró dados; e no total 4.837 contas foram usadas para abrir os testes. SafeDep, que fez um barrido independente, contabilizou 8.093 repositórios que receberam commits maliciosos na janela que analisaram, o que indica que o alcance real pode ser maior porque ambos conteos só consideram ramos por defeito e repositórios públicos visíveis para cada pesquisador.

Tecnicamente, o ataque seguiu um padrão repetivel: abrir uma PR desde wfx-docs para verificar se a conta atacada tinha permissão de escrita; se a verificação era positiva se acrescentava um passo (workflow) ou um hook de postinstall em npm que executava um script cuja soma SHA-256 é 89695abb392d5cfd4972672961e644bb46baa98a1ed7173c2a2816c762735cf. Esse binário/script tenta coletar chaves e tokens de várias fontes locais do runner — variáveis e secrets de Actions, GITHUB_TOKEN, tokens em runtime, metadados de instâncias em runners self-hosted, arquivos de configuração da AWS/Azure/GCP, chaves SSH, artefatos de workflow e até segredos residuais em memória de processos— e depois exfiltra por HTTP POST a servidores observados (por exemplo 194.150.166[.]244:8080, 18.143.168[.]96:8080, 153.75.82[.]159:8080) ou até mesmo um canal do Telegram, segundo SafeDep.

Uma vez que o stealer obteve credenciais OIDC ou tokens válidos podia trocar por sessões na AWS/GCP/Azure e, no caso da AWS, criar chaves de acesso de longa duração e modificar políticas de confiança (trust policy) para conceder acesso a contas externas. No Azure observou-se a criação de credenciais federadas com prefixos como wfx-ci- que permitem autenticação federada persistente desde workflows. Várias destas operações são concebidas para resistir a rotações de chaves.

Os indicadores técnicos fornecidos por Aikido —nomes de ramo (wfx-docs, chore/[a-z0-9]{8}, ci-check-[0-9]{4}), título de PR concreto, mensagens de commit frequentes (por exemplo, “ci: refresh build cache”, “chore: add ci helper”, “chore: add dependency audit workflow”) e a pegada SHA-256 do payload – permitem detectar pegadas da campanha. Aikido também sublinha que qualquer conta usada para abrir um destes PRs deve ser considerada comprometida, embora o stealer não chegasse a ser executado, porque a posse de credenciais foi demonstrada pela capacidade de criar ramos e PRs a partir delas.

Impacto prático e alcance: além de repositórios individuais, o atacante alcançou pipelines de publicação automatizada e pacotes. Aikido identifica uma versão maliciosa em Packagist (digitalelvis/neuronai-studio v3.14.3) e duas versões de um módulo Go contendo o stealer em seu workflow (github.com/onuragtas/docker-env v1.0.278 e v1.0.280). Em alguns casos, o código- fonte ou os binários não foram alterados; o risco veio pela presença do payload em arquivos de workflow ou por hooks de npm postinstall que seriam executados em máquinas de desenvolvedores. Aqueles que instalaram pacotes com esse postinstall ou executaram npm install em repositórios afetados devem assumir compromisso da máquina e agir em conformidade.

O que é conhecido com incerteza: as análises não identificaram publicamente como as credenciais das 4.837 contas foram inicialmente obtidas; não há nenhuma atribuição conclusiva do ator. Aikido assinala uma sobreposição com contas afetadas na onda conhecida como GhostAction em outubro, mas não atribui automaticamente ambos os eventos ao mesmo operador porque as infra-estruturas e métodos mostram diferenças e porque credenciais roubadas podem ser repartidas entre vários atacantes.

Consequências reais que os responsáveis devem assumir incluem perda de segredos e possível escalada em ambientes de nuvem inteiros (creação de chaves, modificação de políticas, incorporação de federação). Em repositórios onde o stealer foi executado, deve ser considerado comprometido tudo o que o workflow pudesse ler, incluindo secrets de Actions, variáveis, tokens OIDC, e papéis/credenciais na AWS/Azure/GCP.

Medidas concretas e priorização: primeiro, trate qualquer conta que abriu um teste como comprometida. Revoque imediatamente tokens de acesso pessoal, OAuth grants, chaves SSH e sessões. Active a autenticação de dois fatores (2FA) em contas com permissões de escrita. Em repositórios afetados, rote e reemplace Todas as secrets e variáveis que o workflow pudesse ler e considerar regenerar qualquer chave de API acessível do runner.

Para procurar por portas traseiras na nuvem, verifique os seguintes eventos e objetos (formas de detecção sugeridas): no Azure AD, procure credenciais federadas com prefixo wfx-ci-*; no AWS CloudTrail procure chamadas AssumeRoleWithWebIdentity ou sessões cujo nome contenha wfx-* seguidas de CreateAccessKey ou UpdateAssumeRolePolicy; em GCP rastree GenerateAccessToken e SignJwt desde sua pool de identidade de workloads. Também inspeccione os logs de Vault para JWT logins originados do emissor OIDC do GitHub. Essas buscas coincidem com os sinais que Aikido e SafeDep destacaram.

Se o seu repositório recebeu o commit malicioso, mas o workflow não chegou a ser executado, como revoque as credenciais do autor e rote segredos: Aikido esclarece que a mera capacidade de empurrar commits confirma controle da conta. Se executou um npm install em uma cópia que continha o hook malicioso, tente a máquina como comprometida: faça um reinstalado a partir de zero, revoque credenciais armazenadas localmente e rote chaves API e tokens usados a partir desse ambiente.

Para reduzir a superfície no futuro, aplique as práticas de endurecimento para o GitHub Actions: conceda o menor privilégio possível a Tokens, limite as permissões de GITHUB_TOKEN e active a autenticação OIDC com auditoria; use o runners self-hosted com isolamento e sem metadados acessíveis se não forem necessários; e configure regras para bloquear commits ou PRs que provem de ramos ou mensagens suspeitos. O GitHub mantém documentação sobre hardening e OIDC que pode servir de guia prático: GitHub — Security hardening with OpenID Connect e GitHub — Security hardening for GitHub Actions.

Além disso, audite as atividades de STS e OIDC em provedores de nuvem; por exemplo, a API da AWS para AssumeRoleWithWebIdentity e seu uso estão documentados aqui: AWS STS — AssumeRoleWithWebIdentity. Essas pesquisas ajudam a detectar tentativas de troca de tokens e criação de chaves que o stealer aproveita.

Resumo: a campanha tem mostrado um padrão automatizado e eficaz: uso de credenciais roubadas para inserir um stealer em workflows e hooks que exfiltran segredos e escalam em ambientes cloud. Se a sua organização usar o GitHub Actions, qualquer repositório em que uma conta tenha aberto o PR de teste deve ser considerado em risco até a revogação de credenciais, a rotação de secrets e a auditoria de papéis em nuvem e runners. A falta de uma atribuição clara e a possibilidade de o ator persista mediante federação implicam que a resposta deve ser ampla e rápida.