The popular expert unixfreaxjp analyzed a new China ELF DDoS’er malware tracked as “Linux/DDoSMan” that evolves from the Elknot malware to deliver new ELF bot .

Non-Technical-Premise

“This report is meant for incident response or Linux forensics purpose, TO HELP admin & IR folks”, with this the very beginning sentence starts the new analysis of one of the reverser of the worldwide extended security community, the head of MalwareMustDie team, (Mr.) unixfreaxjp. And the first thought coming at the mind is: while everybody is looking for “fame” and “glory” here there is someone who is working hard just “TO HELP”. It is there a security group greater than this?

But let’s go to the finding.

The new unixfreaxjp’s analysis talks about a new China ELF malware DDoS’er “Linux/DDoSMan” which seems to be a new DDoS botnet client installer that utilized the old Elknot bot binary (also known as ChickDDoS or Mayday) along with a new ELF bot (as downloader and persistence function installer): these are two ELF bot binaries which are dropped by the new found Linux/DDoSMan .

About this attribution unixfreaxjp comments on Virus Total as follows: “This is the new bot client of the “DDOS manager” toolkit used by China(PRC) DoS attacker. (….) The code seems inspired from multiple source code of China basis DDoS client, like Elknot. Not xorDDoS or ChinaZ one, not a surprise since many of code shared openly.”

But what kind of malware is this Elknot Trojan? How the MMD team found this in the first place? The story is well documented going back in the past years when one project of MalwareMustDie (MMD) team was very active to monitor the China origin ELF DDoS’er malware threat since Aug 2012. The growth was very rapid at that time (Sept. 2014), as described on the MMD blog when MMD detected 5 variants active under almost 15 panels scattered in China network. There is a video describing their work that shows many of Elknot analysis was posted.



On the MMD blog is still possible to read “I am quite active in supporting the team members of this project, so recently almost everyday I reverse ELF files between 5-10 binaries. They are not aiming servers with x32 or x64 architecture but the router devices that runs on Linux too.” We could say here to have a ““Mirai” idea “ante-litteram” 2 years before. Firstly written, the Linux/Elknot was analyzed and published publicly in the kernelmode.info as per below post:



Which links to the MMD behavior analysis report in 2013 in here and further debug report as follows in here: the latter one it describes the committed malware name as Linux/Elknot. The further analysis and report of the ELknot infection is written nearly in the kernelmode.info in the same thread. Thank you to the admin team of KernelMode who still keep the documentation of this malware analysis still available until now.

Linux/Elknot malware that time is known for multiple standard packet flood in several protocols (UDP, TCP, ICMP & HTTP) and amplification DNS attack of the China series of this DDoS trojan was firstly introduced by the this malware, before Linux/BillGates started to be detected. We can say Linux/Elknot series is the oldest root of the many ELF flooder built by adversaries in the same territory, and one of the most popular ELF flooder in that territory within 2014.



But if we go on the Akamai blog we can still find a reference to Elknot posted on April 4, 2016 on a topic referred to “BillGates”, another DDoS malware whose “attack vectors available within the toolkit include: ICMP flood, TCP flood, UDP flood, SYN flood, HTTP Flood (Layer7) and DNS reflection floods. This malware is an update and reuse from the Elknot’s malware source code. It’s been detected in the wild for a few years now.”. So we can see that Akamai blog explicitly talks about Elknot linking directly the web page of MalwareMustDie blog and telling with the language of the politically correct that for the “botnet activity, most of the organizations are located in the Asia region”.

If we go deeper in the Elknot series analysis on AESDDOS in MMD blogs mentioned above (“about the ARM version of the evolved Eknot basis with so many specific modification reversed and reported”) we get many interesting information and we learn a lot about China malware including Elknot scheme.



Figure 1: The Linux/AES . Ddos for ARM CPI on MMD blog

And inside this post we can find a lot of considerations about the behavior of the malware and of the threat actor like the encryption of the binary and of the communication: “This a sign of protection, someone want to hide something, in the end that person is hiding EVERYTHING which ending up to be very suspicious 🙂 – So the binary could be packed or encrypted protection, we have many possibility.

Further details of this family of ELF malware we posted regularly in here:–>[link]”

The further details on Linux/AESDDoS are on kernelmode.info as is referred by unifreaxjp on his new analysis that can be found here: https://www.kernelmode.info/forum/viewtopic.php?f=16&t=3483

The new Malware

But let’s go back to the new analysis: we have a combination of “new” and “old” code that is allowing the bot client to perform an interaction client and server involving multiple platform used by this botnet: the ELF bot (the client) is delivered on compromised devices in Linux platform while the C&C (Win32 PE) is in listening mode on a Windows platform waiting for a callbacks sent by the bot-installer, the one that executes the new ELF is the “downloader” and “installer” while the old Elkont code is responsible to manage the DDoS related configuration part, in example: to execute commands sent from C2, sending statistic data of the infected servers , threading, DDOS attacks, etc, as is shown in the next figure.

Figure 2: The C2 software for Linux DDoS

Going deeper in the unixfreaxjp’s analysis we read more about the new scheme adopted in the malware configuration:

