Ransomware and trojan horses are often delivered to unsuspecting users as e-mail attachments. Once activated, such malware can cause excessive damage on the computer where the malware was activated, or worse yet, spread to other networked devices as well.
This article describes a strain of malware recently analysed by the Crimson Wall team. The malware was written in C# and is heavily obfuscated. Furthermore, it also contains checks to ensure that it is not executed in a virtual environment. During the investigation, an encryption key was found that we'll make available in the hope of assisting others that fell victim to this strain of malware.
Although no ransonware-like activities were observed while studying the malware it is still possible that the malware will eventually use its encryption routines for malicious purposes. For this reason we'll publish the key to ensure that others that were actually hit by this strain of malware may benefit from our research by using the extracted key to decrypt data encrypted by the malware.
In this article we'll be discussing the following topics:
- De-compiling malware written in C#.
- Unpacking malware and de-obfuscating heaviliy obfuscated code.
- Bypassing a popular virtual machine check function that is currenttly being used by malware written in C#.
- Operation of malware referred to internally as "FrogsGrieving".
- Extraction of an encryption key found within the decompiled code.
Analysis of the FrogsGrieving malware.
The FrogsGrieving malware has been obseved to be distrubuted via e-mail, typically as an attachment to an email. The attacker attempts to trick the user into opening the attachment by giving it an inviting name (in this case a name that implies that the attachment contains an invoice). The screenshot below shows an actual e-mail message delivered with the FrogsGrieving malware:
[Image: FrogsGrieving e-mail message. Note the extension of the malware is .gz.]
The malware was distributed in an archive with a .gz extension. This is rather strange as gzip files are generally not used to compress business-related data. Using the GNU file command it was established that the file was in fact not a gzip-compressed archive, but rather a RAR archive. The attacker therefore likely assumed that the victim would have WinRAR installed.
[Image: The attachment is actually compressed using RAR.]
Since WinRAR is clever enough to realise that the file extension is incorrect it would still be able to extract the archive, even though the extension is wrong. The attackers likely used this method to hide their malware from mail virus scanners and email server rules that forbid attachments in the RAR format.
Unpacking the RAR file creates a file called "INV92939488434pdf.exe".
[Image: Unpacking the RAR file.]
The created binary file was loaded into Ghidra. Ghidra revealed that the binary masqueraded as a legitimate application called HP Coolsense.
[Image: Portable Executable (PE) information.]
The binary was de-compiled using ILSpy. The screenshot below shows that the FrogsGrieving malware was using a namespace called "devineblueprint":
[Image: Obfuscated C# output created be de-compiling the malware.]
What is also interesting is that the actual malware payload was stored in a url-encoded gzip string. The following screenshot shows the names of the decompiled source files created. Only one file name was not obfuscated.
[Image: Files created by the decompiler.]
[Image: Obfuscated VM detection code.]
Some Googling revealed that malware named "Infinity Cryptor" used relatively similar code to perform VM detection.
[Image: Infinity crypter: malware-as-a-service.]
The reason why malware performs VM detection is that malware research teams (including the team at Crimson Wall) run malware in virtual environments to study their behaviour. This VM detection code is simply yet another measure to make it more difficult for researchers to study the malware.
Although the VM detection code is not an exact match of the code used by the Infinity crypter it is still a close enough match to realise some resemblence. It is likely that the author copied parts of the detection routine from other malware (such as Infinity cryptor). Studying the VM detection code used by the malware revealed that many checks were in place to detect VirtualBox and VMWare. However, no checks were in place to detect KVM.
A KVM virtual machine was subsequently created and the malware executed again. This time the malware actually ran since the VM detection routine did not detect KVM.
Process Monitor showed that the malware constantly modified a file named "sysmain.sdb". As explained here, application compatibility shims can be used by malware to execute processes.
[Image: Process Monitor output.]
The malware successfully installed itself in the virtual machine using shims. Once installed the malware ran constantly, causing excessive CPU usage.
[Image: Excessive CPU usage caused by the malware.]
The malware was kept running for a few days until all VM resources were exhausted.
[Image: Eventually the malware exhausted system resources and applications started to fail.]
It was observed that the malware would create log files on a daily basis and place these logs in the "AppData/roaming" directory:
[Image: Monitoring files created by malware.]
Logs were also kept:
[Image: Logs kept by malware.]
What is important to note is that the VM was denied access to the internet. It is therefore likely that parts of the malware were not activated as it could not contact any command/control service.
De-obfuscation and private key extraction
As explained previously, the executable file was simply a loader for an embedded binary file (in url-encoded gzip format). Code was written using Mono to simply perform a url-decode on the string data and then decompress and dump the resulting binary data to a file. The file was called "dump3" (this name may come up in subsequent screenshots).
The resulting binary file was also decompiled using ILSpy. This code was also obfuscated. The obfuscator used was identified as ".NET Reactor":
[Image: Detection of the used obfuscator.]
De4dot was used to provide some de-obfuscation.
[Image: De-obfuscation with de4dot.]
The resulting binary was decompiled using ILSpy. Afte this step the decompiled code could be read with greater ease.
During inspection of the decompiled code a key and IV was noticed. The file containing both can be downloaded from this link:
We share this key in the hope that it would help others that were infected by this strain of malware and somehow ended up in a situation in which key is required for decryption purposes.