Ransomware na camada do hipervisor: como os invasores usam os recursos do ESXi e do vCenter para fins maliciosos

Nossa Equipe Global de Resposta a Emergências (GERT) investigou recentemente um incidente no qual um invasor destruiu o ambiente de virtualização de uma organização ao longo de um período de 10 dias. A campanha teve como alvo quatro hosts ESXi, todas as máquinas virtuais hospedadas neles, ambos os dispositivos vCenter Server Appliances e toda a infraestrutura de backup conectada. As notas de resgate identificaram o grupo BlackNevas, observado pela primeira vez em novembro de 2024. Um aspecto interessante desse ataque é que nenhuma vulnerabilidade da camada de virtualização foi explorada. Não houve escapes do guest para o host nem corrupção de memória do hipervisor. Todas as ações executadas contra o ESXi foram realizadas por meio de interfaces legítimas de gerenciamento da VMware.

Em setembro de 2021, o código-fonte do ransomware Babuk foi divulgado na internet, incluindo sua versão para ESXi, tornando o ransomware direcionado ao ESXi acessível a cibercriminosos com conhecimentos técnicos relativamente limitados. Pelo menos dez famílias de ransomware posteriores utilizaram esse código vazado, incluindo grupos que, de outra forma, não teriam a experiência necessária para desenvolver do zero criptografadores de ransomware compatíveis com ESXi. Observamos vários operadores usando criptografadores para ESXi derivados do Babuk, juntamente com versões do LockBit para Windows cujo código havia sido vazado. Vale destacar que, embora a versão do Babuk para ESXi possa ter como alvo sistemas antigos e atualizados, as organizações visadas utilizavam versões do ESXi não compatíveis, o que facilitava os ataques.

Este artigo examina por que a camada do hipervisor continua sendo difícil de monitorar, quais são os caminhos de acesso mais comuns usados por invasores para alcançá-la e como eles estabelecem persistência no plano de gerenciamento. Também analisaremos a arquitetura dos criptografadores para ESXi, a destruição deliberada da infraestrutura de backup e as fontes de registros que permitem reconstruir os acontecimentos após um incidente. Ao final deste artigo, apresentaremos indicadores de comprometimento identificados durante a investigação.

Por que o hipervisor altera a dinâmica econômica do ransomware.

A virtualização permite gerenciar recursos de maneira econômica e eficiente, além de simplificar a aplicação simultânea de atualizações e políticas. No entanto, ao mesmo tempo, ela reduz o número de pontos de controle e amplia o impacto potencial de um ciberataque. Em ambientes não virtualizados, o comprometimento de um único sistema guest normalmente afeta apenas um sistema operacional. O comprometimento do plano de gerenciamento da virtualização concede ao invasor acesso a vários hosts de hipervisor, enquanto o impacto direto em um armazenamento de dados (datastore) do ESXi pode tornar vários sistemas guest indisponíveis de uma só vez. Isso torna a camada do hipervisor um alvo atraente para operadores de ransomware, especialmente quando controladores de domínio, servidores de aplicativos, bancos de dados e cargas de trabalho de backup compartilham o mesmo ambiente virtualizado.

De acordo com o relatório global da Kaspersky sobre serviços de cibersegurança, o ransomware representou 39,4% dos incidentes tratados pela GERT em 2025, e os dados do início de 2026 mostram que ele continua sendo uma ameaça significativa. Em 2023, a SentinelOne documentou que várias famílias de ransomware estavam usando criptografadores para ESXi derivados do código-fonte vazado do Babuk. Isso reduziu a barreira de desenvolvimento para agentes que não possuíam a experiência necessária para criar amostras capazes de operar no ESXi. Isso torna os ataques de ransomware contra ambientes de virtualização mais acessíveis a um conjunto mais amplo de agentes de ameaça, e essa tendência continua presente até hoje.

A assimetria de visibilidade

O ESXi é um hipervisor especializado baseado no VMkernel proprietário da VMware. Ele compartilha algumas semelhanças com o Linux e outros sistemas semelhantes ao Unix, aceita comandos Linux e executa determinados softwares semelhantes aos do Linux, mas é diferente das distribuições Linux de uso geral. A Broadcom afirma que ferramentas de segurança prontas para uso, projetadas para sistemas operacionais de uso geral, não podem ser executadas no ESXi da maneira habitual e que não é possível instalar diretamente agentes de terceiros ou antivírus no ESXi e no vCenter Server Appliance (VCSA). Por isso, os defensores dependem fortemente dos mecanismos de proteção integrados, da telemetria do plano de gerenciamento, das integrações com soluções de segurança sem agente e da coleta de telemetria da infraestrutura externa aos hosts ESXi.

Em geral, os sistemas operacionais guest são protegidos por softwares de EDR. No entanto, se um processo executado no ESXi modificar um disco de máquina virtual (VMDK) ou um arquivo relacionado no datastore, um agente de EDR dentro do sistema guest não conseguirá observar diretamente nem atribuir a operação ao processo do hipervisor que a executou. A telemetria do sistema guest pode registrar consequências, como falhas de E/S ou um desligamento abrupto, mas a execução maliciosa ocorre fora dos limites desse sistema. No incidente analisado neste artigo, isso tornou a telemetria nativa do host e a do plano de gerenciamento essenciais para reconstruir a linha do tempo do incidente.

Como os invasores chegam à camada de virtualização

Existem diferentes caminhos de entrada no ambiente, cada um exigindo controles específicos, mas todos podem, em última instância, proporcionar acesso ao plano centralizado de gerenciamento da virtualização e aos hosts ESXi que ele controla. Neste artigo, examinaremos quatro caminhos principais que podem levar ao comprometimento da infraestrutura de virtualização:

• Exploração de vulnerabilidade
• Reutilização de credenciais do ambiente Windows
• Abuso da integração com o Active Directory
• Infraestrutura de backup como ponte para obtenção de credenciais

Exploração de vulnerabilidade

