
Projeto Open-OSS/privacy-filter copiou a apresentação do openai/privacy-filter, alcançou destaque na plataforma e acionava uma cadeia Windows com PowerShell, exclusões no Defender e exfiltração de dados sensíveis.
| Componente | Repositório Open-OSS/privacy-filter no Hugging Face, criado para se passar pelo modelo legítimo openai/privacy-filter. |
| Vetor | Execução manual de start.bat no Windows ou loader.py em ambientes Unix-like após clonagem do repositório falso. |
| Impacto | Download e execução de infostealer em Rust capaz de coletar capturas de tela, dados de Discord, carteiras de criptomoedas, extensões, navegadores Chromium e Gecko, metadados do sistema e arquivos locais sensíveis. |
| Prioridade | Bloquear os domínios observados, auditar hosts que executaram o repositório falso, revisar exclusões do Microsoft Defender e rotacionar credenciais, tokens e seeds expostos. |
| Artefatos | loader.py, start.bat, cmd.exe, PowerShell, tarefa agendada temporária, o0q2l47f.exe e CodeRun102.exe. |
| IoCs | api.eth-fastscan[.]org, api[.]eth-fastscan[.]org, recargapopular[.]com e welovechinatown[.]info. |
Um repositório malicioso no Hugging Face, identificado como Open-OSS/privacy-filter, foi estruturado para imitar o modelo aberto openai/privacy-filter, associado à detecção e redação de informações pessoalmente identificáveis em texto não estruturado. A falsificação não se limitou ao nome: a descrição do projeto legítimo foi copiada para reduzir suspeitas durante a avaliação inicial por usuários interessados em integrar proteção de privacidade a aplicações de IA. O repositório falso chegou à primeira posição de tendências da plataforma antes de ser desabilitado, acumulando aproximadamente 244 mil downloads e 667 curtidas em cerca de 18 horas. A velocidade e o volume desses sinais indicam provável inflagem artificial para criar aparência de confiança e induzir mais instalações.
A carga real não era um modelo funcional de privacidade, mas uma cadeia de infecção voltada a usuários Windows. O fluxo começava quando a vítima clonava o projeto e executava os scripts sugeridos pelo próprio repositório. No Windows, o ponto de entrada era start.bat; em Linux e macOS, o repositório instruía o uso de loader.py. O componente Python continha lógica para desabilitar verificação SSL, resolver uma URL codificada em Base64 hospedada em um serviço público de JSON e obter comandos que eram repassados ao PowerShell. Essa separação permitia aos operadores trocar payloads sem alterar o repositório, preservando a fachada do pacote enquanto a infraestrutura remota controlava os estágios seguintes.
A campanha combina abuso de confiança em ecossistemas de modelos de IA, técnicas comuns de supply chain e execução de malware em estáções de trabalho. O risco principal recai sobre pesquisadores, desenvolvedores e equipes que testam modelos recém-publicados a partir de instruções fornecidas em cartões de modelo, especialmente quando esses scripts pedem execução local com permissões interativas. A presença de domínios compartilhados com outra atividade envolvendo pacote npm malicioso e ValleyRAT amplia a hipótese de uma operação mais abrangente contra ecossistemas abertos, embora a atribuição definitiva dependa de telemetria adicional e correlação independente.
O loader.py atuava como resolvedor inicial. Após a execução, o script alterava o comportamento padrão de validação TLS, decodificava uma URL em Base64 e consultava um conteúdo hospedado no JSON Keeper. O uso de um serviço de paste como dead drop resolver reduz a necessidade de manter indicadores fixos dentro do repositório e permite que o operador altere o comando de próxima etapa com baixo atrito. O comando recuperado era entregue ao PowerShell, que então baixava um script em lote a partir de api.eth-fastscan[.]org e o executava por meio de cmd.exe. Essa arquitetura cria uma divisão clara entre isca, resolvedor, downloader e payload final.
O segundo estágio preparava o ambiente Windows antes de iniciar o binário final. O script em lote elevava privilégios por meio de um prompt de Controle de Conta de Usuário, criava exclusões no Microsoft Defender Antivirus, baixava o executável seguinte a partir da mesma infraestrutura e registrava uma tarefa agendada para iniciar um script PowerShell responsável por executar o malware. A tarefa agendada não foi usada como persistência duradoura: após a execução, o malware aguardava cerca de dois segundos e removia seus próprios artefatos temporários. A função da tarefa era obter execução em contexto SYSTEM uma única vez, não sobreviver a reinicializações.
O estágio final era um infostealer escrito em Rust. As capacidades descritas incluem captura de tela, coleta de metadados do sistema, busca por dados do Discord, carteiras de criptomoedas, extensões relacionadas a criptoativos, configurações do FileZilla, frases-semente de carteiras e dados de navegadores baseados nos motores Chromium e Gecko. O malware também executava verificações contra depuradores, sandboxes e máquinas virtuais, além de tentar interferir no Windows Antimalware Scan Interface e no Event Tracing for Windows. A exfiltração dos dados ocorria em formato JSON para recargapopular[.]com, concentrando informações de identidade, sessão, arquivos locais e ambiente em uma estrutura adequada para processamento automatizado pelo operador.
A exposição principal está em hosts que clonaram ou executaram o repositório Open-OSS/privacy-filter antes de sua remoção. O impacto confirmado se concentra em Windows, pois a cadeia de maior risco depende de PowerShell, cmd.exe, elevação via UAC, exclusões no Microsoft Defender e tarefa agendada. A presença de instruções para Linux e macOS ainda deve ser tratada como sinal de tentativa de ampliar a superfície, mas os artefatos descritos para execução completa apontam para comprometimento Windows. Ambientes de pesquisa, notebooks de desenvolvimento, estáções com acesso a repositórios privados, navegadores autenticados, clientes de Discord e carteiras digitais são os ativos com maior probabilidade de dano.
O incidente também mostra uma superfície específica de ecossistemas de IA: a confiança depositada em cartões de modelo, instruções de instalação e métricas de popularidade. Um projeto que copia a descrição de um modelo legítimo e aparece em tendências pode atravessar controles manuais superficiais, principalmente quando a equipe avalia rapidamente novas publicações. Downloads, curtidas e posição em ranking não devem ser tratados como prova de legitimidade. Para modelos e datasets, o conteúdo executável associado ao repositório deve ser avaliado separadamente dos pesos, da documentação e do nome do mantenedor.
- Estáções Windows que executaram
start.bat,loader.pyou comandos PowerShell derivados do repositório falso. - Navegadores Chromium e Gecko com sessões, cookies, senhas, extensões ou perfis acessíveis ao usuário comprometido.
- Clientes e arquivos locais relacionados a Discord, FileZilla, carteiras de criptomoedas e frases-semente armazenadas em texto ou arquivos previsíveis.
- Ambientes de desenvolvimento que clonam modelos de IA diretamente em máquinas com credenciais de nuvem, repositórios privados ou acesso a pipelines.
A caça deve começar por eventos de processo nos endpoints. Procure execução de python.exe ou pythonw.exe iniciando loader.py, chamadas subsequentes a powershell.exe, criação de cmd.exe como filho de PowerShell e downloads de scripts a partir de domínios relacionados a eth-fastscan. Em seguida, revise alterações no Microsoft Defender, principalmente criação de exclusões próximas ao momento de execução do script. Como o malware tenta interferir em AMSI e ETW, a ausência de telemetria após uma cadeia de execução suspeita também deve ser tratada como evidência contextual, não como indicação de limpeza.
No Windows, eventos de tarefa agendada são particularmente importantes. A campanha usou a tarefa como lançador temporário em contexto elevado, com remoção antes da reinicialização. Isso reduz a chance de encontrar persistência ativa após o incidente, mas deixa rastros em logs de criação, execução e exclusão de tarefas, além de artefatos no histórico do PowerShell, cache de scripts, Prefetch e eventos de segurança relacionados a elevação. Em rede, a investigação deve correlacionar requisições para api.eth-fastscan[.]org, api[.]eth-fastscan[.]org, recargapopular[.]com e welovechinatown[.]info, considerando que o dead drop pode ter servido comandos variáveis ao longo do tempo.
Também é necessário revisar sinais fora do host. Em repositórios internos, procure referências ao clone do projeto falso, commits que adicionem Open-OSS/privacy-filter, arquivos start.bat ou loader.py provenientes da amostra e execuções em pipelines. Em logs de proxy, EDR e DNS, correlacione o primeiro acesso ao Hugging Face com downloads subsequentes para infraestrutura externa. Caso a máquina tenha armazenado credenciais de nuvem, tokens de Git, chaves de API ou seeds de carteiras, a investigação deve assumir possível exposição mesmo que a exfiltração observada tenha falhado.
- Processos
powershell.exeiniciados por Python ou por scripts obtidos de diretórios associados ao clone do repositório. - Conexões DNS ou HTTP para
api.eth-fastscan[.]org,api[.]eth-fastscan[.]org,recargapopular[.]comewelovechinatown[.]info. - Criação e remoção de tarefas agendadas em janela curta, especialmente antes de execução de binários recém-baixados.
- Novas exclusões no Microsoft Defender Antivirus sem mudança administrativa documentada.
- Tentativas de desativação ou bypass de AMSI e ETW próximas à execução de PowerShell.
A resposta deve tratar qualquer execução do repositório falso como comprometimento de endpoint, não apenas como download de pacote suspeito. Primeiro, isole a máquina afetada para preservar evidências e impedir novas exfiltrações. Em seguida, colete eventos de processo, PowerShell, tarefas agendadas, Microsoft Defender, DNS, proxy e EDR antes de limpar artefatos. Remova scripts, binários e tarefas remanescentes, reverta exclusões criadas no Defender e valide se AMSI e ETW estão operacionais. A ausência de persistência duradoura descrita na cadeia não elimina o impacto, pois o objetivo do infostealer é coletar e enviar dados em uma única execução.
A contenção precisa incluir rotação de segredos. Tokens de Git, chaves de API, sessões de navegadores, credenciais salvas, cookies, tokens de Discord, credenciais de FTP e seeds de carteiras presentes no host devem ser considerados expostos. Para carteiras de criptomoedas, a ação defensiva não é apenas trocar senha: fundos devem ser movidos para carteiras novas quando houver indício de acesso a frases-semente ou extensões comprometidas. Para ambientes corporativos, revise acessos recentes de contas usadas no endpoint, invalide sessões, force reautenticação e procure uso anômalo em serviços de nuvem e repositórios.
Como medida preventiva, organizações que consomem modelos de IA devem separar avaliação de modelos de execução de scripts. Repositórios externos devem ser clonados em sandboxes descartáveis sem credenciais persistentes, sem perfil de navegador real e sem carteiras ou tokens locais. Scripts auxiliares como start.bat, loader.py, hooks de instalação e comandos PowerShell devem passar por revisão antes da execução. Métricas de popularidade em plataformas públicas não substituem verificação de mantenedor, histórico do projeto, assinatura de artefatos, diferenças entre forks e análise de código executável.
- Bloquear os domínios observados em DNS, proxy, firewall e EDR, mantendo alerta para variações da infraestrutura.
- Auditar endpoints que clonaram ou executaram
Open-OSS/privacy-filter, com foco em PowerShell, tarefas agendadas e exclusões no Defender. - Rotacionar credenciais e tokens presentes em hosts afetados, incluindo Git, nuvem, navegadores, Discord, FTP e carteiras.
- Executar modelos e scripts de repositórios públicos em ambientes descartáveis sem segredos, perfis reais de navegador ou acesso direto a redes internas.
- Adicionar verificação de namespace e mantenedor para modelos de IA, bloqueando typosquatting e clones que copiam cartões de modelos legítimos.
0 Comentários