Migrou de VMware para Proxmox? Um ransomware já mira você

Se o seu time migrou os servidores de VMware para Proxmox nos últimos dois anos, essa notícia é para você. Surgiu uma variante do ransomware Pay2Key — grupo com ligação ao Irã — construída especificamente para atacar ambientes Proxmox. E ela não faz o de sempre: ela estudou como o Proxmox funciona e usa os próprios comandos da plataforma para desligar suas máquinas virtuais, apagar seus backups e só depois criptografar o que sobrar.

Por que isso importa tanto? Porque a maioria das defesas contra ransomware em ambientes virtualizados foi pensada para o VMware ESXi. As ferramentas de ataque conhecidas (ESXiArgs, BlackBasta, LockBit) usavam comandos do próprio ESXi. Nada disso funciona no Proxmox, que tem outra arquitetura. O Pay2Key é o primeiro caso amplamente observado de um ransomware que fez a lição de casa e escreveu código sob medida para essa plataforma.

Por que o Proxmox virou alvo agora

A resposta é simples: gente migrou em massa. Depois que a Broadcom comprou a VMware em 2023, muitas empresas fugiram do aumento de custo de licenciamento e adotaram o Proxmox, que é open-source e gratuito. Entre 2024 e 2025 essa onda de migração cresceu bastante, especialmente na América do Sul, Europa e Oriente Médio.

Ou seja: hoje há uma quantidade enorme de cargas de trabalho de produção rodando em Proxmox. Onde tem volume e dinheiro, o crime organizado aparece. E o Pay2Key não é amador — só na campanha que começou no verão de 2025 (hemisfério norte), o grupo alega mais de US$ 8 milhões em resgates pagos, ligados a cerca de 170 vítimas no mundo.

O que esse ataque faz de diferente

O ponto mais grave não é a criptografia em si. É a destruição dos backups. Deixa eu explicar por que isso muda o jogo.

O Proxmox permite marcar backups como "protegidos" — um cadeado feito justamente para impedir exclusão não autorizada. Muita gente confia nesse recurso como se fosse a proteção final contra ransomware. O Pay2Key faz o seguinte, em sequência:

• Mapeia todo o ambiente consultando a API do Proxmox (pvesh get /cluster/resources). Sem precisar conhecer sua infraestrutura de antemão, ele descobre todas as VMs, nós e áreas de armazenamento.
• Desliga suas máquinas virtuais e containers à força, usando qm stop --skiplock e pct stop --skiplock. Aquele --skiplock ignora o mecanismo de proteção que impede desligamentos durante backups e snapshots.
• Remove a proteção dos backups e os apaga via API. Primeiro tira o cadeado (--protected 0), depois deleta. Isso alcança backups guardados dentro do datastore gerenciado pelo Proxmox — algo que ransomwares comuns, que apagam por extensão de arquivo, nem chegariam a tocar.
• Desliga as defesas do sistema (SELinux, AppArmor) antes de criptografar, para não deixar rastro nem ser bloqueado.

De ainda criptografa arquivos com prioridade para o que dói mais: imagens de disco de VMs (qcow2, vmdk, vma), bancos de dados e arquivos de backup.

A lição prática para o seu negócio

Se você tirou uma conclusão desse cenário, que seja esta: backup que está no mesmo ambiente que você quer proteger não é backup — é uma cópia. No momento em que o atacante tem acesso root ao host Proxmox, ele acessa tudo que estiver ali dentro, inclusive os backups "protegidos".

A defesa de verdade é a velha regra do 3-2-1, com um detalhe que virou obrigatório: pelo menos uma cópia precisa ser imutável e fora do alcance do servidor de produção. Backup em outro storage do mesmo cluster não conta. Backup que a conta root consegue apagar não conta.

Recomendações concretas para conversar com seu time ou com quem cuida da sua TI:

• Backup off-site e imutável. Uma cópia em outro local, em mídia que não pode ser sobrescrita ou apagada dentro da janela de retenção (imutabilidade real, seja em appliance dedicado, object storage com object lock ou fita).
• Restrinja quem executa pvesh, qm e pct. Por padrão, o Proxmox não força controle de acesso nesses comandos na linha de comando. Isso precisa ser configurado com políticas de sudo. Ninguém deveria usar --skiplock fora de janela de manutenção.
• Monitore o acesso ao diretório /etc/pve. Qualquer processo estranho tocando ali é sinal de alerta. Vale também alertar sobre qualquer pvesh delete fora do horário administrativo.
• Reduza a superfície de acesso remoto. O Pay2Key historicamente entra por RDP e endpoints expostos. Feche o que não precisa estar na internet, ative MFA e mantenha o acesso administrativo atrás de VPN.
• Teste a restauração. Backup que nunca foi restaurado é uma promessa, não uma garantia. Faça o exercício de recuperação periodicamente.

Migrar do VMware para o Proxmox foi uma decisão financeira acertada para muita gente. Mas trocar de plataforma não te livra dos riscos — só muda o mapa. Quem migrou herdou uma economia real e, junto, a responsabilidade de proteger o novo ambiente com o mesmo rigor. O Pay2Key mostrou que os atacantes já estudaram o terreno. A pergunta honesta é: seu backup sobreviveria a um deles com acesso root ao host?