BlackNevas ransomware destroys an organization's VMware ESXi estate and backups in 10 days via stolen credentials and vCenter
Matéria consolidada. Reúne 2 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que as 2 fontes trouxeram em 14/11/2026 12:03; os links antigos trazem para cá.
Fontes: gbhackers.com ↗ securelist.com ↗
The BlackNevas ransomware group destroyed an organization's entire VMware ESXi virtualization infrastructure over about ten days, including hosts, virtual machines, vCenter Server Appliances and backup environments. The case was analyzed by Kaspersky's Global Emergency Response Team (securelist.com) and covered again a day later (gbhackers.com). The attackers exploited no ESXi hypervisor vulnerabilities and no memory corruption. They used legitimate VMware management interfaces and stolen administrative credentials (securelist.com, gbhackers.com). Initial access came from credential reuse on compromised Windows systems and from backup infrastructure abuse (securelist.com). The incident shows how weakly the virtualization layer is monitored, and how reachable vCenter and backup systems are once credentials are stolen.
Entenda a falha
A vulnerabilidade
CVE-2025-64393 is a deserialization flaw in the Backup Viewer role of Veeam Backup & Replication. According to gbhackers.com, a single low-privilege role can lead to SYSTEM-level code execution on the backup server. The articles give no affected or fixed versions and no CVSS score, and they do not say what access an attacker needs beyond that role. It is cited as an example of backup-software risk, not as the entry point. Neither source says it was exploited in the BlackNevas intrusion, which used stolen valid credentials and legitimate VMware management interfaces, not a hypervisor flaw.
Como funciona
The articles do not describe the internal flow of CVE-2025-64393. They say only that a Backup Viewer role can yield SYSTEM execution on the backup server through a deserialization flaw. gbhackers.com separately mentions a BinaryFormatter deserialization RCE in Veeam Backup & Replication that lets low-privileged domain users run code, as a similar flaw. It does not say whether that is the same bug. In the BlackNevas incident, the attackers gained administrative execution on backup servers by other means and extracted stored service accounts, hypervisor credentials and repository access. They then used those secrets to pivot to vCenter and ESXi.
Por que é vulnerável
The articles name the class of flaw, deserialization, and say a single low-privilege role is enough to reach SYSTEM execution. They do not explain why it went unnoticed or what the fix changes. gbhackers.com stresses that patching alone is not enough when a recovery system shares the production identity plane. It recommends separating backup authority from production Active Directory.
Como foi descoberta
The articles do not say how or by whom CVE-2025-64393 was found or reported. The BlackNevas intrusion was documented by Kaspersky's Global Emergency Response Team (GERT), which found no hypervisor exploitation, only valid accounts and legitimate management interfaces. gbhackers.com cites the CVE only as context.
Explicação gerada por IA a partir da matéria e dos artigos, em 14/11/2026 12:18.
Detalhes técnicos
- Access: Valid credentials (MITRE ATT&CK T1078) came from non-virtualization systems and backup servers, and were used for lateral movement to vCenter and connected backup environments (gbhackers.com).
- Persistence: The attackers used common management and tunneling tools, MeshAgent and Ligolo-ng reverse tunnels (securelist.com, gbhackers.com).
- SSH enablement: They manipulated vCenter Host Profiles to enable SSH on ESXi hosts, which gave direct remote access and a route to deploy the ransomware payloads (securelist.com, gbhackers.com).
- Removing recovery options: Before detonation, antivirus and backup services were disabled and backup repositories were encrypted (gbhackers.com).
- Payload: The ransomware is described as related to the Trigona-derived BlackNevas family (gbhackers.com). It damaged virtual disks and crippled recovery (securelist.com, gbhackers.com).
- Logging: ESXi logs live in volatile memory, so remote logging is required to preserve evidence (gbhackers.com).
Remediação
- Treat vCenter as a Tier 0 asset and restrict administrative accounts (securelist.com, gbhackers.com).
- Enable multi-factor authentication and keep lockdown mode enabled on ESXi hosts (gbhackers.com).
- Isolate backup infrastructure and segregate it from production domains (securelist.com, gbhackers.com).
- Implement comprehensive detection and logging, including remote logging of ESXi logs (securelist.com, gbhackers.com).
- Defenders should also watch for unexpected Host Profile changes, SSH being enabled on ESXi hosts, and MeshAgent or Ligolo-ng activity. These items are inferred from the described tactics, not listed as recommendations in the sources.
Relatos divergentes
- Payload effect: securelist.com, the more detailed and primary source, says the payloads partially overwrote virtual disk metadata. gbhackers.com says the payload wiped virtual machine disks by destroying critical boot records. The two descriptions may not be equivalent, and the securelist.com wording should be preferred.
- Veeam CVE: gbhackers.com cites CVE-2025-64393 in Veeam Backup & Replication as a critical flaw commonly exploited in such attacks. Neither source says it was exploited in this incident. securelist.com attributes backup access to abuse of the backup infrastructure, without naming a CVE.
Linha do tempo
-
BlackNevas ransomware group destroys VMware ESXi virtual machines and backup infrastructure via legitimate management interfaces
ler a análise desta fonte ocultar
The BlackNevas ransomware group executed a destructive 10-day intrusion targeting VMware ESXi virtualization infrastructures. Using legitimate administrative VMware management interfaces and stolen credentials, they accessed vCenter Server Appliances and connected backup environments without exploiting hypervisor flaws or memory corruption. The attackers leveraged valid credentials (MITRE ATT&CK T1078) obtained from non-virtualization systems and backup servers to move laterally, deploying tools such as MeshAgent and Ligolo-ng reverse tunnels to maintain persistence. They manipulated vCenter Host Profiles to enable SSH on ESXi hosts, facilitating further access. Prior to payload detonation, antivirus and backup services were disabled and backup repositories encrypted, effectively removing recovery options. The ransomware payload, related to the Trigona-derived BlackNevas family, wiped virtual machine disks by destroying critical boot records. Defense recommendations include treating vCenter as a Tier 0 asset, enabling multi-factor authentication, maintaining system lockdown modes, and segregating backup from production domains. ESXi logs reside in volatile memory requiring remote logging. This incident underscores the risk posed by credential compromise and backup environment vulnerabilities, especially critical flaws like CVE-2025-64393 in Veeam Backup & Replication, commonly exploited in such attacks.
-
BlackNevas ransomware destroys ESXi virtualization estate via legitimate management interfaces
ler a análise desta fonte ocultar
In a detailed investigation, Kaspersky’s Global Emergency Response Team analyzed a devastating ransomware campaign by the BlackNevas group that destroyed an organization's entire VMware ESXi virtualization infrastructure, including hosts, virtual machines, vCenter Server Appliances, and backup environments over ten days. Notably, the attackers did not exploit any ESXi hypervisor vulnerabilities; instead, they used legitimate VMware management interfaces and stolen administrative credentials to gain access and persist within the environment. The initial access vectors included credential reuse from compromised Windows systems and backup infrastructure abuse, with the adversaries establishing persistence via common management tools like MeshAgent and Ligolo-ng. The attackers manipulated vCenter Host Profiles to enable SSH on ESXi hosts, allowing direct remote access and subsequent deployment of ransomware payloads that partially overwrote virtual disk metadata, crippling recovery capabilities. The attack underscores the challenges in monitoring and securing virtualization layers, emphasizing the need to treat vCenter as a Tier 0 asset, restrict administrative accounts, isolate backup infrastructure, and implement comprehensive detection and logging strategies.