Não foram encontradas evidências no incidente analisado que indicassem que uma vulnerabilidade do ESXi tivesse sido usada como caminho de acesso inicial. Ainda assim, as vulnerabilidades conhecidas publicamente continuam sendo importantes, pois já foram utilizadas para comprometer a infraestrutura de gerenciamento da virtualização. Como os exploits estão disponíveis na internet, esse é um dos caminhos de entrada mais prováveis. A seguir, apresentamos alguns exemplos de vulnerabilidades que afetam ambientes de virtualização e cuja exploração por invasores já foi observada. Por exemplo, o grupo Twelve encadeou as vulnerabilidades CVE-2021-21972 e CVE-2021-22005 para instalar um web shell diretamente em um dispositivo vCenter. Esse recurso carregou um backdoor, que estabeleceu persistência por meio da injeção de um objeto compartilhado no daemon SSH. Observe que essas vulnerabilidades não estão relacionadas ao incidente analisado. Elas são apresentadas apenas como exemplos de possíveis vetores de acesso inicial e podem ajudar os defensores a definir a superfície de ataque relevante e priorizar as atividades de aplicação de correções.

CVE	Camada	Efeito sobre a segurança	KEV*	Por que isso é relevante neste contexto
CVE-2021-21974	ESXi OpenSLP	Execução remota de código no serviço OpenSLP vulnerável	Não	Historicamente associada às discussões sobre o ransomware ESXiArgs.
CVE-2021-22005	vCenter Server	Envio arbitrário de arquivos que pode levar à execução remota de código	Sim	Uso documentado em atividades relacionadas a ransomware.
CVE-2021-21972	Plug-in do vCenter	Execução remota de código sem autenticação por meio de um plug-in do vSphere Client	Sim	Uso documentado em atividades relacionadas a ransomware.
CVE-2021-21985	Plug-in vSAN Health Check do vCenter	Execução remota de código	Sim	Uso documentado em atividades relacionadas a ransomware.
CVE-2023-34048	vCenter DCERPC	Gravação fora dos limites da memória, que pode levar à execução remota de código	Sim	Vulnerabilidade conhecida por ter sido explorada, que afeta o vCenter. Embora não haja dados sobre seu envolvimento em incidentes de ransomware, ela merece atenção devido ao impacto que pode causar no plano de gerenciamento da virtualização.
CVE-2024-37085	Integração do ESXi com o Active Directory	As permissões do AD podem resultar em privilégios administrativos completos no ESXi	Sim	Uso documentado em atividades relacionadas a ransomware. Essa vulnerabilidade também destaca os riscos decorrentes da relação entre as identidades do AD e o acesso administrativo ao ESXi.
CVE-2024-38812 / 38813	vCenter DCERPC	Execução remota de código/escalonamento de privilégios para root	Sim	Vulnerabilidades conhecidas por terem sido exploradas, que afetam o vCenter. Embora não haja dados sobre o envolvimento dessas vulnerabilidades em incidentes de ransomware, elas merecem atenção devido ao impacto que podem causar no plano de gerenciamento da virtualização.
CVE-2025-22224 / 22225 / 22226	ESXi / Workstation / Fusion	Cadeia de ataque do guest para o host que exige privilégios prévios no sistema guest	Sim	Vulnerabilidades conhecidas por terem sido exploradas, que permitem uma cadeia de ataque do guest para o host. A exploração da CVE-2025-22225 foi observada em incidentes de ransomware. No entanto, essa cadeia de ataque exige acesso privilegiado à máquina virtual guest, o que a torna menos crítica do que vulnerabilidades que permitem execução remota de código sem autenticação.

* Banco de dados de Vulnerabilidades Conhecidas como Exploradas (KEV), mantido pela CISA. O status KEV indica que a exploração de uma vulnerabilidade foi observada em ambientes reais, mas, por si só, não indica que ela tenha sido usada em ataques de ransomware. Quando há uso documentado em ataques de ransomware, essa informação é indicada separadamente. Nem o status KEV nem a exploração conhecida por agentes de ransomware significam que a vulnerabilidade tenha sido utilizada no incidente analisado.

Integração com o Active Directory

A CVE-2024-37085 é um bom exemplo de por que é fundamental autenticar-se separadamente em diferentes sistemas, mesmo quando o próprio hipervisor está atualizado com as correções de segurança. A vulnerabilidade afeta hosts ESXi configurados para usar o AD no gerenciamento de usuários. De acordo com a Microsoft, ela é explorada por operadores de ransomware, incluindo Akira e Black Basta, que abusam do comportamento do grupo ESX Admins para obter privilégios administrativos. A CISA inclui essa vulnerabilidade em seu catálogo KEV e indica que ela foi utilizada em incidentes de ransomware.
A vulnerabilidade foi corrigida no ESXi 8.0 U3. Para sistemas mais antigos, a Broadcom recomenda a seguinte solução alternativa:

• alterar o valor de esxAdminsGroupAutoAdd de true para false;
• alterar authValidateInterval de 1440 para 90 minutos;
• remover, quando apropriado, o mapeamento padrão do grupo ESX Admins.

Esses controles reduzem a exposição, mas a lição arquitetural é mais ampla: o comprometimento do domínio não deve permitir automaticamente que um invasor obtenha privilégios de administrador do hipervisor.

Recomendações para os defensores

Evite dependências diretas e desnecessárias do Active Directory nos hosts ESXi. Quando os requisitos de negócio exigirem essa integração, siga o princípio do menor privilégio: adicione aos grupos administrativos somente as contas que realmente precisam desse nível de acesso; use contas administrativas separadas, com credenciais distintas para o domínio e para os hipervisores; restrinja o acesso às interfaces de gerenciamento do ESXi e do vCenter aos segmentos de rede, às contas e às estações de trabalho estritamente necessários; e valide continuamente as alterações nas permissões do ESXi. O controle de acesso baseado em funções (RBAC) do vCenter e a federação de identidades devem ser configurados para a administração da virtualização. Credenciais corporativas comuns e grupos amplos do domínio não devem ser usados para acessar o vCenter ou o ESXi com privilégios elevados.

Reutilização de credenciais do ambiente Windows

O terceiro caminho não requer vulnerabilidade alguma. Credenciais administrativas presentes em controladores de domínio, servidores de salto (jump servers), sistemas de backup, infraestrutura de identidade ou estações de trabalho de administradores podem permitir o acesso ao vCenter ou ao ESXi caso as mesmas contas administrativas sejam utilizadas em diferentes segmentos da infraestrutura. O MITRE ATT&CK considera a técnica Valid Accounts (Contas válidas) aplicável ao ESXi e observa especificamente que contas padrão ou de domínio comprometidas podem proporcionar acesso privilegiado a outros sistemas.

