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

Key facts

Detection coverage

As of 2026-11-13, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5951 across Splunk SPL, Microsoft KQL and Sigma, covering 15 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: BlackNevas ESXi Host Profile SSH Enablement Followed by Direct SSH Logon

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

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

// 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

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.

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

Indicators of compromise

As of 2026-11-13, Threadlinqs Intelligence tracks 15 indicators of compromise for TL-2026-5951.

Sample indicators (3 of 15)

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

Defanged, TLP:CLEAR. Full set of 15 indicators: unlock with TL Creds.

Technical analysis

Ransom notes name BlackNevas and the command-line style matches Trigona/BlackNevas, but attribution is not confirmed because no ESXi encryptor binary was recovered.

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 techniques by tactic:

Lateral Movement

T1021.004 SSH

Defense Evasion

T1036.004 Masquerade Task or Service

Execution

T1059.004 Unix Shell

Initial Access

T1078.002 Domain Accounts

Command and Control

T1219 Remote Access Tools; T1572 Protocol Tunneling

Impact

T1485 Data Destruction; T1489 Service Stop; T1490 Inhibit System Recovery

Persistence

T1543.002 Systemd Service

Credential Access

T1555 Credentials from Password Stores

defense-impairment

T1685 Disable or Modify Tools

Remediation

Patches

• Patch and retire unsupported ESXi versions
• Apply Broadcom AD hardening guidance; CVE-2024-37085 is fixed in ESXi 8.0 U3

Immediate actions

• Isolate vCenter from enterprise segments while keeping a controlled investigator path
• Export vCenter Events/Tasks, SSO audit, sessions and Host Profile definitions before rotating credentials
• Collect ESXi auth.log, shell.log, vpxa.log, vobd.log, hostd.log, vmkernel.log, vmkwarning.log, vmksummary.log, esxupdate.log, hostprofiletrace.log
• Preserve VCSA /etc/systemd/system, referenced /opt/vmware binaries, shell history, wtmp and auth logs
• Do not reboot ESXi to evict the attacker; ramdisk logs may be lost
• Rotate compromised admin credentials after evidence is preserved

Workarounds

• Set esxAdminsGroupAutoAdd to false and authValidateInterval to 90 minutes; clear default ESX Admins mapping on older builds
• Keep execInstalledOnly enabled and host acceptance level at baseline
• Stop Host Profiles from re-enabling SSH; remove unauthorized systemd units only after imaging

Longer-term hardening

• Treat vCenter as Tier 0 with dedicated admin identities, phishing-resistant MFA and restricted management networks
• Separate virtualization identities from enterprise/domain admin accounts; audit ESX Admins mappings
• Keep ESXi SSH and Shell disabled by default; use Lockdown Mode where suitable and require approval for shell enablement
• Forward ESXi and VCSA logs to remote storage outside the virtualization trust domain
• Design backup as a separate security boundary with independent identities, isolated repositories and restore tests that assume vCenter and AD are down

Affected and fixed versions

• VMware (Broadcom) — ESXi
  Vulnerable versions: Environments with valid-credential access to vCenter/ESXi management; no specific vulnerable build identified
• VMware (Broadcom) — vCenter Server Appliance (VCSA)
  Vulnerable versions: Environments with exposed or credential-reachable VCSA management; no specific vulnerable build identified

Timeline

