CVE-2026-59310: o que a campanha contra o VMware vCenter revela

A Broadcom disponibilizou versões corrigidas, mas não informou uma solução alternativa. Portanto, a aplicação das atualizações indicadas pela fornecedora é a remediação oficial para os sistemas vulneráveis.

A linha do tempo: patch primeiro, exploração cinco dias depois

A Broadcom divulgou a CVE-2026-59310 e publicou as correções em 29 de julho. A QUIRSO, empresa alemã de resposta a incidentes, relatou sinais de exploração ativa a partir de 3 de agosto, com rápida expansão da campanha nos dias seguintes.

Essa sequência é particularmente importante para a resposta a incidentes. Um sistema atualizado depois de 3 de agosto não deve ser considerado limpo apenas porque o processo de atualização foi concluído com sucesso. As equipes precisam separar duas tarefas: corrigir a vulnerabilidade e verificar se o invasor já havia obtido acesso.

O alcance da campanha

Pesquisadores associaram a atividade a 361 endereços IP de vítimas observados em 47 países. Alemanha, Estados Unidos, Turquia, Irã e França teriam concentrado mais da metade desse conjunto.

É importante interpretar esse número com cautela: um endereço IP não corresponde necessariamente a uma única organização. Portanto, “361 vítimas” não comprova que 361 empresas ou instituições distintas tenham sido atingidas. Ainda assim, os relatos disponíveis indicam uma campanha ampla contra sistemas vCenter acessíveis pela internet ou expostos de outra forma à rede.

Por que pesquisadores suspeitam de uma ligação com a China

A QUIRSO avaliou com confiança moderada uma possível ligação da campanha com a China. Entre os indícios relatados estão artefatos em língua chinesa, ferramentas e pesquisas reutilizadas publicamente, atividade compatível com o horário UTC+08:00 e um conjunto de vítimas que aparentemente não incluía a China continental.

Esses elementos sustentam uma avaliação regional ou linguística, mas não identificam um grupo estatal chinês específico nem comprovam orientação governamental. A atribuição baseada em artefatos de malware, padrões de horário e perfil das vítimas pode mudar conforme novas evidências surgirem. A descrição mais cautelosa, portanto, é “ator suspeito com ligação à China”, e não uma operação estatal confirmada.

Como teria sido a cadeia de invasão

A campanha parece ter usado a CVE-2026-59310 para obter a execução inicial e, em seguida, instalado várias camadas de persistência e acesso:

1. Travessia de diretórios: requisições criadas para explorar o serviço Syslog teriam escapado do caminho previsto e gravado conteúdo controlado pelos invasores.
2. Persistência via cron: os invasores teriam criado entradas de cron malformadas para que tarefas agendadas executassem comandos posteriores.
3. Entrega de backdoor: segundo os relatos sobre as intrusões observadas, curl ou wget baixaram um backdoor chamado linuxFile, ofuscado com WebSocket e XOR.
4. Reverse SSH: ferramentas de reverse SSH foram instaladas para criar uma conexão de saída com a infraestrutura controlada pelos invasores. A Shadowserver informou que esse mecanismo de persistência apareceu em todas as vítimas de seu relatório especial.
5. Abuso de credenciais e contas: investigadores relataram contas administrativas não autorizadas no vCenter e no ESXi, além do uso indevido de credenciais do VMware Directory Service.
6. Implantação de ransomware: ao menos parte dos relatos vinculou a atividade a uma variante de ransomware derivada do Babuk, que acrescenta a extensão .babyk aos arquivos.

A descoberta do reverse SSH é especialmente relevante. A conclusão operacional da Shadowserver é direta: sistemas nos quais esse mecanismo foi implantado devem ser tratados como totalmente comprometidos. Remover um binário ou apagar uma tarefa de cron, sem reconstruir a confiança no appliance e trocar credenciais privilegiadas, não é uma estratégia de recuperação suficiente.

O ransomware pode ter sido usado para dificultar a perícia