No incidente analisado, credenciais obtidas em sistemas que não pertenciam à infraestrutura de virtualização, mas estavam dentro do perímetro da organização, foram usadas para acessar os dispositivos vCenter Server Appliance. Diferentemente da exploração de vulnerabilidades, a autenticação bem-sucedida com uma conta válida pode parecer uma atividade operacional normal. Para detectar esse tipo de atividade de forma confiável, os analistas precisam avaliar o host de origem, o histórico da conta, o horário, o destino, as ações administrativas subsequentes e se a conta autenticada costuma administrar a infraestrutura de virtualização.

Infraestrutura de backup como uma ponte para obtenção de credenciais

As plataformas de backup não são meros repositórios passivos de armazenamento. Em geral, elas exigem contas de serviço, credenciais de hipervisores, acesso aos repositórios e amplo alcance de rede para proteger e restaurar cargas de trabalho críticas. Isso transforma o servidor de backup em um ponto de confiança concentrado. No incidente analisado, após obter capacidade de execução com privilégios administrativos na infraestrutura de backup, o invasor extraiu credenciais armazenadas, criando um caminho para outros níveis da infraestrutura.

Persistência no plano de gerenciamento

Agora que explicamos os possíveis riscos, vamos voltar ao estudo de caso. Os invasores conseguiram comprometer, por meio de SSH, o dispositivo vCenter responsável pelo gerenciamento da recuperação de desastres da infraestrutura de virtualização, onde estabeleceram duas camadas de persistência. A primeira utilizava o MeshAgent, o componente de endpoint da plataforma legítima de gerenciamento remoto MeshCentral. A segunda utilizava o Ligolo-ng como um túnel reverso implementado por meio de um serviço systemd. Essa atividade corresponde a duas técnicas do ATT&CK: Serviço systemd (T1543.002) e Tunelamento de protocolo (T1572).

A sequência cronológica foi a seguinte. Os invasores autenticaram-se no dispositivo como root por meio de SSH. Quarenta e três segundos depois, baixaram e implantaram o MeshAgent por meio de um shell script. A sessão SSH durou, ao todo, dois minutos e 26 segundos. Após o encerramento da sessão, o invasor não voltou a usar SSH para acessar o dispositivo comprometido, reduzindo assim a eficácia do monitoramento concentrado exclusivamente em sessões SSH interativas. Cerca de quatro horas depois, os invasores retornaram por meio do MeshAgent e instalaram o túnel Ligolo-ng como uma unidade persistente do systemd.

Artefato de persistência no VCSA: /etc/systemd/system/vmware-vdma.service

A unidade utiliza um prefixo semelhante aos usados pela VMware, coloca o binário em /opt/vmware/bin/, descreve funções plausíveis de manutenção do dispositivo e define Restart=always. Um defensor não deve considerar malicioso, por padrão, todo serviço não reconhecido cujo nome seja semelhante ao de um serviço VMware, pois podem existir integrações personalizadas. No entanto, um serviço que não conste na lista de serviços considerados confiáveis pela organização representa uma anomalia de alta confiabilidade que exige validação imediata.

Além do incidente analisado, também foram documentadas técnicas mais avançadas de persistência no ESXi. Por exemplo, a Mandiant observou invasores utilizando pacotes maliciosos do vSphere Installation Bundle (VIB) como mecanismo de persistência em hosts ESXi comprometidos. Isso demonstra que invasores com acesso administrativo podem estabelecer persistência na camada do hipervisor, inclusive mecanismos que sobrevivem à reinicialização dos hosts. No entanto, o incidente analisado demonstra que softwares comuns de gerenciamento remoto e um serviço systemd podem ser suficientes quando o próprio vCenter é considerado confiável e monitorado de forma inadequada.

Transformação do vCenter em um plano de controle para operações ofensivas

Uma técnica interessante observada no incidente foi o uso dos Perfis de host (Host Profiles) do vCenter. Os Perfis de host destinam-se a capturar e aplicar configurações em hosts ESXi. Um Perfil de host pode ser aplicado a hosts individuais, clusters de hosts ou a todos os hosts associados ao perfil. Ele também pode conter subperfis que abrangem aspectos específicos da configuração, como a autenticação. Entre outras configurações, os Perfis de host podem incluir parâmetros do Modo de Suporte Técnico (TSM) e do TSM-SSH.

No incidente analisado, o invasor utilizou Perfis de host para alterar o estado do serviço TSM-SSH e habilitar o SSH nos hosts ESXi visados. As evidências registraram a seguinte sequência:

Offset	Fonte	Evento observado	Evidência principal
T+0	vCenter	Leitura da configuração do host por meio do fluxo de trabalho de Perfil de host	vpxa.log
T+10m18s	vCenter	Alteração de configuração enviada para habilitar o SSH	vpxa.log
T+10m51s	vCenter / ESXi	O serviço TSM-SSH atingiu o estado RUNNING, indicando que o SSH foi habilitado no host e que ele está acessível a partir de um dispositivo remoto.	vpxa.log + vobd.log

Sequência de manipulação do Perfil de host observada antes do acesso direto ao ESXi.

Observe que o intervalo de 33 segundos entre o envio da alteração de configuração e o serviço TSM-SSH atingir o estado RUNNING é curto o suficiente para permitir uma correlação rápida desses eventos mediante a comparação de registros de diferentes fontes. No total, o invasor levou onze minutos desde a leitura inicial da configuração até reconfigurar o host, passando de uma política que mantinha o SSH desabilitado para permitir o acesso remoto direto. Em seguida, foi estabelecida uma conexão SSH direta aos hosts ESXi visados, originada do endereço IP do dispositivo vCenter, uma origem que normalmente seria considerada altamente confiável na rede de gerenciamento.

Por que a alteração da configuração do ESXi por meio do vCenter representa uma falha no limite de confiança

O fortalecimento da segurança dos hosts é importante, mas os controles administrados centralmente não devem ser considerados independentes quando a ferramenta central de gerenciamento é comprometida. Se o vCenter tiver autoridade para modificar o estado dos hosts, um invasor que o controle poderá fazer com que uma alteração maliciosa seja estruturalmente semelhante a uma atividade legítima de conformidade: ler a configuração, aplicar o estado desejado e observar o resultado. Os elementos que permitem distinguir as duas situações passam a ser o contexto de autorização, o horário, a conta de origem, a janela de manutenção e a possibilidade de o próprio estado desejado enfraquecer a segurança.

