Anthony Lai, Alan Ho, and Ken Wong from VXRL
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
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:
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.
From a holistic view, we can find those unmatched nodes (in red color):
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:
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.
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.
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.
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:
- 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.
- A new temporary helper variable is created and set to 0.
- 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:
- Two helper variables p1 and p2 are created and set to 0.
- The variable p1 is increased by 1 and the result is modulo divided by 256.
- 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.
- The value in the array at position p1 is swapped with the value in the array at position p2.
- 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.
- The value in the array at position p3 is a new keystream byte.
- If more keystream bytes are needed, all the steps from point II onwards should be repeated.
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:
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.
Elliptic Curve 25519 algorithm
For the details of the RC4, Elliptic Curve algorithm, and 25519 algorithms, you can study from the following links:
We use ANY.RUN to conduct the dynamic analysis of the REvil Ransomware
OS: Windows 10 Professional (build: 16299, 64 bit)
Executing the REvil Sample
The ransomware sample is named as netframe.exe
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.
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.
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.
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.
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:
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.