Pierluigi Paganini
April 02, 2019
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
But if we go on the Akamai blog we can still find a reference to Elknot posted on April 4,
If we go deeper in the Elknot series analysis on AESDDOS in MMD blogs mentioned above (“about the
Figure 1: The Linux/AES
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
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\n
Content-Length: {SIZE OF SENT DATA}\r\n
Host: 193[.]201[.]224[.]238:8852\r\n
User-Agent: LuaSocket 3.0-rc1\r\n
TE: trailers\r\n
Connection: close, TE\r\n\r\n
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
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.
About the Author:
Odisseus – Independent Security Researcher involved in Italy and worldwide in topics related to hacking, penetration testing and development.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – Elknot malware, DDoS)
[adrotate banner=”5″]
[adrotate banner=”13″]