Por isso, o vCenter deve ser tratado como um ativo de Nível 0 e receber o mais alto nível de proteção possível. As contas administrativas do plano de gerenciamento devem ser isoladas das contas usadas na administração corporativa comum; o acesso à rede deve ser restrito a caminhos de gerenciamento dedicados; alterações de configuração de alto risco devem exigir autenticação forte e monitoramento; e o tráfego entre o vCenter e o ESXi deve ser comparado cuidadosamente com uma linha de base do comportamento normal (incluindo padrões de conexão, portas, protocolos, sistemas de origem e de destino) em vez de ser considerado confiável automaticamente. Todas as discrepâncias significativas devem ser tratadas como suspeitas e investigadas.

Oportunidade de detecção de alta confiabilidade

Deve ser gerado um alerta quando a conformidade do Perfil de host (ou a correção de conformidade, na terminologia da VMware) alterar a configuração do TSM ou do TSM-SSH fora de uma janela aprovada, especialmente se, em seguida, ocorrer uma nova sessão SSH originada do vCenter ou de outro dispositivo de gerenciamento. Essa sequência é mais precisa do que gerar alertas apenas para conexões SSH, pois cada etapa é legítima quando considerada isoladamente, mas se torna perigosa quando combinada com as demais.

Observações sobre o abuso do ESXi: ferramentas nativas do sistema e controles a monitorar.

Depois que um invasor obtém privilégios administrativos no ESXi, muitas ações destrutivas não exigem exploração. O projeto LOLESXi cataloga binários e scripts nativos do ESXi que foram utilizados indevidamente por agentes de ameaça, incluindo utilitários administrativos capazes de enumerar máquinas virtuais, controlar seu estado de energia e alterar configurações. Esse comportamento se assemelha ao uso de ferramentas nativas em ataques contra Windows, mas o alvo é o plano de controle do hipervisor.

Existem dois mecanismos de fortalecimento da segurança do ESXi cujas alterações podem ser consideradas altamente suspeitas. O nível de aceitação do host controla quais VIBs podem ser instalados. A configuração execInstalledOnly controla se binários que não foram instalados podem ser executados. A Broadcom afirma que o ESXi 8 habilita, por padrão, a opção de runtime execInstalledOnly e alerta que desativá-la permite a execução de binários desconhecidos que não foram instalados, aumentando o risco de ransomware. Também existe uma configuração de imposição no nível do kernel com o mesmo nome, relacionada à opção de runtime, mas distinta dela. Alterações nessa configuração podem exigir uma reinicialização.

Controle	O que ele controla:	Por que uma alteração é suspeita	Evidências úteis
Nível de aceitação do host	Quais pacotes VIB podem ser instalados	Reduzir o nível para um nível de confiança inferior amplia os tipos de pacotes que o host aceitará	esxcli / config events / esxupdate.log
Runtime execInstalledOnly	Execução de binários que não foram instalados por meio de pacotes VIB	O valor 0/FALSE permite a execução de código não instalado	vobd.log + configurações avançadas
Aplicação do kernel execInstalledOnly	Mecanismo mais rigoroso de aplicação de políticas no nível de inicialização do VMkernel, que restringe a execução a arquivos instalados por meio de pacotes VIB e que não foram modificados posteriormente.	O enfraquecimento dessa proteção pode exigir uma reinicialização e altera a linha de base de segurança	configurações do kernel + histórico de inicialização

Controles do ESXi que os invasores podem tentar enfraquecer

Entenda a fase de impacto no ESXi

Interrupção das máquinas virtuais antes de iniciar o impacto

Em geral, os criptografadores de ransomware para ESXi mais sofisticados interrompem as máquinas guest antes de modificar os dados dos discos virtuais, pois as VMs em execução mantêm estados ativos e bloqueios de arquivos. As diferentes famílias implementam esse processo de maneiras distintas, o que permite criar mecanismos de detecção comportamental úteis. As famílias descritas a seguir não estão relacionadas ao incidente analisado, mas essas descrições podem ser úteis para a proteção contra ransomware em geral.

Família de ransomware	Método de interrupção das VMs observado ou documentado
GwisinLocker, LockBit, Conti	Enumeram os processos das máquinas virtuais (worlds) com o comando esxcli vm process list e encerram individualmente esses processos com o comando esxcli vm process kill.
AvosLocker, RedAlert (também conhecido como N13V)	Utilizam um único encadeamento de comandos no shell para enumerar os processos e forçar seu encerramento.
Hive, fcker.py	Utilizam vim-cmd vmsvc/power.off para desligar máquinas virtuais registradas.
Builds do RansomHub ESXi	Contêm lógica personalizada em C++ capaz de enumerar e interromper máquinas sem depender da sequência de comandos esxcli ou vim-cmd.

Como diferentes famílias de criptografadores para ESXi liberam o estado das VMs antes de iniciar operações destrutivas nos arquivos

Não conhecemos a técnica exata utilizada para encerrar as VMs no incidente analisado. No entanto, uma sequência rápida de operações de desligamento ou encerramento de processos em várias VMs é sempre um forte indicador de que uma ação destrutiva está prestes a ocorrer. Nas evidências do caso analisado, todas as VMs do host de recuperação de desastres pararam de funcionar em 23 segundos. Ao mesmo tempo, o arquivo vmksummary.log, que registra o número de VMs em execução a cada hora, mostrou uma queda da quantidade normal de VMs para zero.

Entrega de payloads e comportamento do FlowSsh

A payload foi transferida para o ESXi por meio de SFTP. O arquivo de log de autenticação auth.log revelou um identificador de cliente associado ao FlowSsh, a biblioteca cliente SSH da Bitvise para C, C++ e .NET. O FlowSsh é compatível com SFTP, solicitações de execução remota, sessões de shell interativas e tunelamento. Esses recursos são compatíveis com o método de entrega observado. No entanto, a identificação da biblioteca deve se basear principalmente no identificador de cliente registrado, e não apenas em inferências sobre o comportamento.

Após a entrega da payload, foi executada a seguinte sequência de comandos. Reconstruímos essa sequência principalmente a partir do arquivo de log shell.log.

Offset	Comando observado	Observação analítica
T+0	true	Sondagem sem operação em uma sessão dedicada.
T+1s	chmod +x /tmp/esx64	Sessão de execução separada.
T+1m48s	true	Segunda sondagem sem operação.
T+1m49s	./tmp/esx64 /selftest	Sessão de execução separada; estágio de validação da payload.

