Thursday, September 3, 2015

MMD-0041-2015 - Reversing PE Mail-Grabber Spambot & its c99 Gate

I don't know about the origin of the infection, but when I talked with Mr. Christopher Lowson while examining the CNC of the threat, I guessed a PC was infected with this malware and the callback is why me and Mr. Lawson talked. Beforehand, thank's to the Emerging Threat to allow me to write this up, I will start this report from the malware analysis to its CNC gates, in as secure manner as possible.

The unknown SFX RAR .Net PE malware (sounds lame enough?)

The sample is a PE (6222e15ed2c71429c472e5f0fa40d727) and it was reported a week ago (2015-08-27 15:10:48 UTC). A grep info in pescanner will show you:

File:    ./Release.exe
Size:    263514 bytes
Type:    PE32 executable (GUI) Intel 80386, for MS Windows
MD5:     6222e15ed2c71429c472e5f0fa40d727
SHA1:    a9316503ad6dd9e10fa8506fe69cc5aa7cc4eafe
Date:    0x54E0521F [Sun Feb 15 08:00:31 2015 UTC]
EP:      0x41d7cb .text 0/4
CRC:     Claimed: 0x0, Actual: 0x4a8a2 [SUSPICIOUS]

The CRC differences is showing packed/archives or both, I tend to check further the insides for sure with my beloved UNIX shell reversing tool, the almighty radare:

..this is showing overlay of SFX Rar file. A test (t command) in unrar shows the contents safely:

Testing     MAPIEx.dll                            OK
Testing     NetMAPI.dll                           OK
Testing     aa.exe                                OK
Oh, it seems there are two run time dll to run the aa.exe, Let's check again what is the aa.exe:
MD5 (aa.exe) = fa056e635791f18b21898bc0ff6a9978
aa.exe: PE32 (GUI) Intel 80386 Mono/".Net assembly", for MS Windows

The above result is a self explanatory. The point is: Always do static analysis beforehand, it is very important to recognize which binary we are dealing and how is the best way to deal with before we start firing some disassemblers to check its bits or opcodes.

Okay, since now we know how it's developed, let's decompile it in the same way it was built. You'll find these loaded resources:

OutlookContactsViewer.Form1.resources (Embedded, Public)
OutlookContactsViewer.Properties.Resources.resources (Embedded, Public)

The above resources is having the code to execute the malware, so the rest of this reversing is just depending on our skill to read that code.. I will cover the important parts only to PoC the badness of this binary and won't share the full code for the security purpose, as follows..

Peeling the malcode :-)

This is how the malcode was started... by initiation some variables and starting the main function to call to its loading-form:

And the loaded form has the main code of main functions for overall malcode operation:

As you can see it has two commands of "extract" and "spread". Between the "===" delimeter string, the data/text will be filled by email addresses grabbed from functions: GetMailsFromContacts(), GetMailsFromHeaders() and GetMailsFromMessages().

Functions called due to the "extract" command is the text formulation of the strings following by the POST command to send data to the web gates with URL defined in the initialization variable part.

Now we know the purpose of the runtime file is; NetMAPI library was used to perform email-grabbing act i.e. as per snipped below code in GetMailsFromContacts()

..and it is added with the regex to grep the email addresses in GetMailsFromHeaders() and GetMailsFromMessages() parts:

The same library also being used to spread spam via "spread" command (below), yes..it is a PoC that we also have a kind of spambot too here. Noted that the subject, body message and the attachment variables hard coded in the initiation part was stored here:

I snip some significant codes (only) that's utilizing HTTP protocol for uploading grabbed emails to the gate as per below, to understand and to figure ways to mitigate the threat further:

To be noted this malware reads the multipart encoded part of an email too:

A sample traffic captured for the uploads is here:

So we have the good idea what the malware is doing, yes? It sends spam, it grabs email address and uploaded them to the remote gate.

The gate

The gate is a hacked sites, I spotted the c99shell by the first time I see it. I spent much time studying c99shell before, the link is here-->[link]. This one looks injected to the compromised web site via PGP vulnerability that allows remote file uploading.

It is the latest standard version noticing this command list:

This is the up.php gate's code:

So this is how the up.php works in receiving the request, using GeoIP (by Maxmind) API to check the location of POSTed IP, making directory of that country code (if not exist) and writing files with the list of grabbed emails in it (if succeeded), it explains many directories with country code names. It also make logs of access and has the ban access function too, the details for that is written in the included func.php.. Please noted the "Nothing to do.." decoy.

It's not being used but below is snipped for the logging and banning codes, I "secured" it a bit:-)

This is what files were injected and created in that panel, if you see the same files in your servers please delete or secure them all + fix the PHP flaw that caused the file upload.

The email data of the victims that has been grabbed was plenty.. thanks to Mr. Lowson to clean this threat's gate to stop this badness. Below is the snip per 4 lines each data in the CO (randomly picked) directory..

Unknown threat with zero detection

I don't think we have any PE detection sig for this threat (in VT point of view): [Release.exe] [aa.exe]

A saying in my country says: "What we don't know, even small mater, may hurt us badly" ..I guess this is the case.

Additionals..

#MalwareMustDie

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

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

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

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

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

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

The full code is beautified as per below:

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

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

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

The IP that serves this malware is located in Germany:

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

The AutoIt PE "Banco" banking trojan

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

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

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

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

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

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

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

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

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

How AutoIt can inject memory?

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

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

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

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

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

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

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

Summary of the PE's malicious behavior detected:

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

HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced EnableBalloonTips
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{XXX}\InProcServer32
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]
The payload in 7zip format is here -->[link]

The next challenge...encryption VBE:

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!