Uma falha crítica no VMware vCenter Server, identificada como CVE-2026-59310, entrou no radar após ser associada a atividades de exploração contra ambientes de virtualização. Com pontuação CVSS 9.8, o problema permite execução arbitrária de código e pode transformar um servidor responsável pelo gerenciamento da infraestrutura VMware em um ponto de entrada para ataques muito mais amplos.
A investigação conduzida pela QUIRSO descreve uma cadeia de comprometimento que vai além da exploração inicial. Os invasores teriam estabelecido mecanismos de persistência, criado contas clandestinas, acessado credenciais armazenadas no vmdir e avançado contra hosts ESXi. O elemento mais incomum aparece no estágio final: a utilização de um ransomware baseado no Babuk que pode ter servido também para destruir evidências e dificultar a análise forense.
O cenário merece atenção especial porque o vCenter Server ocupa uma posição privilegiada dentro de ambientes VMware. Um comprometimento bem-sucedido do plano de gerenciamento pode oferecer ao invasor condições para alcançar hosts ESXi, máquinas virtuais, credenciais administrativas e outros componentes críticos da infraestrutura.
Como funciona a falha crítica no VMware vCenter
A CVE-2026-59310 é uma vulnerabilidade de travessia de diretório presente no componente Syslog do VMware vCenter Server. O problema permite que um atacante manipule caminhos de arquivos de forma indevida e, em determinadas condições, consiga alcançar arquivos fora do diretório originalmente destinado ao serviço.
A gravidade é explicada pela possibilidade de transformar essa condição em execução arbitrária de código. A vulnerabilidade possui características que tornam a exploração particularmente preocupante: pode ser alcançada remotamente, não exige privilégios prévios e não depende da interação de um usuário.
A Broadcom classificou a falha com CVSS 9.8, colocando-a entre os problemas de segurança de maior prioridade para administradores de ambientes VMware.
O risco não está limitado ao funcionamento do serviço Syslog. Quando um invasor consegue executar código no appliance do vCenter, o objetivo pode passar rapidamente de exploração para persistência e movimentação lateral.
Na campanha analisada pela QUIRSO, os atacantes teriam aproveitado a capacidade de manipulação de arquivos para inserir conteúdo em diretórios executados automaticamente pelo sistema, incluindo estruturas relacionadas ao cron.
Essa técnica permite que o invasor transforme uma exploração pontual em um mecanismo de execução recorrente.
A instalação do backdoor linuxFile
Depois de obter acesso ao sistema, os invasores teriam implantado o linuxFile, descrito na investigação como um backdoor utilizado para manter comunicação com a infraestrutura controlada pelos atacantes.
O malware também teria empregado WebSockets para estabelecer canais de comunicação com o servidor de comando e controle.
A escolha desse mecanismo é relevante porque conexões WebSocket podem se misturar ao tráfego de aplicações web legítimas, dependendo da configuração da rede e dos mecanismos de inspeção disponíveis.
Para equipes de defesa, isso significa que a identificação de um comprometimento não deve depender apenas da procura por processos obviamente maliciosos. Conexões persistentes, processos inesperados e alterações recentes no appliance também precisam ser investigados.
Persistência transforma a invasão em ameaça prolongada
A exploração inicial da CVE-2026-59310 é apenas o começo do problema. Depois de entrar no sistema, o atacante precisa garantir que consiga retornar ao ambiente mesmo que a vulnerabilidade seja corrigida.
Segundo a investigação da QUIRSO, uma das técnicas utilizadas foi a criação de tarefas no cron com nomes semelhantes aos de componentes legítimos do VMware.
Entre os nomes observados aparece vmware-vpxd-stats, uma escolha que pode dificultar a identificação durante uma inspeção rápida.
Essa técnica explora uma fragilidade comum em processos de resposta a incidentes: confiar exclusivamente no nome de um processo ou serviço.
Um administrador pode reconhecer o prefixo vmware e concluir que determinado componente é legítimo. Porém, em uma investigação, é necessário verificar também quem criou o arquivo, quando ele foi criado, quais permissões possui, o que executa e com qual processo se relaciona.
A campanha também teria utilizado webshells JSP, criando outro mecanismo de acesso persistente ao ambiente comprometido.
Um webshell pode permitir execução remota de comandos por meio de uma aplicação web, oferecendo ao invasor uma alternativa caso o acesso obtido pela vulnerabilidade original seja perdido.
Roubo de credenciais amplia o impacto do ataque
Um dos pontos mais preocupantes da campanha está relacionado ao vmdir, componente utilizado pelo VMware para serviços de diretório e identidade do ambiente vSphere.
Segundo a análise divulgada pela QUIRSO, os atacantes exploraram componentes associados ao vmafd, incluindo funcionalidades Python, para acessar informações armazenadas no diretório.
O objetivo seria obter credenciais e informações de autenticação que poderiam facilitar novas etapas do ataque.
Esse comportamento muda significativamente o perfil da ameaça. O invasor deixa de depender apenas de uma vulnerabilidade técnica e passa a buscar as próprias credenciais utilizadas para administrar o ambiente.
Com essas informações, uma operação maliciosa pode ganhar maior capacidade de movimentação dentro da infraestrutura.
Contas administrativas clandestinas no vSphere
A investigação também aponta para a criação de contas administrativas falsas no vSphere SSO.
Essa técnica fornece persistência em uma camada diferente do sistema operacional. Mesmo que determinados arquivos maliciosos sejam removidos, uma conta administrativa criada no serviço de identidade pode continuar permitindo acesso ao ambiente.
Outro indicador mencionado é a concessão de privilégios sudo irrestritos à conta perfcharts.
Alterações desse tipo devem ser tratadas como sinais de possível comprometimento, especialmente quando não existe uma justificativa operacional documentada.
Em ambientes corporativos, a existência de contas de serviço torna esse tipo de investigação ainda mais difícil. Por isso, organizações precisam manter uma linha de base de usuários, grupos, permissões e serviços legítimos.
Sem essa referência, alterações realizadas pelo atacante podem parecer parte normal da operação.
Ransomware Babuk chega aos hosts ESXi
Depois de comprometer o vCenter, a campanha teria avançado para os hosts ESXi, onde foi identificado um criptografador baseado no código do Babuk.
O Babuk é associado historicamente a ataques contra organizações e ambientes corporativos, incluindo infraestruturas de virtualização.
A presença de um locker baseado nesse código, entretanto, não significa automaticamente que o grupo original responsável pelo Babuk esteja por trás da operação.
Código de ransomware pode ser reutilizado, adaptado e incorporado por diferentes grupos criminosos. Por isso, a identificação de uma família de malware não deve ser confundida com atribuição definitiva do ataque.
O aspecto mais interessante da campanha é a possível finalidade do ransomware.
Babuk pode ter sido usado como cortina de fumaça forense
De acordo com a hipótese apresentada pelos pesquisadores, o ransomware não teria sido utilizado somente para criptografar dados.
A execução contra hosts ESXi poderia ter ajudado a destruir arquivos de log e dificultar a reconstrução da atividade dos invasores.
Essa estratégia transforma o ransomware em uma espécie de cortina de fumaça forense.
Em um ataque convencional, a criptografia já causa indisponibilidade e pressão operacional. Em uma campanha cuidadosamente planejada, porém, o impacto pode ser aproveitado para mascarar atividades anteriores.
Imagine uma organização tentando descobrir quando o invasor entrou, quais contas utilizou, quais servidores acessou e quais informações foram copiadas.
Se os registros locais foram destruídos ou alterados durante o ataque, parte dessa linha do tempo pode desaparecer.
Isso explica por que logs centralizados são tão importantes em ambientes críticos. Registros mantidos somente no próprio servidor comprometido podem ser apagados pelo atacante.
Servidores Syslog externos, plataformas SIEM, registros de firewall, autenticação centralizada e mecanismos independentes de monitoramento podem preservar evidências que o invasor não consegue modificar facilmente.
Indícios não significam atribuição definitiva
A investigação também identificou características que podem ajudar a traçar o perfil do grupo responsável, incluindo horários de atividade e informações relacionadas ao fuso horário utilizado pelos operadores.
Esses indicadores podem ser úteis para pesquisadores de ameaças, mas precisam ser interpretados com cautela.
Fuso horário, idioma, infraestrutura ou ferramentas utilizadas não são provas isoladas de nacionalidade ou identidade.
A atribuição de um ataque exige correlação entre múltiplos elementos técnicos e de inteligência.
Para os administradores, entretanto, a identidade exata do invasor é secundária. O aspecto mais importante é reconhecer os indicadores de comprometimento e determinar se a infraestrutura foi afetada.
Por que o vCenter é um alvo tão valioso?
O VMware vCenter Server funciona como uma camada central de gerenciamento em muitos ambientes vSphere.
A partir dele, administradores podem controlar hosts ESXi, máquinas virtuais, armazenamento, redes, permissões e diferentes recursos da infraestrutura.
Isso significa que comprometer o vCenter pode oferecer ao invasor uma posição estratégica dentro do ambiente.
Uma falha crítica no VMware vCenter é, portanto, diferente de uma vulnerabilidade encontrada em um servidor comum. O impacto potencial precisa ser avaliado considerando todos os ativos administrados pelo componente comprometido.
A situação se torna ainda mais delicada quando o atacante consegue obter credenciais administrativas e mecanismos de persistência.
Nesse cenário, simplesmente corrigir a vulnerabilidade pode não ser suficiente. A organização precisa determinar se o invasor deixou outros mecanismos de acesso.
Como proteger o VMware vCenter contra a exploração
A principal medida é aplicar imediatamente as atualizações oficiais da Broadcom para as versões afetadas.
A CVE-2026-59310 não possui um workaround oficial que substitua a atualização. Por isso, ambientes expostos devem priorizar a aplicação das versões corrigidas indicadas pelo fabricante.
O acesso ao vCenter Server também deve permanecer restrito à rede de gerenciamento sempre que possível. Interfaces administrativas não devem ficar acessíveis diretamente pela internet ou por segmentos que não necessitam desse acesso.
Em ambientes que possam ter sido comprometidos, a atualização deve ser acompanhada de uma investigação de segurança.
Os administradores devem verificar especialmente:
- Arquivos e tarefas em /etc/cron.d/;
- serviços e unidades systemd inesperados;
- contas novas no vSphere SSO;
- alterações nos grupos administrativos;
- privilégios sudo associados a contas de serviço;
- presença de arquivos JSP desconhecidos;
- processos e conexões de rede incomuns;
- alterações relacionadas ao vmdir;
- atividade suspeita nos hosts ESXi;
- logs centralizados correspondentes ao período do possível comprometimento.
Também é recomendável revisar e, quando necessário, rotacionar credenciais utilizadas pelo vCenter e pelos componentes relacionados.
Se houver evidências de comprometimento, a equipe deve preservar os registros disponíveis antes de iniciar ações que possam sobrescrever ou eliminar artefatos relevantes.
A prioridade deve ser reconstruir a sequência do ataque: acesso inicial, persistência, roubo de credenciais, movimentação lateral e eventual exfiltração ou destruição de dados.
Uma falha crítica que exige resposta imediata
A CVE-2026-59310 demonstra como uma vulnerabilidade aparentemente relacionada a um componente específico pode representar uma ameaça muito maior quando está presente em uma plataforma responsável pelo gerenciamento de toda uma infraestrutura virtualizada.
O cenário investigado pela QUIRSO reforça essa preocupação ao combinar execução remota de código, persistência, roubo de credenciais, criação de contas administrativas e ransomware contra hosts ESXi.
Para os administradores, a mensagem é direta: corrigir o vCenter é apenas o primeiro passo quando existe suspeita de exploração.
É necessário verificar se o invasor criou mecanismos de persistência, alterou contas, acessou credenciais ou avançou para os hosts ESXi.
Em ambientes corporativos, o plano de gerenciamento da virtualização precisa ser tratado como infraestrutura crítica. Manter o vCenter atualizado, limitar sua exposição, monitorar alterações administrativas e armazenar logs fora dos sistemas gerenciados são medidas fundamentais para reduzir o impacto de uma intrusão.
A combinação entre uma falha crítica e técnicas de sabotagem forense mostra que, em ataques modernos, impedir a entrada do invasor e preservar evidências são partes da mesma estratégia de defesa.