Cada par de comandos foi precedido por uma sessão executando somente o comando true. Esse padrão repetitivo é compatível com a configuração automatizada de canais do FlowSsh. No entanto, isoladamente, ele não pode ser considerado um indicador confiável da ferramenta utilizada. Operadores humanos também poderiam ter digitado true, e outros frameworks de automação poderiam ter emitido testes de conectividade. Portanto, a sequência deve ser investigada como uma impressão digital comportamental, e não tratada como uma assinatura exclusiva do FlowSsh. Seu valor aumenta quando combinada com um identificador incomum de cliente SSH, a transferência de arquivos por SFTP para /tmp, o uso de chmod e uma execução subsequente de autoteste ou da payload.

A janela de três horas antes do autoteste

A execução de /selftest durou aproximadamente 16 segundos e ocorreu cerca de três horas antes da execução destrutiva final. Um teste realizado antes do impacto pode indicar que o operador estava verificando a compatibilidade com o build do ESXi do alvo antes de prosseguir com a execução destrutiva.

Oportunidade de detecção antes do impacto

Trate a transferência inesperada de executáveis para /tmp, seguida de sua execução e de acesso posterior a /vmfs, como uma sequência crítica que antecede o impacto. Embora indicadores individuais, como chmod +x, possam ser ambíguos quando analisados isoladamente, a execução inesperada de um arquivo executável recém-transferido para /tmp pode, por si só, ser um forte indicador de atividade maliciosa. A sequência completa fornece evidência contextual mais robusta ao relacionar a transferência da payload, sua execução, a validação e o acesso subsequente à camada de armazenamento das máquinas virtuais.

Comando de execução destrutiva e confiabilidade das evidências

Os invasores executaram o seguinte comando para iniciar a atividade destrutiva.

Comando de execução destrutiva observado no ESXi

Vamos decompor o comando em parâmetros e analisar sua utilidade forense. A interpretação dos parâmetros é acompanhada de um nível de confiança, pois não é possível reconstruir os detalhes exatos da implementação sem o binário.

Parâmetro	Significado observado ou corroborado	Confiança da interpretação
/p /vmfs/	O caminho de destino é o root do VMFS, onde ficam armazenados os arquivos das máquinas virtuais.	Alta: comando direto + caminho da plataforma.
/depth 5	Profundidade de recursão no diretório.	Alta: significado convencional do argumento e posição observada.
/wipe	Comportamento de sobrescrita ou apagamento; artefatos ._wipe estavam presentes em vários armazenamentos de dados.	Alto para comportamento destrutivo, médio para implementação exata.
/allsys	Inclui arquivos de sistema. Isso é compatível com o comportamento documentado publicamente das famílias BlackNevas/Trigona.	Média: a avaliação baseia-se na comparação com o comportamento documentado publicamente da família de malware; a ausência do binário impede a validação direta.
/detach	Desvincular o processo do terminal; a atividade continuou após a desconexão SSH.	Alta: documentação externa + continuidade dos efeitos observada no incidente.
/-showvolumes	Suprimir a listagem de volumes, de acordo com os parâmetros documentados para a família.	Média: baseado apenas em documentação comparativa.

O estilo de argumentos com barras à frente se assemelha à família de comandos Trigona e BlackNevas. O SentinelOne descreve o BlackNevas como uma variante derivada do Trigona, com versões capazes de atuar no ESXi e parâmetros especializados, incluindo /p ou /path, /wipe, /depth e /detach. Essa comparação reforça a atribuição, mas não substitui a confirmação por meio de um hash do binário ou de uma correspondência obtida por engenharia reversa.

Sobrescrita parcial e o que realmente significam 2 KB

Os artefatos do incidente indicaram que aproximadamente os primeiros 2 KB dos arquivos de discos virtuais foram sobrescritos. Danos ao início de um disco podem destruir o MBR de proteção, o cabeçalho GPT primário e outras estruturas iniciais de inicialização ou do sistema de arquivos, o que pode impedir imediatamente a inicialização de uma máquina guest. No entanto, a especificação UEFI exige que mídias GPT mantenham tanto o cabeçalho GPT primário quanto o de backup, além das matrizes de entradas de partição, em locais distintos. Se a GPT primária estiver corrompida e a cópia de backup estiver íntegra, softwares compatíveis com GPT deverão usar o backup, o que poderá ajudar a restaurar a estrutura primária. Portanto, a sobrescrita dos primeiros 2 KB, por si só, não comprova que os metadados das partições sejam irrecuperáveis. A recuperação prática depende de terem sido modificados outros registros de inicialização, metadados do sistema de arquivos, estruturas de volumes, descritores ou dados de aplicativos, além do layout exato do disco virtual.

Destruição prévia do caminho de recuperação

No incidente analisado, os danos à infraestrutura de backup não foram meramente colaterais. O invasor desativou a proteção antivírus no ambiente de backup dias antes do ataque principal e, posteriormente, interrompeu os serviços de backup, criptografou a infraestrutura de recuperação e prejudicou o acesso administrativo, tudo isso também antes da execução destrutiva no ESXi. A ordem das operações reduziu a capacidade dos defensores de restaurar os sistemas de produção justamente no momento em que essa capacidade era mais necessária.

Isso altera a definição de uma arquitetura de backup resiliente. A imutabilidade do armazenamento é valiosa, mas não protege as identidades, os servidores de gerenciamento, os repositórios, os caminhos de rede, as credenciais e os procedimentos necessários para restaurar os sistemas. A recuperação deve ser projetada como um limite de segurança separado, com identidades administrativas independentes, caminhos de gerenciamento restritos, opções de recuperação offline ou logicamente isoladas, procedimentos de restauração testados e monitoramento que não dependa do plano de controle da produção.

Duas vulnerabilidades recentes no Veeam ilustram perfeitamente esse problema. Embora nenhuma dessas vulnerabilidades tenha sido observada em exploração no caso analisado, ambas se aproveitam de políticas frágeis de gerenciamento de privilégios, o que pode torná-las exploráveis por qualquer usuário do domínio, inclusive por aqueles com os níveis mais baixos de privilégio. A CVE-2024-40711 consta no banco de dados KEV da CISA como uma vulnerabilidade explorada por ransomware. A CVE-2025-23120 é mais recente e ainda não consta no KEV. No entanto, vale observar que, segundo a Veeam, ela permite a execução remota de código (RCE), mas afeta apenas servidores de backup associados a um domínio. A lição geral não se limita a um fornecedor específico: um sistema de recuperação que dependa do mesmo plano de identidade da infraestrutura de produção pode ser comprometido e usado para alcançar os objetivos dos invasores.