• 2021-09-01 Babuk ESXi ransomware source code leaked (September 2021; month precision); since reused by at least ten ransomware families and paired with leaked LockBit Windows builds.
• 2024-11-01 BlackNevas ransomware, a Trigona derivative per SentinelOne, first observed (November 2024; month precision).
• 2026-11-13 Kaspersky GERT publishes the case on Securelist, noting no vulnerability was exploited and attribution to BlackNevas/Trigona is supported but unconfirmed.
• 2026-11-13 Detonation: .locked-ioc-10 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes; all VMs stopped within 23 s, first ~2 KB of VMDKs overwritten, four ESXi hosts, two VCSAs and backups destroyed.
• 2026-11-13 Payload locked-ioc-10 uploaded via SFTP, chmod +x, and run with /selftest (~16 s) about 3 hours before detonation; backup services stopped and backup infrastructure encrypted beforehand.
• 2026-11-13 Offset ~+10 days (relative): Host Profile read on vCenter, config pushed at T+10m18s, TSM-SSH RUNNING at T+10m51s; direct SSH from the vCenter IP to ESXi hosts follows.
• 2026-11-13 Offset ~+4 h after first VCSA session: attacker returns via MeshAgent and installs Ligolo-ng v0.8.2 as systemd unit vmware-vdma.service with C2 locked-ioc-5:443.
• 2026-11-13 Incident day 0 (absolute incident dates not disclosed; offsets relative): attacker reuses admin credentials from non-virtualization systems, logs in to a VCSA as root over SSH and deploys MeshAgent 43 s into a 2m26s session; AV had been disabled on the backup environment days earlier.

Sources cited

• CISA Known Exploited Vulnerabilities Catalog (CVE-2024-37085 and other VMware CVEs discussed as background) CISA · Government advisory
• Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes (Securelist, Kaspersky GERT) Kaspersky Securelist · Research · 2026-11-13
• SentinelOne Anthology: BlackNevas SentinelOne · Research
• SentinelOne: What Is Trigona Ransomware? SentinelOne · Research
• MeshCentral (legitimate remote-management tool abused as MeshAgent) GitHub · Code repository
• Ligolo-ng (reverse tunneling tool) GitHub · Code repository
• LOLESXi - native ESXi binaries abused by attackers lolesxi-project.github.io · Code repository
• SentinelOne: From Conti to Akira - Decoding the Latest Linux/ESXi Ransomware Families SentinelOne · Blog

More in ransomware

• Pixelleaks (new group) claims data leak from Huangshi Medical Laboratory / Ezong Medical Group x Getein JV (China, healthcare)
• Ransomware Leak-Site Cadence Analysis: INCRANSOM, TheGentlemen and Audit Team Run Active Intrusion Pipelines Amid Group Consolidation
• Vexy Ransomware lists Upper Web (Brazil, Technology) as a victim
• AI-Enabled Ransomware Evolution: Machine-Speed Kill Chains and Initial Access Broker Disruption (TrendAI Assessment, ARTEX Agentic Exploitation Context)
• Everest ransomware leak-site listing: "Final Notice Before Publication" (victim unnamed)

More from BlackNevas

• BlackNevas and The Gentlemen Ransomware Cases Against ESXi and Proxmox Virtualization Environments

Other reports on CVE-2024-37085

• Gentlemen Ransomware (Storm-2697): Double-Extortion RaaS with Fortinet Exploitation, BYOVD EDR Killers and GPO-Based Mass Deployment
• Healthcare Sector Ransomware Targeting and Expanding Attack Surface (Qilin, Akira, DragonForce, LockBit, The Gentlemen)
• The First 24 Hours of a Ransomware Intrusion: Exfiltration, Credential Theft and Backup Targeting (Akira, REDBIKE, AGENDA)
• The Gentlemen RaaS overtakes Qilin as #1 ransomware operation, wields GentleKiller EDR-killer framework (400+ processes, 8 BYOVD variants) and 90% affiliate payouts
• Akira Ransomware Kill Chain — SSLVPN Credential Stuffing → Kerberoasting → RDP Lateral → vssadmin Shadow Copy Deletion (SANS ISC Forensic Reconstruction, May 2026)
• Foxconn North American Factories Cyberattack — Nitrogen Ransomware Claims 8 TB / 11M+ Documents Stolen, Including Network Topologies for AMD/Intel/Google

Previous and next in ransomware

• Beast Ransomware (RaaS) Disables Backup Services, Deletes Shadow Copies, and Encrypts Network Drives Previous report
• Ransomware attack on Belarusian cloud provider ActiveCloud disrupts hosting, email and virtual servers Next report