COVID-19 Ransomware Analysis

Versa Security Lab recently analyzed couple of malware samples which arrives on a computer through phishing emails containing documents with embedded link which eventually leads to the download of the malware. Some of these may arrive through websites pretending to provide information on the recent Corona virus outbreak. The past few months have seen several malicious webservers and domains being set up, purportedly serving information on the Covid-19 virus outbreak. Most of these sites are hosts to ransomware and other malware types. In this blog we are going to look at one sample which encrypts files contents and updates the system boot sector to print a ransomware note.

The sample analyzed in this report (MD5: ec517204fbcf7a980d137b116afa946d) encrypts files with extensions “.txt”, “.doc”, “.pdf”, “.bat”, “.png” etc. These are files important to the end user and are the file types targeted by ransomware.  The primary tool for analysis will be Procmon from Microsoft Sysinternals for dynamic analysis, Windbg and IDA pro for static analysis installed inside a Windows10 32bit VM.

Procmon is configured to filter out all events except those coming from the sample under analysis. When the sample is executed it copies itself to the “Temp” folder inside the users %AppData%\Local\ folder. For each execution the sample copies itself with a different filename containing random characters. From the proc mon log it can be seen that the sample after copying launches itself as follows.

“12:28:32.0653409PM”,”covid.exe”,”6072″,”Process Create”,”C:\Users\winny\AppData\Local\Temp\vmxyqcxi.exe”,”SUCCESS”,”PID: 8188, Command line: “”C:\Users\winny\AppData\Local\Temp\vmxyqcxi.exe””  {03c279c0-2364-11ea-a25c-806e6f6e6963} “”C:\Users\winny\OneDrive\Desktop\covid.exe”””

Once the sample starts execution from the “Temp” folder one of the first things that it does is the renaming of the C drive to what’s shown in the figure below. The Volume is renamed to CoronaVirus(C:)

Figure 1 – Volume renamed

The following disassembled code from IDA pro shows the location responsible for the above action. The call to SetVolumeLabelW sets the volume name to “CoronaVirus”. These calls are inside the function located at virtual address 004038D0.

Figure 2 – Function responsible for volume name change

The sample uses a decoding function to decode the names of programs, strings, DLLs and API names at runtime. This function located at 00401810 is called several times from several functions.

Figure 3 – String decoding function at 00401810

In the following figure we analyze one such call to the string decoding function inside Windbg. The value of the register eax before the call to the decoding function is shown and it has the address of an encoded string. The decoding function takes this string, decodes it into a new buffer and returns it in eax register. In the figure below we see that the gibberish contained at the address in the eax register after decoding becomes the string “CoronaVirus”.

Figure 4 – String decoding

This string decoding function is called several times in a function located at the address 00404380. Studying the function inside IDA pro, one can see that a lot of library names and function names are being decoded and the address of several API’s are resolved at runtime. This ensures that static analysis tools won’t know which all API’s are employed by the sample.

Figure 5 – Decode DLL and API names and resolve API address

In the test VM which had several “.txt” files, all of them were encrypted. The figure below displays the IDA pro license file before executing the sample.

Figure 6 – IDA Pro license.txt file before sample execution

After execution of the sample the same text file is no longer readable and IDA pro fails to launch. In addition to encrypting the file, the file is also renamed. The new filename is a combination of an email address and the original filename and original extension as shown in the figure below.

Figure 7 – Encrypted IDA Pro license, after sample execution

The sample leaves a ransomware note inside the folders where files were encrypted. In addition, from ProcMon logs we can see that the following subkey is set under “Run” key.

“12:28:31.8574304PM”,”covid.exe”,”6072″,”RegSetValue”,”HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\gvkpxy”,”SUCCESS”,”Type: REG_SZ, Length: 100, Data: C:\Users\winny\AppData\Local\Temp\CoronaVirus.txt”

This ensures that whenever there is a user login to the desktop the contents of the text file “CoronaVirus.txt” is displayed. The following figure is a screen capture made when a user logged into the system after the VM was infected with this ransomware.

Figure 8 – Ransomware note displayed on login

The sample also sets up the BootExecute registry key and points it to an executable dropped at runtime. Setting this key ensures that during system boot the ransomware message is displayed. This message is like the ransomware message displayed at user login time.

Figure 9 – BootExecute key modified by sample

The VM in which the sample was analyzed had its boot sector corrupted. This is a side effect of the malwares execution and failing to setup the boot sector properly in the Windows 10 32-bit VM. On reboot the following screen was seen, instead of a ransomware note.

Figure 10 – Corrupt boot sector


Detection of Covid-19 Malware Samples

The sample used in this analysis is detected by the Versa Operating System, VOS™ (formerly FlexVNF), Anti Virus engine as W32/Trojan.ZUSB-7895. In addition, we advise users to be careful when opening emails from untrusted sources and visiting websites claiming to provide information on Corona virus. Clicking on links inside PDF or MS office documents and enabling macro execution inside MS office documents should be avoided. When looking up information about Corona, the biological virus, use trusted websites setup by proper authorities. Do not visit websites received inside emails from untrusted sources.




Download the full report here