Detecção e investigação

Há vários arquivos de log que documentam eventos do ESXi. Essas fontes permitem reconstruir um incidente destrutivo no hipervisor mesmo quando não há um agente de endpoint instalado no ESXi. A limitação está no período de retenção. A Broadcom informa que o ESXi registra internamente em uma RAM disk, que é limitado no espaço e limpo na reinicialização, e que o syslog persistente ou syslog remoto é necessário se os logs precisarem sobreviver à reinicialização e à perda de armazenamento local. Recomendamos coletar logs em um armazenamento remoto para manter a visibilidade forense dos incidentes no ESXi.

Linha de	Fonte	O que ela permite comprovar	Risco de perda	Observação sobre a coleta
P1	auth.log	Autenticação SSH, origem, horário das sessões e identificadores de cliente	Médio	Encaminhamento remoto; preservação antes da rotação.
P1	shell.log	Todos os comandos executados no ESXi Shell, além da ativação e desativação do shell	Médio	Fonte de maior valor para identificar comandos executados.
P1	vpxa.log	Ações do vCenter no host, incluindo fluxos de trabalho de gerenciamento.	Médio	Correlação com os eventos e tarefas do vCenter.
P1	vobd.log	Alterações no estado do serviço, observações de segurança e eventos execInstalledOnly	Médio	Evidências úteis de configuração com alto valor de sinalização.
P1	Eventos/Tarefas do vCenter	Principal, objeto e ação administrativa	Médio	Exportação imediata se o vCenter ainda estiver disponível.
P1	systemd + sistema de arquivos do VCSA	Unidades de persistência e binários referenciados	Médio	Para /etc/systemd/system e /opt/vmware, valide o sistema de arquivos atual e a configuração dos serviços em relação à configuração aprovada pela organização
P2	vmkernel.log / vmkwarning.log	Armazenamento, ciclo de vida dos processos, avisos do kernel	Médio	Corrobora o impacto e o comportamento do host.
P2	vmksummary.log	Contagem horária de máquinas virtuais em execução e sinal de atividade do host	Médio	Útil para avaliar a escala do impacto; fornece uma indicação temporal aproximada.
P2	esxupdate.log	Atividade de instalação do VIB/patch	Médio	Crítico quando há suspeita de instalação de VIB malicioso.
P2	vmware.log por máquina virtual	Eventos de energia e dispositivo específicos da máquina virtual	Médio	Em risco se o armazenamento de dados for criptografado ou apagado.
P2	hostprofiletrace.log	Atividade de aplicação/conformidade do Perfil de host	Médio	Preservar em caso de suspeita de abuso do Perfil de host.
P3	fdm.log / vmauthd.log / syslog.log	HA, porta 902 e contexto geral do daemon	Médio	Corroboração útil após a coleta das evidências P1/P2.

Telemetria da camada de virtualização classificada por valor investigativo. A retenção varia conforme o ambiente; o encaminhamento remoto reduz o risco de perder as evidências junto com o host

Oportunidades de detecção de alta confiança

Esta seção apresenta um resumo das observações comportamentais de detecção mais valiosas derivadas do incidente analisado. As regras mais fortes correlacionam ações legítimas em uma sequência anormal, em vez de gerar alertas para cada comando administrativo isoladamente.

Detecção	Comportamento	Telemetria	Gravidade
Perfil de host -> TSM-SSH	A correção do Perfil de host altera o TSM-SSH de desativado por política para ativo, fora de uma janela de mudança aprovada.	Eventos do vCenter, vpxa.log, vobd.log	Crítica
Acesso SSH direto originado no vCenter	Nova sessão SSH do vCenter para o ESXi após uma alteração no estado de segurança.	auth.log + fluxo de rede	Crítica
Nova unidade systemd semelhante a componentes VMware	Unidade nova ou modificada em /etc/systemd/system que referencia um binário fora da linha de base, em um caminho semelhante aos usados pelo VMware.	Sistema de arquivos/auditoria do VCSA	Alta
execInstalledOnly enfraquecido	/User/execInstalledOnly passa a ser 0/FALSE ou a aplicação da política do kernel é desativada.	vobd.log + auditoria de configuração	Crítica
Nível de aceitação reduzido	O nível de aceitação do host é alterado para um nível de confiança inferior, fora de uma janela de manutenção.	Configuração do vCenter/ESXi	Alta
Sequência automatizada de sondagem por SSH	Uma sessão contendo apenas o comando true é seguida, segundos depois, por exec ou chmod, a partir da mesma origem ou do mesmo cliente.	auth.log + shell.log	Alto quando combinado
Validação da payload	Um executável em /tmp executa um autoteste breve e depois acessa /vmfs.	shell.log	Crítica
Encerramento em massa de máquinas virtuais	Diversas ações de desligamento de máquinas virtuais ou de encerramento de processos em segundos ou minutos.	shell.log, hostd.log, tarefas do vCenter	Crítica
Impacto precedido por ações contra backup	Os serviços de backup são interrompidos ou os controles de segurança são desativados pouco antes de alterações no hipervisor.	Telemetria do Windows/dos sistemas de backup + vCenter	Crítica
Artefatos de apagamento de datastores	Criação rápida de marcadores de apagamento ou gravações destrutivas em vários volumes VMFS.	filesystem + vobd/vmkernel	Crítica

Exemplo de lógica de correlação

A seguir, apresentamos alguns exemplos de lógica de correlação independente de tecnologia que podem ser usados para investigar incidentes semelhantes. Observe que não são regras SIEM prontas para uso, mas podem ser utilizadas como base para desenvolver suas próprias regras.

Exemplo 1: abuso do Perfil de host que leva ao acesso direto ao ESXi:

Exemplo 2: preparação de uma payload no ESXi antes do impacto:

Resposta a incidentes na camada de virtualização

Esta seção apresenta ações recomendadas para responder a um incidente envolvendo ransomware no ESXi.

Primeiros 30 minutos após a descoberta do incidente

