Ladrão de segredos wfx no GitHub Actions: como caçá-lo quando rotacionar chaves não basta

Em 10 de novembro de 2026, uma campanha de roubo de credenciais que os pesquisadores chamam de wfx (também relatada como wfx-loot e WFX Phantom) começou a inserir ladrões de segredos de CI em repositórios do GitHub em grande escala. Os dados da SafeDep mostram commits maliciosos chegando a partir das 12:46 UTC de 10 de novembro.

A reação instintiva é rotacionar tudo. Você deve rotacionar, mas a rotação sozinha pode deixar ao atacante um caminho funcional de volta, por meio de configurações de confiança que nenhum segredo controla.

O que é o wfx e por que ele parece trabalho normal de desenvolvedor

Não há nenhum bug do GitHub Actions no centro disso. A análise da StepSecurity afirma que o atacante possui tokens válidos de contas reais de desenvolvedores e bots e os usa como um desenvolvedor faria, abrindo pull requests e enviando commits. Nada no seu feed de atividades parece um exploit. Parece um colega, ou um bot, fazendo trabalho de rotina.

A escala é grande. A Aikido relata que 4,837 contas comprometidas abriram pull requests de sondagem em 61,764 repositórios e que pelo menos 1,835 repositórios executaram o payload e tiveram credenciais exfiltradas. A SafeDep contou, de forma independente, 61,879 pull requests de sondagem em 61,734 repositórios a partir de 4,833 contas, com 91% ainda abertos. A StepSecurity relatou mais de 63,000 pull requests de sondagem até as 07:40 UTC de 12 de novembro, cerca de 90% deles ainda abertos, com novos surgindo a cada poucos minutos.

Por que os números dos pesquisadores diferem

Cada contagem mede algo diferente, em um momento diferente, então os números se complementam em vez de competir. A SafeDep contou 8,093 repositórios que receberam commits maliciosos entre as 12:46 UTC de 10 de novembro e as 04:36 UTC de 12 de novembro, e a campanha ainda estava ativa quando essa busca foi feita. A SecurityWeek observa que o número de commits não indica necessariamente execução bem-sucedida, enquanto o número da Aikido, de mais de 1,800 repositórios, reflete sinais de que o ladrão realmente foi executado. O próprio conjunto de dados da GitGuardian reúne 28,500 patches de payload de 2,367 contas em 17,715 repositórios.

Um pull request de sondagem significa que uma conta tentou entrar, um commit malicioso significa que ela tinha acesso de escrita, e uma execução confirmada significa que segredos provavelmente vazaram. Qual dessas três situações se aplica a você deve orientar seus próximos passos, e somente seus próprios logs podem dizer qual delas é.

Como o ladrão alcança os segredos de CI

Pull requests de sondagem testam o acesso

Sugerimos tratar qualquer pull request de sondagem como sinal de que alguém testou o que um token roubado conseguia alcançar. A Help Net Security relata que 10,431 dos pull requests de sondagem foram para repositórios que a conta não possuía, alcançados por meio de acesso de colaborador ou de organização. Assim, um único token roubado expõe todos os projetos nos quais seu dono pode escrever, independentemente de quem seja o dono do repositório.

A injeção em workflows foi a principal rota de entrega

Depois que o acesso é confirmado, o passo seguinte habitual é injetar o ladrão em um workflow existente. A StepSecurity encontrou mais de 21,000 commits com a mensagem ci: refresh build cache entre 10 e 12 de novembro. A SafeDep encontrou 1,343 repositórios em que o autor do commit malicioso era uma conta diferente da do dono, como um colaborador ou um bot. Esse segundo número importa para a definição do escopo, porque quando o token de um colaborador ou de um bot é roubado, o commit malicioso chega ao seu repositório em nome dele, e uma revisão que olha apenas a atividade do dono não vai detectá-lo.

A retenção do GitHub barrou uma variante, mas não a outra

