Contas do GitHub sequestradas: wfx-loot rouba segredos

O que é a campanha wfx-loot no GitHub?

A wfx-loot é uma campanha em que um atacante usa credenciais roubadas do GitHub para enviar um workflow malicioso a repositórios em que essas contas podem gravar, roubando segredos do GitHub Actions e credenciais de nuvem ^[1]. A Aikido Security, que a relatou primeiro, deu esse nome a partir do nome que o próprio atacante usa para o malware (“wfx”) e da palavra empregada para os segredos roubados (“loot”) ^[1]. A SafeDep também credita à Aikido o primeiro relato ^[5].

A StepSecurity chama o mesmo ladrão de “wfx” e destaca um ponto-chave: o atacante não explora uma falha do GitHub Actions ^[2]. Em vez disso, ele usa tokens válidos de contas reais de desenvolvedores e de bots, abrindo pull requests e enviando commits como um desenvolvedor faria ^[2][4].

A Aikido acredita que o objetivo principal são os segredos de CI, e não se espalhar por pacotes de software, embora a carga maliciosa tenha chegado a pelo menos um pacote do Packagist e um do Go por meio de gatilhos de publicação automatizada ^[1]. O BleepingComputer, com base na análise da Aikido, relata que algumas das contas comprometidas pertenciam a grandes organizações ^[3].

Qual o tamanho do ataque wfx-loot?

A Aikido contabiliza 4.837 contas comprometidas que abriram pull requests de sondagem em 61.764 repositórios, com o ladrão executado em pelo menos 1.806 repositórios ^[1]. Os números diferem um pouco entre os pesquisadores porque cada um pesquisou o GitHub em um momento diferente, enquanto a campanha ainda estava ativa.

• Aikido: 4.837 contas, 61.764 repositórios; 10.431 pull requests foram para repositórios que a conta não possui; 92% ainda abertos; pelo menos 50 usuários comprometidos publicam pacotes no npm, Go, Packagist, PyPI ou crates ^[1].
• Aikido (número do resumo): pelo menos 1.835 repositórios executaram a carga e tiveram credenciais levadas; o BleepingComputer usa esse número ^[1][3].
• StepSecurity: mais de 63.000 pull requests de sondagem às 07:40 UTC de 12 de novembro, cerca de 90% ainda abertos ^[2].
• SafeDep: 8.093 repositórios receberam commits maliciosos entre 10 e 12 de novembro, número que, como observa o SecurityWeek, não significa necessariamente que o ladrão tenha sido executado ^[5][4].

A Aikido alerta que sua contagem de execuções pode subestimar o impacto, porque os logs de execução foram apagados nos repositórios afetados ^[1].

Como funciona o ladrão wfx-loot?

Para cada repositório em que um token roubado pode gravar, o atacante sonda, envia a carga maliciosa e depois limpa os rastros em cerca de um minuto ^[1].

1. Sondagem: um pull request intitulado “docs: dependency audit notes”, a partir de uma branch chamada wfx-docs, adiciona um pequeno arquivo de notas. “O pull request não faz nada por si só”, diz a StepSecurity; ele apenas mostra que o token tem acesso de gravação ^[2][4].
2. Carga maliciosa: um script de shell de cerca de 1.500 linhas chega de uma entre três formas: injetado em um workflow existente (“ci: refresh build cache”), como um script mais um hook postinstall do npm (“chore: add ci helper”), ou como um novo workflow em uma branch chore/ descartável (“chore: add dependency audit workflow”) ^[1].
3. Limpeza: o atacante reverte a alteração e apaga a execução do workflow e seus logs ^[1]. Um número de execução ausente costuma ser o único vestígio ^[1].

O script coleta segredos e tokens do GitHub Actions, todo o ambiente do runner, arquivos de credenciais da AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH e mais, históricos de shell e chaves de provedores de IA e de ferramentas de desenvolvimento ^[1][3]. Ele chega a ler a memória dos processos em execução no runner ^[1][4]. A Aikido constatou que as cópias que analisou enviavam os dados roubados apenas por HTTP POST a servidores controlados pelo atacante ^[1]. A StepSecurity viu depois uma mudança: a partir de cerca das 05:30 UTC de 12 de novembro, as novas cópias passaram a enviar dados somente pelo Telegram, de modo que bloquear apenas os endereços de servidor divulgados já não as detém ^[2].

Por que trocar os segredos não basta?

Porque o ladrão tenta plantar backdoors que sobrevivem à troca de credenciais ^[1][2]. A Aikido descreve três truques de persistência ^[1]:

• Verificações de status falsificadas: a Aikido diz que ele publica falsas verificações de “sucesso” com os nomes das verificações obrigatórias de um repositório, o que pode liberar as barreiras de merge da proteção de branch ^[1]. A StepSecurity constatou esse recurso desativado em todas as 101 amostras que examinou ^[2].
• Reescrita da política de confiança da AWS: ele pode definir a política de confiança de uma role para permitir qualquer conta da AWS ^[1].
• Injeção de identidade federada no Azure: ele pode adicionar credenciais federadas chamadas wfx-ci-… a aplicativos do Azure AD, permitindo que workflows do repositório comprometido se autentiquem sem um segredo armazenado ^[1].

Ele também pode gerar tokens OIDC do GitHub e trocá-los por sessões da AWS, do Google Cloud e do Azure, encadear outras roles IAM e criar chaves de acesso da AWS de longa duração ^[1][3]. Por isso a StepSecurity diz para “remover a persistência, porque a troca por si só não a remove” ^[2].