1. Isole o acesso de gerenciamento do vCenter dos segmentos corporativos comuns, preservando o acesso dos investigadores por meio de um caminho controlado.
2. Exporte os eventos e as tarefas do vCenter, os registros de auditoria do SSO, as sessões ativas e as definições atuais do Perfil de host antes que as alterações de correção eliminem o contexto.
3. Colete os arquivos auth.log, shell.log, vpxa.log, vobd.log, hostd.log, vmkernel.log, vmkwarning.log, vmksummary.log, esxupdate.log e hostprofiletrace.log do ESXi em todos os hosts afetados.
4. Preserve os diretórios /etc/systemd/system e os caminhos em /opt/vmware do VCSA referenciados por unidades anteriormente desconhecidas ou não aprovadas, além do histórico do shell, wtmp, registros de autenticação e cópias ou hashes de binários suspeitos.
5. Colete a telemetria dos servidores de backup, o estado dos serviços, as evidências dos repositórios de credenciais e os registros de rede antes de reconstruir a infraestrutura ou alternar as credenciais.
6. Registre o estado atual de execInstalledOnly, o nível de aceitação do host, o estado do SSH/ESXi Shell, o Modo de bloqueio, a associação ao domínio e os mapeamentos de permissões do ESXi.

Não comece reiniciando o ESXi apenas para remover uma sessão do invasor. A persistência dos registros do ESXi depende da configuração de scratch e do syslog, e uma reinicialização pode destruir evidências armazenadas na RAM disk. Confirme que os registros críticos foram copiados ou retidos remotamente antes de realizar ações de contenção disruptivas, a menos que o impacto em andamento torne inevitável um desligamento imediato.

Prioridades de contenção

• Revogue ou altere as credenciais administrativas comprometidas e remova os caminhos de acesso controlados pelo invasor, mas preserve primeiro os registros de autenticação e de tarefas.
• Desative o acesso não aprovado por TSM-SSH e ESXi Shell após coletar as evidências; certifique-se de que os Perfis de host ou outras automações não os reativem imediatamente.
• Remova serviços systemd não autorizados e agentes de gerenciamento remoto do VCSA somente depois de criar uma imagem ou preservar a unidade e os binários referenciados.
• Restaure as configurações de execInstalledOnly e do nível de aceitação para a linha de base aprovada, após determinar que isso não prejudicará a coleta de evidências nem as ferramentas críticas de recuperação.
• Segmente ou desconecte da produção a infraestrutura de backup comprometida e estabeleça um plano de controle de recuperação limpo antes de tentar uma restauração em larga escala.

Reforço da arquitetura com base no caso

Trate o vCenter como Nível 0

O VMware vCenter não é apenas um console de inventário. Ele pode ter a autoridade para configurar hosts, gerenciar identidades, ligar e desligar máquinas virtuais, aplicar Perfis de host e intermediar o acesso em todo o ambiente virtualizado. O incidente analisado demonstra por que o comprometimento do vCenter pode enfraquecer os controles aplicados por meio do plano de gerenciamento da virtualização, concedendo ao invasor privilégios suficientes para configurar hosts, controlar máquinas virtuais e modificar configurações relevantes para a segurança em todo o ambiente virtualizado, o que pode permitir a interrupção ou destruição de todo esse ambiente em questão de minutos. Proteja o vCenter com identidades administrativas dedicadas, MFA resistente a phishing por meio de federação de identidade compatível, acesso restrito à rede de gerenciamento, sessões privilegiadas monitoradas e monitoramento rigoroso das operações de alteração de Perfil de host e de cluster.

Separe as identidades de virtualização da administração corporativa tradicional

Evite reutilizar amplamente credenciais de administrador de domínio ou de estações de trabalho para a administração da virtualização. Quando o ESXi estiver associado a um domínio, aplique a configuração segura do Active Directory seguindo as recomendações da Broadcom e audite continuamente os mapeamentos de grupos e as permissões. Observe que a técnica Contas válidas também se aplica a ambientes ESXi. Além disso, como exemplo da subtécnica Contas padrão, a MITRE menciona especificamente a conta vpxuser, usada pelo vCenter para gerenciar hosts.

Restrinja os caminhos de gerenciamento direto do ESXi

O SSH é útil para solucionar problemas, mas deve ser tratado como um caminho administrativo excepcional, e não como uma forma rotineira de acesso diário. A ativação não autorizada do SSH nos hosts ESXi, tanto diretamente quanto por meio do vCenter, deve ser detectada pelo monitoramento das alterações no TSM-SSH e tratada como um evento suspeito. Para reforçar ainda mais a segurança dos hosts ESXi, use o Modo de bloqueio quando isso for operacionalmente adequado, restringindo o acesso a um pequeno conjunto de usuários explicitamente autorizados; aplique filtros à rede de gerenciamento e estabeleça políticas de aprovação e rastreamento para quaisquer alterações, especialmente para a ativação do acesso ao shell.

Torne o caminho de registro de logs independente do host afetado

Os logs de syslog remotos do ESXi e do vCenter devem ser armazenados em uma infraestrutura externa ao domínio de confiança da virtualização. Um scratch persistente aumenta a capacidade de preservar os logs após uma reinicialização, mas as evidências locais ainda podem ser perdidas se o armazenamento de dados ou o host for destruído. Recomenda-se usar registro centralizado de logs, por exemplo, por meio de um SIEM, incluindo telemetria de autenticação, shell, gerenciamento de hosts, Perfil de host e tarefas do vCenter. O registro de logs adequado deve ser configurado antes de qualquer incidente, para que a equipe de resposta tenha acesso ao quadro completo em uma emergência.

Planeje os backups como um limite de segurança separado

Use identidades administrativas independentes para os backups, minimize as dependências de domínio, isole os repositórios e as interfaces de gerenciamento, proteja cópias imutáveis contra o uso de credenciais de produção e teste a recuperação supondo que o vCenter e o Active Directory de produção estejam indisponíveis. Um projeto de backup não deve ser avaliado apenas pela imutabilidade dos dados, mas também pela capacidade de um operador com ambiente limpo autenticar-se, acessar o repositório, validar os dados e restaurar as cargas de trabalho após o comprometimento do plano de controle de produção.

Conclusão

A principal lição do incidente analisado não é que o ESXi precise de mais um agente de endpoint. É que a segurança da virtualização depende, simultaneamente, da integridade do plano de gerenciamento, do plano de identidade e do plano de recuperação. Mesmo totalmente corrigido e protegido, um hipervisor ainda pode se tornar o ponto de maior impacto de um ataque de ransomware quando o sistema autorizado a gerenciá-lo já foi comprometido. O invasor não precisou quebrar a criptografia da VMware nem escapar de uma máquina virtual guest. Depois de obter acesso a um controle privilegiado do vCenter, foi possível usar um mecanismo legítimo de conformidade para alterar o estado do host, ativar o SSH e criar um caminho para o ESXi que, estruturalmente, se parecia com atividades normais de administração.

