Botnet de mineração mira instâncias ComfyUI expostas na internet

Campanha explora implantações ComfyUI sem autenticação adequada para executar código por nós personalizados, instalar mineradores, manter persistência e transformar hosts comprometidos em proxies.

Componente	Instâncias ComfyUI expostas publicamente, especialmente implantações com ComfyUI-Manager e famílias de nós personalizados capazes de executar Python arbitrário.
Vetor	Varredura automatizada de faixas de IP em provedores de nuvem, seguida de abuso de nós personalizados sem autenticação; quando o nó vulnerável não existe, o operador tenta instalá-lo via ComfyUI-Manager.
Impacto	Execução remota de código, instalação de mineradores XMRig e lolMiner, persistência local, ocultação de processos, eliminação de mineradores rivais e possível uso do host como nó de proxy Hysteria V2.
Prioridade	Remover exposição direta do ComfyUI, exigir autenticação e controle de rede, auditar nós personalizados e ComfyUI-Manager, investigar processos de mineração e revisar persistência em crontab, systemd e chaves SSH.
Versões	O contexto não delimita versões específicas do ComfyUI; a condição relevante é a implantação acessível pela internet com nós personalizados inseguros ou ComfyUI-Manager disponível.
Artefatos	ComfyUI-Shell-Executor, ghost.sh, q11.txt, q12.txt, XMRig, lolMiner, Hysteria V2, LD_PRELOAD e painel de comando e controle baseado em Flask.
IoCs	Exemplos defangados citados no contexto incluem 77.110.96[.]200 como infraestrutura de diretório aberto e 120.241.40[.]237 como endereço associado a tentativa de login SSH observada.
Mitigação	Isolar serviços ComfyUI da internet, restringir instalação de nós, remover pacotes não confiáveis, invalidar persistência adicionada, coletar evidências antes da limpeza e validar que não há Docker API ou Redis sem autenticação na rede local.

Resumo técnico

Uma campanha ativa está mirando mais de 1.000 instâncias ComfyUI acessíveis publicamente para montar uma botnet voltada a mineração de criptomoedas e intermediação de tráfego. O alvo é uma superfície típica de ambientes de IA generativa executados de forma experimental ou operacional em servidores de nuvem: interfaces expostas na internet, dependência de extensões de terceiros e permissões amplas para execução de fluxos personalizados. O ataque não depende de uma vulnerabilidade identificada por CVE no material analisado; a condição explorada é uma combinação de exposição remota, ausência de autenticação efetiva e nós personalizados capazes de aceitar código Python bruto ou instalar componentes adicionais por meio do ComfyUI-Manager.

O operador usa scanners em Python criados especificamente para enumerar instâncias ComfyUI em faixas de IP de grandes provedores de nuvem, verificar se o ComfyUI-Manager está presente e identificar nós personalizados que ofereçam execução insegura. Quando um nó vulnerável já existe, a cadeia usa esse caminho para entregar código controlado pelo invasor. Quando o nó não está disponível, o scanner tenta usar o ComfyUI-Manager para instalar um pacote malicioso chamado ComfyUI-Shell-Executor, que busca um script de próximo estágio e transforma o host em parte da operação. O resultado observado inclui mineração com XMRig para Monero, mineração com lolMiner para Conflux e instalação de Hysteria V2, possivelmente para monetizar os sistemas comprometidos como proxies.

A campanha também revela evolução operacional. O payload principal recebeu ajustes para detecção de sandbox, ocultação de processos, remoção agressiva de concorrentes e propagação para serviços internos mal configurados. Há mecanismos para reiniciar a cadeia a cada inicialização do ComfyUI, baixar novamente o script em intervalos recorrentes, manter cópias do minerador em múltiplos caminhos e dificultar remoção de binários. A presença de um painel de comando e controle baseado em Flask indica administração centralizada dos hosts, com capacidade de enviar instruções ou implantar cargas adicionais. Para defesa, o caso deve ser tratado como comprometimento de servidor Linux exposto, não apenas como consumo anômalo de CPU.

Fluxo técnico

A primeira fase é reconhecimento automatizado. Dois utilitários de varredura foram descritos no contexto: ambos procuram instâncias ComfyUI expostas em infraestrutura de nuvem, enquanto um deles também funciona como estrutura de exploração. A lógica procura famílias específicas de nós personalizados que aceitam entrada em Python e a executam sem exigir autenticação. Esse desenho transforma um recurso legítimo de extensibilidade em canal de execução remota quando o serviço é publicado sem barreiras de acesso. A exploração fica condicionada à presença desses nós ou à possibilidade de instalá-los por meio do ComfyUI-Manager.

