Background
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 task
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
Upon execution it will show a nice logo:
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 60.190.216.225 and it looks like the CNC is set to same IP too:
Connecting to 60.190.216.225 8090.. unknown [60.190.216.225] 8090 open Connection to 60.190.216.225 8090 port [tcp/*] succeeded! MMD-LOVE-ELF->60.190.216.225:8090 (ESTABLISHED)it's showing the location somewhere in PRC/China:
[0x08049880]> !ipchk geo 60.190.216.225
-----------------------------------------------------------
ipchk-shell 1.5 FreeBSD version - by @unixfreaxjp
-----------------------------------------------------------
Source : geo
IP : 60.190.216.225
-----------------------------------------------------------
geoip:
{
"ip": "60.190.216.225",
"hostname": "No Hostname",
"city": "Shaoxing",
"region": "Zhejiang Sheng",
"country": "CN",
"loc": "30.0110,120.5715",
"org": "AS4134 No.31,Jin-rong Street"
}
So 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:
...and it is stated:
it's prohibited for illegal use
the author is not responsible Sweet! :) we can go back to this "moral issue" later on. Let's move on first to peel this a bit more..
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:
GCC 3.0
// 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)
/lib/ld-linux.so.2 (0xb774a000)
// first copy of libs listed in ELF 1st image addresses can be found below:
000000000134 /lib/ld-linux.so.2
0000000007C5 libpthread.so.0
000000000881 libstdc++.so.6
000000000C5F libm.so.6
000000000C69 libgcc_s.so.1
000000000C86 libc.so.6
// 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)
---------------------
*)ref: http://www.opensource.apple.com/source/gcc/gcc-5488/gcc/crtstuff.c
0x00E64C __CTOR_LIST__
0x00E65A __DTOR_LIST__
0x00E668 __JCR_LIST__
0x00E675 dtor_idx.5793
0x00E683 completed.5791
0x00E692 __do_global_dtors_aux
0x00E6A8 frame_dummy
0x00E6B4 __CTOR_END__
0x00E6C1 __FRAME_END__
0x00E6CF __JCR_END__
0x00E6DB __do_global_ctors_aux
-------------------------
3. 0x00E6F1 synserv.cpp
-------------------------
0x00E6FD _GLOBAL__I_dout
0x00E70D __tcf_6
0x00E715 _Z41__static_initialization_and_destruction_0ii
0x00E745 _ZSt8__ioinit
0x00E753 __tcf_4
0x00E75B __tcf_5
0x00E763 __tcf_3
0x00E76B _ZZ12GetTxPpsByIfRKSsiE7s_ticks
0x00E78B __tcf_2
0x00E793 _ZZ12GetTxPpsByIfRKSsiE9s_packets
0x00E7B5 __tcf_1
0x00E7BD _ZZ6GetPPSPciE7s_ticks
0x00E7D4 __tcf_0
0x00E7DC _ZZ6GetPPSPciE9s_packets
0x00E7F5 _ZZ6GetCpuvE3s_u
0x00E806 _ZZ6GetCpuvE3s_i
0x00E817 _ZZ6GetCpuvE3s_s
0x00E828 _ZZ6GetCpuvE3s_n
0x00E839 _ZGVZ12GetTxPpsByIfRKSsiE9s_packets
0x00E85D _ZGVZ12GetTxPpsByIfRKSsiE7s_ticks
0x00E87F _ZGVZ6GetPPSPciE9s_packets
0x00E89A _ZGVZ6GetPPSPciE7s_ticks
0x00E8B3 _ZGVZ12SendCPUUsagevE9lastConID
0x00E8D3 _ZZ12SendCPUUsagevE9lastConID
0x00E8F1 _ZZ12SendCPUUsagevE14s_lastCpuUsage
---------------------
4. 0x00E915 syn.cpp
---------------------
0x00E91D _GLOBAL__I_g_cycleInfo
0x00E934 g_sockArray
0x00E940 g_cycleSynDip
0x00E94E g_pktsSize
0x00E959 g_pktsBufferQueue
0x00E96B g_pktsBufferQueueInit
0x00E981 g_lockSockCreation
0x00E994 g_lockSockIdx
0x00E9A2 g_sockIdx
0x00E9AC __preinit_array_start
0x00E9C2 __fini_array_end
0x00E9D3 _GLOBAL_OFFSET_TABLE_
0x00E9E9 __preinit_array_end
0x00E9FD __fini_array_start
0x00EA10 __init_array_end
0x00EA21 __init_array_start
0x00EA34 _DYNAMIC
0x00EA3D data_startI 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.
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:
*) Noted:
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 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" SYN attack (will not going to discuss it "too" detail in here), as per listed below:
TcpFloodThread ; send some tcp packets
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
Furthermore, the DealwithDDoS() is the function that is commonly used in Chinese actor's made malware since Elknot era, then AES.DDoS and Mr.Black are also using this function as their main attack manager function until now. If you follow ELF workshop that I am doing, I made 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():
*) 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, callback & send information), it's a remote bot client for DDOS purpose, receiving 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, and the backdoor functions 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
Latest Memo:
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.
Follow up:
@EmergingThreats @node5 friends, I am sending you all traffic pcaps of this new "KDefend" #ELF #botnet #malware https://t.co/HaBZ875RpU
— ☩MalwareMustDie (@MalwareMustDie) December 4, 2015@MalwareMustDie I'm opening a new repository for Linux/KDefend in https://t.co/X5acf609QS https://t.co/n0aujyLlNQ
cc: @Xylit0l @hFireF0X
— ☩MalwareMustDie (@MalwareMustDie) December 3, 2015Please stay safe! #MalwareMustDie!
