A new ransomware group dubbed BERT has surfaced with a disruptive approach aimed at virtualized infrastructures, particularly those using VMware ESXi. Unlike conventional ransomware, BERT forcibly shuts down virtual machines before encryption, crippling recovery strategies and amplifying business disruption.
Targeting the Core of Virtual Infrastructure
First spotted in April 2025 and tracked under the alias “Water Pombero”, BERT has already impacted organizations in Asia, Europe, and North America. Its Linux variant is especially dangerous: it detects ESXi environments and executes commands to forcibly terminate all active virtual machines before beginning the encryption process. This eliminates the possibility of quick backup or live migration, making recovery significantly harder.
High-Speed, Multi-Platform Encryption
Capable of running up to 50 threads concurrently, BERT rapidly encrypts large-scale virtual environments. If launched without arguments, it automatically begins terminating VMs using native ESXi commands—demonstrating a deep understanding of VMware infrastructure.
The malware also targets Windows and Linux systems, often using PowerShell scripts to disable defenses like Windows Defender and User Account Control before retrieving payloads from Russian-based servers. Its cross-platform design enables it to strike hybrid IT environments efficiently.
Impact Across Industries
BERT has primarily targeted the healthcare, technology, and events sectors, with evidence pointing to the reuse of code from previously leaked REvil ransomware. This repurposing indicates a high level of sophistication and a deliberate effort to increase impact.
VMware Environments at Elevated Risk
Traditional disaster recovery plans—such as restoring virtual machines from backups or moving workloads—are rendered ineffective when hypervisors are compromised. A single infected ESXi host can lead to the encryption of dozens of VMs. BERT uses specific file extensions to mark its victims: .encryptedbybert on Windows and .encrypted_by_bert on Linux and ESXi.
Mitigation Strategies
- Monitor for abnormal PowerShell usage and script execution, especially ones disabling security layers.
- Segment ESXi management networks to restrict lateral movement.
- Maintain offline, immutable backups and test recovery procedures regularly.
Recommendations for RELIANOID Clients Using VMware
Clients of RELIANOID using VMware ESXi are advised to:
1. Do Not Run RELIANOID on the Same ESXi Host as the Workloads
Why: BERT shuts down VMs on compromised ESXi hosts before encryption. If RELIANOID runs on the same host, it will be stopped along with your backend services—making it impossible to redirect, failover, or provide maintenance access.
Recommendation:
- Use anti-affinity rules to keep RELIANOID on a separate host or cluster from the backend VMs (e.g., databases, application servers).
- If possible, deploy RELIANOID as a cluster across multiple ESXi hosts to ensure at least one survives a hypervisor-level ransomware attack.
2. Back Up RELIANOID Configuration Off the ESXi Infrastructure
Why: If RELIANOID is encrypted or deleted, configuration loss will complicate recovery—even if backend services are restored.
Recommendation:
- Automate external RELIANOID config exports to secure, offsite storage (outside the ESXi cluster).
- Store backups on immutable storage (e.g., object storage with write-once, read-many policies).
3. Protect the RELIANOID VM from Being Compromised via VMware Tools or Shared Services
Why: Sophisticated ransomware like BERT may abuse guest tools or weak inter-VM communication.
Recommendation:
- Disable unnecessary VMware Tools features inside the RELIANOID VM.
- Avoid using shared ISO/CD-ROMs or shared virtual disks between RELIANOID and other VMs.
- Do not install any additional software inside RELIANOID unless absolutely necessary—minimize its attack surface.
4. Isolate the RELIANOID VM from the ESXi Management Plane
Why: BERT compromises ESXi through admin interfaces. RELIANOID should never have access to ESXi management to prevent becoming an attack bridge.
Recommendation:
- Do not connect RELIANOID to any port group or VLAN used for ESXi management or VMotion.
- Use dedicated virtual NICs/VLANs for frontend (WAN/public) and backend (app servers) traffic only.
- Block RELIANOID from resolving or communicating with ESXi IPs/subnets.
5. Monitor for Signs of VM Termination or Suspicious Behavior from Inside RELIANOID
Why: If BERT is preparing to encrypt the ESXi host, the RELIANOID VM may experience unexpected shutdowns or command attempts.
Recommendation:
- Enable syslog forwarding from RELIANOID to external logging/SIEM.
- Monitor for:
- Sudden shutdown events
- High CPU/disk/network spikes not tied to normal LB activity
- Unusual SSH or login attempts
6. Have a Preconfigured Standby RELIANOID Appliance Outside of ESXi
Why: If the ESXi environment is fully compromised, RELIANOID must be quickly redeployable elsewhere (e.g., cloud, bare metal, different hypervisor).
Recommendation:
- Maintain a pre-installed, pre-configured RELIANOID image (OVA, ISO, or LXC) in another location (e.g., cloud object storage, offsite data center).
- Ensure DNS records, NAT, and SSL certs can be quickly re-pointed to the new RELIANOID node.
As attacks grow more targeted and advanced, the need for proactive infrastructure security is more critical than ever. RELIANOID is here to help you stay ahead.
Related Blogs
