CiberSegurançaNews
Tendência

Hackers exploram falha crítica no VMware vCenter e ataques já alcançam 47 países

Vulnerabilidade CVE-2026-59310 permite execução remota de código sem autenticação; campanha começou poucos dias após a correção e já evoluiu para persistência, roubo de credenciais e ransomware em ambientes ESXi.

Uma vulnerabilidade crítica no VMware vCenter Server transformou-se rapidamente em uma campanha internacional de ataques. A falha CVE-2026-59310, classificada com CVSS 9,8, está sendo explorada contra servidores vulneráveis para executar código remotamente e estabelecer acesso persistente à infraestrutura das vítimas.

A empresa alemã de resposta a incidentes QUIRSO identificou 361 endereços IP associados a sistemas comprometidos em 47 países. O número, porém, não deve ser interpretado diretamente como 361 empresas atingidas, já que alguns endereços pertencem a provedores de hospedagem, nuvens ou infraestruturas compartilhadas.

O cenário ficou ainda mais grave nos últimos dias. Investigações posteriores associaram a campanha, com confiança moderada, a um ator de ameaça de língua chinesa e encontraram evidências de comprometimentos envolvendo acesso root, roubo de credenciais e até implantação de ransomware derivado do Babuk contra hipervisores ESXi.

O que é a CVE-2026-59310

A CVE-2026-59310 é uma vulnerabilidade de directory traversal localizada no serviço Syslog do VMware vCenter Server.

Esse tipo de falha permite manipular caminhos utilizados pelo sistema para alcançar locais que deveriam estar fora do escopo permitido.

No caso do vCenter, o impacto é particularmente grave: um atacante não autenticado que tenha acesso de rede ao serviço vulnerável pode explorar o problema para conseguir execução arbitrária de código.

A Broadcom divulgou e corrigiu a vulnerabilidade em 29 de julho de 2026, dentro do boletim de segurança VMSA-2026-0006.

O intervalo até o início dos ataques foi extremamente curto.

Exploração começou cinco dias depois

Os primeiros sistemas comprometidos observados pela QUIRSO começaram a se comunicar com a infraestrutura dos atacantes em 3 de agosto.

Isso ocorreu somente cinco dias após a divulgação e disponibilização da correção.

Até 5 de agosto, pesquisadores já haviam identificado mais de 340 IPs de vítimas realizando conexões com a infraestrutura utilizada pelos invasores. Posteriormente, o levantamento chegou a 361 endereços em 47 países.

Alemanha, Estados Unidos, Turquia, Irã e França concentravam mais da metade dos endereços observados.

A velocidade da exploração demonstra um problema crescente para equipes de segurança: o intervalo entre a publicação de uma vulnerabilidade crítica e sua utilização em ataques reais pode ser medido em dias — e, em alguns casos, horas.

Hackers utilizam reverse SSH para manter acesso

Conseguir entrar no servidor é apenas a primeira etapa.

Depois da exploração da CVE-2026-59310, os invasores foram observados instalando o reverse_ssh, ferramenta open source legítima que pode ser utilizada em testes de segurança, mas também abusada para estabelecer canais persistentes de acesso remoto.

Em uma conexão SSH convencional, o administrador inicia uma sessão em direção ao servidor.

No modelo reverso, a própria máquina comprometida inicia uma conexão para uma infraestrutura externa controlada pelo invasor.

Isso pode ajudar o atacante a contornar determinadas barreiras de entrada e manter um canal de comando sobre o sistema.

A QUIRSO também identificou mecanismos destinados a preservar essa persistência após o comprometimento.

Por isso, atualizar um equipamento que já tenha sido invadido pode não ser suficiente.

Campanha foi associada a ator de língua chinesa

A investigação ganhou novos elementos após a análise aprofundada de sistemas comprometidos.

Segundo a QUIRSO, existem indícios que permitem associar a operação, com confiança moderada, a um ator de ameaça de língua chinesa, possivelmente operando no fuso UTC+08:00.

Isso não equivale a uma atribuição definitiva a um governo ou organização específica.

Atribuição em cibersegurança exige cautela, pois infraestrutura, ferramentas, idiomas e horários de operação podem ser deliberadamente manipulados pelos próprios atacantes.

O que os pesquisadores sustentam até agora é uma provável ligação com um ator de língua chinesa, e não uma confirmação pública de responsabilidade estatal.

Outra vulnerabilidade do vCenter também aparece nos ataques

A investigação encontrou ainda evidências envolvendo outra vulnerabilidade crítica: CVE-2026-59309.

Em pelo menos um vCenter comprometido analisado pelos pesquisadores, foram encontrados sinais compatíveis com exploração tanto da CVE-2026-59310 quanto da CVE-2026-59309.

A segunda falha é relacionada a bypass de autenticação.

Segundo a investigação, atividades suspeitas compatíveis com a exploração da CVE-2026-59309 foram observadas já em 1º de agosto, seguidas pela criação de uma conta administrativa no vCenter.

O cenário reforça que organizações não devem analisar apenas uma CVE isoladamente. Atacantes podem combinar diferentes vulnerabilidades para construir uma cadeia de comprometimento mais completa.

Ataque pode chegar aos hipervisores ESXi