Quando o ComfyUI-Manager está instalado, o fluxo passa a ter uma segunda rota. Em vez de depender apenas do que já existe no alvo, o scanner tenta introduzir o próprio componente vulnerável. O pacote ComfyUI-Shell-Executor foi criado para buscar um próximo estágio a partir de infraestrutura controlada pelo operador. O contexto cita que o pacote primeiro foi observado entregando um arquivo intermediário chamado q11.txt, que desempacotava ghost.sh, e depois foi atualizado em 2 de abril de 2026 para buscar q12.txt; essa alteração foi revertida em 9 de abril de 2026 no repositório associado. Esses nomes são úteis para caça em artefatos locais, caches de pacotes, histórico de extensões e logs de requisições de saída.

Após obter execução, o operador tenta reduzir rastros dentro da própria aplicação ao limpar o histórico de prompts do ComfyUI. Essa limpeza não elimina necessariamente evidências em logs de sistema, rede, processo ou shell, mas remove um artefato que poderia indicar a entrada usada na aplicação. Em seguida, a cadeia baixa e executa um script shell de instalação. Como a publicação de comandos copiáveis aumentaria o risco operacional, o detalhe relevante para defesa é o comportamento: o script desativa histórico de shell, encerra mineradores concorrentes, inicia o processo de mineração, usa LD_PRELOAD para esconder um processo de vigilância e tenta recriar o minerador caso ele seja encerrado.

A persistência aparece em várias camadas. Uma versão mais nova do scanner configura a repetição do download do script em janelas de seis horas e também reexecuta o fluxo quando o ComfyUI é iniciado. O minerador é copiado para mais de um local, permitindo retomada caso o diretório principal seja removido. O malware também usa o atributo de imutabilidade de arquivos do Linux para impedir exclusão, modificação ou renomeação de binários, inclusive por usuários com privilégios elevados, caso a defesa tente uma limpeza superficial. Além disso, há referência a inserção de um stub de chave SSH em authorized_keys, o que sugere tentativa de manter acesso remoto persistente.

A disputa por recursos é tratada de forma agressiva. O script encerra processos que consomem mais de 80% de CPU, examina execuções vindas de diretórios temporários como /tmp, memória compartilhada e /var/tmp, e remove entradas de crontab ou serviços systemd associados a mineração rival. O código também mira um concorrente chamado Hisana: em vez de apenas finalizar essa operação, altera sua configuração para redirecionar a mineração ao próprio operador e ocupa a porta de comando e controle do concorrente com um listener falso. Essa conduta mostra que o objetivo não é discrição prolongada em ambiente corporativo tradicional, mas controle de capacidade computacional e eliminação de competição em hosts já expostos.

A etapa de expansão inclui caminhos além do ComfyUI. A versão atualizada possui rotina chamada spread_docker_api, que procura na sub-rede local servidores Docker sem autenticação na porta 2375 e, quando encontra um daemon exposto, cria um contêiner privilegiado com o sistema de arquivos do host montado para executar o mesmo fluxo de instalação. O contexto também menciona varredura por Redis sem autenticação para propagar o script. Essas rotas não confirmam movimentação lateral ampla em todos os incidentes, mas elevam o risco em redes onde serviços administrativos foram deixados acessíveis internamente sem controle de identidade, segmentação ou firewall.

Superfície afetada

A superfície principal é qualquer instância ComfyUI publicada diretamente na internet sem autenticação forte, filtragem por origem ou proteção de camada de aplicação. O risco cresce quando a implantação permite instalação de nós por ComfyUI-Manager, carrega extensões de procedência desconhecida ou mantém nós personalizados que executam Python a partir de entradas remotas. Como ComfyUI costuma ser usado em ambientes de geração de imagens e fluxos de IA, equipes podem tratá-lo como ferramenta interna temporária e deixar controles básicos fora do padrão aplicado a sistemas web corporativos. Essa diferença de maturidade operacional é justamente o que torna a exposição útil para campanhas oportunistas.

