Actively exploited Security news
BlackNevas ransomware wiped ESXi and backups after enabling SSH through vCenter Host Profiles
On 13 November 2026 Kaspersky GERT published its analysis of a BlackNevas ransomware intrusion that encrypted four ESXi hosts with every virtual machine on them, both vCenter appliances and the backup infrastructure. No VMware vulnerability was needed: credentials stolen from other systems and everyday vCenter features were enough. Here is how it unfolded, the indicators, and what to monitor.
Key points
- On 13 November 2026 Kaspersky GERT described an incident in which the BlackNevas group (which SentinelOne describes as a Trigona derivative) destroyed four ESXi hosts, both vCenter appliances and the backups over roughly 10 days.
- No ESXi vulnerability was found as the entry point. The attackers logged in to vCenter with credentials stolen from non-virtualization systems and pulled more credentials from the backup infrastructure.
- On the vCenter appliance they deployed MeshAgent and a Ligolo-ng tunnel disguised as a service called vmware-vdma. They enabled SSH on the ESXi hosts through vCenter Host Profiles.
- Before encryption they disabled antivirus and stopped backup services. On the disaster-recovery host they then stopped all VMs within 23 seconds and ran the encryptor directly against the VMFS volumes.
- The report includes indicators (IPs, a domain, hashes, service names) and concrete detection logic that can go straight into a SIEM.
What happened
On 13 November 2026 Kaspersky's Global Emergency Response Team (GERT) published an analysis of an intrusion in which the BlackNevas group destroyed a victim's entire virtualized estate: four ESXi hosts with every VM on them, both vCenter Server Appliances (VCSAs) and the connected backup infrastructure. Roughly 10 days passed between initial access and the destructive phase. The report does not name the victim or say when the attack took place.
The ransom notes named the group. Kaspersky says BlackNevas was first observed in November 2024 and cites SentinelOne, which describes it as a derivative of the Trigona ransomware with ESXi-capable builds.
The key finding: no ESXi vulnerability was used for entry. Credentials stolen from other systems, plus features vSphere admins use every day, were all the attackers needed.
How the attack unfolded
vCenter appliance. The attacker logged in over SSH as root and, 43 seconds later, used a script to deploy MeshAgent, the endpoint component of the MeshCentral remote-management tool. About four hours later they used it to install a Ligolo-ng 0.8.2 tunnel as the systemd unit vmware-vdma.service, described as "DNS, time, VM settings sync" to blend in with VMware components.
ESXi hosts. SSH on the hosts was switched on through Host Profiles by changing the TSM-SSH service state in a profile. Connections to ESXi then came from the vCenter appliance's IP address, so on the network they looked like routine management. Kaspersky found the traces in vpxa.log, vobd.log and hostprofiletrace.log.
Backups first. Before touching ESXi, the attackers disabled antivirus in the backup environment, stopped backup services, encrypted the recovery infrastructure and disrupted administrative access. The backup infrastructure was also where they harvested further credentials.
Encryption. The encryptor reached ESXi over SFTP into /tmp; the client identifier points to Bitvise's FlowSsh library. About three hours before detonation the attacker ran it in a self-test mode, probably to check compatibility with the ESXi build. All VMs on the disaster-recovery host then stopped within 23 seconds, and the attacker launched the encryptor against the VMFS volumes. Roughly the first 2 KB of each virtual disk file was overwritten. Kaspersky notes that this doesn't necessarily make partition metadata unrecoverable, since backup GPT headers may survive.
How to tell if you were hit
Indicators from the analysis (defanged). Kaspersky notes that they are specific to this incident. No hashes are available for the ESXi encryptor, the Ligolo-ng binary or the installer scripts.
api.cloudvflare[.]com
45.149.154[.]135
91.92.242[.]121
31.41.33[.]212
188.240.57[.]94
SHA-256 15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf
SHA-256 5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78
SHA-1 28f8da19ddcdf26e426875c7a834b34a79bc1c33 svhost.exe / lock.exe
Services: vmware-vdma, vspbind
Files: /etc/systemd/system/vmware-vdma.service
/opt/vmware/bin/agent
/tmp/esx64Behavior is a better signal than hashes. Kaspersky recommends alerting on:
- Host Profile → SSH: a remediation that sets TSM or TSM-SSH to running outside an approved window, especially when an SSH session from vCenter follows.
- New systemd units under
/etc/systemd/systemon the VCSA that launch non-baselined binaries from VMware-looking paths. - Weakened ESXi controls:
execInstalledOnlyswitched off or the host acceptance level lowered. - A binary run from
/tmpfollowed by access to/vmfs, a critical pre-impact sequence. - Mass VM power-offs within a few minutes.
- Backup services or security tools stopped shortly before hypervisor changes.
You can paste logs or SIEM exports into our IOC extractor to pull out IPs, domains and hashes. It runs entirely in your browser.
What to do
Kaspersky's recommendations, with Broadcom's documentation added:
- Treat vCenter as Tier 0: dedicated admin identities, phishing-resistant MFA, a restricted management network and monitored privileged sessions.
- Separate virtualization and backup identities from the enterprise domain, and don't reuse domain admin accounts for them. Keep backups on separate identities and networks, and test restores assuming vCenter and production AD are unavailable.
- Restrict direct SSH to ESXi and use Lockdown Mode where operations allow.
- Keep
execInstalledOnlyon. Broadcom says it is enabled by default in ESXi 8.0 and later, and that turning it off makes hosts more vulnerable to ransomware. - AD-joined ESXi: per Broadcom KB 369707, set
esxAdminsGroupAutoAddto false and shortenauthValidateInterval. - Forward ESXi and VCSA logs outside the virtualization trust domain, so an attacker can't destroy them along with the estate.
- Patch the known vCenter, ESXi and Veeam flaws the report lists as common paths to the hypervisor (none were used in this incident).
- During response, preserve logs and evidence before rotating credentials, and don't reboot ESXi just to remove an attacker session.
Wiping ESXi as the final step also featured in the recent attacks on Check Point gateways.
Timeline
- November 2024 – BlackNevas first observed (per Kaspersky).
- Not disclosed – the incident: about 10 days from initial access to destruction.
- 13 November 2026 – Kaspersky GERT publishes its analysis with indicators and detection logic.
Verified against sources on 13 November 2026.
FAQ
Did the attackers exploit a VMware vulnerability?
According to Kaspersky, no. The analysis found no ESXi vulnerability used for entry. The attackers relied on credentials stolen from other systems and legitimate vCenter features. Older vCenter and ESXi flaws appear in the report only as well-known paths that are still worth patching.
Why does it matter that backups were hit first?
If attackers disable antivirus, stop backup services and encrypt the recovery infrastructure before touching the hypervisor, the victim has nothing to restore from, which raises the pressure to pay. Backups need separate identities and networks, and restores should be tested on the assumption that vCenter and production AD are gone.
Is it enough to block the listed IPs and hashes?
No. Kaspersky stresses that the indicators are specific to this incident, not durable signatures, and no hashes are available for the ESXi encryptor or the Ligolo-ng binary. Behavioral detections are more reliable: SSH enabled via Host Profiles, new systemd units on the VCSA, a binary executed from /tmp and mass VM power-offs.
Should we reboot ESXi if we find an attacker session?
Kaspersky advises preserving logs and evidence before rebooting or rotating credentials. Don't reboot ESXi just to kill an attacker session, because much of the logging lives in memory and a reboot wipes it.
Sources
- Kaspersky Securelist – Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes (13 November 2026)
- Broadcom TechDocs – Deactivate the execInstalledOnly Internal Runtime Option, vSphere 8.0
- Broadcom TechDocs – Securing the ESXi Configuration, vSphere 8.0
- Broadcom KB 369707 – Secure Default Settings for ESXi Active Directory integration
Spotted a mistake? Let us know and we will correct it openly.
Related
Actively exploited
Attackers abuse GSocket for stealthy access to Linux servers
On 11 November 2026 Microsoft published an analysis of intrusions in which attackers, after breaking in through a vulnerable web application, install the legitimate open-source tool GSocket on Linux servers. The connection goes out through a shared relay network, so inbound firewall rules never see it, and the attackers keep access even after the original flaw is patched. The write-up includes paths, hashes, domains and hunting queries.
Actively exploited
Citrus ransomware gets in through contractor accounts and spreads Sn00py by Group Policy
On 11 November 2026 Kaspersky described Citrus, a previously undocumented Russian-speaking ransomware group. It logged in with low-privilege contractor accounts, hid its traffic in VLESS tunnels disguised as Yandex, impersonated a domain controller through an AD CS flaw patched in July and finally pushed its Go-based Sn00py encryptor to the whole domain through Group Policy.
Actively exploited
Attackers exploit a critical Xen Orchestra flaw to take over XCP-ng virtualization
On 10 November 2026 Vates published security advisory VSA-2026-062 for a critical flaw in Xen Orchestra, the web management console for XCP-ng. An unauthenticated attacker can make REST API requests as the owner of a valid login token, typically an administrator, and from there run code on managed XCP-ng hosts as root. Vates says a threat actor is already exploiting it. Fixed xo-server 5.213.1 and 5.211.2 shipped the same day.