Kaspersky’s Global Emergency Response Team (GERT) published a case on 13 November 2026 on Securelist about an attack on a virtualized environment. The ransom notes named BlackNevas, which Kaspersky says was first seen in November 2024. Kaspersky cites SentinelOne for describing BlackNevas as a Trigona derivative, and says command-line resemblance in this case strengthens the attribution; we did not open SentinelOne’s report. Kaspersky reports that no vulnerability in the virtualization layer was exploited; the attackers used legitimate administrative features.
Scope
Over a ten-day dwell time, the attackers destroyed four ESXi hosts and all their virtual machines, two vCenter Server Appliances (VCSAs) and the backup infrastructure. Kaspersky notes ransomware accounted for 39.4% of its 2025 incident-response cases.
Attack chain (as reported)
- vCenter access. The attackers logged in as root over SSH to a VCSA and deployed MeshAgent for remote control; the post puts this 43 seconds after login.
- Tunnel. About four hours later, Ligolo-ng was installed as a systemd service named
vmware-vdma. - SSH on ESXi. A Host Profile was pushed from vCenter to enable the ESXi SSH service (TSM-SSH). Kaspersky puts the whole reconfiguration, from the first configuration read to direct SSH access, at 11 minutes.
- Backups. Antivirus on the backup server was disabled days before detonation.
- Payload. The encryptor was delivered over SFTP. About three hours before detonation, the actor ran
./tmp/esx64 /selftest. - Detonation. All VMs on the disaster-recovery host were stopped within 23 seconds, followed by
./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes. About 2 KB of each VMDK was overwritten, which is enough to make the disks unusable.
Notes naming BlackNevas were left, but overwriting about 2 KB of each VMDK is, in our assessment, closer to destruction than conventional encryption. Kaspersky itself says the 2 KB overwrite does not by itself mean the disks are unrecoverable (it points to GPT backup headers), so treat “destruction” as our label, not a finding. Whether paying would have enabled recovery is not something we can state from the post.
Indicators
Kaspersky lists, among others: the domain api.cloudvflare[.]com and IPs 45.149.154[.]135, 91.92.242[.]121, 31.41.33[.]212 and 188.240.57[.]94, plus file hashes. It has no hashes for the ESXi encryptor. Take the full list from the Securelist post.
Defender priorities (from the post, with our emphasis)
- Treat vCenter as Tier 0. The whole chain started with a vCenter appliance; its compromise gave control of every host.
- Disable SSH and the ESXi Shell when not in use, and alert when they are enabled, including through Host Profiles.
- Forward logs off-host. ESXi logs sit on a ramdisk; Kaspersky advises not rebooting hosts during response because logs are lost.
- Restrict execution with
execInstalledOnlyso unsigned binaries in/tmpdo not run. - Apply the CVE-2024-37085 workaround where relevant (the post lists it among its mitigations).
- Make backups a separate security boundary: separate credentials, separate administration, and tested offline copies.
Our assessment
The case matters because the attackers needed no exploit: they used root access to a management appliance and its built-in features. Defences that look only for malware on hosts would have seen little until the final minutes.
For tracking purposes, the key lesson is detection timing: the warning signs (new systemd service on a VCSA, Host Profile change, SSH enabled, backup AV disabled) all preceded encryption by hours or days. Alerts on those four events are cheap relative to the outcome.
Single-source caveat: this is Kaspersky’s account of one engagement. We have not seen independent confirmation of the BlackNevas link.