Pluto Security detalha campanha de mineração de criptomoedas Load/Mine no Hugging Face

A equipe de pesquisa da Pluto Security publicou, em 29 de outubro de 2026, seu relatório Load/Mine, que revela uma campanha de mineração de criptomoedas e backdoor distribuída por meio de repositórios maliciosos de modelos no Hugging Face. O relatório contabiliza 31 repositórios maliciosos em sete contas do Hugging Face, além de um espelho no ModelScope, com 29.818 downloads registrados da campanha e 32.376 quando são incluídos 13 repositórios vinculados. A Pluto afirma que esse número representa downloads, não infecções confirmadas nem vítimas únicas.

O relatório, de autoria de Shaked Chen, Eitan Chassid e Yotam Perkal, afirma que a campanha voltou poucos dias após a remoção inicial: 19 repositórios da segunda onda registraram mais de 29.000 downloads e ainda estavam ativos oito dias depois de a Pluto denunciá-los. Segundo o relatório, a carteira que recebeu os pagamentos da primeira onda obteve cerca de 2.276 PRL, aproximadamente US$ 5.000, em receitas de mineração na blockchain.

Como o código malicioso é executado

A campanha se baseia em um comportamento documentado de carregamento do Transformers, e não em pesos adulterados. Carregar um repositório com trust_remote_code=True importa o código Python do repositório com os privilégios de quem faz a chamada antes de carregar quaisquer pesos. O repositório config.json usa auto_map para especificar o módulo e a classe Python a carregar; o Transformers baixa o arquivo referenciado para o cache de módulos, e a exec_module() chamada executa o código de nível superior do arquivo antes de retornar a classe de modelo solicitada. O relatório observa que esse é um comportamento documentado, não o padrão, e que a política de segurança do Transformers instrui os usuários a verificar o conteúdo dos arquivos de modelagem ao usar o argumento. O relatório também cita a CVE-2026-22807, na qual versões do vLLM a partir da 0.10.1 e anteriores à correção na 0.14.0 carregavam auto_map módulos sem verificar a configuração trust_remote_code , permitindo que um repositório malicioso executasse código na inicialização do servidor.

Descoberta e associação entre contas

A Pluto criou um scanner que abrange cada .py arquivo referenciado por auto_map em um config.json, além de arquivos Python armazenados junto aos pesos dos modelos, identificando padrões como subprocess, socket, ctypes, memfd_create e decodificação em base64. A primeira detecção foi dsxk4mr8tq/qwen2-tiny-gpt2, que continha um arquivo de 305 linhas chamado modeling_evil.py; a conta tinha seis repositórios criados em um intervalo de 2,5 horas, em 12 de outubro de 2026.

A pista que permitiu atribuir a autoria veio dos arquivos de backup. O qwen2-tiny-lite repositório continha modeling_evil.py.bak-src e modeling_evil.py.bak-sync, versões anteriores do mesmo malware cujos URLs de download apontavam não para a conta descartável, mas para hhzz667 no Hugging Face e wssb123e no ModelScope. O relatório afirma que o operador copiou código de produção para uma conta de teste, atualizou os URLs no arquivo principal e se esqueceu dos backups. A primeira onda somou 12 repositórios em três contas e duas plataformas, com mais de 700 downloads registrados antes da remoção e nenhum alerta de segurança.

Anatomia do payload

Tomando MENXIANGYU/qwen2-tiny como exemplo representativo, o relatório descreve um payload que primeiro grava /tmp/.cch/svc.py, um mecanismo de monitoramento que reinicia um minerador ausente a cada 120 segundos, com comandos de inicialização acrescentados a /root/.bashrc, /root/.profile e ao .bashrc. Três versões acrescentam um shell reverso que se conecta a 212.32.253.3 pelas portas 443 ou 9443 e tenta se reconectar após cada desconexão.

O binário do minerador, syscore.bin, é iniciado por meio de memfd_create e fexecve disfarçado como o processo de kernel kworker/u20:1, sem deixar no disco um caminho para o executável na primeira inicialização; uma cópia de reserva persiste em /tmp/.cch/sync. O binário de 40,6 MB é compactado com UPX, com dois UPX! marcadores alterados para PEK! para que a ferramenta padrão de descompactação o rejeite; a Pluto restaurou os marcadores e descompactou um minerador chamado peakminer, iniciado com endereços de pools e o login krxXJ2PKQW.worker. Os comprovantes de progresso são gravados no registro local de modelos do Xinference como qwen2-tiny- seguidos por códigos de status em base32; o payload também remove registros de mineradores concorrentes e encerra processos correspondentes.

Duas ondas e adaptação após a remoção