O caso também demonstra por que incidentes de ransomware destrutivo muitas vezes são decididos antes mesmo de a criptografia começar. O invasor estabeleceu mecanismos alternativos de persistência, validou a payload para ESXi horas antes de detoná-la, interrompeu primeiro a capacidade de backup e, em seguida, executou atividades disruptivas a partir da camada menos visível para os controles das máquinas virtuais guest. Cada etapa criou uma oportunidade de detecção, mas essas oportunidades estavam na telemetria de gerenciamento, virtualização e recuperação, e não em uma árvore convencional de processos de endpoint.

A defesa duradoura é, portanto, arquitetural. Trate o vCenter como Nível 0. Separe as identidades de virtualização da administração corporativa tradicional. Restrinja o acesso direto ao ESXi. Preserve os logs nativos fora da plataforma afetada. Detecte alterações de configuração de alto risco como sequências de eventos, e não como comandos isolados. E projete a recuperação de modo que o comprometimento da identidade de produção ou do gerenciamento da virtualização não conceda também a autoridade necessária para destruir os sistemas exigidos para restaurá-los.

Mapeamento de MITRE ATT&CK

Técnica	Nome	Relevância para o caso	Status
T1078 / T1078.002	Valid Accounts / Domain Accounts	Credenciais corporativas roubadas usadas para obter acesso privilegiado à infraestrutura.	Observado/contextual
T1078.001	Valid Accounts: Default Accounts	Relevante para as relações de confiança das contas root e vpxuser no ESXi.	Não observado no incidente analisado, mas relevante para a plataforma ESXi
T1021.004	Remote Services: SSH	SSH usado para a administração do vCenter e do ESXi; a MITRE contempla explicitamente o SSH do ESXi.	Observado
T1543.002	Create or Modify System Process: Systemd Service	O Ligolo-ng estabeleceu persistência no VCSA como vmware-vdma.service.	Observado
T1572	Protocol Tunneling	O Ligolo-ng criou uma rota em túnel para o segmento de gerenciamento.	Observado
T1490	Inhibit System Recovery	Os serviços de backup e a infraestrutura de recuperação foram interrompidos antes do impacto na produção.	Observado
T1486	Data Encrypted for Impact	As cargas de trabalho de virtualização ficaram indisponíveis durante a fase de ransomware.	Impacto observado

Mapeamentos ATT&CK selecionados de forma conservadora, com base no comportamento observado e nas técnicas ATT&CK atuais compatíveis com ESXi

Indicadores do incidente

Os seguintes indicadores foram recuperados durante a investigação. São artefatos específicos do incidente, não assinaturas duradouras do BlackNevas nem de qualquer outra família de ransomware. Nomes de serviços, nomes de arquivos, domínios e infraestrutura de VPS podem ser alterados ou reassociados. Não há hashes disponíveis para o criptografador de ESXi, o binário do Ligolo-ng, o script instalador do agente nem o script de extração de credenciais, pois esses arquivos não estavam disponíveis.

Tipo	Indicador	Contexto	Confiança	Escopo
Serviço	vmware-vdma	Unidade systemd que se faz passar por um serviço VMware no VCSA.	Alta	Específico do incidente
Serviço	vspbind	Serviço do Windows para o agente de gerenciamento remoto.	Alta	Específico do incidente
Domínio	api.cloudvflare[.]com	Ligolo-ng C2; imitação do domínio cloudflare.com com alteração de um caractere.	Alta	Específico do incidente
IPv4	45.149.154[.]135	C2 do agente de gerenciamento remoto.	Alta	Específico do incidente
IPv4	91.92.242[.]121	VPS usado para acesso inicial ao portal.	Alta	Específico do incidente
IPv4	31.41.33[.]212	VPS usado para acesso inicial ao portal.	Alta	Específico do incidente
IPv4	188.240.57[.]94	VPS usado para acesso inicial ao portal.	Alta	Específico do incidente
SHA-1	28f8da19ddcdf26e426875c7a834b34a79bc1c33	svhost.exe/lock.exe	Alta	Específico da amostra
SHA-256	15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf	Agente de gerenciamento remoto.	Alta	Específico da amostra
SHA-256	5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78	Variante instalada do agente de gerenciamento remoto.	Alta	Específico da amostra

Indicadores do incidente para investigação retrospectiva de ameaças

Conjunto mínimo de coleta forense para ambientes de virtualização

Camada	Fonte de telemetria	Valor investigativo
Autenticação do ESXi	/var/run/log/auth.log	Endereços IP de origem, usuários, horários das sessões SSH e identificadores de cliente.
Comandos do ESXi	/var/run/log/shell.log	Comandos exatos executados através do ESXi Shell.
Gerenciamento do vCenter para o host	vpxa.log + eventos/tarefas do vCenter	Correção do Perfil de host, alterações de serviço e fonte administrativa.
Observações de segurança do host	vobd.log	Eventos de execInstalledOnly, serviços e estado de segurança.
Gerenciamento de host	hostd.log	Tarefas de máquinas virtuais e hosts; interações com APIs/gerenciamento.
Kernel/armazenamento	vmkernel.log + vmkwarning.log	Falhas de armazenamento, ciclo de vida dos processos e avisos do VMkernel.
Escala de impacto	vmksummary.log	Contagem horária de máquinas virtuais e sinal de atividade do host.
Histórico de VIB	esxupdate.log	Instalação de patch/VIB.
Perfil de host	hostprofiletrace.log	Atividade de aplicação e conformidade do perfil.
Evidências por máquina virtual	vmware.log ao lado do arquivo VMX	Operações de energia e dispositivos de máquinas virtuais individuais.
Persistência no VCSA	/etc/systemd/system + binários referenciados	Serviços não autorizados e caminhos de persistência.
Acesso ao VCSA	Logs de SSO, logs de autenticação, wtmp e histórico do shell	Contexto de autenticação, sessão e comandos.
Camada de backup	Logs de aplicativos + telemetria do Windows + evidências do repositório de credenciais	Comprometimento do caminho de recuperação e ponte de credenciais.
Rede	Firewall/fluxo de rede/proxy/DNS	SSH do vCenter para o ESXi, C2, tunelamento e movimentação entre segmentos de gerenciamento.

Conjunto mínimo de coleta para um incidente suspeito de ransomware na camada de virtualização