BlackNevas Case: How vCenter and Backups Failed

The ESXi vCenter ransomware backup attack investigated by Kaspersky shows how one compromised management plane can amplify an intrusion across virtual machines and recovery systems. Its Global Emergency Response Team examined an incident spanning four ESXi hosts, two vCenter Server Appliances and connected backup infrastructure over ten days. The ransom notes used the BlackNevas name, but the report does not establish a wider campaign or a definitive operator identity.

This case is chiefly about administrative authority, not a demonstrated hypervisor flaw. Kaspersky says it found no evidence that an ESXi vulnerability provided initial access. Credentials taken from systems outside virtualization helped the intruder reach vCenter, where legitimate management features became part of the attack path.

Teams reviewing this ransomware case can pair ransomware intelligence with local management and backup telemetry. That external context does not replace the host logs needed to establish this incident’s sequence.

ESXi vCenter Ransomware Backup Attack: The Observed Chain

The intrusion crossed three connected boundaries: enterprise identity, virtualization management and recovery administration. Kaspersky reports that attackers used credentials from non-virtualization systems to reach the vCenter appliances. Administrative access on backup infrastructure also exposed stored credentials that could bridge into other tiers.

On the disaster-recovery vCenter appliance, the attackers authenticated through SSH and installed a legitimate remote-management agent. They later returned through that agent and added a persistent tunnel as a systemd service. Kaspersky maps the observed SSH access, service persistence and tunneling to ATT&CK T1021.004, T1543.002 and T1572.

1. 1Reused privileged accessCredentials from outside virtualization reached vCenter
2. 2Persistent management accessA remote-management agent and systemd tunnel survived the initial SSH session
3. 3Host Profile changevCenter pushed an SSH-enabling configuration to ESXi
4. 4Direct host accessSSH from the vCenter appliance reached the target hosts
5. 5Recovery and VM impactBackup capability was disrupted before ESXi ransomware detonation

This sequence matters because each step can resemble authorized administration when viewed alone. A successful vCenter login, Host Profile remediation or SSH connection has ordinary operational uses. Their order, principal, source and change window distinguish this incident from a planned maintenance task.

How Did a Host Profile Open the ESXi Path?

Host Profiles allow vCenter to apply configuration across ESXi hosts. In Kaspersky’s case, the adversary changed the TSM-SSH service state through that workflow. The host then reported SSH running, and direct SSH sessions came from the vCenter appliance.

Kaspersky’s records show the configuration change ten minutes and eighteen seconds after the initial Host Profile read. SSH reached the running state thirty-three seconds after the push. That short interval gives defenders a concrete correlation window across vCenter Events, host management logs and service-state records.

A host-level policy that normally disables SSH can fail as a boundary when its controller is compromised. The malicious change still arrives through an authorized management mechanism. Our defensive reading is to alert on an unapproved Host Profile change followed by new vCenter-originated SSH, rather than treating either event as conclusive alone.

Teams investigating similar behavior can also compare this case with our GhostFrame ESXi defender priorities. The cases differ, so a shared ESXi target should not be read as shared attribution. The useful common question is whether management-plane evidence survives long enough to reconstruct host changes.

Why Did the Backup Failure Matter Before Encryption?

Kaspersky reports that the attackers disabled antivirus protection in the backup environment days before the main attack. They later stopped backup services, encrypted recovery infrastructure and disrupted administrative access before final ESXi detonation. Those actions map to ATT&CK T1490, Inhibit System Recovery, within the observed incident.

Backup servers often hold credentials, repository access and reachability into protected workloads. Administrative execution on the backup infrastructure exposed stored credentials in this case. A supposedly immutable copy cannot help quickly if the operator cannot authenticate, reach the repository or run a clean restore.

Our immutable backup explainer defines the storage property, while this incident highlights the rest of the recovery path. Test whether a clean administrator can restore with production identity and vCenter unavailable. Record where backup authentication, management and repository permissions still depend on the affected environment.

