Cerber Ransomware Evolved to Evade Machine Learning

Ransomware text with red lock
Cerber ransomware, which dodges machine learning systems, can be defeated with more powerful security approach that uses several layers of protection.

Since its discovery in 2016, the Cerber ransomware has grown to be one of the biggest threats of its kind.

Over time, the malicious code has undergone multiple enhancements and has reached out to the public through various distribution channels.

These include exploit kits, spam emails, and malware like Betabot.

According to Mark Nunnikhoven, the vice president of Trend Micro’s cloud research team, these changes are being developed according to how various products identify malware that are a potential threat.

Some recent enhancements in Cerber Ransomware

A past version of the malicious ransomware that was first identified in October 2016 presented a threat that killed database processes on the infected systems.

The most recent version that was noticed has a striking difference over its earlier counterparts – this version completely avoids machine learning that makes it all the more difficult to locate the malicious software on systems that it has infected.

On the system that it attacks, the single ransomware file splits itself into various mini files and infects different running processes.

While the mode of system infection is through a phishing email, like the previous versions, the difference lies in the email’s contents.

The email features a link to a self-extracting ZIP archive.

This archive has already been uploaded to a Dropbox account that is owned by the attackers, and is responsible for downloading and extracting the ransomware.

There are three files in the archive: a DLL file, a binary file resembling a configuration, and a Visual Basic script.

Users tend to activate the installer unknowingly that triggers the malware and its related files, following which the users’ files are encrypted with the ransomware.

How do the three files work?

The three files in the archive are closely linked with one another and work in near-perfect synchronization.

The Visual Basic script is first executed by the Windows Script Host.

The executed file then loads the DLL file with its name using the run32dll.exe file.

The loaded DLL file is then responsible for executing the contents of the ransomware’s binary file.

It must be noted that the DLL file is neither encrypted nor packed.

The DLL file analyses the binary file and decrypts it partially.

The decrypted code that is then executed by the DLL includes the configuration settings and the loader for the malware.

What checks are performed by the loader?

Business, Technology, Internet and network concept. Man showing a word in a virtual tablet of the future: Machine learning
This version completely avoids machine learning that makes it all the more difficult to locate the malicious software on systems that it has infected.

The ransomware loader first analyzes the system on which it is loaded to ascertain if the system is a virtual machine or a sandbox setup.

It also checks to see if the environment is protected or if there are any products such as anti-virus software installed on the system.

If the loader encounters any of the three above mentioned situations, it stops running in the background with immediate effect to prevent the analysis of the ransomware code on the injected processes.

It is worth recalling that cybersecurity researchers generally opt for these three methods to investigate malware in a possibly infected system and prevent it from infecting the network system fully.

This also prevents the ransomware from getting detected.

The ransomware binary file is then loaded on another process.

Alternatively, in an unprotected environment or in the absence of a virtual machine or a sandbox setup, the entire binary code gets itself injected into as many processes as possible that are currently being executed.

Problems encountered with the latest version of Cerber Ransomware

In a recent blog post, Gilbert Sison mentioned that systems that adopt the static machine learning strategies are the ones that are most vulnerable to the loading and packaging mechanisms deployed by the ransomware.

This is because these strategies do not rely on any form of emulation or execution techniques for analysis of files.

Moreover, self-extracting files are often simple and straightforward to the extent that it could be a problem to detect static machine learning files.

In addition, unpacked binaries, such as those that appear in ransomware, may seem to be harmless and do not show traits of maliciousness to the least extent.

Yet, while the current ransomware version does elude machine learning methods, making use of solutions that do not rely too much on machine learning is a feasible solution.

Another option is to make use of security approaches that provide multiple protection layers since Cerber still has drawbacks – like making using of an unpacked DLL file.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.