Technical Analysis of REvil ransomware

Research Team:
Anthony Lai, Alan Ho, and Ken Wong from VXRL

October 2021

Background

Recently, we have dealt with ransomware incidents and can restore the ransomware binary from the C:\perflogs folder in the victim machine, which is afterward executed to encrypt the entire NAS file server.

Given this incident, we hope to highlight a few technical features of REvil in both static analysis and dynamic analysis areas.

Ransomware REvil Hashes

md5: 30883080a1ece1a12dea56e56ac9b095

sha1: 96468bdd860e5f84086337806c5afee03f4d232b

sha256: 5d070ff8da0cf01fb955394cecafa84f31b731826c2a0b110bc2d226ff4ab192

Static Analysis

Similarity Level

We have taken another public REvil sample (https://github.com/UIM-SEC/ransomware-samples/blob/master/revil_sodinokibi.zip and hash value: 2ca64feaaf5ab6cf96677fbc2bc0e1995b3bc93472d7af884139aa757240e3f6) for binary similarity and differing:

Binary Differing with BinDiff

Our captured sample from the victim machine is similar to the public sample with a similarity level of 0.86. There is 83% of functions are matched. Most of the unmatched functions are related to thread and process.

Function Similarity Score
Function Block and Flow Comparison
Figure out partially unmatched function
Unmatched Function Reverse Engineering
List of Primary Unmatched Functions

From a holistic view, we can find those unmatched nodes (in red color):

Binary Differing Overview

We illustrate one block at 0x400635C, which is not found in the REvil public sample, let us carry out further analysis about this block in the Feature section:

Unmatched Function Analysis — 1
Unmatched function Analysis — 2

Feature Level

  1. Anti-Debugging

We have found REvil has implemented rdtsc instruction The Read-Time-Stamp-Counter (RDTSC) instruction can be used by malware to determine how quickly the CPU executes the program’s instructions. It returns the count of the number of ticks since the last system reboot as a 64-bit value placed into EDX:EAX.

It will execute RDTSC twice and then calculate the difference between low order values and check it with the CMP condition. If the difference lays below 0xFFFFFFFFh no debugger is found if it is above or equal then the application is debugged.

Anti-Debugging with rdtsc — 1
Anti-Debugging with rdtsc — 2

2. Cryptography

RC4 is used for encryption

Compared with other ransomware families, some may use Windows Crypto API, however, we did not find it, a reasonable prediction is they will implement the encryption inside the binary.

Import Table

From the binary similarity comparison, we have identified unmatched functions, in response to the address 0x40635C, and cross-checking with IDA disassembler, we have identified it is RC4 encryption algorithm.

Reverse engineered function in RC4 — KSA
Reverse engineered function in RC4 — PRGA

For advanced analysts or cryptographers, it is quite basic for RC4, you can simply skip it, but we publish a blog is for educational purposes, hopefully, we can get different levels of analysts can understand and reload some missing knowledge.

RC4 is a stream symmetric cipher. It operates by creating long keystream sequences and adding them to data bytes.

RC4 encrypts data by adding it XOR byte by byte, one after the other, to keystream bytes. The whole RC4 algorithm is based on creating keystream bytes. The keystream is received from a 1-d table called the T table.

The T table is 256-byte long and is created based on the secret key. It is created as the first step of both encryption and decryption. The following operations must be performed to create the table:

  1. Every cell in the table is filled with a number equal to its position. The positions of the table are numbered ​from 0 to 255.
  2. A new temporary helper variable is created and set to 0.
  3. For each element in the array the two following operations are performed (note, that the values ​are ​from 0 to 255):
  • The value of the temporary variable is updated.
  • The number in the array at the current position is swapped with the number in the array at the position determined by the temporary variable.

During encryption and decryption, the keystream bytes are constantly generated. They are added XOR to message bytes. The keystream bytes are produced based on the T table. The following steps are performed:

  1. Two helper variables p1 and p2 are created and set to 0.
  2. The variable p1 is increased by 1 and the result is modulo divided by 256.
  3. The variable p2 is increased by the value in the array T at the position determined by the temporary variable p1 (T[p1]). Then, the result is divided modulo by 256.
  4. The value in the array at position p1 is swapped with the value in the array at position p2.
  5. The value in the array at position p1 is added to the value in the array at position p2. Then, the result is modulo divided by 256 and assigned to the new helper variable p3.
  6. The value in the array at position p3 is a new keystream byte.
  7. If more keystream bytes are needed, all the steps from point II onwards should be repeated.
RC4 Algorithm

RC4 Algorithm

As working on reverse engineering, we are required to identify some loop counters and for loop routine, which can be easier for us to predict and lead us to precise judgment on which type of encryption is done, we reference to open source rc4 implementation in C language in Github and simply put it to godbolt.org to convert and verify our analysis:

RC4 in C Vs Assembly Instruction — KSA
RC4 in C Vs Assembly Instruction — PRGA

Elliptic Curve 25519

We have identified the ransomware implements Elliptic Curve 25519 algorithm. We have compared it with the one in the OpenSSL GitHub repository (https://github.com/openssl/openssl/blob/master/crypto/ec/curve25519.c) for verification.

Elliptical Curve 25519 Function — 1
Elliptical Curve 25519 Function — 2

Elliptic Curve 25519 algorithm

For the details of the RC4, Elliptic Curve algorithm, and 25519 algorithms, you can study from the following links:

http://www.crypto-it.net/eng/symmetric/rc4.html

https://crypto.stanford.edu/~dabo/cs255/lectures/ECC.pdf

https://fission.codes/blog/everything-you-wanted-to-know-about-elliptic-curve-cryptography/

Dynamic Analysis

We use ANY.RUN to conduct the dynamic analysis of the REvil Ransomware

md5: 30883080a1ece1a12dea56e56ac9b095
sha1: 96468bdd860e5f84086337806c5afee03f4d232b
sha256: 5d070ff8da0cf01fb955394cecafa84f31b731826c2a0b110bc2d226ff4ab192

OS: Windows 10 Professional (build: 16299, 64 bit)

Executing the REvil Sample

The ransomware sample is named as netframe.exe

The REvil Ransomware is imported to the ANY.RUN
Manually executed the sample
The document and media files are encrypted, and the background is changed
The Ransom Notes

Typical behavior of Ransomware, once executed, it will encrypt the document and media files, change the desktop background and ask the victim to read the Ransom notes.

*updated on 17-Oct-2021, The Happy Blog from REvil was gone offline.
ref: https://thehackernews.com/2021/10/revil-ransomware-gang-goes-underground.html

Network Analysis

There are a few connections made during the analysis, however, it is making connections to legitimate sources like Microsoft. The sample itself does not make outbound network connections.

Processes Analysis

netframe.exe is extracted and executed manually, the process analyzer detects that it will read computer names, environment values, create files and rename files like ransomware.

process graph
netframe.exe is flagged as a dangerous process

Mitre ATT&CK Matrix

The MITRE ATT&CK™ framework is a comprehensive matrix of tactics and techniques for better classifying the attacks and assessing organizational risk.

Mitre ATT&CK Matrix of the sample

Execution: It is executed manually by the user

Discover: It queries the registry and system information

Impact: It encrypts the data

Compared with another ransomware sample, REvil is relatively not noisy, which behaves more stealthy especially creating different processes and executing more malicious actions:

Non-REvil family ransomware exhibits more malicious activities

Conclusion

Our team has done the static and dynamic analysis of the REvil Sample. We studied the binary similarity between our sample and the published public REvil sample, and reverse engineering of our captured REvil_sodinokibi sample, getting to know the applied anti-debugging techniques and encryption algorithms.

From dynamic analysis, the sample does not make network connections, this implies that the ransomware is tailored-made for the victim, the encryption key is already pre-defined. We did not see noisy network traffic including key download and stolen data upload, as the attacker keeps everything simple and atomic.

In the coming new article, we will discuss another ransomware captured in our incident response. Please stay tuned.

VXRL Team is founded by group of enthusiastic security researchers, providing information security services and contribute to the community. https://www.vxrl.hk