O ransomware já ataca o Proxmox diretamente — e apaga primeiro os teus backups

A Broadcom alterou os preços da VMware e muitas empresas saíram. As licenças perpétuas foram retiradas, o licenciamento por socket passou a ser por núcleo e, em abril de 2025, a compra mínima passou de 16 núcleos para 72 — um salto de 4.5x só no mínimo. Empresas de média dimensão com dez ou vinte hosts começaram a ver renovações passar de trinta ou cinquenta mil por ano para algumas centenas de milhares. A Gartner prevê que, até 2028, cerca de 70% dos clientes empresariais da VMware terão transferido pelo menos metade das suas cargas de trabalho para outro lado.

Para as pequenas e médias empresas, esse outro lado tem sido muitas vezes o Proxmox VE. É capaz, é open source, corre em hardware que já tens e a conversa sobre licenças desaparece.

Os atacantes leem o mesmo mercado.

A ameaça já não é genérica

Durante anos, o ransomware que atingia um hipervisor era ransomware que, por acaso, encontrava um hipervisor. Cifrava ficheiros, e alguns desses ficheiros eram imagens de disco. O Proxmox era um dano colateral.

Isso mudou. Investigadores de segurança da Halcyon documentaram uma variante para Linux da família de ransomware Pay2Key que foi concebida de raiz para atacar ambientes Proxmox, detetada pela primeira vez no final de agosto de 2025. O Pay2Key foi avaliado conjuntamente pelo FBI, pela CISA e pelo DoD Cyber Crime Center como uma operação de informação iraniana. A campanha renovada não era um projeto secundário: os investigadores contabilizaram pelo menos 51 pagamentos de resgate confirmados num período de quatro meses, num total de mais de quatro milhões de dólares.

O que faz valer a pena prestar atenção a esta variante não é a cifragem. É o facto de o malware falar Proxmox.

Não luta contra a plataforma. Usa as próprias ferramentas da plataforma:

• Interrompe as tuas cargas de trabalho com os teus próprios comandos. qm stop --skiplock para as máquinas virtuais, pct stop --skiplock para os contentores. A flag --skiplock existe para que os administradores possam ultrapassar as próprias proteções de concorrência do Proxmox. O malware usa-a exatamente para isso.
• Desarma a proteção dos teus backups através da API. Antes de apagar o que quer que seja, executa pvesh set /nodes//storage//content/ --protected 0. Não precisa de contornar a flag de proteção. Simplesmente desliga-a, tal como tu farias.
• Depois cifra o que resta. Imagens de disco das VMs (qcow2, vma, vmdk), bases de dados (sql, mdf, mdb) e ficheiros de backup (bak, img, backup), usando ChaCha20 com chaves por ficheiro envolvidas em Curve25519.

Há uma boa notícia escondida na análise: o malware precisa de root e termina imediatamente sem ele. Tudo o que se segue depende desse facto.

A frase que vale a pena reler

Se o teu plano contra ransomware é a flag "protected" nos teus backups do Proxmox, não tens um plano contra ransomware.

Essa flag é uma salvaguarda contra o erro humano — impede-te de apagar por acidente, à meia-noite, o backup do mês passado. Nunca foi um controlo contra um adversário, e este malware demonstra porquê: tudo o que um administrador pode ligar e desligar através da API, um atacante com root pode ligar e desligar através da mesma API.

Este é o equívoco mais comum que encontramos em ambientes Proxmox. As equipas apontam para os backups protegidos no mesmo host, ou numa partilha NFS onde o host pode escrever, e apresentam-nos como a sua garantia de recuperação. Não são uma garantia de recuperação. Estão dentro do raio de impacto.

A outra porta: escapar da VM convidada

A segunda coisa que mudou em 2026 é a própria fronteira do hipervisor.

CVE-2026-64561, apelidada *Zapscape*, é um use-after-free na shadow MMU do KVM em x86 — a camada de virtualização sobre a qual o Proxmox é construído. Durante o tratamento de falhas de página desencadeadas pela VM convidada, o KVM pode recuperar páginas da MMU e invalidar uma shadow root que o caminho de tratamento da falha ainda está a usar e, como esse caminho não volta a verificar, a execução continua sob uma raiz invalidada. A consequência prática é crua: alguém com root dentro de uma única VM pode, nas condições certas, obter root no host — e, por conseguinte, sobre todas as outras VMs desse host.

O código defeituoso foi introduzido em 2020 e corrigido upstream no Linux a 21 de julho de 2026. Tem uma pontuação base CVSS 3.1 de 7.0.

O que levanta a única pergunta que importa: o kernel do teu host é mais recente do que essa correção?

Em muitos ambientes, a resposta honesta é "ninguém verificou". E essa lacuna é o verdadeiro tema deste artigo.

É um problema de migração, não um problema do Proxmox

O Proxmox não é menos seguro do que aquilo que deixaste. É uma plataforma bem concebida, com uma equipa séria por trás.

O risco vem da forma como as organizações lá chegaram. Uma migração motivada por uma renovação de licenças é uma migração com prazo, e os prazos produzem um conjunto previsível de atalhos:

