BigLock is a ransomware discovered in 2020 and also known as “corona-lock.” It encrypts files on the victim system with chacha and AES encryption as specified by the ransomware authors in the ransom note. All encrypted files are appended with “.corona-lock” extension. The malware took advantage of the corona pandemic period by tricking people to open malicious documents with a name like “CORONA TREATMENT.doc” file distributed as an email attachment which is carrying malicious ransomware payload. The malware is spread through spam emails having subject line as “Corona Virus Cure for China or Italy”. Upon execution, the malware modifies registry entries and injects malicious code among boot-up files. After encryption, the ransom-note “README_LOCK.txt” dropped on the desktop and other folders.
The ransom notes state that the data has been encrypted and the algorithm used for encryption are cha and AES. Further, the victims are warned not to use any third-party software or decryption tools. To recover encrypted data the ransom note mentions an email-id to contact malware authors.
Risk Score: 8
Confidence Level: High.
Suspected Malware: BigLock Malware.
Threat actor Associations:
Other Malware related to BigLock: CovidWorldCry Ransomware, CoronaLock Ransomware.
First Seen: May 2020.
File Details: As shown in Figure1 and Figure3, the following are the details related to the ransomware “BigLLock”.
File Type: Windows PE-32 Executable
Compilation Time: March 2019
As shown in Figure1 above the malware is Visual C/C++ based and is PE-32 executable. Further, Figure2 below specifies that the malware is packed.
Figure3 below shows the hashes corresponding to the ransomware and shows that the file has a GUI subsystem and compilation timestamp of 28 March 2019 that is the time when the corona (covid-19) pandemic starts.
Figure4 below shows that how the ransomware is detected as malicious by different anti-malware solutions and some specifically mentioned it related to ransom activity (see highlighted part in Figure4 below).
Figure5 below shows the sections present in the malware and looking quite normal except the .data section which has a large difference in its raw and virtual size and may contain some malicious packed code.
Figure6 below shows the libraries imported by the malware and indicated some of the functionality which it carries which includes low-level functionality to handle memory and devices, the functionality of handling graphical user interface, and other user-interface components.
Figure7 below shows the APIs imported by the ransomware and indicate the following functionality/capability in the malware:
Upon execution of the ransomware, it encrypts the file with the extension “.corona_lock”, for example, if the filename is “sample.zip” after encryption the file name changed to “sample.zip.corona-lock” as shown in Figure8 (highlighted in red) given below. It also excludes the file having some specific extension like .exe. .dll (see Figure8 highlighted part in green).
Figure 9 shows all the folders accessed by the ransomware.
Figure10 below shows the ransom note dropped by the ransomware on the victim machine. It specifies that the encryption used is the combination of ChaCha and AES encryption algorithms and the files encrypted were marked by extension “.corona-lock”. Further instructions are given to the victim not to use any decryption tools which results in loss of data permanently and not contact any third party like data recovery companies. One email-Id “[email protected]” is also mentioned to contact malware authors for getting decryption key. Each victim user has been assigned a unique id as specified in the ransom note below in Figure10. The malware authors instructed that during correspondence the victim must specify this unique id. The ransom notes also specify a long list of files encrypted by the ransomware.
Figure11 below shows the process tree corresponding to ransomware execution. As shown at point1, the malware unpacks the packed code and uses process hollowing to replace the process with a new malicious process with the same name. After that the malware deletes the shadow volume copies by three different methods, In the first method as shown in Figure11 (at point 2 ), the malware tries to remove the shadow copies by resizing them by using the vssadmin.exe utility available in windows. This method of resizing diff areas to remove shadow copies is relatively new in ransomware families. Similarly in 2nd method at point 3 it used the same utility “vssadmin.exe” to delete the shadow copies by executing the command: “vssadmin.exe Delete Shadows /All /Quiet” and in the 3rd method (as shown at point 4), the ransomware used the “wmic.exe” utility of windows to delete the shadow copies as “wmic.exe SHADOWCOPY /nointeractive”. The methods 2nd and 3rd are quite popular among ransomware families to delete the shadow volume copies so that the victim can’t be able to recover the encrypted files. At last, as shown in Figure11 (point5), the malware tries to delete the ransomware executable from the system.
Figure12 below shows some snippets of registry access by the ransomware. Here the highlighted part shows that the malware tries to gain persistence by modifying registry entries.
|1||Initial Access (TA0001)||T1566 Phishing|
|2||Execution (TA0002)||T1204.002 Malicious File|
|3||Persistence (TA0003)||T1547.001 Registry Keys|
|4||Defense Evasion (TA0005)||T1112 Modify Registry|
|T1497.003 Time-Based Evasion|
|T1055.012 Process Hollowing|
|5||Discovery (TA0007)||T1082 System Information Discovery|
|6||Impact (TA0040)||T1486 Data Encrypted|