Revix Linux Ransomware

7 min readDec 7, 2021

A duplicate copy of this article by Vishal can also be found here: 
https://angle.ankura.com/post/102hcny/revix-linux-ransomware

In the first half of 2021, we started to see the REvil ransomware operators targeting Linux-based systems with a new Linux version of the more commonly seen Windows version of the same ransomware. There have been a few versions of this Linux-based malware since then.

In this publication, we take a look at the latest version, 1.2a.

Malpedia link

YouTube link

YARA Rulesets

https://github.com/YaraExchange/yarasigs/blob/master/ransomware/crime_lin_revil.yar
https://github.com/YaraExchange/yarasigs/blob/master/ransomware/crime_lin_revix.yar

Quick Snapshot

Class: ELF64
Type: Dynamically Linked 
Machine: X86-64
Number of section headers: 28
Entry Point: 0x401650
callq: __libc_start_main@plt 
MD5: c83df66c46bcbc05cd987661882ff061

Introduction

The execution of this malware is straight forward. It traverses through the directories targeted by it and encrypts the files present in those directories. Once encryption is complete, it drops a ransom note in the directory with the usual ransom message and instructions on how to pay the bad actors to get the decryption key.

This malware requires a couple of parameters to be passed to it in order for it to successfully execute. It also requires to be run with escalated privileges in order to be able to successfully encrypt files on the disk.

One of the main targets for this malware is VMware’s ESX platform, which we’ve seen before in a different Linux ransomware, Darkside.

This malware is not able to encrypt data if being executed by a non-privileged user. It also checks the files in the target directories to see if they are already encrypted.

Analysis

For the purpose of this publication, we analyse this malware both statically and dynamically. We switch between the two methodologies as we go through the analysis process.

A quick look at section .init:

Section .text:

Functions

The malware loads a number of functions upon initialisation. Following some of the interesting ones we are able to extract useful information that can be used to understand the flow of execution and write some detections as we’ll see later in this article.

Initialization

Let’s take a quick look at the program initialization:

Parameters for the command-line arguments

Execution

When executed as a non-privileged user, the malware is not able to achieve full execution.

As we can see in the image below, the malware has been provided the directory ‘here’ for the purpose of this analysis:

The malware tries to access the data in this directory for read/write and is not successful as the image below shows:

The malware also tries to encrypt the test file that we have provided for the purpose of this analysis in the target directory but the encryption process fails as that action requires higher privileges:

As a result, the execution fails to achieve the desired outcome for the malware, as shown by the result in the image below:

Another point of interest from this failed execution is that the malware attempted to execute a esxcli command but was not able to do so:

All of this changes when we run the malware with escalated privileges.

Firstly, the malware is able to access the data in the target directory:

Next, we can see that the malware is able to perform read/write functions on the data in the target directories, resulting in successful encryption of that data:

We can see from the image below that the malware is able to write the ransom-note text file to the disk:

And finally, we can see that the execution is completed successfully, resulting in the data present in the target directory being encrypted:

The file we provided in the target directory is now encrypted and a ransom-note is created in the same directory:

The malware also checks if the data in the target directory is already encrypted. To demonstrate this, we ran the malware against the same target directory one more time.

Upon execution, the malware runs a check on the data present in the target directory and identifies it to be already encrypted:

As a result, the execution ends up with no data being encrypted:

VMware ESX targeting

This malware also tries to use the esxcli, the command line interface for VMware ESX platform. Let’s take a quick look at the parameters passed to esx as command-line arguments.

esxcli --formatter=csv --format-param=fields=="WorldID,DisplayName" vm process list | awk -F "\"*,\"*" '{system("esxcli vm process kill --type=force --world-id=" $1)}'

vm process list

List the virtual machines on this system. This command currently will only list running VMs on the system.

vm process kill

Used to forcibly kill Virtual Machines that are stuck and not responding to normal stop operations.

— type

There are three types of VM kills that can be attempted: [soft, hard, force].

— world-id | -w

The World ID of the Virtual Machine to kill. This can be obtained from the ‘vm process list’ command (required)

So basically what these esx command-line arguments are doing is shutting down all VMs running on the ESX platform.

The idea is to run the malware targeting the ‘/vmfs’ directory and encrypt all the data present in that directory so all the VMs are rendered inoperable until the data is decrypted.

This targeting is similar to that seen in DarkSide’s Linux variant.

Command-line Arguments

The malware requires the following parameters to be passed for its execution to begin:

elf.exe — path /vmfs/ — threads 5

It also allows the ‘ — silent’ option that executes the malware without stopping the VMs

— silent (-s) use for not stoping VMs mode *

Config

The config of this Linux version is similar to that of its Windows variant, only with less fields.

Here’s an image showing the config we were able to extract from the sample we analysed:

Profiling

The malware also gathers information about the victim machine which is gathered by running this command:

uname -a && echo “ | “ && hostname

And we can see the result in the stack:

The info is then passed through the registers:

And the end-result is created in the form of this config with the victim information:

Encryption

The malware uses Salsa20 encryption algorithm (just like its Windows variant) to encrypt the data and here’s the pseudocode for the function that implements it:

Mitigation

Detections

The malware runs this command to determine machine info:

uname -a && echo " | " && hostname

The malware tries to query this directory:

/dev/urandom

The malware runs this command to stop VMs running on the ESX platform in order to encrypt the data on those VMs:

esxcli --formatter=csv --format-param=fields=="WorldID,DisplayName" vm process list | awk -F "\"*,\"*" '{system("esxcli vm process kill --type=force --world-id=" $1)}'

Typos:

In some instances, typos that malware authors commit to the code are useful in detection of the malware or similar code used in other malware. These are a couple of typos we found in this variant of Revix:

--silent (-s) use for not stoping VMs modesemms to be protected by os but let's encrypt anyway…

Conclusion

As we can see in the analysis notes above, the execution is a bit clunky in this variant and requires multiple conditions to be met before the ransomware is successful in encrypting data. The malware needs to be executed as a command-line argument with elevated privileges and specified target directories and number of threads. If the malware is not run in silent mode, it will try to stop the VMs which could trigger off a detection and quite possibly fail to encrypt data on the VMs due to reduced/restricted access.