O vCenter ocupa uma posição estratégica na infraestrutura VMware.

A plataforma é utilizada para centralizar o gerenciamento de ambientes virtualizados, incluindo hosts ESXi e máquinas virtuais.

Comprometer essa camada pode, portanto, oferecer ao atacante um ponto privilegiado para avançar sobre outros componentes.

As investigações mais recentes encontraram evidências de uma etapa particularmente destrutiva: utilização de ransomware derivado do Babuk contra hipervisores VMware ESXi.

Isso transforma o incidente de uma invasão do sistema de gerenciamento em uma possível ameaça à própria disponibilidade das máquinas virtuais.

Por que ransomware contra ESXi preocupa tanto?

Um único host ESXi pode executar diversas máquinas virtuais.

Essas máquinas podem hospedar bancos de dados, aplicações corporativas, sistemas internos, servidores de arquivos e serviços essenciais.

Em vez de criptografar individualmente dezenas de servidores virtuais, um grupo de ransomware pode tentar atacar diretamente a infraestrutura de virtualização.

O resultado potencial é um efeito multiplicador.

Se o hipervisor e os arquivos das máquinas virtuais forem comprometidos, vários serviços podem ficar indisponíveis simultaneamente.

É justamente por isso que ambientes VMware são alvos frequentes de operadores de ransomware.

Instalar o patch pode não resolver um servidor já comprometido

Existe uma diferença fundamental entre corrigir uma vulnerabilidade e remover um invasor que já a explorou.

O patch impede novas tentativas de exploração daquele problema específico.

Mas, se o atacante entrou antes da atualização e criou mecanismos alternativos de persistência, corrigir a CVE não necessariamente remove esse acesso.

A campanha envolvendo o vCenter demonstra exatamente esse risco, pois os atacantes utilizaram mecanismos de reverse SSH após obter o comprometimento inicial.

Empresas que mantiveram servidores vulneráveis acessíveis durante o período de exploração devem, portanto, considerar uma investigação adicional.

O que administradores devem verificar

A prioridade é aplicar as versões corrigidas indicadas pela Broadcom. Segundo as informações técnicas disponíveis, as correções abrangem linhas do vCenter Server 8.0, 9.0.x e 9.1.x, além dos produtos VMware Cloud Foundation e VMware vSphere Foundation que incorporam builds vulneráveis do vCenter.

A Broadcom não disponibilizou uma solução alternativa que substitua a aplicação da atualização para a CVE-2026-59310, tornando o patch a principal medida preventiva.

Em ambientes que permaneceram vulneráveis, administradores também precisam procurar sinais de comprometimento e persistência, incluindo artefatos relacionados ao reverse_ssh, alterações inesperadas, contas administrativas não reconhecidas e conexões externas suspeitas.

A Shadowserver Foundation passou inclusive a disponibilizar relatórios especiais relacionados a sistemas observados participando da infraestrutura associada à exploração da CVE-2026-59310.

VMware é infraestrutura crítica dentro das empresas

A gravidade dessa campanha vai além da pontuação CVSS.

Servidores vCenter normalmente não são aplicações comuns voltadas ao usuário final. Eles ocupam uma posição administrativa dentro da infraestrutura.

Em determinados ambientes, comprometer o sistema de gerenciamento da virtualização pode oferecer ao invasor visibilidade ou controle sobre uma grande quantidade de ativos.

Isso faz com que a segmentação de rede seja tão importante quanto a atualização.

Interfaces administrativas como vCenter não deveriam ficar desnecessariamente expostas à internet e devem ser acessíveis somente a redes e usuários autorizados.

Não há confirmação específica de vítimas brasileiras

O levantamento da QUIRSO identificou sistemas em 47 países, mas as fontes consultadas não apresentam evidências suficientes para afirmar que organizações brasileiras estejam entre as vítimas.

Portanto, não é possível afirmar que empresas no Brasil foram comprometidas nessa campanha específica.

Isso não reduz a relevância do alerta para organizações brasileiras que utilizam VMware.

Qualquer ambiente executando versões vulneráveis e acessível ao atacante dentro das condições necessárias pode representar uma superfície de ataque.

Cinco dias mostram como mudou a gestão de vulnerabilidades

Talvez o dado mais importante desse incidente seja o intervalo entre correção e exploração.

A Broadcom divulgou o problema em 29 de julho.

Em 3 de agosto, sistemas comprometidos já estavam se comunicando com a infraestrutura dos invasores.

Para vulnerabilidades críticas em sistemas estratégicos, o antigo modelo de aplicar atualizações apenas durante uma janela mensal de manutenção pode não acompanhar mais a velocidade dos atacantes.

O caso do vCenter mostra uma realidade cada vez mais presente na cibersegurança corporativa: publicar um patch também pode iniciar uma corrida entre administradores tentando corrigir seus sistemas e atacantes tentando descobrir e explorar aqueles que permaneceram vulneráveis.

Para organizações que utilizam VMware, a resposta deve envolver não apenas atualização, mas também investigação de comprometimento, revisão de credenciais, controle de acesso e redução da exposição da infraestrutura de gerenciamento.

Artigos relacionados

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Botão Voltar ao topo