Servidores Linux com permissões amplas para o processo da aplicação ficam mais expostos ao impacto completo. Se o usuário que executa o ComfyUI consegue escrever em caminhos sensíveis, criar tarefas recorrentes, manipular serviços, alterar atributos de arquivos ou adicionar chaves SSH, o comprometimento sai do escopo da aplicação e passa a afetar o host. A presença de Docker API sem autenticação na porta 2375 ou Redis sem autenticação na rede local amplia o risco para outros ativos próximos. O contexto também indica que há infraestrutura ligada a diretório aberto em 77.110.96[.]200 e uma tentativa de login SSH como root para 120.241.40[.]237, ambos defangados aqui para evitar publicação de indicadores ativos.

A campanha não deve ser confundida com exploração genérica de todos os sistemas de IA. O dado concreto recebido aponta para ComfyUI, ComfyUI-Manager, nós personalizados inseguros e serviços auxiliares mal configurados. Também não há base no contexto para afirmar vazamento de dados, roubo de modelos, exfiltração de prompts ou comprometimento de contas corporativas. O impacto confirmado se concentra em execução de código, mineração, persistência, ocultação, controle remoto e possível monetização como proxy. Equipes devem manter a análise nesse limite para evitar conclusões não sustentadas, mas a resposta deve considerar o host como potencialmente comprometido até prova em contrário.

• Instâncias ComfyUI acessíveis pela internet sem autenticação efetiva ou restrição de rede.
• Ambientes com ComfyUI-Manager disponível para instalação de nós personalizados.
• Hosts Linux onde o processo da aplicação possui permissões suficientes para persistência local e manipulação de arquivos.
• Redes internas com Docker API na porta 2375 ou Redis sem autenticação acessível a partir do host comprometido.
• Servidores com tráfego de saída permitido para infraestrutura desconhecida, pools de mineração ou endpoints de proxy.

Hunting e telemetria

A investigação deve começar pela exposição externa. Inventarie endereços públicos, regras de firewall, balanceadores e túneis que encaminham tráfego para ComfyUI. Procure acessos incomuns à interface, chamadas relacionadas a instalação de nós, alteração recente de extensões e limpeza inesperada do histórico de prompts. Em disco, revise diretórios de nós personalizados, caches do ComfyUI-Manager e artefatos com nomes como ComfyUI-Shell-Executor, ghost.sh, q11.txt e q12.txt. A ausência desses nomes não exclui comprometimento, pois a campanha foi descrita como em evolução, mas a presença deles deve ser tratada como sinal forte.

No endpoint, a telemetria deve priorizar processos de mineração, processos ocultos e persistência. Busque binários compatíveis com XMRig e lolMiner, uso anômalo de CPU ou GPU, processos executados de diretórios temporários, bibliotecas carregadas por LD_PRELOAD e alterações em atributos de arquivos que impeçam remoção. Revise crontab, unidades systemd criadas ou modificadas recentemente, entradas em authorized_keys e conexões TCP para portas citadas no contexto como usadas para concorrentes ou infraestrutura de mineração. Como o script tenta matar rivais e limpar persistências de outros mineradores, a presença de entradas removidas ou truncadas também pode indicar atividade adversária.

Na rede, investigue conexões de saída para pools de mineração, tráfego compatível com Hysteria V2, sessões persistentes para infraestrutura desconhecida e consultas ou downloads a partir de hosts defangados associados à campanha. Em ambientes de nuvem, cruze horários de pico de CPU, aumento de custo computacional, criação de processos incomuns e novas conexões de saída. Para redes internas, procure varreduras partindo do host ComfyUI em direção à porta 2375 de Docker e a serviços Redis sem autenticação. Essa caça é importante porque a etapa de propagação pode não atingir a internet, mas ainda comprometer recursos internos caso serviços administrativos estejam expostos lateralmente.

A detecção de sandbox descrita no payload também é útil para análise. A amostra calcula sinais relacionados a pouca memória, disco reduzido, número de interfaces de rede, depuradores e palavras associadas a ambientes de análise em nome de usuário ou saída do kernel. Se a pontuação excede um limiar, o malware encerra a execução. Em laboratório defensivo, isso significa que uma amostra pode parecer inativa em ambientes pequenos demais ou claramente identificados como análise. Em produção, esses mesmos critérios podem explicar por que alguns hosts foram minerados enquanto outros apenas receberam tentativas de exploração sem atividade completa.

• Criação ou atualização recente de nós personalizados do ComfyUI sem mudança aprovada.
• Referências locais a ComfyUI-Shell-Executor, ghost.sh, q11.txt ou q12.txt em disco, cache ou logs.
• Processos de mineração, alto consumo sustentado de CPU ou GPU e execução a partir de /tmp, memória compartilhada ou /var/tmp.
• Uso de LD_PRELOAD, atributos de arquivo imutável e múltiplas cópias de binários de mineração.
• Novas entradas em authorized_keys, crontab ou systemd relacionadas ao usuário que executa ComfyUI.
• Conexões de saída para pools de mineração, infraestrutura desconhecida ou tráfego compatível com proxy Hysteria V2.
• Varredura interna para Docker API na porta 2375 ou Redis sem autenticação originada do host ComfyUI.