A GitGuardian relata que toda execução de payload de novembro que ainda conseguia observar a partir de alterações em arquivos de workflow foi colocada em action_required e nunca começou. A variante com hook de npm não foi retida: em uma amostra de 19 repositórios em que o script foi executado, 18 relataram exfiltração bem-sucedida. Nossa leitura é que um hook de dependência pega carona em um workflow que já existe, em vez de chegar como uma alteração em arquivo de workflow, então um processo de revisão focado apenas em arquivos de workflow pode não sinalizá-lo. Para os defensores, isso significa revisar os manifestos de dependências com a mesma desconfiança dedicada aos arquivos de workflow.

Outras rotas: GitHub Apps e exfiltração via Telegram

Nem todo token roubado era pessoal. A StepSecurity descobriu que 173 pull requests de sondagem, abertos a partir de 19 contas, foram feitos por meio do GitHub App da Fly.io (app ID 34557). Seu escopo precisa abranger concessões OAuth e instalações de GitHub Apps, além de tokens de acesso pessoal. A exfiltração também mudou. As primeiras cópias enviavam dados para endereços IP específicos, e a StepSecurity relata que a mudança para o Telegram faz com que listas de bloqueio criadas a partir dos endereços IP de 10 de novembro deixem passar as cópias mais recentes. Uma ocorrência envolvendo esses endereços ainda merece investigação, mas um resultado vazio na lista de bloqueio diz muito pouco sobre se dados vazaram ou não.

Por que rotacionar chaves não encerra o comprometimento

O GitHub criou sua integração OIDC para limitar danos. A documentação do GitHub explica que o provedor de nuvem emite um token de acesso de curta duração, válido apenas para um único job, que depois expira. Um token OIDC roubado, por si só, não vale muito, então um atacante que quer permanecer precisa transformar essa janela curta em uma relação de confiança duradoura.

Credenciais de identidade federada do Entra como backdoor

No Azure, a credencial de identidade federada é a ferramenta óbvia para isso. A Microsoft a descreve como uma credencial que cria uma relação de confiança entre um aplicativo e um provedor de identidade externo. A Aikido relata que, uma vez instalado esse backdoor, qualquer workflow naquele repositório pode se autenticar no Azure sem um segredo armazenado, mesmo depois que todos os tokens forem rotacionados.

Políticas de confiança da AWS com escopo frouxo para o OIDC do GitHub

Na AWS, a exposição está nas políticas de confiança das roles. A AWS alerta que, se você não limitar a chave de condição token.actions.githubusercontent.com:sub a uma organização ou repositório específico, GitHub Actions de organizações ou repositórios fora do seu controle podem assumir roles associadas ao provedor de identidade do GitHub na sua conta.

A rotação substitui os segredos roubados, mas deixa a configuração de confiança exatamente como o atacante a deixou, e esse é o ponto que a liderança mais precisa ouvir antes de aprovar uma resposta como concluída.

A caça ao wfx: uma ordem de operações

Passo 1: Defina o escopo das identidades

Liste todas as contas humanas, bots e GitHub Apps com acesso de escrita em suas organizações, incluindo colaboradores externos. Qualquer conta que apareça em pull requests de sondagem é de alto risco. Sinalize também as contas atingidas na onda GhostAction de outubro: a Aikido descobriu que essas contas tinham probabilidade significativamente maior do que a média de serem afetadas pelo wfx, e a GitGuardian encontrou 431 contas do wfx, cerca de 20%, que já haviam sido comprometidas no GhostAction.

Passo 2: Pesquise no GitHub

Pesquise em todos os repositórios nos quais suas contas podem escrever, não apenas nos que você possui. Procure por:

• Pull requests de sondagem, abertos ou fechados, de contas que você não esperaria.
• Commits intitulados ci: refresh build cache, em branches padrão e não padrão.
• Alterações em arquivos sob .github/workflows/ desde 10 de novembro.
• Alterações em scripts de ciclo de vida do package.json, como preinstall, install e postinstall.

