Friday, August 28, 2015

MMD-0040-2015 - Learning about VBE Obfuscation & AutoIt Banco Trojan

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 very simplified, beautified, make it easy to stare at (I mean..to read)
2. Break the codes into pieces, comment them, make sure you know how each component works, do not be embarrass to make many comments, it is for your own good.
3. To securely simulate the code to debug. Use compiler/interpreter if possible, if not..use our brain for it, make some notes, in this level most of the time in heavy obfuscated challenge 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 whe relax you can use those cells, and if you push it hard, your work will not effective and many miss will occur. A one little miss of a single bit will drag you to a time-consuming trouble-shooting later on which lead you back to square one..which is mostly how a failure starts, so noted this point number 4 well, PS: this point goes to the bosses/management of the reverse engineers too, understand this if you want your team to do the work well
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.

So 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
Etc activities for instance:
Self rename file extension of itself into .exe
Binding to local INET socket to open & listening port 2038
Mutex: "\BaseNamedObjects\2015.0.11"
And some strings to mitigate these security products:
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 address origin (GeoIP & ASN):
  "ip": "187.17.111.103",
  "hostname": "No Hostname",
  "city": null,
  "country": "BR",
  "loc": "-23.5477,-46.6358",
  "org": "AS7162 Universo Online S.A."
The domain is registered with an email contact of ARNALDOBALTAZAR@GMAIL.COM to ENOM.COM:
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

It's downloadable in a 7zip format from here -->[link]

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

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

Saturday, August 22, 2015

MMD-0039-2015 - ChinaZ made new malware: ELF Linux/BillGates.Lite

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 threat 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 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
but this variant is not having these functions which is the result of the functions in ThreadMonGates.cpp in original Linux/BillGates. I am raising this difference as the number one since this is the easiest way to recognize this variant from the previous original versions.

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 the stripped & 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
It's the known config that's been used by Linux/Elknot to initiate the attack with assembling the local IP of the infected server, forming the port range of the malicious outbound attack.

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::InitializeEv function, 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
..and the below snip code shows that one function is actually having the actual aggressive code for launching the packet attack:

..and yes, this "ThreadAttack::PktAtk" is the only one that being used (called) by other functions, to perform packet flood attack.

To be noted: 1. There are so many functions that was there as skeleton but not fully coded.
2. You won't find these kind of attack codes in any Elknot either.. Elknot is old but is way much better coded one :-D

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
The first two libraries are required as the runtime+standard C functions library used, and the third one shows that Linux/BillGates.Lite is relying to libnss (The Naming Scheme of the NSS Modules) for the internet name lookup operations. This is the strong point actually, if the libnss usage in a system can be somehow be more secured or hardened to be used by certain system's user only I bet many ELF malware can not make a lookup..since many of malware are using libnss to translate domain names.

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

One more, a recent incident with the same ASN as origin..

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!

Monday, August 10, 2015

MMD-0038-2015 - ChinaZ and ddos123.xyz

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
we have a what seems to be alive and actively responding CNC here. But let's not jump into any conclusion before seeing the next sections..

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
Just to be sure, I search by RRset mode to find range of activity of the suspected domain, and the result shows it wasn't sinkhole and under origin of the registrant as per initially registered.
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.
We must admit it is a kind of weird for ddoser actor's used hostname showing "ddos" keyword, it's too blatant, isn't it? I mean what would you think to see a CNC of backdoor/ddoser ELF malware with hostname as www.ddos123.xyz? But since the checks are solidly explained and DNSDB records + DNS records implies the initial sate unchanged, showing a full control of the domain from whoever actor who set it up as CNC calls, it makes some senses. But let's also check this a bit further..

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

河南省郑州市 
河南电联通信技术有限公司
And matched to my custom GeoIP API that is pointing to:
  "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"
