ESXi: verify recovery independence
The case investigated by Kaspersky shows why recovery deserves its own assessment. Test whether restoration decisions and access remain available when production management fails.
Читати португальськоюBy Pentesty
What the case establishes
On November 13, 2026, Kaspersky published an investigation into the destruction of four ESXi hosts and associated recovery infrastructure through legitimate management interfaces. Attribution to BlackNevas rests on ransom notes and technical comparisons; the authors did not recover the binary.
The Veeam vulnerabilities discussed in the report were not observed in this case. That distinction matters for planning: teams should assess the authority that actually exists in their environment without selecting a supposed entry point simply because it appears in a news story.
Map restoration for one specific service
Choose one service and a representative synthetic workload for the exercise. List who can request restoration, approve a copy, access the catalog, prepare the destination, and confirm the result. Separate people, accounts, and components: different names do not demonstrate independence when all depend on the same authorization.
Ask each owner to describe the prerequisites for their step. An apparently simple task may require networking, credentials, configuration, or information kept in another system. Turn those answers into a dependency map that can be checked during the exercise without changing production.
Define a failure that can be simulated safely
Agree which dependencies will be unavailable in the test environment. The simulation can represent the absence of identity services or virtualization management, provided the team knows exactly what has been removed from the scenario. Use isolated resources and preserve an authorized way to stop the exercise.
Do not shut down machines in bulk or run destructive commands to reproduce the research narrative. The required test is the ability to perform a defined restoration under controlled conditions. If an essential prerequisite cannot be simulated, document the limitation and seek an approved alternative.
Assess the result through the restored service
The application owner should verify an agreed set of synthetic records, permissions, and essential operations. A completed-task screen does not establish that the copy corresponds to the intended service. Connect the backup identifier to the destination used and the content actually validated.
Measure each step to locate delays involving approval, access, or configuration. Compare the result with the organization’s objectives without promising the same timing during a real incident. Differences in scale and availability must remain visible in the conclusion.
Turn the exercise into a supported decision
Combine the dependency map, granted access, expected denials, and service-owner validation. Request an independent review of what the exercise did not cover. An open issue can then receive priority based on the service it prevents restoring instead of disappearing into a generic task list.
Assign owners and dates to repeat failed steps. Acceptance should state the conditions under which restoration was demonstrated and which dependencies remain fragile. This record provides a concrete basis for discussing investment, permissions, and response capacity with the teams supporting the business.
Frequently asked questions
Does this case establish exploitation of an ESXi flaw?
The investigation describes legitimate management interfaces. The plan should assess existing administrative authority without adding a vulnerability the authors did not observe.
Does having a protected copy complete the assessment?
The proposed assessment also checks whether authorized people can locate the copy, prepare its destination, and validate the service under the exercise’s defined conditions.
Do we need to reproduce the incident’s destruction?
Use a synthetic workload and an isolated unavailability scenario. Restoration can be assessed without deleting production data or executing the software described in the research.
Who should approve the result?
Recovery and identity owners should approve access; the service owner should validate content and operation. Limitations and exceptions need to accompany those decisions.
Sources and references
- totalsecurity: fully read editorial reference
- Kaspersky GERT: original ESXi and vCenter investigation
Original Pentesty analysis, published November 14, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.