Passo 3: Verifique o histórico de execuções de workflows

Sugerimos comparar o histórico de execuções de workflows com o log de auditoria da sua organização e anotar quaisquer execuções que tenham sido excluídas, quem as excluiu e quando. Onde a execução for confirmada, presuma que todos os segredos disponíveis para aquele job foram expostos.

Passo 4: Revise as credenciais federadas do Microsoft Entra

Sugerimos listar as credenciais de identidade federada de todos os registros de aplicativo e de todas as identidades gerenciadas atribuídas pelo usuário. Investigue qualquer coisa que você não criou, qualquer emissor ou subject inesperado e qualquer subject que aponte para um repositório, branch ou ambiente que você não reconhece. Não encontramos uma fonte de fornecedor identificada que confirme um padrão de nomenclatura específico para credenciais maliciosas, então trate quaisquer nomes que circulem informalmente, como wfx-ci-*, como pistas não verificadas e não como indicadores, e lembre-se de que uma credencial renomeada não corresponderia de qualquer forma. Sugerimos usar seus logs de auditoria para determinar quando cada credencial foi adicionada e por quem, o que, a nosso ver, é um teste mais confiável do que qualquer nome.

Passo 5: Revise as políticas de confiança da AWS

Revise todas as roles do IAM que confiam no provedor OIDC do GitHub. A condição sub deve ser restrita a organizações e repositórios específicos e, idealmente, a branches ou ambientes específicos. Uma condição com escopo bem restrito fica assim:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
  }
}

Sugerimos então revisar sua trilha de auditoria na nuvem em busca de edições recentes em políticas de confiança, roles criadas recentemente e assunções de role a partir de repositórios que você não espera.

Passo 6: Revise o uso dos provedores de IA

Para cada chave da OpenAI, da Anthropic e do Gemini que o CI pudesse alcançar, revise o uso e o faturamento. Você está procurando gastos, modelos, regiões ou padrões de requisição que não se encaixam nas suas cargas de trabalho. Para as perguntas mais amplas a fazer quando chaves de IA podem ter sido abusadas, nosso checklist de risco para provedores de inferência pode ajudar.

Passo 7: Preserve as evidências antes de alterar qualquer coisa

Exporte logs de auditoria, registros de execução de workflows, metadados de pull requests e commits, entradas de auditoria do Entra e eventos do CloudTrail antes de iniciar a limpeza. Se você excluir um pull request ou uma credencial maliciosa sem manter um registro, perderá a linha do tempo de que precisará para definir o escopo, elaborar relatórios e fazer qualquer notificação regulatória.

Contenção e recuperação, em sequência

A sequência importa porque um segredo rotacionado pode ser obtido de novo por um caminho de confiança que continua ativo: enquanto uma credencial federada maliciosa ou uma política de confiança frouxa continuar funcionando, um workflow controlado pelo atacante consegue alcançar os novos valores tão facilmente quanto os antigos. A sequência que sugerimos:

1. Remova primeiro o acesso permanente do atacante. Exclua credenciais federadas maliciosas e restrinja as políticas de confiança da AWS antes da rotação, ou ao mesmo tempo.
2. Revogue o acesso ao GitHub. Revogue tokens de acesso pessoal comprometidos, concessões OAuth e instalações de GitHub Apps, incluindo apps de terceiros como o identificado pela StepSecurity.
3. Rotacione os segredos. Isso inclui segredos do Actions, chaves de nuvem, tokens de registros de pacotes e chaves de provedores de IA.
4. Limpe o código. Feche ou exclua pull requests de sondagem e reverta as alterações injetadas em workflows e pacotes nos branches padrão e nos demais. Qualquer pull request de sondagem deixado aberto em uma fila de revisão é uma chance de um mantenedor fazer o merge por engano.
5. Conclua a limpeza do GhostAction. A Aikido encontrou mais de 100 repositórios em que o wfx foi injetado em arquivos de workflow do GhostAction. Se a limpeza de outubro foi apenas parcial, conclua-a agora.
6. Monitore. Use os resultados da caça como linha de base e, daqui em diante, gere alertas para novas credenciais federadas, edições em políticas de confiança e alterações em arquivos de workflow.

