Ransomware em Proxmox e Linux: o que fechar no seu provedor hoje

Provedor de internet virou alvo de varredura automática, e a razão não é sofisticação do atacante. É o contrário. Nos últimos dias, provedores relataram invasões de ransomware seguidas de criptografia de servidores Linux e de hosts Proxmox com máquinas virtuais inteiras cifradas, e o perfil das vítimas se repete com uma regularidade que incomoda: software em fim de vida, firewall desativado e interface de gerenciamento respondendo em IP público.

O que está acontecendo com os servidores de provedor?

Três fatos separados se combinaram para produzir a onda atual. Um ransomware com variante para Linux, um volume recorde de vulnerabilidades por versão de kernel e uma campanha de exploração contra instalações antigas de Proxmox VE expostas na internet. Nenhuma das três frentes exige nada inédito de quem ataca.

O caminho é sempre o mesmo. O atacante varre a internet procurando sistema desatualizado e exposto, entra por uma falha já publicada, escala privilégio até o root e cifra tudo o que alcança. Não há alvo escolhido a dedo nem estudo prévio da sua operação. Existe uma lista de IPs que responderam, e o seu entrou nela.

Isso muda o que você deve olhar primeiro. A pergunta útil não é "quem me atacaria", é "o que meu AS responde hoje para quem escaneia a internet inteira".

Por que o Pay2Key derruba um servidor Linux com antivírus rodando?

Porque o antivírus perde a disputa depois que o atacante já tem root. O Pay2Key é uma operação de ransomware atribuída a grupos iranianos e opera desde agosto de 2025 uma variante específica para Linux, que é justamente o sistema que roda a infraestrutura da maioria dos provedores.

Com privilégio de root, a sequência do malware é conhecida. Ele desativa as proteções do sistema, SELinux e AppArmor. Encerra os serviços em execução para liberar os arquivos que estavam em uso. Cria persistência via cron, para sobreviver a uma reinicialização. E criptografa com ChaCha20, com chave única por arquivo.

A análise técnica publicada pela SOC Prime descreve ainda o modo parcial, que cifra só o começo de arquivos grandes em vez do arquivo inteiro. Em disco de máquina virtual isso é o detalhe que mais dói: o atacante inutiliza a VM em uma fração do tempo que levaria para cifrar tudo, e você perde a janela de reagir no meio do processo.

A tradução prática é curta. Se o atacante chegou ao root do seu servidor, a defesa deixou de ser detecção. Sobram duas coisas: impedir a entrada e ter backup fora do alcance dele.

Quantas falhas um servidor Linux acumula sem atualizar?

Perto de 2.000 por versão de kernel. O Phoronix registrou o salto: o número de CVEs corrigidas a cada release do kernel Linux subiu de cerca de 500 para quase 2.000, em parte porque ferramentas de IA passaram a varrer os aproximadamente 40 milhões de linhas de código do kernel e encontrar falhas antigas que ninguém tinha achado.

A maioria dessas falhas é de baixa gravidade, e é aí que a leitura costuma escorregar. O que importa não é a gravidade média de uma correção isolada, é o acúmulo. Um servidor que ficou seis meses sem atualizar carrega milhares de falhas conhecidas, publicadas, com receita de exploração disponível para qualquer um.

E gravidade baixa não significa inofensiva no conjunto. Basta que uma delas permita escalar privilégio até o root. Isso é tudo de que o Pay2Key precisa para começar a trabalhar. Quanto mais antigo o sistema, maior a probabilidade de que exista pelo menos uma nessa condição.

O Proxmox VE 7 tem um 0-day?

Provavelmente não. Circula o relato de uma falha desconhecida que permitiria invadir o Proxmox VE 7 sem senha, mas a análise da comunidade e da equipe do Proxmox aponta outra história. As vítimas rodavam Proxmox VE 7 sobre Debian 11, os dois fora de suporte há mais de três anos, com o firewall desativado e a interface web exposta diretamente na internet.

Sistema em fim de vida não recebe mais correção de segurança. Toda falha descoberta depois do fim do suporte continua aberta, para sempre, e não existe patch a caminho. O caminho provável do ataque é uma falha conhecida de kernel ou de serviço antigo, não uma falha inédita do Proxmox.

Vale conferir a sua versão agora, porque a régua andou de novo:

Se você roda VE 7 ou VE 8 com a porta 8006 acessível pela internet, trate seu host como alvo prioritário e não como possibilidade remota.

O que dá para fechar hoje?

Três ações cobrem a maior parte do risco e cabem no mesmo dia. Nenhuma delas depende de comprar ferramenta nova.

Tire os painéis de gerenciamento da internet. Interface web do Proxmox na porta 8006, Winbox e API de Mikrotik, SSH, painel de OLT e de monitoramento: nada disso deve responder em IP público. Acesso só por VPN ou por lista de IPs autorizados no firewall. Essa é a ação de maior efeito por minuto investido, porque tira você da lista de quem respondeu ao scan.

Verifique a versão do seu Proxmox. VE 7 e VE 8 estão fora de suporte. Planeje a migração para o VE 9 e, enquanto ela não sai, isole o host da internet por completo. Isolar não é substituto da migração, é o que segura o tempo até ela acontecer.

Garanta backup fora do alcance do atacante. Backup no mesmo servidor, ou em storage montado nele, é cifrado junto com o resto. Mantenha ao menos uma cópia offline ou em um local que o host de produção não consegue apagar, e teste a restauração. Backup que nunca foi restaurado é hipótese, não backup.

O que entra na fila desta semana?

Três frentes que pedem janela de manutenção e planejamento, não trinta minutos entre um chamado e outro.

Atualize kernel e pacotes dos servidores Linux. Aplique as atualizações de segurança pendentes em todos eles e defina uma rotina mensal de patch, com dia marcado. Sistema fora de suporte, como Debian 11 e CentOS 7, precisa de plano de migração com data, não de uma intenção.

Reduza a superfície de ataque. Desative o serviço que você não usa. Troque senha padrão e senha fraca. Use chave SSH em vez de senha. Mantenha SELinux e AppArmor ativos, porque eles são a primeira coisa que o Pay2Key tenta desligar. Restrinja quem tem root.

Monitore para detectar cedo. Configure alerta para login em horário incomum, processo novo rodando como root, criação de cron desconhecido e pico de leitura de disco. Ransomware detectado no início limita o estrago a um servidor. Detectado no fim, o estrago é a operação inteira.

Fontes

• SOC Prime, análise técnica do Pay2Key e da variante para Linux: socprime.com/active-threats/pay2key-technical-analysis/
• Phoronix, sobre o volume de CVEs por versão do kernel Linux: phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000
• Fórum do Proxmox, thread 186078, sobre o suposto RCE não autenticado no Proxmox VE 7