Ransomware and trojan horses are often delivered to unsuspecting users as e-mail attachments. Once activated, such malware can cause excessive
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
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
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.
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”.
The created binary file was loaded into Ghidra. Ghidra revealed that the binary masqueraded as a legitimate application called HP Coolsense.
The binary was de-compiled using ILSpy. The screenshot below shows that the FrogsGrieving malware was using a namespace called “devineblueprint”:
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.
Some Googling revealed that malware named “Infinity Cryptor” used relatively similar code to perform VM detection.
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
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 “
The malware successfully installed itself in the virtual machine using shims. Once installed the malware ran constantly, causing excessive CPU usage.
The malware was kept running for a few days until all VM resources were exhausted.
It was observed that the malware would create log files on a daily basis and place these logs in the “AppData/roaming” directory:
Logs were also kept:
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
The resulting binary file was also decompiled using ILSpy. This code was also obfuscated. The obfuscator used was identified as “.NET Reactor”:
De4dot was used to provide some de-obfuscation.
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.