It's a node in network in Zhengzhou city of Henan, prefecture in the People Republic of China (PRC) country, and, again, comparing the network to several sinkhole database and it doesn't match to any sinkhole nodes too, so we are positive to see an alive CNC in that area, with noted, it is in a hardline IP address.

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
Which is served in a VPS in the very different location and service under this BGP [link] info..
  "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."
This also implies that the actor doesn't want to link the domain to the its usage as CNC hostname, but it is not eliminating the previous result that it has the full control to make domain's record arrangement so far, unless we can proof the domain was hacked or hijacked (checked that too so far and the result is likely not).

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
It is interesting to know the keyword "ddos" was used to more than one domain. And the usage of the .XYZ domain is reminding me to the previous takedown 103 domains that was being used by ChinaZ in different case..a relation?
OK, checking further..each domain was registered in the "same way" too, please see how registration was written as per below snipped WHOIS record:
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"
We can see some attempts to "fake" whois information up there. Made those look suspicious. Seeking more malicious record linked to these domains might lead us to something else, but I will focus to the case we ChinaZ CNC verdict in hand..

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:

was suggesting the actor's effort in seeking for Linux malware..

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:

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

Wednesday, July 15, 2015

MMD-0037-2015 - A bad Shellshock & Linux/XOR.DDoS CNC "under the hood"

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


Well.. it was past my bed time and I about to sleep so I asked our expert mates MMD ELF Team who are living in other part of our globe to check whether this one has something new.

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 data with zlib compression

[Corrected] I mixed up the above zlib part with crypted part below, thanks VT friend for heads up.
The below values of XOR encrypted combined with base64 data is also spotted, we did not see it in the others:

The PoC and the more detail reversing for g.rar is to be added in this part, please take a rain check.

[Additional] Reversing information below is added via good contribution from Mr.Ivan Korolev (thank you very much for your help!) from his reversing on g.rar / 7e2280a2dff5028ef2ab37bd420af5d120dfc1d8:
1. It's backdoor specific commands list (includes "download & run", "backconnect", "download file to location", "set config parameters", "connect to specified C&C" ). And the function that handles C&C communication is located at 0x0804C46E.
2. Zlib is being used twice: (2.1.) When backdoor collects information about the infected system. Collected information XOR-ed with random 0x20-bytes-long key, encoded with base64 and finally compressed with zlib. (2.2.)When backdoor downloads compressed file (cmd id == 0x03)

Thank you Ivan! [/Additional]

A nice tool to deflate compressed zlib data I recommend this nice pipe code [link].

After you done the rest of (g.rar) binary, the result 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 g.rar upon executed will do self-copied in reachable **/**/[s]bin directories, and if not having permissions for those location it will be resided in /tmp or /var/tmp, under random names and flooding the system with spawn & re-spawning process to persist his way to keep alive and connect to CNC.

Below is a single process of g.rar looks like post-infected state in lsof:

COMMAND    PID USER   FD   TYPE    DEVICE SIZE/OFF    NODE NAME
qrD6E16p 12514 test  cwd    DIR       8,6     4096 1048613 /TESTDIR
qrD6E16p 12514 test  rtd    DIR       8,1     4096       2 /
qrD6E16p 12514 test  txt    REG       8,1   664896  264910 /tmp/qrD6E16p
qrD6E16p 12514 test    0u  IPv4 133785570      0t0     TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)

It does flooded your system non-stoppable:

