Voltar
Segurança de virtualização: camadas de ataque e impacto de erros de configuração

Casos de ransomware em ESXi e Proxmox mostram que erros de configuração e credenciais expostas bastam para derrubar a virtualização

Aprofundamento CEVIU

Aprofundamento

O Kaspersky GERT investigou dois casos de ransomware em que a virtualização caiu sem exploit de escape de VM. No primeiro, o grupo BlackNevas partiu de um Windows no segmento do controlador de domínio virtualizado (rastros de AnyDesk e GMER) e chegou ao PRTG Network Monitor. O PRTG tinha acesso amplo aos hosts ESXi e a mesma senha root se repetia em vários nós. Com ela, o atacante entrou por SSH, desativou o execInstalledOnly com esxcli, executou o binário de criptografia e apagou logs.

No segundo, o grupo The Gentlemen achou credenciais root do Proxmox em texto puro nas anotações de uma estação de administrador comprometida. Ativou o websocket do VNC com a conta root e baixou e executou o ransomware no cluster, criptografando todo o ambiente. A conclusão do relato é que patch e configuração segura precisam andar juntos: um hipervisor atualizado cai com senha compartilhada, conta de monitoramento com privilégio demais ou SSH aberto. O texto cita como mitigação identidades dedicadas ao monitoramento, cofre para credenciais únicas por host, SSH desligado com Lockdown Mode, rede de gerenciamento isolada, logs em armazenamento protegido e alertas para mudanças em execInstalledOnly e Secure Boot.

O que mudou

Não há evolução direta do mesmo caso na cobertura anterior, mas há contexto próximo. Em 29 de junho de 2026, o CEVIU publicou "AuditD: como invasores exploram e operam em nós do Proxmox VE", sobre a migração de infraestruturas do VMware para o Proxmox e como adversários atuam nesses nós. O caso do The Gentlemen mostra um exemplo prático dessa atuação, com credencial root vazada e uso do VNC.

Por que isso importa

Para quem opera virtualização, a leitura é que o ponto fraco costuma estar nos sistemas vizinhos do hipervisor, como monitoramento e estações de administração. Vale inventariar onde existem senhas root guardadas (ferramentas, scripts, anotações) e testar se a equipe detectaria a desativação do execInstalledOnly. Isso é interpretação editorial, a partir dos dois casos descritos.

Linha do tempo

  1. CEVIU publica guia de detecção sobre atuação de invasores em nós Proxmox VE.

  2. Kaspersky GERT detalha casos de ransomware em ESXi (BlackNevas) e Proxmox (The Gentlemen).

Perguntas frequentes

Os ataques exigiram escape de VM?

Não. Nos dois casos, o acesso administrativo comum com credencial root válida bastou. O problema foi onde as credenciais estavam guardadas e por onde podiam ser usadas.

Como o BlackNevas contornou a proteção do ESXi?

Com acesso root via SSH, o atacante desativou a política execInstalledOnly com o comando esxcli. Isso permitiu executar o binário de criptografia. Depois ele apagou os logs para dificultar a perícia.

O que fazer com ferramentas de monitoramento como o PRTG?

Dar a elas uma identidade dedicada, com o menor privilégio possível para os sensores. Não usar root do ESXi para consultas rotineiras. Credenciais devem ficar em cofre, únicas por host e rotacionadas após uso emergencial ou suspeita de comprometimento.

Como reduzir o risco no Proxmox?

Não guardar credenciais privilegiadas em anotações. Use gerenciador de senhas aprovado ou PAM, com MFA, e rotacione tudo se uma estação de administrador for comprometida. Também convém isolar a rede de gerenciamento e acessar por jump hosts reforçados.

Fontes

Avalie este artigo:
Categoria
CEVIU Segurança da Informação
Publicado
09 de novembro de 2026
Editoria
CEVIU Segurança da Informação

Quer receber mais sobre CEVIU Segurança da Informação?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser