Back to overview

Threat intelligence, Threat Research

Orova: A New Linux Ransomware Targeting ESXi Hypervisors

by Security News

This week, the SonicWall Capture Labs Threat Research Team identified and analyzed an emerging ransomware family known as Orova. The sample is an ELF 64-bit binary targeting Linux servers and VMware ESXi hypervisors. This target has drawn growing attention from ransomware operators due to the concentrated value of virtual machine datastores. What makes Orova notable is not any single novel technique, but the combination of a modern cryptographic stack built around Curve25519 and ChaCha20, a flexible operator-controlled command-line interface with explicit ESXi VM kill support, hardcoded victim login codes consistent with a Ransomware-as-a-Service affiliate panel, and dual-site Tor infrastructure for payments and data extortion. At 90 KB, statically linked and stripped, this is a lean, portable encryptor engineered to run on any Linux x86-64 host without dependencies and leave as little forensic surface as possible.

Infection Cycle

Once on the target, the binary is invoked with operator-selected flags tailored to the environment. Based on the supported flags found in the binary, a typical ESXi deployment would look like:
#!/bin/bash 
./<binary>--paths=/vmfs/volumes --threads=8 --percent=50 -killvm

The full set of supported flags, extracted from the binary's string table, gives a clear picture of how much operator control is built in:

Flag  Description 
 `--paths=`  Target directory path(s) to encrypt 
 `--threads=`  Worker thread count 
 `--percent=`  Encrypt only first N% of each file (speed optimization) 
 `--delay=`  Sleep N seconds before starting 
 `-killvm`  Kill all running ESXi VMs before encrypting 
 `-logs`  Enable verbose logging 
 `-recent`  Target only recently modified files 
 `-winenv`  Use Windows exclusion lists (for NFS/SMB-mounted shares) 

Once launched, Orova immediately detaches from the terminal and moves itself to a background process, invisible to anyone watching the session that launched it. It then spins up a thread pool sized to the host's CPU count, maximizing encryption throughput unless the operator overrides it with `--threads=`.

Fig 1. Parent exits, child continues
Figure 1. Decompiled background process routine: double fork() with setsid() in between allows Orova to run silently in the background, with stdin/stdout/stderr all redirected to /dev/null.

On ESXi targets, the `-killvm` flag triggers the following shell command before any file is touched:

#!/bin/bash 
for id in $(esxcli vm process list | awk '/World ID:/ {print $3}'); do \
  esxcli vm process kill --type=force --world-id=$id; done

This enumerates every running virtual machine via the ESXi management CLI and force-kills each one.  Without terminating the VMs first, those files are inaccessible and cannot be encrypted. Killing the VMs releases the locks and simultaneously denies service to every workload hosted on the hypervisor before a single byte of encryption has occurred.

The binary recursively walks all paths specified via `--paths=`. Before encrypting any file, it applies an exclusion check against two hardcoded lists -- one for Linux/ESXi environments (default) and one for Windows-share environments (active when `-winenv` is set).

Files and directories that are skipped include system-critical paths and files the operator does not want to destroy - keeping the host bootable enough for the victim to see the ransom note and make contact:

Excluded directories:`windows`, `system32`, `sysvol`, `proc`, `sbin`, `lib64`, `$recycle.bin`, `programdata`, `appdata`, `temp`, `microsoft`, `mozilla`, and ESXi-specific entries including `healthd`, `lifecycle`, `vdtc`

Excluded filenames:Boot-critical files (`bootmgr`, `initrd`, `vmlinuz`, `boot.cfg`), Windows system files (`ntldr`, `ntuser.dat`, `desktop.ini`), and the ransom note itself (`000___How_to_Recover_Encrypted_Files___000.txt`) - ensuring it is never overwritten mid-run

Excluded extensions:`.exe`, `.dll`, `.sys`, `.key`, `.orova`, `.lock`, VMware image extensions (`.b00`–`.b09`, `.v00`–`.v09`, `.t00`–`.t09`), and boot-related types

The `.orova` extension appearing in the exclusion list is a self-protection measure - any file already encrypted and renamed is skipped, preventing double-encryption.

For every file that passes the filter, Orova pulls 32 random bytes from the operating system's random source (`/dev/urandom`) to create a unique one-time key. That key is then combined with the operator's master public key hardcoded into the binary through a key exchange to produce the actual encryption key used on the file. The intermediate values are immediately zeroed out of memory once the exchange is complete, meaning there is nothing left to recover even if the system's memory is captured while Orova is still running. Decryption of any affected file requires the operator's private key, which exists only on the attacker's infrastructure.

Fig 2. Encryption key generation
Fig 2. Encryption key generation

Files are encrypted in-place using ChaCha20, confirmed by the quarter-round rotation constants (16, 12, 8, 7) and the `"expand 32-byte k"` magic string at binary offset `0x13f20` - the standard ChaCha20 initialization constant. Orova does not use AES-256 or RSA-2048 which is common with other ransomware. The Curve25519 + ChaCha20 + SHA-256 stack requires no OpenSSL dependency and performs efficiently on servers that may lack AES hardware acceleration.

After the file content is encrypted, Orova appends a fixed-format trailer using an encrypted file marker "OROVAENCRYPTEDL." 

Fig 3. Final encryption routine
Figure 3. Decompiled file finalization routine: Orova seeks to the end of the encrypted file and writes the ephemeral public key, the OROVAENCRYPTEDL marker, and a flags byte before closing the file handle and renaming it with the .orova extension.

The file is then renamed with `.orova` appended. A database file named `records.db` becomes `records.db.orova`. A VM disk named `vm-disk.vmdk` becomes `vm-disk.vmdk.orova`.

Fig 4. Orova encrypted files
Figure 4. Example of encrypted files with .orova file extension

After processing each directory, Orova drops the ransom note named "000___How_to_Recover_Encrypted_Files___000.txt". The triple-zero prefix ensures it sorts to the top of any directory listing. 

Fig 5. Contents of the ransom note
Figure 5. Contents of the Orova ransom note

Two Tor sites are referenced: a victim-facing payment portal where the victim authenticates with the hardcoded login code, and a public data-leak blog where stolen data is published for non-paying victims. The 72-hour deadline and the specific categories of data claimed ("tax filings", "executive compensation", "contracts") are chosen to maximize urgency for corporate targets.

Fig 6. Onion payment website
Fig 6. Tor payment website that needs the hardcoded authentication code for access.

 

Fig 7. Chat to cybercriminal
Figure 7. Tor payment website will present the victim with a chat box to contact the cybercriminal.

Several indicators in this binary are consistent with a Ransomware-as-a-Service operation. Each build carries a hardcoded per-victim login code (`45NHC5QQUZUBFIFPL4IK3K94`), consistent with affiliate panel deployments where each victim receives a unique identifier. The operator-configurable CLI options with flags for thread count, encryption percentage, VM killing, and target environment points to a shared tool adapted per deployment rather than a one-off attack. Two separate Tor sites are hardcoded: a payment portal for victims and a data-leak blog for publishing stolen data, implying a backend infrastructure maintained across multiple operations. The `-winenv` flag further extends reach to Windows file shares from the same binary, suggesting an actively maintained codebase serving multiple affiliates.

Review of Orova's data leak blog shows 39 non-paying victims published to date, spanning a wide range of industries including manufacturing, healthcare, non-profit, retail, finance, security, and software. The majority of confirmed victims are organizations based in the United States, Hong Kong, and Taiwan, with additional listings from Japan and Egypt. The breadth of sectors targeted, from hospitals to financial firms to software companies, alongside the geographic spread across multiple continents points to an opportunistic operation with no apparent focus on a single industry or region.

Fig 9. Orova data leak site
Figure 9. Orova data leak site showing non-paying victims' sensitive data

As of this writing, the Orova sample analyzed in this post has zero detections on VirusTotal, further confirming how new and under-the-radar this ransomware family currently is.

Fig 10. VT results, 0 detection
Figure 10. Virustotal results showing 0 detections

Sonicwall Protection

SonicWall Capture Labs protects against this threat via the following signature:

  • GAV: Orova.RSM (Trojan)

This threat is also detected by SonicWall Capture ATP with RTDMI™, SonicWall Endpoint Security, and the Capture Client endpoint solution.

 

 

Share This Article

An Article By

Security News

The SonicWall Capture Labs Threat Research Team gathers, analyzes and vets cross-vector threat information from the SonicWall Capture Threat network, consisting of global devices and resources, including more than 1 million security sensors in nearly 200 countries and territories. The research team identifies, analyzes, and mitigates critical vulnerabilities and malware daily through in-depth research, which drives protection for all SonicWall customers. In addition to safeguarding networks globally, the research team supports the larger threat intelligence community by releasing weekly deep technical analyses of the most critical threats to small businesses, providing critical knowledge that defenders need to protect their networks.

Related Articles

  • 사이버 범죄의 이면: SonicWall, 최근 보고서에서 새로운 사이버 공격에 관한 데이터와 위협 행위자의 행태를 공개합니다
    Read More
  • Wind River VxWorks 및 URGENT/11: 즉시 패치
    Read More
  • 크립토재킹 대재앙: 크립토마이닝의 4기사 물리치기
    Read More