A new report from Qianxin's X Lab was released detailing new stealth malware targeting Redhat 7.9 and similar systems:
New Zero-Detection Variant of Melofee Backdoor from Winnti Strikes RHEL 7.9
This malware currently shows zero detection coverage at Virus Total as of today, but Sandfly was able to easily see it operating. In this report we'll discuss Sandfly detection of this malware to help customers assess their hosts for compromise.
As the report above states, the melofee malware has full stealth capabilities. In particular, the malware includes an encrypted Loadable Kernel Module (LKM) rootkit based on the Reptile project which is a common base for many kinds of malware. The encryption helps avoid signature scanning and related detection techniques.
Once the rootkit goes active, it loads the LKM portion rendering the main process invisible along with other capabilities. Casual observation of a system infected with the malware will not show its presence.
The malware has capability to do some of the following:
Hide processes.
Hide files.
Hide kernel module presence.
Hide persistence mechanisms.
The malware has functionality to enable stealth and maintain access to systems where it is executed.
The malware is showing no detection with legacy anti-virus systems as of now, but tactically it is doing many things that are suspicious and identified by Sandfly immediately. Sandfly customers seeing these alerts should take immediate action.
First, we identify a kernel module that is trying to hide itself called kworkerx. The rootkit hides itself once active so it is not present in lsmod or similar commands that try to list active modules.
Once active, the Linux kernel is "tainted" as the malicious module is not signed nor part of the distribution (called out-of-tree). Modules that are unsigned, or out-of-tree, are always suspicious unless you know why they are present (e.g. a proprietary video driver).
In this case, the module taints the kernel with an unsigned module, but then hides itself from view. This creates an inconsistency that Sandfly alerts on. Basically, the kernel says it is tainted with an unsigned module, but nobody is fessing up to have done it. This means the module that caused the taint may very likely be hiding.
On Linux, legitimate kernel modules usually are located in specific directories for the kernel version on the host. When we look for this file we do not find it. This means the module is either loading from a non-standard location (which is suspicious), or is hiding itself from being viewed in the directory with other modules (even more suspicious). In either case, we see an alert for our kworkerx module again as it hides.
If you are using Sandfly's drift detection, you can have it spot new kernel modules that have appeared. In the case of our affected host, we again see that a new module called kworkerx has made its presence known. Drift detection is a powerful way to spot novel malware on Linux across processes, users, SSH keys, kernel modules, network services, and more. We encourage customers to use it where appropriate.
Drift detection easily spots the new module even outside of the suspicious activity it did prior. The list below shows the new module in red among valid green modules the drift detection expects to see on the host.
After the rootkit activates, it spins up a new process called [md] and hides itself. The process is the main communications part of the malware to allow attacker control of the system. The process name is significant as it is trying to impersonate a kernel thread (discussed below). But more significantly, it activates the hidden process detection in Sandfly. Sandfly shows the process forensics data after de-cloaking the entire operation.
The malicious [md] process uses brackets meaning it is trying to look like a kernel thread in process listings. This is a common tactic with Linux malware. In this case, it activates five separate alerts in Sandfly for kernel thread masquerading. The alerts are all variations of the same attack type seen from different perspectives. One of the results is shown below for illustration.
Processes using [brackets] for their name that are not kernel threads are often malicious. For this malware, it leaves a very clear trail that something is wrong with this host.
While we strongly recommend using Sandfly to help hunt for this malware due to the stealth nature, it is possible to find it manually if you choose to do so. While it is tempting to use the cryptographic hash of the malware to search systems, this is notoriously unreliable on Linux. We recommend reading the initial report and looking for the following.
First: A dropper file is present when the malware is active on a host:
/tmp/lock_tmp1
Second: This malicious module directory is present when the malware is active:
/sys/module/kworkerx
An ls command will show the contents, but the fact it is present is enough to know the system is likely infected.
The malware uses crontab to maintain persistence, but other mechanisms may also be used as variants emerge. Due to the nature of Linux malware, it is not recommended to attempt to clean an infected system. The system should be taken offline and root cause analysis performed to determine how the malware made it onto the host. The system should then be re-built after evidence is preserved as needed.
This malware is stealthy and evades traditional detection. We thank the team at Qianxin for disclosing it for security teams protecting Linux.
Sandfly customers are able to use our tactics detection to quickly find and identify systems affected by this and related malware. Please reach out to our support team if you have any questions. Be sure to try Sandfly for free today and let us find these threats for you with our agentless, fast, and safe Linux security approach.