Como verificar se meus repositórios do GitHub foram atingidos?

Procure o pull request de sondagem e as mensagens de commit do atacante desde 10 de novembro e depois verifique se há lacunas nos números de execução dos workflows ^[2][1].

1. Pesquise pull requests com “docs: dependency audit notes” e branches chamadas wfx-docs ou chore/ seguidas de oito caracteres ^[1][2].
2. Pesquise commits desde 10 de novembro com “ci: refresh build cache”, “ci: restore”, “ci: cleanup”, “chore: add ci helper” e “chore: add dependency audit workflow” ^[2].
3. Para cada resultado, abra a aba Actions e procure um número de execução ausente logo após o commit; a StepSecurity chama isso de o sinal mais confiável de que o ladrão foi executado ^[2].
4. Anote qual conta enviou os commits: os tokens dessa conta foram roubados ^[2]. Se existe um pull request de sondagem, a conta está comprometida mesmo que nenhuma carga tenha sido executada ^[1].

Não confie na ausência de artefatos. A Aikido diz que a ausência de artefatos wfx-loot, de entradas de cache wfx- ou de resumos de etapa especiais não significa que os dados não foram levados, porque esses canais foram desativados nesta campanha ^[1]. A Aikido também sugere que a carga pode ser implantada em repositórios privados além dos públicos ^[1].

O que fazer se o ladrão foi executado?

Presuma que todo segredo e toda role de nuvem disponíveis ao workflow afetado estão comprometidos, troque-os e depois procure por persistência ^[1][2].

• Trocar: todos os segredos de repositório, de ambiente e de organização que o job podia alcançar, não apenas os que o workflow cita; tokens de publicação do npm, do PyPI e de outros; e chaves de nuvem armazenadas como segredos ^[2].
• Verificar pacotes: procure versões de pacotes publicadas depois do commit malicioso ^[2].
• AWS: procure políticas de confiança que permitam qualquer principal da AWS, chaves de acesso IAM criadas desde 10 de novembro e sessões do CloudTrail começando com wfx- ^[2].
• Azure: exclua as credenciais de identidade federada chamadas wfx-ci-* nos registros de aplicativos ^[2].
• Google Cloud, Vault, Kubernetes: revise a geração de tokens e os logins feitos com tokens de autenticação do GitHub Actions ^[2].
• GitHub: exclua as branches remanescentes, feche os pull requests de sondagem, verifique se nada foi mesclado com uma verificação falsificada e revogue os tokens, as concessões OAuth e as chaves SSH da conta ^[2].
• Tokens, segundo a documentação do GitHub: revise seus tokens de acesso pessoal em Settings, Developer settings e exclua os que você não reconhece ou não precisa; o GitHub recomenda tokens refinados (fine-grained), apenas as permissões mínimas necessárias e uma data de expiração, porque um token clássico pode acessar todos os repositórios que você acessa ^[6].

O hook do npm também é executado em máquinas de desenvolvedores: quem executou npm install durante a curta janela rodou o ladrão localmente e deve trocar também as próprias credenciais ^[2]. O SecurityWeek resume a orientação de várias empresas de segurança: revogar tokens comprometidos, trocar segredos expostos e verificar alterações não autorizadas na nuvem ^[4]. Para contas de bot, a StepSecurity também sugere avaliar se elas precisam mesmo de permissão para contornar a proteção de branch ^[2]. Uma proteção de login forte dificulta campanhas com contas roubadas; veja Autenticação em dois fatores explicada: qual método de 2FA é o mais seguro?.

Quais pacotes foram afetados?

A Aikido lista um pacote do Packagist e um módulo Go que receberam a carga por publicação automatizada ^[1].

• Packagist: digitalelvis/neuronai-studio versão 3.14.3; a Aikido diz para tratar como comprometida qualquer máquina que o tenha instalado ou aberto ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 e v1.0.280; a carga está apenas em um arquivo de workflow do GitHub Actions, o código-fonte e os binários do Go não mudaram, e as compilações do Go nunca executam arquivos de workflow, mas a Aikido ainda recomenda remover essas versões ^[1].

As contagens diferem: a SafeDep diz que três pacotes no Packagist e no proxy de módulos do Go levam a carga, e o SecurityWeek menciona versões de dois módulos Go ^[5][4]. A SafeDep acrescenta que a carga não foi executada para os consumidores típicos que instalam esses pacotes com composer require ou go get ^[5]. Consulte a lista atual de cada pesquisador antes de confiar em qualquer uma delas.

Quem está por trás da wfx-loot e como obteve os tokens?

Nenhum dos relatos citados aqui identifica o atacante, e a StepSecurity diz que não estabeleceu como os tokens foram obtidos ^[2][4].

A StepSecurity encontrou 173 pull requests de sondagem, de 19 contas, feitos com tokens emitidos ao GitHub App da Fly.io; disse que não conseguiu determinar como foram obtidos e que não tinha evidências de que a infraestrutura da Fly.io tenha sido violada ^[2][4].

A Aikido encontrou sobreposição com contas atingidas pela onda GhostAction de outubro e viu a wfx-loot injetada em arquivos de workflow do GhostAction em mais de 100 repositórios, mas avaliou as duas como campanhas distintas, provavelmente conduzidas por agentes diferentes, já que credenciais roubadas costumam acabar nas mãos de vários grupos ^[1]. Também notou comentários em indonésio em algumas versões mais novas do malware ^[1]. Guardar os tokens com cuidado importa aqui; Gerenciadores de senhas explicados: como funcionam e se são seguros cobre o básico.