• O modelo operacional veio sem alterações. O ambiente antigo era administrado através do vCenter por uma equipa que nunca precisou de disciplina de aplicação de patches em Linux, porque o ESXi era um appliance. O Proxmox é Debian. Tem um gestor de pacotes, um kernel e um fardo de manutenção que agora é teu.
• A interface de gestão acabou por ficar acessível. A interface web ficou exposta, ou atrás de uma VPN com credenciais partilhadas, para que a migração pudesse ser terminada a partir de casa. Ninguém voltou atrás.
• Os backups foram reproduzidos, não redesenhados. A nova configuração replica o agendamento e a retenção antigos, e grava num armazenamento onde o hipervisor pode escrever — que é precisamente o desenho contra o qual o Pay2Key foi escrito.
• Ninguém é responsável pela aplicação de patches. No mundo VMware, as atualizações eram um evento com uma janela de alterações. No Proxmox são uma terça-feira qualquer. Se ninguém tem essa terça-feira na agenda, o kernel do host fica meses para trás e ninguém repara até que um aviso de segurança o mencione.

Nada disto é negligência. É o que acontece quando a infraestrutura muda mais depressa do que o modelo operacional à sua volta.

O que realmente te protege

Aproximadamente por ordem do quanto te rende por cada hora investida:

• Coloca uma cópia dos teus backups fora do alcance de um host comprometido. Externa, imutável ou baseada em pull — o essencial é que o hipervisor não tenha credenciais capazes de a apagar. Se o root no host consegue chegar à tua última cópia boa, estás a uma credencial de não ter nenhuma.
• Restaura alguma coisa. Este mês. Um backup não testado é uma hipótese. Restaura uma VM real num ambiente isolado e cronometra, para que, quando importar, saibas que funciona e quanto tempo vais estar parado.
• Aplica patches ao kernel, não apenas aos pacotes. apt upgrade no Proxmox não te coloca necessariamente num kernel novo, e um kernel com live patching ou fixado pode ficar para trás sem ninguém dar por isso. Compara o kernel em execução com os avisos de segurança que importam — o Zapscape é o exemplo atual mais óbvio.
• Tira a interface web da internet. Os planos de gestão devem estar numa rede separada, atrás de MFA, com contas nominativas. A interface do Proxmox num IP público é um convite, e os scanners encontram-na em poucas horas.
• Dá à API o menor privilégio que funcione. O Proxmox tem um sistema de funções a sério e tokens de API com permissões granulares. As tarefas de backup e a monitorização não precisam de permissões de administrador. O malware precisa de root; cada conta que não o tem é uma porta que continua fechada.
• Cria alertas para os sinais reveladores. Encerramentos com --skiplock que não agendaste. A flag protected de um backup a ser removida. Paragens em massa de VMs fora de uma janela de alterações. São sinais inequívocos e, na maioria dos ambientes, nada está atento a eles.
• Pede a alguém que tente. Um teste de penetração encontra a interface de gestão exposta, a credencial partilhada e o host esquecido que um inventário em papel nunca revela.

Onde entra a Privum

Operamos infraestrutura de produção para clientes em toda a Europa, e uma parte crescente dos pedidos que recebemos é exatamente isto: um ambiente que saiu da VMware à pressa e ao qual não foi dado o modelo operacional de que agora precisa.

Em concreto, o trabalho costuma ser:

• Uma avaliação honesta do que está realmente exposto. A nossa área de cibersegurança realiza testes de penetração externos e revisões de hardening, e reporta o que está acessível, não o que o diagrama diz. Publicamos um exemplo anonimizado de uma delas para que possas ver a forma do resultado antes de te comprometeres.
• Um desenho de backup e recuperação que sobreviva a um host comprometido. Backup e recuperação de desastres é a parte disto que as pessoas adiam e depois lamentam. A pergunta de desenho não é com que frequência fazes backup; é quem o pode apagar.
• Alguém atento, à hora em que isto acontece. Os operadores de ransomware não trabalham em horário de expediente. O nosso NOC 24/7 cobre o período em que ninguém da tua equipa está acordado, que é exatamente o período para o qual este malware foi escrito.
• A disciplina Linux que a plataforma agora exige. Consultoria Linux e trabalho de infraestrutura — cadência de patches, baselines de hardening, segmentação de rede e garantir que aquilo que te mantém atualizado é um processo e não uma pessoa que se lembra.

Não te vamos dizer para abandonares o Proxmox. Para a maioria das empresas que nos procuram, foi a decisão certa e as poupanças foram reais. Mas a poupança nas licenças e o modelo operacional são duas decisões separadas, e muitos ambientes só tomaram a primeira.

Em resumo

O ransomware que percebe o teu hipervisor já não é hipotético. Desliga as tuas VMs com os teus próprios comandos, desativa a proteção dos teus backups através da tua própria API e depois cifra as imagens. Separadamente, uma vulnerabilidade do KVM corrigida em julho de 2026 significa que uma única VM convidada comprometida pode, nas condições erradas, levar o host consigo.

Ambas têm a mesma resposta, e não é um produto. É saber como é realmente o teu ambiente, mantê-lo atualizado e guardar uma cópia dos teus dados num sítio que um host comprometido não consiga alcançar.

Se não tens a certeza de onde estás nesses três pontos, fala com a nossa equipa. Uma avaliação curta é consideravelmente mais barata do que a alternativa, e as empresas que pagaram aqueles quatro milhões de dólares também tinham todas bastante certeza de que estava tudo bem.