Protegendo chaves de provedores de IA no CI

A nosso ver, as chaves de provedores de IA merecem um lugar explícito em qualquer plano de rotação, ao lado das credenciais de nuvem. A Cloud Security Alliance recomenda colocar as chaves de IA sob limites de gasto por projeto e alertas de anomalias de uso, preferir credenciais de curta duração ou intermediadas por proxy em vez de chaves estáticas no CI e incluir os provedores de IA nos runbooks de rotação para incidentes, ao lado das credenciais de nuvem e de registros.

Na prática, dê a cada projeto sua própria chave com seu próprio limite, para que um único vazamento não esgote um orçamento compartilhado. Sempre que possível, encaminhe as chamadas do CI por um proxy interno que guarde a chave real, para que o workflow nunca a veja; nosso guia sobre como um proxy de credenciais mantém as chaves de API longe dos agentes de IA explica esse padrão. A mesma disciplina se aplica antes do CI. Sugerimos verificar também as máquinas dos desenvolvedores, já que arquivos de configuração de agentes locais podem conter credenciais ativas; nosso passo a passo sobre auditoria de configurações locais de agentes e rotação de chaves expostas cobre essa verificação.

Erros comuns na resposta ao wfx

• Tratar a rotação como linha de chegada. Corrija primeiro a configuração de confiança (passo 1 da contenção).
• Confiar nas listas de bloqueio de IPs de 10 de novembro. Elas deixam passar as cópias da era Telegram.
• Presumir que a retenção do GitHub protegeu você. Verifique os hooks do package.json, não apenas os arquivos de workflow.
• Verificar apenas os repositórios que você possui. Defina o escopo pelo acesso de escrita, incluindo direitos de colaborador e de organização.
• Ler as contagens públicas como o seu veredito. Os números públicos não dizem se você foi atingido ou não; seus próprios logs dizem.
• Deixar a limpeza do GhostAction inacabada. Verifique novamente as contas e os arquivos de workflow de outubro.

Ressalvas e os limites do que sabemos

As contagens públicas vêm de buscas no GitHub em momentos específicos, enquanto a campanha ainda estava em andamento, então são retratos tirados no meio da campanha e não totais finais. Elas também medem coisas diferentes: pull requests abertos, commits recebidos e execução confirmada não são intercambiáveis, e a contagem de commits da SafeDep não significa necessariamente que o payload foi executado.

Sugerimos não presumir que conjuntos de dados externos reflitam o que aconteceu nos seus repositórios privados ou instâncias corporativas. Para a maioria das organizações, seus próprios logs de auditoria, logs do Entra e o CloudTrail são a evidência principal, e a pesquisa pública é contexto.

Os indicadores já mudaram uma vez, como mostra a troca de endereços IP fixos pelo Telegram. Mensagens de commit e nomes de credenciais também podem mudar, então consulte os IOCs mais recentes dos fornecedores antes de se apoiar em qualquer padrão isolado.

A Cloud Security Alliance, citando a GitGuardian, relata que o GhostAction usou cerca de 1,900 contas comprometidas para atingir mais de 30,000 repositórios em outubro. Comparado à contagem da Aikido de 61,764 repositórios para o wfx, isso resulta em duas ondas com cerca de um mês de intervalo, a segunda com aproximadamente o dobro do tamanho em repositórios atingidos. Dois pontos de dados não bastam para apontar uma tendência, mas são motivo suficiente para se preparar para outra onda.

Este guia não substitui um trabalho formal de resposta a incidentes quando há dados regulados ou acesso a nuvem de produção envolvidos.