# ESXi/vCenter Ransomware Destroys Virtualization Estate via Legitimate Management Features (BlackNevas/Trigona-linked)

> Kaspersky GERT investigated a roughly 10-day intrusion in which an attacker destroyed four ESXi hosts, every VM on them, two vCenter Server Appliances and connected backup infrastructure. No virtualization-layer vulnerability was exploited: the attacker used reused valid credentials, vCenter Host Profile remediation to enable SSH, and legitimate VMware interfaces. Ransom notes name BlackNevas and the command-line style matches Trigona/BlackNevas, but attribution is not confirmed because no ESXi encryptor binary was recovered.

- **Published:** 2026-11-13T09:18:05Z
- **Last reviewed:** 2026-11-13T09:18:05Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5951
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5951.png
- **ID:** TL-2026-5951
- **Severity:** HIGH
- **Category:** RANSOMWARE
- **Status:** ACTIVE
- **Actor:** BlackNevas
- **Detections:** 9 (1 shown free below) · **IOCs:** 15 (3 shown free below)
- **CVEs:** CVE-2024-37085

## Description

In the incident documented by Kaspersky GERT (Securelist, 13 Nov 2026), the attacker spent about 10 days between initial access and destructive activity. Initial access was not tied to any ESXi or vCenter vulnerability. Administrative credentials harvested from non-virtualization systems (domain controllers, jump servers, backup systems, workstations) were reused to reach the vCenter Server Appliances (VCSA). Valid logins looked normal, so detection depends on source host, account history and whether the account normally manages virtualization. After obtaining admin execution on the backup server, the attacker ran a credential-extraction script against stored credentials, and disabled antivirus on the backup environment days before detonation.

On the VCSA the attacker logged in over SSH as root and fetched and deployed MeshAgent (a MeshCentral endpoint component) via a shell script 43 seconds into a 2m26s session. About four hours later the attacker returned through MeshAgent and installed Ligolo-ng v0.8.2 as a persistent systemd unit, /etc/systemd/system/vmware-vdma.service, described as 'DNS, time, VM settings sync (v2.03.24766)', with ExecStart /opt/vmware/bin/agent and Restart=always. The binary embeds the C2 api.cloudvflare[.]com:443 (a typosquat of cloudflare.com). Because the attacker stopped using SSH after the first session, SSH-only monitoring would miss the return. A Windows remote-management agent was also installed as service 'vspbind'.

To reach the ESXi hosts, the attacker read a Host Profile on vCenter (vpxa.log), pushed a configuration that flipped TSM-SSH from policy-disabled to running (push at T+10m18s, RUNNING at T+10m51s), and then connected by SSH to ESXi directly from the trusted vCenter IP. The payload was uploaded via SFTP (auth.log client identifier consistent with Bitvise FlowSsh). shell.log shows a 'true' probe, 'chmod +x /tmp/esx64', a second probe and './tmp/esx64 /selftest' (about 16 s), roughly three hours before detonation.

Before hypervisor detonation, backup services were stopped, backup infrastructure was encrypted and admin access disrupted. Detonation used './tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes'. All VMs were stopped within 23 seconds (vmksummary.log), the first ~2 KB of VMDK files was overwritten, and '.\_wipe' artifacts were found across datastores. /detach let activity continue after the SSH session ended. The exact VM-stop method is unknown.

Attribution: ransom notes name BlackNevas (first observed November 2024; described as a Trigona derivative citing SentinelOne), and the forward-slash CLI parameters (/p, /path, /wipe, /depth, /detach) match SentinelOne's documentation of BlackNevas. Kaspersky states this supports but does not confirm attribution. The article also notes the leaked Babuk ESXi source (Sept 2021) underlies many ESXi lockers. Several ESXi/vCenter/Veeam CVEs are discussed as background (e.g. CVE-2024-37085, CVE-2021-21972, CVE-2024-40711), but none was identified as the entry point, so cve_list is empty. The key lesson is that fully patched hypervisors still suffer maximum impact when the identity, management or recovery plane is compromised.

