Reveton belongs to a family of ransomware that locks screens and prevents users from using their machines until they pay a certain amount. Reveton may be downloaded to a victim’s machine from malicious site, by an exploit, or through other malware. Reveton variants (DLLs) usually carry extensions such as dss, pss, psv, dat, bfg, or any three random characters. These samples are executed by a batch or link file using rundll32.exe, as shown in Figure 1.
Figure 1. Batch file to launch Reveton.
Reveton comes with various flavors of encryption to evade antimalware detections. In this blog we will give a brief overview of one of the cryptors used by Reveton in recent variants.
Some previous versions of Reveton had random alphanumerical export names, similar to dsde34fefew, which looked suspicious and were easy to identify. Recent versions have new cryptors and use export names that look legitimate.
Some of the new export names can be seen in Figure 2 and in the following list:
- AndroidDesktoCompression
- AndroidTerminal
- DeviceFor
- OfficeAppKeyBoard
Figure 2. Import table.
The cryptor fakes the version information to look like a legitimate file. In this case it uses the version info of a Microsoft file, as shown in Figure 3.
Figure 3. Fake version information.
Multiple sections of the cryptor can be seen in Figure 4. A decryption key sits in the “.data” section, and the encrypted executable file can be found in one of the other data sections.
Figure 4. Data sections.
“GetProcessheap” followed by “rtlAllocateHeap” APIs reserve a chunk of heap memory to decrypt the data, as shown in Figure 5.
Figure 5. Heap memory allocation.
The first layer of encryption is quite simple. The cryptor stores a key that might be one, six, twelve, or sixteen bytes in size. The key usually lies within the first 500 bytes, followed by zeroes, as shown in Figure 6.
Figure 6. The encryption key.
The data is decrypted to the allocated heap (allocated from RtlAllocateHeap) by subtracting the key from the encrypted bytes. (In this case from the fourth section named .xdata.) If the key is of size n, the key is subtracted from first n bytes of the .xdata section and then is subtracted from the next n bytes.
The decrypted data looks like an executable file; however, it doesn’t look like a completely decrypted file. We can see in Figure 7 that section headers are not completely decompressed and that the UPX and .rsrc section names are jumbled.
Figure 7. A partially decrypted UPX file.
The cryptor calls the RtlDecompressBuffer API to deflate this partially compressed data, as shown in Figure 8.
Figure 8. A call to RtlDecompressBuffer.
This functions supports Huffan and LZ compression. The parameters supplied to this function include compressed buffer, and the size of compressed and uncompressed data.
Figure 9. A completely decompressed UPX file.
Figure 10. A completely decompressed section header.
The section names of the UPX packer are fully visible at this point, as show in Figures 9 and 10. Decompressing the UPX file gives us the decrypted Reveton code. Code around the original entry point of Reveton can be seen in Figure 11.
Figure 11. The malware’s original entry point.
McAfee detects this variant of Reveton with following names:
- Ransom-FFK!
- Ransom-FFM!
- Ransom-FFN!
- Ransom-FFO!
- Ransom-FFQ!
Ransomware has become one of the most prevalent threats. Malware writers keep on finding new means to evade detection. As we have seen here, this particular threat employs a few levels of encryption to avoid easy analysis and detection. It’s vital to keep antimalware products updated, and it’s always a good idea to keep a backup of important data.
Thanks to my colleagues Arvind Gowda and Avelino Rico for their valuable support.