Tuesday, June 30, 2015

MMD-0035-2015 - .IptabLex or .IptabLes on shellshock.. sponsored by ChinaZ actor

The background

.IptabLex & .IptabLes ELF DDoS malware is the malware made by China DDoSer crime group, designed to infect multiple architecture of Linux distribution, was aiming for Linux boxes in the internet with the low security and authentication flaw in SSH as vector of infection, was an emerged ELF threat in 2014.

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:

Today, our team mate @benkow has detected a shellshock attack with having the same payload as sample, and curiousity made me taking a deeper analysis this time, to find and feel so surprised to realize that the payload is a Linux IptableS or .IptablesX variant actually. I can not believe this myself so I checked many times until I am very positive with this conclusion and after understanding why we were thinking it was Linux/ChinaZ I wrote this information as the follow up, the return of 2014's DDoS disaster, the IptableS|X threat. Below is the detail.

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"
}
Noted: we seriously need to stop this IP attacking the internet as soon as possible!

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"
}
As you can see, both attacker and infection panel are running from the same route of AS4134.

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   "
CNC hard evidence taken during the test:

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"
}
And the domain registration info is below and looks freezed now :)
"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"
Well, WENDINGBA@163.COM is associated with Xihuang Li and 5 other names. A total of 1,382 associated domains were identified, most of them are registered in GoDaddy or ENOM. He is a professional crook in the field. Below is the snip of the first 20 domains, the information is available for al of us to access:

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"
}
As per predicted, the Linux/BillGates sample is using the same domain of f1122.org and located in the same network as per CNC of IptableS|X, we have the same actor here operated in both CNC, this is a hard evidence. And as always the crooks were closing the connection after I connected :-)

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!

Thursday, June 25, 2015

MMD-0034-2015 - New ELF Linux/DES.Downloader on Elasticsearch CVE-2015-1427 exploit

This is a tough writing, and will be many information will be added after the initial release. We are pushed to release this as alert of an on-going attack on Elasticsearch host(s), it is a real malware incident report, below is the contents:

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"
..geo location is pointing to this area in Hongkong:

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 DES decryption with the below key (used for encrypt the infected machine's data detected by the ELF as botnet agent sent in HTTP botnet request):

Proof of concept of the DES encryption used is as per decrypted in this video:

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, and we are all know that XOR decryption is not changing the size of the object too, we can assume 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 (see the next part)

Post-downloading the GIF data, botnet traffic requested by the malware are replied by the HTTP response 204, and constantly looping to request the same request to the motherhost:

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:

After advisory communication with good friends in Emerging Threat [link tributed] (thank to Will, Darien & Travis). we went back to the main() function in the ELF to confirm a XOR decryption loop used to decrypt the 5k blob of unknown binary in the downloaded GIF file, following by the writing the decrypted data to the new file, change the mode of file to the execution mode, as per shown in the below reversed code:

The saved file to be then be prepared to be forked executed by the ELF (with some error trapping..just don't mind those..see the bottom part) as per details reversing data below:

The XOR decrypted data is proven as the shell script backdoor malware described in the first part of the analysis, and thank you for the XOR decrypter script contributed by good friends in Emerging Threat [link tributed]! The PoC of the decrypting process can be seen in the below video.

Detection ratio and sample

The detection ratio of the ELF malware one is zero:

The detection ratio of the Shell Script backdoor is also zero:

The detection ratio of the GIF data contains the 5kB of XOR decrypted malware code is also zero:

Emerging Threat was urgently releasing IDS filtration in a couple hours after I reported this threat, GREAT action!

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

Actor initial investigation

Certification and web trails of the actor exists in the internet, in example:

..and..
The information above lead us to the location of the actor which was in the below network under a certain time frame:

222.208.0.0/13 
123.144.0.0/14 AS4837 
We believe he "was" living in the area as per shown in below video. More data to be shared to the law enforcement only.

Feedback from security community (tweets)

AV-Test.org's helps to push rate of ELF AV detection ratio, below is the historical timeline for this ELF malware's detection:

#MalwareMustDie!