---
id: "CMP-202611-yjdtwm"
page: "https://infrastack.ai/live/CMP-202611-yjdtwm"
kind: "campaign"
aliases: []
title: "BlackNevas ransomware gang reuses stolen logins to get into vCenter and ESXi, then encrypts and wipes every VM and the backups (Kaspersky)"
severity: "high"
cvss: null
epss: null
exploited: true
status: "open"
category: "infrastructure"
products: [{"name": "VMware ESXi", "fixed": [], "vendor": "Broadcom"}, {"name": "VMware vCenter Server", "fixed": [], "vendor": "Broadcom"}, {"name": "Veeam Backup & Replication", "fixed": [], "vendor": "Veeam"}]
ecosystems: []
tags: ["campaign", "early-warning"]
not_affected_if: []
published_at: null
first_seen_at: "2026-11-13T09:41:47+00:00"
updated_at: "2026-11-13T09:43:18+00:00"
sources: [{"source": "analyst", "url": null, "first_seen_at": "2026-11-13T09:41:47+00:00"}]
exploit_sources: []
---

# BlackNevas ransomware gang reuses stolen logins to get into vCenter and ESXi, then encrypts and wipes every VM and the backups (Kaspersky)

Link for people: https://infrastack.ai/live/CMP-202611-yjdtwm (this .md is for agents)

Kaspersky's Global Emergency Response Team describes a recent BlackNevas ransomware incident (BlackNevas has been active since November 2024; SentinelOne calls it a Trigona derivative). Over 10 days the attacker destroyed one unnamed organization's virtualization estate: four ESXi hosts with all their VMs, two vCenter Server Appliances and the connected backup infrastructure. No VMware vulnerability was used. The attacker logged into the normal VMware management interfaces with credentials stolen from other systems. They planted a Ligolo-ng tunnel on vCenter as a systemd service called 'vmware-vdma', turned on SSH (including through Host Profiles), uploaded the locker over SFTP to /tmp/esx64 and ran it with /allsys and /wipe. The victim's identity and the incident date are unknown.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- :VMware ESXi affected range not listed fixed no fixed version listed
- :VMware vCenter Server affected range not listed fixed no fixed version listed
- :Veeam Backup & Replication affected range not listed fixed no fixed version listed

## Cause

How the attacker got in: a stolen credential that still worked (stolen-credential). The attacker "logged into the normal VMware management interfaces with credentials stolen from other systems", and the record does not say how the incident reached users, customers or dependents.

How it reached others: not stated (unknown).

So it does not happen to you: List your long-lived credentials (GitHub tokens, cloud keys, app and service-principal secrets, CI secrets) with their last rotation; rotate anything older than 90 days or without an owner, and set expiry where it is offered.

Last month's incidents with the same cause, and the full checklist: https://infrastack.ai/live/breaches.md#stolen-credential

## How to check

On vCenter (VCSA), look for a systemd unit named vmware-vdma under /etc/systemd/system that points to /opt/vmware/bin/agent (Ligolo-ng). On Windows, look for a service named vspbind (a remote-management agent). Search network logs for C2 domain api.cloudvflare[.]com and IP 45.149.154[.]135, and for management-portal logins from 91.92.242[.]121, 31.41.33[.]212 or 188.240.57[.]94. On ESXi, look for /tmp/esx64, '_wipe' markers on datastores, and SSH/ESXi Shell (TSM-SSH) being switched on unexpectedly, including through Host Profiles. File hashes: SHA-1 28f8da19ddcdf26e426875c7a834b34a79bc1c33 (svhost.exe / lock.exe); SHA-256 15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf and 5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78 (remote-management agent).

## Fix

Treat vCenter as Tier 0: give it dedicated admin accounts and phishing-resistant MFA, and put the management network behind access restrictions. Make sure domain admin accounts and broad AD groups do not get ESXi or vCenter rights (audit the group mappings; CVE-2024-37085 is fixed in ESXi 8.0 U3). Leave SSH and ESXi Shell off, use Lockdown Mode where you can, and alert on any change to TSM-SSH. Keep execInstalledOnly and the host acceptance levels at their secure settings. Send ESXi and vCenter logs to separate remote storage. Patch vCenter, ESXi and Veeam, and retire unsupported versions. Keep backups on separate identities, and test restoring them on the assumption that AD and vCenter are down.

## Timeline

- 2026-11-13T09:41:47+00:00 analyst

## Documents

- [describes] Kaspersky Securelist: Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes https://securelist.com/esxi-ransomware/121959/

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_