Last Updated: 2018-07-09 18:30:04 UTC
by Renato Marinho (Version: 1)
Going over my WebLogic honeypot, I am used to seeing a lot of crypto miners. The honeypot is vulnerable to CVE-2017-10271. I have written before about the various crypto miners. 
But this weekend, I finally spotted something a bit different. The attacker installed a backdoor which so far is not recognized by any antivirus tool according to Virustotal .
This binary establishes a connection to the attacker for remote control protected by a trivial default password. Note to the attacker: If the password is “replace with your password”; do it!”
Let’s see some details about this case.
The malicious file was uploaded and executed via a well known WebLogic vulnerability. We talked about this vulnerability and related exploits earlier this year . Attackers downloaded the sample using ‘wget’, as seen in Figure 1.
Figure 1: malware sample download
Yet another crypto miner?
Most of the similar exploitations resulted in crypto mining activty. But this did not. No wallet address, no config file, no crypto mining pool connection and no CPU consumption. Instead, the malware established a connection to a command and control (C&C) server to send the victim’s information and to retrieve the attacker’s orders.
Figure 2 shows that this sample is currently not recognized by any of the anti malware tools covered by Virustotal.
Figure 2 – malware sample unknown by VirusTotal engines
Analyzing this sample's past submissions to VT, we can see that it has been uploaded from China and the file was located in a suggestive path: “/home/wys/botnet/botnet-procedure/40”, for example, as seen in Figure 3.
Figure 3 – Unknown sample past submissions
This case piqued my curiosity, and I decided to poke the unknown sample a bit.
First, I run it using ‘strace’ in a controlled environment, as seen in Figure 4.
Figure 4 – Running malware using ‘strace’
As seen, the malicious process collects some information about the victim’s machine reading files such as “/etc/localtime,” “/etc/issue.net” and “/proc/version.” One of those files is “/usr/include/sdfwex.h," which I have no idea what the file does. I couldn’t find anything related to this file on the web.
Trying to disguise amongst another victim’s process, this malware forks to a process called “/usr/bin/ssh,” as seen in Figure 5.
Figure 5 – Malware process disguised as “/usr/bin/ssh”
Once running, the malicious process will try to establish a communication to a C&C server hosted on address www[.]sydwzl[.]cn, port 630, as seen in Figure 6.
Figure 6 – Malware C&C
The C&C traffic encryption is quite interesting. After running the binary multiple times in the same host and comparing initial traffic, I could see that the content was different each time. In other words, for the same collected data, the encryption process generated different results. This means that malware developers are possible using a dynamic key - but it will require further analysis to figure it out.
Going a little bit further in my malware analysis, it was possible to see that the attacker may have a command shell to remotely control victim’s machine. The shell is opened upon certain conditions and orders coming through an encrypted C&C channel.
One of those conditions is a password check. If it matches, the code will continue its flow and bind a “/bin/sh” shell on a TTY in order to execute attackers’ commands, as seen in Figure 7.
Figure 7 – Password check
It turns out that on offset 0x6148c0 we have a hardcoded and unchanged default password, as seen in Figure 8.
Figure 8 – Hardcoded and default password
During my analysis, the malware didn’t manifest additional malicious activities. It may due to some expected timezone, as it reads victim’s localtime or the absence of the particular include file “/usr/include/sdfwex.h”. If you have any additional information about this campaign or this sample, let us know.
www[.]sydwzl[.]cn (ports 630 and 1234)