Friday, December 4, 2015

MMD-0045-2015 - KDefend: a new ELF threat with a disclaimer

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

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 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 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 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():
*) 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

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:

Please stay safe! #MalwareMustDie!

Posted by unixfreaxjp at