Mitigação

A contenção deve começar com isolamento de rede. Instâncias ComfyUI não devem ficar expostas diretamente na internet; quando houver necessidade de acesso remoto, use VPN, proxy autenticado, lista de origem permitida e autenticação forte. Remova regras públicas desnecessárias em firewalls, grupos de segurança de nuvem e túneis. Para ambientes já suspeitos, preserve evidências antes de reiniciar ou limpar o host: capture lista de processos, conexões, tarefas agendadas, serviços, extensões instaladas, artefatos em disco e logs de aplicação. Em seguida, bloqueie tráfego de saída para infraestrutura desconhecida e interrompa o serviço até concluir a triagem.

A correção no ComfyUI exige revisar a cadeia de extensões, não apenas atualizar a aplicação. Remova nós personalizados que executem Python arbitrário ou que não tenham necessidade operacional clara. Desinstale ComfyUI-Shell-Executor caso apareça no ambiente e audite qualquer pacote instalado pelo ComfyUI-Manager após a janela de exposição. Restrinja quem pode instalar nós, documente versões aprovadas e mantenha uma lista de extensões permitidas. Se a aplicação precisar processar fluxos de usuários, separe o ambiente em contêineres ou máquinas de baixa confiança, sem acesso a segredos, socket Docker, credenciais de nuvem, diretórios de produção ou redes administrativas.

A limpeza do host deve considerar persistência múltipla. Remover apenas o processo de mineração não basta, pois o script foi descrito com vigilância, relançamento periódico, cópias em locais alternativos e proteção contra exclusão. Revise atributos de arquivos, unidades systemd, tarefas recorrentes, inicialização do ComfyUI, chaves SSH e bibliotecas pré-carregadas. Procure alterações em regras de firewall local feitas pelo script e entradas voltadas a bloquear pools de mineração concorrentes. Quando houver indício de privilégio elevado ou acesso SSH persistente, a reconstrução do host a partir de imagem confiável costuma ser mais segura que uma higienização manual limitada.

A redução de risco lateral exige fechar serviços internos inseguros. Docker API na porta 2375 não deve ficar exposta sem autenticação, principalmente em sub-redes alcançáveis por aplicações experimentais. Redis também deve exigir autenticação, restrição por rede e configuração alinhada ao uso pretendido. Em nuvem, revise políticas de saída, segmentação entre workloads de IA e sistemas administrativos, credenciais disponíveis no ambiente e permissões do usuário do serviço. Após a contenção, rotacione credenciais que estavam acessíveis ao host comprometido, valide se houve criação de chaves SSH não autorizadas e acompanhe custos de computação para identificar reincidência.

A validação final deve combinar controles preventivos e detecção contínua. Confirme que a instância ComfyUI não aparece em varreduras externas, que apenas nós aprovados estão instalados, que o ComfyUI-Manager não permite instalação sem controle e que o processo da aplicação roda com usuário de menor privilégio. Adicione alertas para alto consumo persistente de CPU ou GPU, execução de mineradores conhecidos, alteração de authorized_keys, uso de LD_PRELOAD, criação de serviços inesperados e varredura para portas internas sensíveis. Como a campanha foi observada em refinamento, a defesa deve depender de comportamento e superfície exposta, não apenas de nomes de arquivo.

• Remover exposição pública direta do ComfyUI e exigir acesso por canal autenticado e restrito por origem.
• Auditar e remover nós personalizados não aprovados, incluindo qualquer ocorrência de ComfyUI-Shell-Executor.
• Desabilitar ou controlar rigidamente o uso do ComfyUI-Manager em ambientes acessíveis por rede.
• Investigar e remover persistência em crontab, systemd, authorized_keys, atributos de arquivo e carregamento por LD_PRELOAD.
• Bloquear Docker API na porta 2375 e Redis sem autenticação em redes internas alcançáveis pelo host.
• Rotacionar credenciais acessíveis ao servidor comprometido e reconstruir o host quando houver indício de privilégio elevado.
• Criar alertas para mineração, tráfego de proxy, downloads de scripts, alto consumo computacional e varredura lateral.