qrD6E16p  12514              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
qrD6E16p  12514              test  rtd       DIR        8,1     4096          2 /
qrD6E16p  12514              test  txt       REG        8,1   664896     264910 /tmp/qrD6E16p
qrD6E16p  12514              test    0u     IPv4  133785570      0t0        TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)
qrD6E16p  12514 12523        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
qrD6E16p  12514 12523        test  rtd       DIR        8,1     4096          2 /
qrD6E16p  12514 12523        test  txt       REG        8,1   664896     264910 /tmp/qrD6E16p
qrD6E16p  12514 12523        test    0u     IPv4  133785570      0t0        TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)
qrD6E16p  12514 12524        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
qrD6E16p  12514 12524        test  rtd       DIR        8,1     4096          2 /
qrD6E16p  12514 12524        test  txt       REG        8,1   664896     264910 /tmp/qrD6E16p
qrD6E16p  12514 12524        test    0u     IPv4  133785570      0t0        TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)
RodiXi3   12631              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
RodiXi3   12631              test  rtd       DIR        8,1     4096          2 /
RodiXi3   12631              test  txt       REG        8,1   664896     268768 /tmp/RodiXi3
QPqitjI5x 12633              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
QPqitjI5x 12633              test  rtd       DIR        8,1     4096          2 /
QPqitjI5x 12633              test  txt       REG        8,1   664896     268769 /tmp/QPqitjI5x6nd
PR2PhLH   12635              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
PR2PhLH   12635              test  rtd       DIR        8,1     4096          2 /
PR2PhLH   12635              test  txt       REG        8,1   664896     268770 /tmp/PR2PhLH
hKE6wECZG 12637              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
hKE6wECZG 12637              test  rtd       DIR        8,1     4096          2 /
hKE6wECZG 12637              test  txt       REG        8,1   664896     268771 /tmp/hKE6wECZGs2
WuMKsp3   12831              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
WuMKsp3   12831              test  rtd       DIR        8,1     4096          2 /
WuMKsp3   12831              test  txt       REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831              test    0u     IPv4  133786107      0t0        TCP MMD.SCREW.XOR.DDOS:37112->211.110.1.32:ssh (CLOSE_WAIT)
WuMKsp3   12831 12844        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
WuMKsp3   12831 12844        test  rtd       DIR        8,1     4096          2 /
WuMKsp3   12831 12844        test  txt       REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12844        test    0u     IPv4  133786107      0t0        TCP MMD.SCREW.XOR.DDOS:37112->211.110.1.32:ssh (CLOSE_WAIT)
WuMKsp3   12831 12844        test    1r      REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12844        test    2w      REG        8,1   622592     268776 /tmp/f9Ca6W
WuMKsp3   12831 12845        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
WuMKsp3   12831 12845        test  rtd       DIR        8,1     4096          2 /
WuMKsp3   12831 12845        test  txt       REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12845        test    0u     IPv4  133786107      0t0        TCP MMD.SCREW.XOR.DDOS:37112->211.110.1.32:ssh (CLOSE_WAIT)
WuMKsp3   12831 12845        test    1r      REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12845        test    2w      REG        8,1   622592     268776 /tmp/f9Ca6W
nZS4n     12912              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
nZS4n     12912              test  rtd       DIR        8,1     4096          2 /
nZS4n     12912              test  txt       REG        8,1   664896     268765 /tmp/nZS4n
5nCVmqNjx 12914              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
5nCVmqNjx 12914              test  rtd       DIR        8,1     4096          2 /
5nCVmqNjx 12914              test  txt       REG        8,1   664896     268766 /tmp/5nCVmqNjx
Rf8tMCwI  12916              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Rf8tMCwI  12916              test  rtd       DIR        8,1     4096          2 /
Rf8tMCwI  12916              test  txt       REG        8,1   664896     268773 /tmp/Rf8tMCwI
8M0LORVgQ 13074              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
8M0LORVgQ 13074              test  rtd       DIR        8,1     4096          2 /
8M0LORVgQ 13074              test  txt       REG        8,1   664896     268782 /tmp/8M0LORVgQVd
8M0LORVgQ 13074              test    0u     IPv4  133786540      0t0        TCP MMD.SCREW.XOR.DDOS:37124->211.110.1.32:ssh (CLOSE_WAIT)
8M0LORVgQ 13074 13091        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
8M0LORVgQ 13074 13091        test  rtd       DIR        8,1     4096          2 /
8M0LORVgQ 13074 13091        test  txt       REG        8,1   664896     268782 /tmp/8M0LORVgQVd
8M0LORVgQ 13074 13091        test    0u     IPv4  133786540      0t0        TCP MMD.SCREW.XOR.DDOS:37124->211.110.1.32:ssh (CLOSE_WAIT)
8M0LORVgQ 13074 13092        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
8M0LORVgQ 13074 13092        test  rtd       DIR        8,1     4096          2 /
8M0LORVgQ 13074 13092        test  txt       REG        8,1   664896     268782 /tmp/8M0LORVgQVd
8M0LORVgQ 13074 13092        test    0u     IPv4  133786540      0t0        TCP MMD.SCREW.XOR.DDOS:37124->211.110.1.32:ssh (CLOSE_WAIT)
AL2RROHuq 13137              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
AL2RROHuq 13137              test  rtd       DIR        8,1     4096          2 /
AL2RROHuq 13137              test  txt       REG        8,1   664896     268780 /tmp/AL2RROHuq
ovxnJH438 13139              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
ovxnJH438 13139              test  rtd       DIR        8,1     4096          2 /
ovxnJH438 13139              test  txt       REG        8,1   664896     268781 /tmp/ovxnJH438UHem
B2xPwN    13141              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
B2xPwN    13141              test  rtd       DIR        8,1     4096          2 /
B2xPwN    13141              test  txt       REG        8,1   664896     268783 /tmp/B2xPwN
pR9QwfBw  13143              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
pR9QwfBw  13143              test  rtd       DIR        8,1     4096          2 /
pR9QwfBw  13143              test  txt       REG        8,1   664896     268784 /tmp/pR9QwfBw
auMlF6Xtv 13145              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
auMlF6Xtv 13145              test  rtd       DIR        8,1     4096          2 /
auMlF6Xtv 13145              test  txt       REG        8,1   664896     268765 /tmp/auMlF6XtvW9Q
iKk6F78   13147              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
iKk6F78   13147              test  rtd       DIR        8,1     4096          2 /
iKk6F78   13147              test  txt       REG        8,1   664896     268773 /tmp/iKk6F78
OnnSe0Asd 13149              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
OnnSe0Asd 13149              test  rtd       DIR        8,1     4096          2 /
OnnSe0Asd 13149              test  txt       REG        8,1   664896     268775 /tmp/OnnSe0AsdJW7
JHpy2Tv   13151              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
JHpy2Tv   13151              test  rtd       DIR        8,1     4096          2 /
JHpy2Tv   13151              test  txt       REG        8,1   664896     268776 /tmp/JHpy2Tv
Hl1GIXA1S 13220              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Hl1GIXA1S 13220              test  rtd       DIR        8,1     4096          2 /
Hl1GIXA1S 13220              test  txt       REG        8,1   664896     268780 /tmp/Hl1GIXA1SVEnOY
Hl1GIXA1S 13220              test    0u     IPv4  133786857      0t0        TCP MMD.SCREW.XOR.DDOS:37132->211.110.1.32:ssh (CLOSE_WAIT)
Hl1GIXA1S 13220 13239        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Hl1GIXA1S 13220 13239        test  rtd       DIR        8,1     4096          2 /
Hl1GIXA1S 13220 13239        test  txt       REG        8,1   664896     268780 /tmp/Hl1GIXA1SVEnOY
Hl1GIXA1S 13220 13239        test    0u     IPv4  133786857      0t0        TCP MMD.SCREW.XOR.DDOS:37132->211.110.1.32:ssh (CLOSE_WAIT)
Hl1GIXA1S 13220 13240        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Hl1GIXA1S 13220 13240        test  rtd       DIR        8,1     4096          2 /
Hl1GIXA1S 13220 13240        test  txt       REG        8,1   664896     268780 /tmp/Hl1GIXA1SVEnOY
Hl1GIXA1S 13220 13240        test    0u     IPv4  133786857      0t0        TCP MMD.SCREW.XOR.DDOS:37132->211.110.1.32:ssh (CLOSE_WAIT)
fggF0R    13290              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
fggF0R    13290              test  rtd       DIR        8,1     4096          2 /
fggF0R    13290              test  txt       REG        8,1   664896     268765 /tmp/fggF0R
KwBN6mHut 13292              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
KwBN6mHut 13292              test  rtd       DIR        8,1     4096          2 /
KwBN6mHut 13292              test  txt       REG        8,1   664896     268773 /tmp/KwBN6mHutUe
BaLWO7KCY 13294              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
BaLWO7KCY 13294              test  rtd       DIR        8,1     4096          2 /
BaLWO7KCY 13294              test  txt       REG        8,1   664896     268776 /tmp/BaLWO7KCY
MPNQT08od 13296              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
MPNQT08od 13296              test  rtd       DIR        8,1     4096          2 /
MPNQT08od 13296              test  txt       REG        8,1   664896     268781 /tmp/MPNQT08odg
6IpaJFDff 13315              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
6IpaJFDff 13315              test  rtd       DIR        8,1     4096          2 /
6IpaJFDff 13315              test  txt       REG        8,1   664896     268783 /tmp/6IpaJFDff5ZS
7IkMtxQ0d 13317              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
7IkMtxQ0d 13317              test  rtd       DIR        8,1     4096          2 /
7IkMtxQ0d 13317              test  txt       REG        8,1   664896     268786 /tmp/7IkMtxQ0dJQC9
86cG6TaT  13321              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
86cG6TaT  13321              test  rtd       DIR        8,1     4096          2 /
86cG6TaT  13321              test  txt       REG        8,1   664896     268788 /tmp/86cG6TaT