“The C2 tool is having IP node scanner and attack function to compromise weak x86-32 server secured auth, DoS attack related commands to contrl the botnet nodes, and the payload management tools. Other supportive samples are also exists to help to distribute the Linux bot installer to be sent successfully to the compromised device, it works under control of the C2 tool. This C2 scheme is new, along with the installer / updater . The Elknot DoS ELF dropped is not new.”

But let’s see what are the execution binaries and what an administrator will see during the first stage of the infection, because this analysis is made for the purpose to raise the system administration awareness:

Installation related code execution:

Code execution:

execve("/tmp/upgrade""); // to execute upgrade

execve("/bin/update-rc.d", ["update-rc.d", "python3.O", "defaults"]); // for updating the malicious task

execve("/usr/bin/chkconfig", ["chkconfig", "--add", "python3.O"]); // for persistence

What administrator will see:

(Unknown) process with image executed from /proc/{PID}/cmdline, with forked from “evil” crond (dropped, executed and deleted malware) process.

The Client Side

Giving a look to the bot client we’ll see that once the malware has infected the remote host the installer ELF will read all server process info by launching open(“/proc/{PID}/cmdline”) for the further malicious purpose. The bot client then will collect infected systems data to send to the C2 in the URL as per shown by the screenshot below, the purpose of this data sent to C2 is for informing the C2 what system is infected so the C2 can send the traffic data back to infected machine with the upgrading binary for the further infection, and also for the statistic of the infected machines. The data of infected machine will be shorted by the Windows C2 utility tool called “Manager” as per shown in the above Win32 GUI screenshot, and that C2 tool will send the infected machine data to the static page served on another host in the web (which seems now is abandoned by the adversary).

Figure 3: Header of the ELF communication

The C2 data is sent from bot client via the malware’s “fabricated” headers as follows, to be processed further as per described previously. This below HTTP header is unique and can be used to mitigate the threat, which is a new action (not spotted in Elknot).

Content-Type: application/x-www-form-urlencoded\r



Content-Length: {SIZE OF SENT DATA}\r



Host: 193[.]201[.]224[.]238:8852\r



User-Agent: LuaSocket 3.0-rc1\r



TE: trailers\r



Connection: close, TE\r

\r



In contrary, Linux/Elknot bot client series will send or receive its data to C2 always in the encoded form instead, with a lot of padding 00 in between. They are using assembly obfuscation to rotate the encoded values. And the way Elknot communicate to the C2 is not using the HTTP protocol but directly write the communication data in the packet to the specific established TCP/port (original protocol often used by China basis malware, windows or linux platform).

After the initial communication is established, the C2 sent the “upgrade” to the Linux/DDosMan bot client according to platform of infected server: it is saved, renamed and executed on the infected node as the upgrade version of the initial malware. The bot client will start its main function. The analysis of unixfreaxjp says that its further process, including to drop ELF binaries embedded in the main ELF binary, is to execute them to perform their parts of malicious activity. “The dropped & executed “downloader” embedded ELF is actually the one that responsible for the “persistence setup” operation too. This part hasn’t been seen in Elknot. And this is not even in the main sample file too. In THIS dropped ELF you can see well the downloader and the persistence installer in the same file.”

See the next figure for the explanation:

Figure 4: Snapshot of the Installer/downloader

Additionally the same connection is reused and the initial code that opens the connection toward the C2 responsible to manage the update of the malware on the infected node.

“So only one dropped binary is the Elknot.” says unixfreaxjp, “Obviously, there is no DDoS functionality in the main sample ELF file or the Downloader ELF file too, the Elknot has it, and the adversary tend to use that function from the C2 tool.”

The Server Side (C2 Tool)

Regarding the C2 tool we have a “Win32” PE and it has the Elknot basis C2 form, along with many additional other forms as we reported in the Figure 2. We can see the scanner tool, interface to write code execution to Linux shell after attack has been performed successfully. With these capabilities the threat actor can use any kind of compromised Windows machine to manage the C2 from its attacks.

To perform the malicious intent the attacker will need the ELF file to send, the script to be sent to hacked PC and the ELF file to be installed after infecting along with its execution toolset.

In order to have an idea on “how the adversary work in making this toolset” MMD has produced a very interesting video published on Youtube describing the techniques adopted by the China threat actors

and recording them live from a compromised server.

Figure 5: MMD Video on Youtube describing China threat actors techniques to delivery malware

Reversing the C2 tool it smells of China even if the reader is not able to translate.

Figure 6: MMD reverse of the C2 Tool

Adversary’s infrastructure info are in the following

The adversary network is as per below (domain, IP and port)

cctybt.com. 3600 IN A 103.119.28.12 tcp/8080

193.201.224.238 tcp/8852

Located in these networks:

AS136782 | 103.119.28.0/24 | PINGTAN-AS | AP Kirin Networks, CN

AS25092 | 193.201.224.0/22 | OPATELECOM, | UA

For the full IOCs and other details of the malware please refer to the Mr. unixfreaxjp research at: https://imgur.com/a/57uOiTu

About the Author:

Odisseus – Independent Security Researcher involved in Italy and worldwide in topics related to hacking, penetration testing and development.

Pierluigi Paganini

(SecurityAffairs – Elknot malware, DDoS)

Share this...

Linkedin Reddit Pinterest

Share On