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 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 variants active under almost 1 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- 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:

Elknot  - Elknot based malware - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

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 MMD blogs  mentioned above (“about the ARM version of Eknot basis with so many specific modification reversed and reported”)  we get many interesting information and we a lot about China malware including Elknot scheme.

Elknot DDoS  - Elknot DDoS - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

Figure 1: The ARM version of Elknot malware 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:–>https://securityaffairs.co/wordpress/83157/malware/new-linux-ddosman-threat-emerged-from-an-evolution-of-the-older-elknot.html”

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 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 of the infected servers , threading,
DDOS attacks, etc, as is shown in the next figure.

Elknot DDoS  - Elknot DDoS 2 - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

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).

- Elknot DDoS 3 - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

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-urlencodedrn
Content-Length: {SIZE OF SENT DATA}rn
Host: 193[.]201[.]224[.]238:8852rn

User-Agent:
LuaSocket 3.0-rc1rn

TE: trailersrn
Connection: close, TErnrn

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 haven’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:

- Elknot DDoS 4 - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

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 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

Elknot DDoS  - Elknot DDoS 5 - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

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.

and recording them live from a compromised server.

Elknot DDoS  - Elknot DDoS 6 - New update about DDoS’er Linux/DDoSMan ELF malware based on ElknotSecurity Affairs

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.

unixfreaxjp team leader of the MalwareMustDie team.

Pierluigi Paganini

(SecurityAffairs – Elknot malware, DDoS)







Source link

No tags for this post.

LEAVE A REPLY

Please enter your comment!
Please enter your name here