Brandefense Blackhole counted 12 dark-chat posts matching BlackNevas from 15 August through 13 November 2026. The measured unit is posts matching the name, not victims, incidents or confirmed activity by this operator. These posts are research context; Kaspersky’s incident evidence supports the case description.

What Happened on ESXi Before the Final Impact?

Kaspersky reports SFTP delivery of the ESXi payload and a short self-test around three hours before final detonation. Its investigators reconstructed the sequence from host authentication and shell logs. The self-test may indicate compatibility checking, but that purpose remains an interpretation rather than an observed operator statement.

The exact virtual-machine stopping method in this incident is unknown. On one disaster-recovery host, however, all VMs stopped within 23 seconds, according to the investigation. An hourly host summary also showed the running VM count falling to zero.

Kaspersky says the destructive phase rendered workloads unavailable and maps it to ATT&CK T1486, Data Encrypted for Impact. Investigators observed roughly the first 2 KB of some virtual-disk files overwritten. That observation does not establish that every disk structure was irrecoverable; recovery depends on the remaining metadata and disk layout.

The distinction matters during response. An early disk overwrite may prevent a guest from booting without proving that all data is gone. Preserve affected virtual disks and document their state before broad repair attempts, then assess recoverability on copies with storage and forensic specialists.

Which Logs Can Reconstruct the Chain?

Start with vCenter Events and Tasks, Host Profile definitions and sign-in records. On ESXi, Kaspersky prioritizes auth.log for SSH sessions, shell.log for commands, vpxa.log for vCenter-driven activity and vobd.log for service-state changes. Correlating these sources can reveal the Host Profile push, SSH enablement and subsequent host access.

Review the vCenter appliance for newly installed remote-management software and unapproved systemd services. A VMware-looking service name is not proof of compromise by itself. Compare the service and its binary with an approved baseline, then tie its creation to the account and session history.

For impact timing, hostd.log and vCenter Tasks can show rapid VM power operations. vmksummary.log provides a coarser running-VM count, while storage and kernel logs can help corroborate datastore disruption. Backup-server security-control changes and service stops should be correlated with the virtualization timeline.

Collection order affects what remains available. Kaspersky notes that ESXi local logs can sit on a limited ramdisk and disappear after reboot. Copy or remotely preserve authentication, shell and management records before disruptive containment when the situation allows.

How Should Defenders Contain and Recover?

First, restrict vCenter management access to a controlled investigation path and export its current Events, Tasks and Host Profiles. Preserve ESXi logs, appliance persistence evidence and backup-server telemetry before rebuilding or rotating credentials. If destructive activity continues, containment may need to move faster than collection.

• Preserve the control planeExport vCenter tasks, sign-ins and Host Profiles before remediation changes them.
• Scope each ESXi hostCollect authentication, shell, vCenter-agent and service-state logs.
• Remove attacker accessRevoke compromised sessions and credentials after retaining their evidence.
• Check host configurationVerify SSH, shell access and security controls against the approved baseline.
• Isolate recoverySeparate compromised backup administration and test a clean restore path.

After evidence collection, disable unapproved SSH and shell access, then verify that Host Profiles will not re-enable them. Restore host security controls to their approved state with the operations team. Remove unauthorized appliance services only after preserving their configuration and associated evidence.

Recovery needs its own administrator accounts, network paths and repository permissions. Kaspersky recommends testing restoration while assuming production Active Directory and vCenter are unavailable. Our ransomware response playbook provides a broader sequence for coordinating containment and restoration.

Keep Kaspersky’s case findings separate from unverified name matches or claims about other organizations. The source supports a local incident sequence, while name-matching chatter offers context without independent confirmation.

Ultimately, this case shows the blast radius of trusted administrative paths. The source supports compromise through credentials and legitimate management interfaces, followed by recovery disruption and ESXi impact. It does not support naming an initial ESXi exploit, a broad BlackNevas campaign or a confirmed actor beyond the ransom-note label.