A atividade associada à extensão .babyk não necessariamente representa uma campanha tradicional de ransomware, cujo foco principal seria criptografar grandes volumes de dados e exigir resgate. Analistas sugeriram que a criptografia seletiva de logs do ESXi poderia ter como objetivo atrapalhar a investigação e ocultar evidências.

Essa explicação ainda é uma inferência, não uma declaração confirmada sobre a intenção dos invasores. Mesmo assim, os defensores devem investigar as duas possibilidades: impacto do ransomware sobre máquinas virtuais e adulteração deliberada de logs para encobrir a invasão.

Repositório no GitHub e reutilização de ferramentas

Relatos também associaram a operação a um repositório no GitHub que apresentava binários de reverse SSH como uma ferramenta Linux para limpeza de arquivos temporários. Disfarçar uma ferramenta de persistência como programa administrativo ou utilitário de manutenção pode facilitar sua distribuição e reduzir a chance de detecção em revisões rotineiras. As evidências disponíveis não estabelecem de forma independente quem administrava o repositório; sua existência, portanto, não deve ser usada como prova de atribuição.

O que o caso significa para a Broadcom

As ações da Broadcom caíram aproximadamente entre 5% e 6% em 14 de agosto, quando relatos sobre a exploração ativa do VMware chegaram aos investidores. Um dos relatos descreveu uma queda de US$ 417,82 para US$ 392,99 na sessão.

Os relatórios de segurança foram um dos fatores associados ao recuo, mas provavelmente não foram necessariamente o único. A cobertura da época também mencionou preocupações mais amplas, incluindo a exposição a dívidas relacionadas à inteligência artificial. Por isso, não é seguro atribuir toda a oscilação das ações — ou um valor exato de perda de valor de mercado — exclusivamente à CVE-2026-59310.

Os dados disponíveis não são suficientes para concluir que a campanha já tenha provocado uma queda mensurável na receita do VMware. Os efeitos de curto prazo mais sustentáveis são custos de remediação para clientes, risco de interrupções operacionais e pressão reputacional. Qualquer impacto prolongado na receita exigiria divulgações da empresa ou novas evidências financeiras.

O que administradores de vCenter devem fazer

Aplicar o patch é o primeiro passo, não o último. As organizações devem:

1. Instalar imediatamente as versões corrigidas pela Broadcom em todas as instâncias afetadas do vCenter, priorizando sistemas expostos à internet e appliances acessíveis a partir de redes internas amplas. A Broadcom não lista uma solução alternativa.
2. Presumir comprometimento quando houver indicadores, como alterações inesperadas no cron, artefatos de reverse SSH, linuxFile, downloads inexplicados via curl ou wget, administradores desconhecidos no vCenter ou ESXi e atividade anômala no VMware Directory Service.
3. Isolar appliances suspeitos e preservar imagens de disco, logs e evidências voláteis antes de reconstruir o ambiente, sempre que isso for operacionalmente viável.
4. Trocar credenciais privilegiadas, incluindo as do vCenter SSO, VMware Directory Service, ESXi ou root, APIs, contas de serviço e administradores vinculados. Também é necessário invalidar sessões ativas e revisar caminhos de federação.
5. Reconstruir, em vez de apenas “limpar”, sistemas com persistência confirmada. A remoção de contas não autorizadas, tarefas de cron, binários, chaves SSH e túneis deve fazer parte de um processo documentado de resposta a incidentes.
6. Realizar busca em toda a infraestrutura virtual por atividade associada a .babyk, conexões de saída inesperadas via SSH ou WebSocket, contas indevidas e sinais de adulteração dos logs do ESXi.
7. Restaurar dados e telemetria confiáveis a partir de backups conhecidos como íntegros e imutáveis quando logs ou configurações tiverem sido alterados.
8. Reduzir a exposição futura restringindo o acesso administrativo ao vCenter a redes segmentadas e monitorando conexões de saída de servidores vCenter e hosts ESXi.

A conclusão operacional é simples: atualize todos os sistemas vCenter vulneráveis, mas não confunda um patch aplicado com um ambiente livre de invasores. A combinação de exploração rápida, persistência via reverse SSH e relatos de abuso de credenciais exige que appliances expostos sejam investigados como possíveis comprometimentos totais.