> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # BlackNevas destroys VMware estate using leaked Babuk ESXi code - URL: https://f4n6.co.uk/security-feed/blacknevas-destroys-vmware-estate-using-leaked-babuk-esxi-code/ - Published: 2026-11-13T11:59:31.000Z - Updated: 2026-11-13T11:59:31.000Z - Author: Jeff Davies - Tags: #security-feed, CVE-2021-21972, CVE-2021-22005, CVE-2021-21974, BlackNevas, Babuk, LockBit, Twelve ## 1\. Executive summary Kaspersky's Global Emergency Response Team (GERT) investigated an intrusion in which an adversary destroyed an organization's virtualization estate over a 10-day period, targeting four ESXi hosts, every VM hosted on them, both vCenter Server Appliances and all connected backup infrastructure. The ransom notes identified the attacker as BlackNevas, a group Kaspersky says was first observed in November 2024\. No virtualization-layer vulnerability was exploited: the adversary reached vCenter with credentials stolen from non-virtualization systems, used vCenter Host Profiles to enable SSH on ESXi hosts, and delivered an ESXi encryptor over SFTP. The CVEs Kaspersky cites in the report (CVE-2021-21972 and CVE-2021-22005 at CVSS 9.8, both in CISA KEV since 2021-11-03; CVE-2021-21974 at CVSS 8.8, not in KEV) are background on virtualization attack surface, not the vector here. EMEA financial services firms running shared VMware estates where vCenter, backup and production identity sit in one trust domain carry the exposure this case describes; the risk is architectural, not patch-level. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 17: ICT-related incident management process | The adversary disabled antivirus on the backup environment days before the main attack, then stopped backup services and encrypted recovery infrastructure before ESXi detonation, in that order. | The incident-management process must cover the recovery plane as a distinct stage: detection and escalation for backup-service stoppage and security-control disablement, not only for production impact. | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | Four ESXi hosts, every VM on them, both VCSAs and all connected backup infrastructure were destroyed over 10 days. | An event of this scale meets the major-incident threshold on duration and impact; the reporting clock runs from classification, and the timeline evidence needed to classify sits in ESXi logs that a reboot can erase. | | DORA Art. 28: ICT third-party risk — general principles | vCenter and ESXi are third-party (Broadcom) products whose management plane the attacker abused through supported interfaces; backup infrastructure is a further third-party dependency. | Third-party risk assessment must cover the management-plane and recovery-plane dependencies, including whether the provider's supported interfaces can be turned against the estate. | ## 3\. Technical analysis & attack chain Kaspersky states plainly that no virtualization-layer vulnerability was exploited: no guest-to-host escape, no hypervisor memory corruption. Every action against ESXi went through legitimate VMware management interfaces. The confirmed sequence, reconstructed by GERT from host and management-plane telemetry: 1. Credentials obtained from non-virtualization systems inside the perimeter were used to reach the vCenter Server Appliances. Kaspersky does not state which systems, which accounts, or how the credentials were first taken. 2. The attacker authenticated to the vCenter appliance managing virtualization disaster recovery as root over SSH. Forty-three seconds later they fetched and deployed MeshAgent, the endpoint component of the legitimate MeshCentral remote management platform, through a shell script. The SSH session lasted 2 minutes 26 seconds; the adversary did not use SSH to that appliance again. 3. Roughly four hours later they returned through MeshAgent and installed Ligolo-ng v0.8.2 as a persistent systemd unit, giving a reverse tunnel into the management segment (T1543.002, T1572). The unit file is `/etc/systemd/system/vmware-vdma.service`, service name `vmware-vdma`, description "DNS, time, VM settings sync (v2.03.24766)", `ExecStart=/opt/vmware/bin/agent`, `Restart=always`. Strings in `/opt/vmware/bin/agent` include `Ligolo-ng v0.8.2` and `api.cloudvflare[.]com:443`. 4. Using vCenter Host Profiles, the attacker changed the Tech Support Mode SSH (TSM-SSH) service state to enable SSH on target ESXi hosts. The recorded sequence: at T+0 vCenter read host configuration through the Host Profile workflow (`vpxa.log`); at T+10m18s a configuration change was pushed to enable SSH (`vpxa.log`); at T+10m51s TSM-SSH reached RUNNING state (`vpxa.log` \+ `vobd.log`). Eleven minutes from initial read to remote access. Subsequent direct SSH to the ESXi hosts originated from the vCenter appliance IP. 5. The ESXi payload was delivered over SFTP. `auth.log` recorded a client identifier associated with FlowSsh, Bitvise's SSH client library. Kaspersky notes the library identification rests primarily on the recorded client identifier, not on behaviour alone. 6. Commands, reconstructed mainly from `shell.log`: `true` (no-op probe, dedicated session); at T+1s `chmod +x /tmp/esx64`; at T+1m48s `true` again; at T+1m49s `./tmp/esx64 /selftest`. The self-test ran about 16 seconds, roughly three hours before detonation. 7. Destructive execution: `./tmp/esx64 /p /vmfs/ /depth 5 /wipe /allsys /detach /-showvolumes`. Kaspersky's parameter reading: `/p /vmfs/` targets the VMFS root (high confidence); `/depth 5` is recursion depth (high); `/wipe` is overwrite behaviour, with `._wipe` artifacts present across datastores (high for destructive behaviour, medium for implementation); `/allsys` includes system files, aligned with publicly documented BlackNevas/Trigona behaviour (medium, no binary to validate); `/detach` detaches from the terminal, activity continued after SSH disconnect (high); `/-showvolumes` suppresses volume listing per documented family parameters (medium). 8. Approximately the first 2 KB of virtual disk files were overwritten. Kaspersky notes this can destroy the protective MBR and primary GPT header, but that the UEFI specification requires backup GPT headers, so a 2 KB overwrite alone does not make partition metadata unrecoverable; practical recovery depends on what else was modified and the virtual-disk layout. 9. Backup infrastructure was hit first, not as collateral. The attacker disabled antivirus on the backup environment days before the main attack, later stopped backup services, encrypted the recovery infrastructure and disrupted administrative access, all before ESXi detonation. Kaspersky also states the adversary extracted stored credentials after gaining administrative execution on backup infrastructure, creating a route to other tiers. The VM-stop method used in this incident is not known. Kaspersky gives the family behaviours as context: GwisinLocker, LockBit and Conti enumerate worlds with `esxcli vm process list` and kill with `esxcli vm process kill`; AvosLocker and RedAlert (aka N13V) use a single shell pipeline; Hive and fcker.py use `vim-cmd vmsvc/power.off`; RansomHub ESXi builds use custom C++ logic. In this case the disaster-recovery host showed all VMs stopping within 23 seconds and `vmksummary.log` dropping to zero. Attribution and confidence. The ransom notes identified the attacker as BlackNevas; that is the operator's own claim. Kaspersky's comparison to the Trigona and BlackNevas command-line family (SentinelOne describes BlackNevas as a Trigona derivative with ESXi-capable builds and switches including `/p` or `/path`, `/wipe`, `/depth` and `/detach`) strengthens attribution but, in Kaspersky's words, does not replace a binary hash or reverse-engineered match. No hash is available for the ESXi encryptor, the Ligolo-ng binary, the agent installer script or the credential-extraction script. BlackNevas has no MITRE ATT&CK profile; treat the attribution as unconfirmed. The Kaspersky report is the single source for this incident. The CVEs Kaspersky lists are explicitly not related to this incident and are given as attack-surface illustration. CVE-2021-21972 (vSphere Client plugin, unauthenticated RCE) and CVE-2021-22005 (vCenter Server, arbitrary file upload leading to RCE) are both CVSS 9.8 critical and in CISA KEV since 2021-11-03; CVE-2021-21974 (ESXi OpenSLP, RCE) is CVSS 8.8 high and not in KEV. Kaspersky describes the Twelve group chaining CVE-2021-21972 and CVE-2021-22005 to plant a web shell on a vCenter appliance, loading a backdoor that injected a shared object into the SSH daemon for persistence. That is a separate event. The report also covers CVE-2024-37085 (ESXi AD integration, fixed in ESXi 8.0 U3, exploited by Akira and Black Basta per Microsoft, in CISA KEV) and the Veeam flaws CVE-2024-40711 (in KEV, exploited by ransomware) and CVE-2025-23120 (not in KEV, affects domain-joined backup servers only), neither seen exploited in this case. ## 4\. Mitigation & containment P1 within 24h - Treat vCenter as Tier 0\. Restrict management-network access to dedicated paths, require phishing-resistant MFA through supported identity federation for vCenter administrative accounts, and monitor privileged sessions. The attacker in this case reached vCenter with credentials from non-virtualization systems and then used Host Profiles to enable SSH. - Audit `/etc/systemd/system` and `/opt/vmware` on every VCSA against the organisation's approved service list. Any unit referencing a non-baselined binary under a VMware-like path, particularly one with `Restart=always`, is a high-confidence anomaly. Check for `vmware-vdma.service` and `/opt/vmware/bin/agent`. - Check `execInstalledOnly` runtime state and kernel enforcement on every ESXi host. Value 0/FALSE permits non-installed code to run; ESXi 8 enables the runtime option by default. Also check host acceptance level for any change to a less trusted level. - Confirm ESXi and vCenter logs are forwarded to remote storage outside the virtualization trust domain. ESXi logs internally to a ramdisk cleared at reboot; do not reboot an ESXi host to evict a session before `auth.log`, `shell.log`, `vpxa.log`, `vobd.log` and vCenter Events/Tasks are preserved. - Block egress to `api.cloudvflare[.]com` and the listed IPv4 addresses at proxy, DNS and firewall; hunt for the hashes in §5. P2 within 72h - Remove unnecessary direct Active Directory dependency on ESXi hosts. Where AD is required, apply Broadcom's secure AD configuration, restrict administrative group membership to accounts that need it, use separate admin credentials for domain and hypervisor, and continuously audit ESXi permission mappings. For CVE-2024-37085 on older systems, Broadcom's workaround is to set `esxAdminsGroupAutoAdd` from true to false and `authValidateInterval` from 1440 to 90 minutes; the fix is ESXi 8.0 U3. - Disable SSH on ESXi hosts except during approved troubleshooting windows, use Lockdown Mode where operationally suitable, and alert on any TSM or TSM-SSH state change outside an approved window, especially when followed within minutes by an SSH session from vCenter or another management appliance. - Separate backup identities and management from production. Use independent administrative identities for backup, minimise domain dependencies, isolate repositories and management interfaces, and protect immutable copies from production credentials. Test a restore assuming vCenter and production AD are unavailable. - Hunt for the pre-impact sequence: SFTP upload or new executable under `/tmp`, `chmod` or execution from the same SSH client or source, a short validation run, then access to `/vmfs`. Treat it as critical. P3 within 7 days - Patch or isolate unsupported ESXi versions. Kaspersky notes the target organisations ran unsupported ESXi versions, which the Babuk-derived locker targets alongside current builds. - Build correlation rules from the two logic examples in the report: Host Profile remediation changing TSM/TSM-SSH to RUNNING within 5 minutes with no approved change window, escalating to critical if an SSH session from vCenter follows within 15 minutes; and the `/tmp` staging sequence above. - Review Veeam exposure. CVE-2024-40711 is in CISA KEV and exploited by ransomware; CVE-2025-23120 affects domain-joined backup servers only. Neither was seen exploited in this case. No fixed release for either is named in the Kaspersky report; check Veeam's own advisory. ## 5\. Indicators of compromise Kaspersky states these are incident-specific artifacts, not durable signatures for BlackNevas or any family; service names, filenames, domains and VPS infrastructure can be changed or reassigned. Single-sourced (Kaspersky GERT); verify before enforcement. | Type | Value | Confidence | Source | | ------- | ---------------------------------------------------------------- | ---------- | -------------- | | service | vmware-vdma | High | Kaspersky GERT | | service | vspbind | High | Kaspersky GERT | | domain | api.cloudvflare\[.\]com | High | Kaspersky GERT | | ipv4 | 45.149.154\[.\]135 | High | Kaspersky GERT | | ipv4 | 91.92.242\[.\]121 | High | Kaspersky GERT | | ipv4 | 31.41.33\[.\]212 | High | Kaspersky GERT | | ipv4 | 188.240.57\[.\]94 | High | Kaspersky GERT | | sha1 | 28f8da19ddcdf26e426875c7a834b34a79bc1c33 | High | Kaspersky GERT | | sha256 | 15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf | High | Kaspersky GERT | | sha256 | 5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78 | High | Kaspersky GERT | The sha1 value is recorded against svhost.exe / lock.exe; the two sha256 values are the remote-management agent and an installed variant. No hashes are available for the ESXi encryptor, the Ligolo-ng binary, the agent installer script or the credential-extraction script. ```iocs service vmware-vdma service vspbind domain api.cloudvflare[.]com ipv4 45.149.154[.]135 ipv4 91.92.242[.]121 ipv4 31.41.33[.]212 ipv4 188.240.57[.]94 sha1 28f8da19ddcdf26e426875c7a834b34a79bc1c33 sha256 15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf sha256 5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78 ``` Behavioural indicators | Behaviour | Where to observe | Confidence | | --------------------------------------------------------------------------------------------------------------- | ----------------------------------- | ------------------ | | Host Profile remediation changes TSM or TSM-SSH to RUNNING outside an approved window | vCenter Events, vpxa.log, vobd.log | High | | New SSH session from vCenter to ESXi after a security-state change | auth.log \+ network flow | High | | New or modified systemd unit in /etc/systemd/system referencing a non-baselined binary under a VMware-like path | VCSA filesystem / audit | High | | execInstalledOnly set to 0/FALSE or kernel enforcement disabled | vobd.log \+ config audit | High | | Host acceptance level lowered outside maintenance | vCenter / ESXi config | High | | true\-only SSH session followed seconds later by exec or chmod from the same source or client | auth.log \+ shell.log | High when combined | | Executable under /tmp performs a short self-test and later touches /vmfs | shell.log | High | | Many VM power-off or world-kill actions within seconds or minutes | shell.log, hostd.log, vCenter Tasks | High | | Backup services stop or security controls disabled shortly before hypervisor changes | Windows/backup telemetry + vCenter | High | | Rapid creation of wipe markers or destructive writes across multiple VMFS volumes | filesystem + vobd/vmkernel | High | ## 6\. Detection ```yara rule ESXi_Ligolo_VMWare_Masquerade_Unit { meta: author = "Adverse Trace" date = "2026-11-13" reference = "https://securelist.com/esxi-ransomware/121959/" description = "Detects the vmware-vdma systemd unit and Ligolo-ng agent strings observed on a compromised VCSA" strings: $unit = "vmware-vdma.service" ascii wide $desc = "DNS, time, VM settings sync" ascii wide $exec = "/opt/vmware/bin/agent" ascii wide $ligolo = "Ligolo-ng v0.8.2" ascii wide $c2 = "api.cloudvflare.com:443" ascii wide condition: uint32(0) == 0x464c457f and 2 of them } ``` ```yaml title: Host Profile remediation enables TSM-SSH followed by vCenter-originated SSH id: 8f3c2a71-6b4e-4d19-9a02-7c5e1d0b4a66 status: experimental description: Correlates a Host Profile change enabling TSM-SSH with a subsequent SSH session from vCenter to the same ESXi host author: Adverse Trace date: 2026-11-13 references: - https://securelist.com/esxi-ransomware/121959/ logsource: product: vmware service: vcenter detection: profile_change: event_type: 'HostProfileApply' service_changed|contains: - 'TSM-SSH' - 'TSM' new_state: 'RUNNING' ssh_from_vcenter: event_type: 'SSHSession' source_role: 'vcenter' timeframe: 15m condition: profile_change | near ssh_from_vcenter falsepositives: - Approved maintenance windows that legitimately enable SSH on ESXi hosts level: critical ``` ```yaml title: ESXi payload staged under /tmp and executed before VMFS access id: 2d9b7e04-1c58-4f6a-b3d7-9e0a5c8f1b23 status: experimental description: Detects an executable written under /tmp, chmod or execution from the same SSH source, and subsequent access to /vmfs author: Adverse Trace date: 2026-11-13 references: - https://securelist.com/esxi-ransomware/121959/ logsource: product: vmware service: esxi detection: staging: file_path|startswith: '/tmp/' action: 'create' execution: command_line|contains: - 'chmod +x /tmp/' - '/selftest' vmfs_access: command_line|contains: '/vmfs/' timeframe: 4h condition: staging and execution and vmfs_access falsepositives: - Legitimate administrative scripts staged under /tmp during approved maintenance level: critical ``` ## CVE assessment 3 referenced CVEs — **2 actively exploited (CISA KEV)**, 2 critical (CVSS ≥ 9.0) | CVE | CVSS | Exploited | EPSS | Summary | | -------------------------------------------------------------------------------- | ------------ | ---------------- | ---- | -------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2021-21972](https://nvd.nist.gov/vuln/detail/CVE-2021-21972?ref=f4n6.co.uk) | 9.8 Critical | ⚠ KEV 2021-11-03 | 100% | The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with ne… | | [CVE-2021-22005](https://nvd.nist.gov/vuln/detail/CVE-2021-22005?ref=f4n6.co.uk) | 9.8 Critical | ⚠ KEV 2021-11-03 | 100% | The vCenter Server contains an arbitrary file upload vulnerability in the Analytics service. A malicious actor with network acc… | | [CVE-2021-21974](https://nvd.nist.gov/vuln/detail/CVE-2021-21974?ref=f4n6.co.uk) | 8.8 High | — | 45% | OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a… | ## 7\. Sources - Kaspersky GERT (Securelist), "Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes", https://securelist.com/esxi-ransomware/121959/, 2026-11-13 - Kaspersky GReAT (Securelist), "Virtualization security: attack layers and misconfiguration impact", https://securelist.com/virtualization-security-esxi-and-proxmox-ransomware-cases/121819/ (separate ESXi and Proxmox cases; no facts from it are used above) ## 8\. Adverse Trace position Adverse Trace assesses this as a high-impact destructive intrusion against a single victim, with the severity resting on the architectural exposure rather than on any CVE: no vulnerability was exploited, and the CVEs Kaspersky cites are background. The BlackNevas attribution is the operator's claim in the ransom note, supported only by command-line comparison to a publicly documented family; it is unconfirmed and single-sourced, and we will not treat it as established until a binary match is published. For EMEA financial services clients the exposure is concrete: any estate where vCenter can enable SSH on hosts by policy, where backup administration shares an identity plane with production, and where ESXi logs live only in ramdisk is one stolen credential away from the outcome described here. We will track for a published hash of the ESXi encryptor or a reverse-engineered match to BlackNevas, and we will reissue this advisory if either appears. Clients running VMware estates should complete the P1 checks in §4 and report back on `execInstalledOnly` state and VCSA systemd baselines within 24 hours. --- [Read the original source →](https://securelist.com/esxi-ransomware/121959/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*