O relatório atribui a primeira onda à conta hhzz667, criada em 29 de abril de 2026 e inativa havia cinco meses. Em 21 de setembro de 2026, ela publicou qwen2-shell, um backdoor SSH de 37 linhas que instala uma chave ed25519 em authorized_keys com um sinal de comunicação para um servidor da Alibaba Cloud; o README foi copiado do cartão oficial do modelo Qwen2.5-0.5B. Em 22 de setembro, o operador lançou qwen2-final, um minerador sem arquivo de 305 linhas, disfarçado de processo de kernel, com um mecanismo para eliminar mineradores concorrentes e enviar relatórios de status do Xinference sob nomes aparentemente inofensivos, como Qwen2Config. Os comentários no código estavam em chinês simplificado.

Pluto informou Hugging Face e ModelScope sobre a primeira onda, e as contas foram removidas. A segunda onda surgiu poucos dias depois: 19 repositórios em cinco contas, incluindo MENXIANGYU, com 13 repositórios, além de wjsbg, soumikmahato, r1r13 e htt0118, a última criada em 25 de outubro de 2026. Um repositório, MENXIANGYU/qa-whl-1021, publicado 8,5 horas após o e-mail de divulgação de Pluto, é um script de escape de contêiner para o host que monta discos do host, tem como alvo o diretório do GPUStack e /var/lib/gpustack permite fazer login como root no host. Um dropper posterior restringe o segundo estágio por IP de origem, retornando uma resposta 403 com o texto “IP estático.” para os demais solicitantes. O principal repositório MENXIANGYU/qwen2-tiny passou de 7.354 downloads em 20 de outubro para 28.412 em 28 de outubro, o que corresponde a 97,7% dos downloads da segunda onda.

Receitas da mineração e vítimas identificadas

A carteira da primeira onda recebeu cerca de 2.276 PRL em 716 transações e transferiu cerca de 2.241 PRL adiante; ela ainda estava ativa nos painéis públicos de pools em 21 de outubro, depois que os repositórios foram removidos. Na Kryptex, a carteira mostrava dois trabalhadores online que reportavam peakminer/2.16.5 cerca de 1.008 PRL, aproximadamente US$ 2.237 em recompensas nos 30 dias até o momento da captura. Durante a análise, nove trabalhadores com nomes no estilo de notebooks se conectaram em um intervalo de 90 segundos e pararam de enviar shares cerca de seis minutos depois; segundo o relatório, esse perfil é compatível com um cluster de GPUs compartilhado. Uma hl família rastreada separadamente, que usava execução semelhante no momento da importação, exibia uma carteira MoneroOcean com 13 trabalhadores e cerca de US$ 26 pagos em aproximadamente um mês.

Lacuna na cobertura dos scanners

Nenhum dos 12 repositórios da primeira onda foi sinalizado, e o payload principal da segunda onda modeling_evil2.py foi considerado “seguro” por todos os scanners executados; segundo as verificações de Pluto, a JFrog informou que ele não era um modelo de aprendizado de máquina. A documentação de varredura de malware do Hugging Face afirma que todos os arquivos de repositório menores que 2 GB passam por um scanner de malware a cada commit. A documentação de varredura de pickle informa que o scanner executa verificações antivírus com o ClamAV e verificações de importação de pickle; o ClamAV não cobre exploits de pickle, e a varredura “não é 100% infalível”, cabendo ao usuário verificar a segurança. Pluto afirma que examinar os .py arquivos que um auto_map indica antes de o sinalizador ser definido teria detectado todos os payloads da campanha, e que uma verificação estática no momento do envio para subprocess, socket, ctypes ou chamadas para IPs brutos em auto_maparquivos referenciados teria detectado os payloads mais cedo.

Avaliação de atribuição e medidas recomendadas

Pluto avalia que se trata de um operador ou pequeno grupo de língua chinesa, motivado financeiramente, citando comentários em chinês simplificado, um servidor de comando e controle da Alibaba Cloud, espelhamento no ModelScope e no hf-mirror.com, alvos que pressupõem o uso de Xinference e Tencent Cloud e concentração da atividade entre 18:38 e 21:19 UTC. A compilação “parasit” de soumikmahato contém comentários em indonésio, o que, segundo o relatório, é compatível tanto com um segundo operador no mesmo nicho quanto com um único operador que executa uma linha deliberadamente diferente na aparência.

O relatório recomenda que qualquer pessoa que tenha carregado um modelo listado com o código personalizado ativado verifique os hosts em busca de /tmp/.cch/processos inesperados, svc.py um processo kworker/u20:1 com argumentos de mineração, conteúdo codificado qwen2-tiny- ou ezv- registros de Xinference e conexões com os servidores e pools listados. Pluto recomenda isolar as máquinas afetadas, preservar as evidências, remover todas as formas de persistência, trocar as credenciais expostas usando uma máquina limpa, reconstruir o sistema a partir de uma imagem confiável quando não for possível confirmar a integridade do host, exigir autenticação na API do Xinference e fixar as revisões de modelos já analisadas. Pluto afirma que espera mais campanhas desse tipo e que está monitorando a situação.