We have been closely monitoring Cerber ransomware since it first emerged on a Russian password-protected forum, offered as-a-service for members only.
At present, Cerber ransomware constitutes a sophisticated malware threat to organizations. (it was responsible for more than 25% of the total number of ransomware infections recorded worldwide in June 2016, according to Microsoft). Files encrypted by Cerber are currently non-decryptable.
On August 23, 2016, a member of the same closed forum where Cerber ransomware is traded posted a detailed analysis of the loader that the malware uses to install itself. According to his post, he did this after hearing that the loader is very useful and capable of installing any malware without detection. His conclusion was that the loader does not employ any extraordinary methods to install the ransomware, but its tremendous advantage of being fully undetectable by AV programs is due to the usage of several rare code functions that are difficult to emulate.
First, he posted the full obfuscated code of the loader, explaining parts of it:
- Another part of the code creates a Desktop shortcut, probably also as an anti-emulator measure (the post writer comments that in his opinion AV would quickly detect it).
- The next part of the code is obfuscated – a HEX code which is divided and deobfuscated using XOR.After deobfuscation, we can see that the code contains anti-emulation.
- Then a random string is created and a path from %TEMP% environment obtained for it.
- The next stage involves downloading the malicious file from an URL address and saving it in the system.
- A parameter is added to the header to block AV bots and researchers: setRequestHeader(‘cerber’,’true’)
- If the malicious payload was downloaded properly, it is executed.
- Finally, the Eval alternative is launched.
Summarizing the analysis, the post author concludes that the advantages of the loader are a good implementation of the payload download and execution and errors control. The disadvantages he mentions are weak implementation of obfuscation and anti-emulation, and low level of usability functionality. He also attached an AV scanner report from August 23, showing a detection rate of 15/40.
Several days later, on August 27, 2016, the same forum member posted that he had analyzed the latest version of the loader and was surprised by the fact it is totally undetectable by AV programs. Moreover, this version is capable of installing payloads from several alternative URL addresses and it uses improved debugging. This version does not use anti-emulation at all, but employs a unique method that totally blocks the AV syntax emulation.
Below is a description of the main techniques used by the loader to remain undetected:
- Replacement of the Eval function (even though it is a simple technique, it is used extensively by JS packers and therefore cannot be detected by AV as malicious).
- The part of the code that avoids emulation is an array that contains random data, with the first element being the important one. The functions Math.floor and Math.random always output only the first element in the array and AV cannot properly emulate them. Full undetectability is achieved by using these two functions.
The emulator will always output one single value and will never reach the part of the array when the right value is located. As a result, the emulator cannot perform the calculations, a critical error occurs and the AV programs are unable to identify the loader as a malicious file.
The post author attached an AV scanner report showing a 0/35 detection rate (as of August 27, 2016).