## MITRE ATT&CK

- T1078.002 Domain Accounts
- T1555 Credentials from Password Stores
- T1021.004 SSH
- T1059.004 Unix Shell
- T1219 Remote Access Tools
- T1572 Protocol Tunneling
- T1543.002 Systemd Service
- T1036.004 Masquerade Task or Service
- T1685 Disable or Modify Tools
- T1489 Service Stop
- T1490 Inhibit System Recovery
- T1485 Data Destruction

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**BlackNevas ESXi Host Profile SSH Enablement Followed by Direct SSH Logon** (`TL-2026-5951-SPL-001`)

Detects the TL-2026-5951 pre-detonation pattern where vCenter Host Profile remediation flips TSM-SSH from disabled to running on an ESXi host and an SSH logon to the same host follows (T1021.004 with valid domain/admin credentials, T1078.002). No vulnerability is exploited in this intrusion, so the signal is the management-plane behaviour: SSH should be off by default and should not be enabled and used by an account outside the virtualization admin population.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1078.002, T1021.004
- **Data sources:** VMware ESXi syslog (index=esxi sourcetype=vmw-syslog), VMware ESXi auth.log / vobd.log / hostd.log forwarded via syslog, Azure Sentinel Syslog table
- **Severity:** high
- **Confidence:** high

### Splunk SPL

````spl
index=esxi sourcetype=vmw-syslog earliest=-24h ("SSH access has been enabled" OR "TSM-SSH" OR "Accepted password for" OR "Accepted keyboard-interactive/pam for" OR "Accepted publickey for")
```Stage 1: Host Profile remediation flips TSM-SSH to running. Stage 2: direct SSH logon on the same ESXi host (TL-2026-5951 BlackNevas T1021.004)```
| eval stage=case(match(_raw,"SSH access has been enabled|TSM-SSH"),"ssh_enabled",match(_raw,"Accepted (password|keyboard-interactive/pam|publickey) for"),"ssh_login")
| eval ssh_user=if(stage="ssh_login",replace(_raw,".*Accepted [^ ]+ for ([^ ]+) from .*","\1"),null()), ssh_src=if(stage="ssh_login",replace(_raw,".* from ([0-9.]+) port .*","\1"),null())
| stats min(_time) as first_seen max(_time) as last_seen values(stage) as stages values(ssh_user) as ssh_users values(ssh_src) as ssh_sources by host
| where mvcount(stages)=2
| eval first_seen=strftime(first_seen,"%F %T"), last_seen=strftime(last_seen,"%F %T")
| table host first_seen last_seen ssh_users ssh_sources
````

### Microsoft KQL

```kql
// ESXi syslog forwarded to Sentinel: SSH enabled then SSH logon on same host
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("SSH access has been enabled", "TSM-SSH", "Accepted password for", "Accepted keyboard-interactive/pam for", "Accepted publickey for")
| extend Stage = case(SyslogMessage has_any ("SSH access has been enabled", "TSM-SSH"), "ssh_enabled", SyslogMessage has "Accepted", "ssh_login", "other")
| extend SshUser = extract(@"Accepted [^ ]+ for ([^ ]+) from", 1, SyslogMessage), SshSource = extract(@" from ([0-9.]+) port", 1, SyslogMessage)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Stages = make_set(Stage), SshUsers = make_set(SshUser), SshSources = make_set(SshSource) by Computer
| where array_length(set_intersect(Stages, dynamic(["ssh_enabled", "ssh_login"]))) == 2
| project Computer, FirstSeen, LastSeen, SshUsers, SshSources
```

### Sigma

