Friday, June 26, 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; ||AS9293 | | HKNET | HK | | HKNet Company Ltd/NTT Com Asia Ltd||AS9293 | | HKNET | HK | | HKNet Company Ltd/NTT Com Asia Ltd ||AS4847 |   | CNIX  | CN | | China Networks Inter-Exchange


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:


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


[1] Script: (

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": " /",
  "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: 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:

The information above lead us to the location of the actor which was in the below network under a certain time frame: 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)'s helps to push rate of ELF AV detection ratio, below is the historical timeline for this ELF malware's detection:


Wednesday, June 24, 2015

MMD-0033-2015 - Linux/XorDDoS infection incident report (CNC: HOSTASA.ORG)


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 with the below GeoIP details:

  "ip": "",
  "hostname": "",
  "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:
[2015-06-23 01:29:42]: Client version: [SSH-2.0-PUTTY]
[2015-06-23 01:29:43]: Login succeeded [***/***] 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 ( panel screenshot taken at the time the attack was in progress:

The IP info of this panel:

  "ip": "",
  "hostname": "No Hostname",
  "city": "Nanjing",
  "region": "Jiangsu",
  "country": "CN",
  "loc": "32.0617,118.7778",
  "org": "AS11282 SERVERYOU INC",
  "postal": "210004"
(Additional) The domain information:
;                      IN      A

;; ANSWER SECTION:               600     IN      A               600     IN      A

;; AUTHORITY SECTION:               3596    IN      NS               3596    IN      NS
Below is more proof of the domain's used, a check mate:

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 > 27458+ A? (32)
08:21:20.080602 IP mmd.bangs.xorddos.38988 > 44387+ A? (33)
08:21:25.092061 IP mmd.bangs.xorddos.45477 > 58191+ A? (33)
08:21:25.269790 IP mmd.bangs.xorddos.51687 > 22201+ A? (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:


..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:         300     IN      A        300     IN      A        300     IN      A        300     IN      A

;; AUTHORITY SECTION:            3600    IN      NS            3600    IN      NS            3600    IN      NS            3600    IN      NS

;; ADDITIONAL SECTION: 2669 IN   A 649 IN    A 159 IN    A 2772 IN   A 

Up and alive CNCs are in USA:

  "ip": "",
  "hostname": "No Hostname",
  "city": "Newark",
  "region": "Delaware",
  "country": "US",
  "loc": "39.7151,-75.7306",
  "postal": "19711"

  "ip": "",
  "hostname": "No Hostname",
  "city": "Los Angeles",
  "region": "California",
  "country": "US",
  "loc": "34.0530,-118.2642",
  "postal": "90017"
These other two CNCs are allocated in Hongkong network:
  "ip": "",
  "hostname": "No Hostname",
  "city": "Central District",
  "country": "HK",
  "loc": "22.2833,114.1500",
  "org": "AS62466 ClearDDoS Technologies"

  "ip": "",
  "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:", LLC (R1288-LROR)"
Sponsoring Registrar IANA ID: 625
WHOIS Server:
Referral URL:
Domain Status: 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:

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:
ROID: 20141229s10001s73492202-cn
Domain Status: ok
Registrant ID: ji27ikgt6kc203
Registrant: "蔡厚泉 (Cai Hou Sien/Quan)"
Registrant Contact Email: ""
Sponsoring Registrar: 北京新网数码信息技术有限公司
Name Server:
Name Server:
Registration Time: 2014-12-29 10:13:43
Expiration Time: 2015-12-29 10:13:43
DNSSEC: unsigned
ps: CNNIC has more information of this registration, I took liberty to query them to find this crook is using the same and other ID to several poor reputation .CN domains, under the same and different name too, on the same QQ:
Domain   RegistrantID     Name
------------------------------ ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ej55v35357p95m   沈涛 ji27ikgt6kc203   蔡厚泉 ej55v35357p95m   沈涛 ji27ikgt6kc203   蔡厚泉
And after seeking for a while, all of these reference lead to the individual identification here:

Which is living nearby the Tanxi Bus Station in Sanyuanli street, Baiyun district, Guangzou prefecture, PRC, as per described in ths map:
I will leave this data for the authority to follow this lead further.

Detection ratio and samples

ELF samples are all in Virus Total with the below links:
( = 3c49b5160b981f06bd5242662f8d0a54
( = bcb6b83a4e6e20ffe0ce3c750360ddf5
( = a99c10cb9713770b9e7dda376cddee3a
( = d1b5b4b4b5a118e384c7ff487e14ac3f
( = 83eea5625ca2affd3e841d3b374e88eb

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