To reverse is a thing, to PoC what you reversed is correct is another thing. I patched my kernel to intercept every malware activities and dropped the method of depending on system calling tracer to have better view and the result is good, it applying the method to g.rar the PoC of the CNC also can be spotted in its callback process:

// cnc
domain:
GroUndHog.MapSnode.CoM
IP: 211.110.1.32
sendto(0, "#o\1\0\0\1\0\0\0\0\0\0\tGroUndHog\10MapSnode\3CoM"..., 40, 0, 
   {sa_family=AF_INET, 
    sin_port=htons(53), 
    sin_addr=inet_addr("8.8.8.8")}, 16) = 40

Summing up the malware related IP addresses involved up to this point:

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 

"Linux/killfile" ELF (downloader, kills processes & runs etc malware)

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*
I will explain some important functions of this module.

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

 'crtstuff.c'
 'btv1.2.c'
 'http_download.c'
 'libsock.c'
It fakes itself as the bluetooth process:

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
below is the reversing sheet for the killing list:

The IP is located in Korea Telecom, which it seems the bad actor hacked the server:
{
  "ip": "115.23.172.31",
  "hostname": "kill.et2046.com",
  "city": Seoul,
  "country": "KR",
  "loc": "37.5700,126.9800",
  "org": "AS4766 Korea Telecom"
}
And the et2046.com domain used can't be good one, is registered in GoDaddy under below information:
   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 <<<
With the contact email address of tuhao550@gmail.com:
   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"
this domain and this email address also found by our friend Dr. DiMino in DeepEndResearch [link]

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.

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
If you just check this psc into the Virus Total [link] it is shown with a full verdict (37/56) from AV companies as a Linux ELF Virus, a known nasty variant called Linux/RST who infect to other ELF & opening backdoor [link]. This looks very bad isn't it...

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 hacktool in 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"

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"
}
I am pretty sure that et2046.com domain is under control if the bad actor and below chronological IP data linked to this case /et2046.com, must be linked to the actor:
115.23.172.31 (current)
115.23.172.6 (May 2014)
115.23.172.47 (current)
This is strange since many of the Korea IP addresses was used in his infrastructure, I think S. Korea cyber law enforcement has to notice this matter..

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)
Their location is in:

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.

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

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!

Follow up

The attacks are still coming, detected in August 4th 2015, using SAME infrastructure to infect since the payloads are still in there.

#MalwareMustDie