```yaml
title: ESXi SSH Service Enabled Through Host Profile or Management Action
id: 7a3e9c14-5b2d-4f68-9e01-c4d8a2b61f30
status: experimental
description: Detects ESXi audit events showing SSH access being enabled. In the TL-2026-5951 BlackNevas-linked intrusion the attacker pushed a vCenter Host Profile that started TSM-SSH and then logged in over SSH from the vCenter IP.
references:
  - https://securelist.com/esxi-ransomware/121959/
  - https://www.sentinelone.com/anthology/blacknevas/
author: Threadlinqs Team
date: 2026-11-13
tags:
  - attack.initial-access
  - attack.t1078.002
  - attack.lateral-movement
  - attack.t1021.004
logsource:
  product: esxi
  service: syslog
detection:
  keywords:
    - 'SSH access has been enabled'
    - 'esx.audit.ssh.enabled'
  condition: keywords
falsepositives:
  - Approved maintenance windows where an administrator temporarily enables SSH
  - Host Profile compliance runs that legitimately set TSM-SSH
level: high
```

**Known false positives:**

- Approved maintenance windows where an authorized administrator enables SSH through vCenter or the DCUI
- Host Profile compliance remediation that intentionally sets TSM-SSH to running
- Scheduled automation or backup agents that use SSH to ESXi hosts

**Tuning notes:** Adjust index/sourcetype to where ESXi syslog is ingested. Allow-list change-ticketed maintenance windows and known jump-host/automation source IPs. Raise priority when the SSH source IP is the vCenter appliance or when the account does not normally manage virtualization. Verify the exact ESXi message strings against your ESXi build.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- ESXi Payload Staging: chmod +x [indicator] and /selftest After SFTP Upload (locked: unlock with TL Creds)
- Backup Service Stop and Recovery Inhibition on Backup Server (Veeam, VSS, wbadmin) (locked: unlock with TL Creds)
- Remote-Management Agent Hashes, vspbind Service and MeshAgent/Ligolo Execution (locked: unlock with TL Creds)
- Backup Credential Store Extraction (Veeam Credentials Table / Get-Creds Script) (locked: unlock with TL Creds)
- Antivirus Disabled or Excluded on Backup Environment Before Detonation (locked: unlock with TL Creds)
- BlackNevas ESXi Wiper Detonation: esx64 /wipe /detach /allsys on VMFS (locked: unlock with TL Creds)
- VCSA Masquerading systemd Unit vmware-vdma Hosting Ligolo-ng Agent (locked: unlock with TL Creds)
- BlackNevas Ligolo-ng C2 Typosquat [indicator] and Known Threat IPs (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sample indicators (3 of 15)

Defanged, TLP:CLEAR.

- IP address: `45.149.154[.]135`
- Domain: `api[.]cloudvflare[.]com`
- File hash: `28f8da19ddcdf26e426875c7a834b34a79bc1c33`

Full set of 15 indicators unlocks with TL Creds: https://threadlinqs.com/tl-creds

## Sources

- [Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes (Securelist, Kaspersky GERT)](https://securelist.com/esxi-ransomware/121959/)
- [SentinelOne Anthology: BlackNevas](https://www.sentinelone.com/anthology/blacknevas/)
- [SentinelOne: What Is Trigona Ransomware?](https://www.sentinelone.com/anthology/trigona/)
- [SentinelOne: From Conti to Akira - Decoding the Latest Linux/ESXi Ransomware Families](https://www.sentinelone.com/blog/from-conti-to-akira-decoding-the-latest-linux-esxi-ransomware-families/)
- [CISA Known Exploited Vulnerabilities Catalog (CVE-2024-37085 and other VMware CVEs discussed as background)](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [MeshCentral (legitimate remote-management tool abused as MeshAgent)](https://github.com/Ylianst/MeshCentral)
- [Ligolo-ng (reverse tunneling tool)](https://github.com/nicocha30/ligolo-ng)
- [LOLESXi - native ESXi binaries abused by attackers](https://lolesxi-project.github.io/LOLESXi/)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5951