MMD-0045-2015 - KDefend: a new ELF threat with a disclaimer04 Dec 2015
It's been a while not writing new analysis in our blog & this timing is just perfect.
On December 1st, 2015 this sample was detected by our ELF team member @benkow_
..and our ELF Team started to investigate the threat and come into conclusion that another new ELF malware was spotted, and post this is the report. It was calling itself "KDefend" or "KDLinux", so we call it as "Linux/KDefend" then. We separate some tasks in members in this report, and will cover to highlights of this new malware hopefully will help others in tracking and mitigating the threat for the future. I will do the ELF binary analysis to figure what kind of threat it is, with some pointer hint in my analysis that hopefully can be useful for fellow UNIX sysadmins and malware researchers.
The KDefend; How does it look like?
It is a bit unusual to our post, but I decided to write the behaviour part first this time for you to see the fact that we would like to stress in this new malware finding.
The binary is in here -->[virustotal] with the below status:
[0x08049880]> !file taskUpon execution it will show a nice logo:
task: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked,
interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, not stripped
[0x08049880]> !md5 task
MD5 (task) = f93d664aac485af82ec863c251626441
[0x08049880]> !size task
text data bss dec hex filename
44871 1396 772660 818927 c7eef task
Please don't mind my shell's language & character setting is just unmatched to original encoding and caused the garbled result in the screenshot, it's not a problem. With a good team work (thank's to @wirehack7 for good chinese decoding tip) I reversed the function that printed and decoded the characters used to show the original chinese language used, and then we also "free-translated" it too as per below:
So now you see.. here it is, that message in the logo is our other main topic for today, we have a new malware pretending as a stress tool and having a "disclaimer message" as per shown above.
*) Noted: the translation was a free translation level, feel free to help in correcting it. Thanks!
How does the infection (attacker, panel and CNC) go?
Well okay, first, let's see if this so called "stress tool" was being used as per what its disclaimer said... Which is unfortunately not. It was found in action during its effort to infect a linux server with the SSH brute access as per logged below:
The attacker IP & download panel IP is all 22.214.171.124 and it looks like the CNC is set to same IP too:
Connecting to 126.96.36.199 8090..it's showing the location somewhere in PRC/China:
unknown [188.8.131.52] 8090 open
Connection to 184.108.40.206 8090 port [tcp/*] succeeded!
[0x08049880]> !ipchk geo 220.127.116.11So this malware was homing to the mothership and sending its initial traffic which is the infected machine's sensitive information like what we recorded here:
ipchk-shell 1.5 FreeBSD version - by @unixfreaxjp
Source : geo
IP : 18.104.22.168
"hostname": "No Hostname",
"region": "Zhejiang Sheng",
"org": "AS4134 No.31,Jin-rong Street"
...and it is stated:
it's prohibited for illegal useSweet! :) we can go back to this "moral issue" later on. Let's move on first to peel this a bit more..
the author is not responsible
How is it built?
Below is the details on how this malware was built, mind the text format. Please refer to the status of the binary above beforehand. There's nothing so special in it, but it's always good to know these level of information:
// compiler:I don't know how to comment here..except a unix programming beginner is coding and compiling a .cpp coded malware. It's always good (at least for my research) to know how or where the source is and what libraries are used, so we can know exactly where to after our malcodes. In analysis of a dynamic linked ELF binary, like this case, I used to breakdown each library before start hitting any disassembler to reverse the purpose.
// compilation environment:
GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-44)
// linked libraries used
linux-gate.so.1 => (0xb7749000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7724000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7638000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7611000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75f4000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7490000)
// first copy of libs listed in ELF 1st image addresses can be found below:
// these are the source codes resource:
1. 0x011851 main(.cpp)
2. 0x00E641 crtstuff.c
(BE NOTED: This is a GCC constructors/destructors for C++ obj/Open Source)
3. 0x00E6F1 synserv.cpp
4. 0x00E915 syn.cpp
The short explanation of the libraries used above are:
linux-gate.so.1 is known as a virtual DSO, a shared object exposed by the kernel at a fixed address in every process' memory. ld-linux.so.2 is a "locator" to load the dynamic libraries it needs for execution, it searches for and loads the unresolved libraries, and then it passes control to the application starting point. libm.so.6 contains functions to mathematical process libs. libpthread.so.0 (POSIX threads) is used for threaded programming, in this code it was used for send, connect, recvfrom, sendto and its threat connection mutex. libstdc++.so.6, libgcc_s.so.1, and libc.so.6 is for cpp and GCC/libc programming base functions. The leftover ones are mostly the source code related trails.
What does it do? How does it run? A summary..
It is an explanation on an idea on how it firstly runs. After the loading & print "that logo" data, it starts the daemonized UDP listener & threading its process to listen into UDP/52066. So this is the backdoor function number one. Upon failed binding into UDP/52066 it will retry and upon succeed it will use another backdoor connection to the hard coded CNC IP/port via DDosSock_Init/0x0804cb8c (see the ip/port written in above section), then start to harvest the data of client to be in communication with their mothership (via ConnectClient/0x0804cb9a).
Noted the UdpLitenThread typo, it is really a "Deja Vu" typo for a specific previous malware case and coder's MO, I will go to that soon..
From above step, it utilized an "almost generic" CreateConnectSocket()/0x0804a3ac for the remote connection, it uses original GetSysinfo() (0x0804A0DE) for information harvest purpose that is responsible for the initial data sent in the pcap captured at above section.
You'll also see further backdoor functions executed like NetPPS and CPUUsage will be used to send its self-explanatory data to the mothership. The important part is, in the SendNetPPS() function you'll see the usage of "ifconfig" shell command used for grabbing the transmitted packet data (see in subs GetTxPacketsMap), was executed and piped with "grep" for its desired data:
Well, as you saw in above section, I blocked the ifconfig in the path searched by this malware:
and did you see how the data sent to the CNC? While it can't grep, it seems it doesn't implement the error trapping and the variable names stays there as per it is :) That's why I personally think it's an amateur was hired to make this code, maybe we just have to seek for a youth malcode programmer again for it.
It has another backdoor too like: the updater function, it was calling DealwithUpdate()/0x0804B5EE for getting the updates with kicking another shell command "wget -t3 -O", refer to function download()/0x804b67b:
Upon post-downloading, the executable permission is set, using "chmod -R 777" for further process:
1. Most of operation invoking shell or pipes are driven by using the stdio.h's popen() and pclose().
2. It notices itself as "KDLinux" that can be seen in the download process.
More information that are interesting to dig: (1) The UDP opened port was meant to receive encoded data for being used as a bot operational purpose, it has the decoder function (xref: 0x0804cce9) for that purpose. (2) This is a DDoS'er bot: the attack vectors is controlled by DealwithDDoS() main function, used are covering some basics and what they call it as "Cycle" a custom SYN flood attack (will not going to discuss it "too" detail in here), as per listed below:
TcpFloodThread ; send some tcp packetsFurthermore, the DealwithDDoS() is the function that is commonly used in Chinese actor's made ELF flooder malware since Linux/Elknot DDoS'er bot variant era, then Linux/AES.DDoS and Linux/Mr.Black are also using this function as their main attack manager function until now. If you follow ELF Workshop Malware Analysis that I am doing, I made and demonstrated a simple personal ELF analysis system that I called it as "ELF skeleton (literally looks like skeleton)", it has the function scanning to check calls like this, below is the snapshot of its check result on DealwithDDoS():
NormalSendThread ; socket connecting and flood
NormalUdpPacketThread ; simple UDP connect and flood
NormalSynPacketThread ; simulate SYN connection to flood
NormalDnsSendThread ; connects & manipulates DNS search..not sure how to apply this
CycleSynSendThread ; original made SYN attack
SynSendThread_Old ;; // it's uncoded
*) Noted: It shows that the ChinaZ is in the list, but that is actually the AES.DDOS malware they used(parent of Mr.Black for router basis ELF malware).
So what this malware does? It's a backdoor (bind/listen to an opened port, making unnoticed callback to a remote host & send server's sensitive information), it's a remote bot client for DDOS attack purpose that receiving encoded commands via connected ports, A Trojan Downloader too (for updates purpose apparently..but who knows what can be expanded/applied more in here), and these are the major functionality of this malware.
Is it meant to be a tool as per stated in the disclaimer? No way. The way it decodes commands, the specific flood used, the backdoor (homing and listening to open port) functions and the trojan-like downloader part, altogether doesn't show any of good tool specification.
Who's the possible actor of this incident?
Could this be another ChinaZ's new malware experiment? Why not. Judging by their development MO (leftover unwanted function uncoded instead eliminated them), copy pasting known other China ELF malware's functions, networking used and some of their typical typo, ASCII & symbols "china brand" are matched to some incidents of ChinaZ actors, we have strong possibility for it.
The ChinaZ group is also the most aggressive one in the market in research and development for the new trojan ddoser, they made new codes, buying other chinese ELF sources, contacting several C coders to combine functionality to make a better ELF bruter trojans, like this.
Epilogue: A DDoS'er with "Disclaimer" vs "Rule of Engagement"
We think the message used in "Disclaimer" part is an important aspect here. The coder is trying to bend the responsibility of what he coded by writing few lines to dodge from responsibility. This smells just as the same excuse used as previous ChinaZ coder spotted in the GitHub [link]. Below are the opinions from our team mates due to this "Disclaimer issue" that I think it is worth to share as opinions, and please feel free to tweet us your opinion to be added in this post.
"I believe in RoE - "Rules of engagement". It is super bad violation of RoE to use these tools against something you do not own, or have well and just cause to discharge against. The internet is not having a certain rules, just like a battlefield, and everyone is armed, or can potentially become armed. So discipline is utterly paramount to having a stable and peaceful internet. It is a major violation of RoE to use these tools against something you do not own or don't have a well and just cause to do so." @yinettesys
"Creating illegal tools remains illegal, even if you write "only for legal use". No matter "un-harmful" it is stated. This program is clearly meant to harm other host in internet. It's the same to forbid the creation of bombs but then normal people are creating some for "research use. This disclaimer is used by malware authors writing to dodge laws. "Don't use for illegal things"..words is bailing out and tacking the backdoor with "use only for legal purposes" which is never making any sense. It's just like you are admitting there that you actually know that actions performed by this tool is illegal but spread it anyway with making it public aka releasing it, and then a bad person using it.." @wirehack7
"The similar disclaimer for many DDoS tools is a trend now, specially in the DDoS related services or threat. And this malware coder is seeing how that disclaimer method is effective and just utilizing it. Hopefully our law can see how dangerous this tool it is by function explained in this analysis, and see by the real penetration/infection/attack that is currently distributed. There is no legality on its scheme. It is a malware with its complete malicious functions intact, and the malware coder has his own responsibility to build such aggressive software." @unixfreaxjp
All analysis was done (as usual) in FreeBSD unix shell with radare, only ELF skeleton that's using different scheme. Thank's to help/support from MMD ELF team mates, MMD folks and all malware fighter-brotherhood for motivating us to keep on posting.
Please stay safe! #MalwareMustDie!