Uma intrusão recém-divulgada revelou que o grupo BlackNevas destruiu toda a infraestrutura de virtualização de uma organização ao longo de 10 dias.
A Equipe Global de Resposta a Emergências (GERT) da Kaspersky documentou que os invasores apagaram quatro hosts ESXi (hipervisor da VMware), todas as máquinas virtuais neles hospedadas, os dois dispositivos vCenter Server Appliance (VCSA) e toda a infraestrutura de backup conectada.
Eles não exploraram nenhuma falha de hypervisor, nenhuma fuga da máquina virtual para o host nem corrupção de memória. Todas as ações foram executadas por meio de interfaces de gerenciamento legítimas da VMware, o que fez a intrusão parecer uma administração de rotina.
Ransomware BlackNevas ataca servidores VMware ESXi
A movimentação inicial dependeu de contas válidas (MITRE ATT&CK T1078). Credenciais de sistemas não relacionados à virtualização, dentro do perímetro, deram acesso aos dispositivos vCenter.
Os invasores também extraíram segredos armazenados em servidores de backup depois de obter execução administrativa neles. Plataformas de backup guardam contas de serviço, credenciais de hypervisor e acesso a repositórios, o que as torna um ponto de pivô conveniente para outros níveis da infraestrutura.
Falhas semelhantes em softwares de backup continuam surgindo, como a execução remota de código (RCE) por meio de desserialização do BinaryFormatter no Veeam Backup & Replication, que permite a usuários de domínio com privilégios baixos executar código em servidores de backup.
No vCenter de recuperação de desastres, os operadores se conectaram via SSH (protocolo de acesso remoto seguro) como root e implantaram o MeshAgent, componente de endpoint do MeshCentral, em 43 segundos.
Cerca de quatro horas depois, eles voltaram pelo MeshAgent e instalaram um túnel reverso Ligolo-ng como uma unidade systemd chamada vmware-vdma.service.
O binário ficava em /opt/vmware/bin/agent e enviava beacons para api.cloudvflare[.]com:443. A unidade usava uma descrição no estilo VMware e Restart=always, o que corresponde às técnicas T1543.002 (Serviço Systemd) e T1572 (Tunelamento de Protocolo) do MITRE ATT&CK. Como os invasores nunca mais usaram SSH interativo, o monitoramento limitado às sessões SSH não os detectou.
A técnica mais incomum foi o abuso dos Host Profiles do vCenter. O invasor usou o fluxo de conformidade para enviar uma alteração de configuração que mudou o TSM-SSH (modo de suporte técnico com SSH) de desativado para em execução.
O SSH atingiu o estado RUNNING 33 segundos após o envio, e sessões diretas para os hosts ESXi passaram a se originar do IP confiável do vCenter. Defensores podem correlacionar entradas dos logs vpxa.log e vobd.log para identificar essa sequência.
Crie alertas para a remediação de Host Profile que altere o TSM-SSH fora de uma janela de mudança aprovada, seguida de uma nova sessão SSH a partir do dispositivo de gerenciamento.
Antes da detonação, os invasores desativaram o antivírus do ambiente de backup com dias de antecedência, interromperam os serviços de backup e criptografaram os repositórios de recuperação.
Essa ordem eliminou o caminho de restauração antes de a produção ser afetada. Falhas críticas de execução remota de código no Veeam Backup & Replication são uma rota recorrente para esse tipo de adulteração de backups.
Aplicar correções isoladamente não basta, porque um sistema de recuperação que compartilha o plano de identidade da produção pode ser comprometido por essa via. Uma falha de desserialização no Backup Viewer, CVE-2025-64393, mostra como um único papel de baixo privilégio pode resultar em execução como SYSTEM no servidor de backup.
O payload chegou via SFTP (protocolo de transferência segura de arquivos), e o auth.log registrou um identificador de cliente FlowSsh. Os operadores executaram chmod +x em /tmp/esx64 e o rodaram com a opção /selftest por cerca de 16 segundos.
A Securelist relatou que, cerca de três horas depois, os invasores executaram o comando final: ./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes. As opções com barra são compatíveis com a família BlackNevas, derivada do Trigona.
Todas as VMs no host de recuperação de desastres foram interrompidas em até 23 segundos, e o vmksummary.log mostrou que a contagem de VMs em execução caiu para zero. Cerca de 2 KB iniciais de cada disco virtual foram sobrescritos, destruindo o MBR e o cabeçalho GPT primário. O GPT de backup ainda pode permitir uma recuperação parcial.
Os defensores devem tratar o vCenter como ativo de Nível 0 e atribuir a ele identidades administrativas dedicadas, com MFA resistente a phishing (autenticação multifator). Devem manter a opção de runtime execInstalledOnly e os níveis de aceitação de VIB (pacotes de instalação do ESXi) na linha de base aprovada e habilitar o Lockdown Mode sempre que as operações permitirem.
Os logs do ESXi ficam em um disco em RAM (ramdisk) que é limpo na reinicialização. Por isso, encaminhe auth.log, shell.log, vpxa.log e vobd.log para um syslog remoto. Separe a autoridade de backup do Active Directory (AD) de produção e teste restaurações partindo da premissa de que o vCenter e o AD estão indisponíveis.
IOCs
Observação: endereços IP e domínios foram intencionalmente desfigurados (ex.: [.]) para evitar resolução ou hiperlink acidentais. Refaça a formatação apenas em plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou seu SIEM.
