Sunday, June 15, 2014

The background

I think some of Linux sysadmins and malware researchers already know this issue well by reading references in sysadmin/linux forums or reported incident in works, or maybe facing this problem them self. Since the wave of attacks are still spotted and hitting several services with the known webapp vulnerabilities, yet there are no complete verdict details of the threat (yet), we feel it's important to raise an alert on this subject in MMD post as advisory to help fellow admins who may google info of this threat with hoping this may help giving thorough explanation. The recent vulnerability that was exploited to spread this malware infection is a per tweeted here:

Maybe some of us think that DDoS tools are just only infiltrating victim sites with some kids attemting to hack on unattended sites & installing their bots written in IRC Perl/PHP DDoS'er scripts. This post is a good reading for you who think that way, since it explained a more serious threat using ELF DoS binaries specifically built to conduct DDoS action in hacked Linux servers via serious root exploitation method in each infection. This threat is known as the infection of .IptabLex and .IptabLes ELF #DDoS backdoor trojan (malware). The infection was coming from China, and is world-wide now, hitting various Linux based services with new flaws in vulnerability and giving problems to some of us. Here goes the details..

The worldwide incidents reported

First, how is the coverage of this infection? Below is the list of reported incidents of the current threat world wide, I followed & collected in chronological basis, all are referring to the same binary sets and similar infection modus operandi. Infected server's distributions are varied like Debian, Ubuntu, Slackware, CentOS to Redhat, via vulnerability in server application like Tomcat, Elasticsearch, Apache struts etc. But all of them are informing same vector of hack in code injection vulnerability.
FYI. No, we have not seen any FreeBSD or Mac OS X based server as victim (yet).

Source of threat

The origin of the threat is coming from China, which can be technically described in the next analysis sections, but there are so many report posted about the threat in China sites with this reference -->>[here]

While the first two are the malware binaries them self, following by the autostart scripts. Usually the infected host is having both binaries. The bigger size one is the newer and "advanced version", and the smaller one is limited version.

In some cases the "advanced" versions is having runtime problem and created segmentation fault (crash) as per lsof below:

Definition of the Malware

This malware is the DDoS bot ELF malware variant, with a bot backdoor function connected to the CNC which sending them instruction to attack targeted hosts by SYN Flood or DNS Flood DoS techniques. It was autostarted as daemon everytime the host's services started.

So far we see no RAT (Remote Access Trojan) functionality spotted unless for the specific DoS bot functions, and also no sign of rootkits/system environment deletion detected except the additional of autostart scripts.
The deletion process of this malware can be performed safely by execution of the below commands:

The smaller size and big size is different in Symbol table '.symtab' entries, if you diff the table functions, the newer version (the bigger in size) is suggesting the "advanced mode" version with the "pro" features:

Reverse Engineering Highlights

Reversing this malware is interesting, and overall reverse effort was taking longer time than I thought. In this highlight I will guide you to the best way to go to the malicious code PoC the verdict the DoS activities. After choosing your best disassembler, I suggest you start trailing the function in address .text:0804DA40 called startmain() to find the good trail that can lead you to the DDoS functions (the verdict) soon:

Seek the calls lead to this function's start addeess (0x80533B0) and you will see the main DDoS function directly referring to it:

SynFloodThread
DnsFloodThread

The above functions are DoS function which can be reversed as per here-->>[Pastebin] and here-->>[Pastebin], which can be breakdown deeper in how the SYN or UDP packets were formed, randomization of size and the build then followed by the sending thread. The details of those sub functions I will not cover here since it is going to be very long (but please feel free to comment for requests), and the pastebins showed enough evidence of the attack act performed by this flooder.

Let's moving on. In the .rodata:080B3360 you'll find the URL that the malware use for "test purpose", which can help PoC'ing the origin of this malware w/o much heavy reversing:

As you can see, three of the listed sites are Chinese web sites. The other things that can help to ID is the multilanguage Linux trace detected and the way it compiled the binaries (based on previous reference of similar threat from same origin, it is typical)

More malicious activities on the update server's data (link) which clearly show the fetch for updates then save it and deleting those upon done, infected host's sensitive information taken (link), getting networking information of the infected host (link), and hard coding installation of autostart scripts and installation steps (link) which PoC'ed all of the symptoms written above. For the own data handle itself this malware uses a compression logic with the decompression logic that's so "spaghetti coded" like the image below:
..with the code can be viewed here (link) ; Note: All reversed snips can be viewed in each shown disassembler links.

Analysis Samples & Virus Total

Samples are all in Virus Total already with the below hashes, under detection ratio between 3/54 to 8/54:

4baf340e3701b640ad36fb8f606e2aa7f494dd34dc3315c0943f3325c7766f80
a65f430a03c3717250d15d5745ec7c36a60962ae6473938ee545a0267b6857a4
86f34d9974f42ed557f4ae998da50af04b04b03c7e5cf01279ad1ca6bbb4ab1a
fa5e8571c93abbaf7014c9fcecffedeffdac0a3a15d459036fb149a47dfcfb61
d3dafa7f23858711a5fbc195f934b6891114e44d23c86796b2c042f1c2b6e026
ec546a0084120070ee0ea6f00673e42ca13c85f5bd8375a4e62d88541152de6d
(thank's to "Angel Hun" for the last two samples!)

Tiger Security [link], the cyber intelligence and information security entity, was just releasing the detail intelligence report of this threat which explaining the CNC operation behind the scene, as per written in their good report here-->[link]

For the questions and comments are welcome. I need more samples of the recent incidents, if you happen to know ones please help to send us the sample via the DropBox link in the right panel in our (this) blog menu. The comment with the sensitive information or privacy will not posted. With thank you in advance.

That's interesting, this attacker went into system using two methods only (1) weak accounts and (2) exploits (Apache/Struts/Elastic..)It would be very nice if you may kindly share the vulnerable vector aimed.

That's fine, thanks for your work. I have been slowly reversing the command protocol of this binary. I got most of the basic commands down. When ti comes to the DDoS commands, things get a little more difficult because the commands get decompressed when received. Then the spiral of data decompression becomes very convoluted and long. I haven't been able to verify what the network signature for these DDoS commands yet.

In that case, let me see what I can do from our side.Will ping you offline, please send me email address or etc contact info for the messaging purpose, that information will not be posted automatically.

4. I've installed auditd and sysdig, to trace the samba issue, but they aren't very useful as .flush appears and then a couple of hours later I'm reinfected showing how getsetup.rar is downloaded.5. I left the server on overnight sans firewall, Iptables/x, .flush and the PIDs only to get the server reinfected the following morning. 6. Removing just IptabLes/x and the PIDs gets the system reinfected after a couple of hours.7. Removing and installing samba gets the smbd and nmbd binaries +/-8 min of life with .flush on the system.8. Auditd cannot tell me who deleted smbd even when watching /usr/sbin/smbd. I only get a entry of .flush and 1 or 2 entries later samba errors.9. The logs I have checked in /var/log/ have amnesia.10. My bash logs for all the users are squeaky clean.11. Cron does have jobs, but I cannot find them if .flush is on the system. If I delete .flush I find the jobs.12. Rebooting the server after I deleted .flush gets me a couple of minutes then it reappears.13. Adding a country code block in CSF for China doesn't get the server infected.14. Leaving it like that for a hour or 2 still no infection, then switching of CSF and bang in a couple of minutes .flush reappears and auditd and sysdig cannot tell me how. ( backtracing what process created .flush in the first place) 15. Blocking the IPs in .flush and the IPs I have found on the net for Iptables/x and removing China's country codes, .flush will reappear, but no IptabLes/x.16. .flush runs with a UID 0. 17. Rkhunter and Chkrootkit come up blank though I have found forum posts as far back as 2007 relating to IptabLes/x.

Either I get hacked everytime, or there is a friendly that downloads .flush or .flush has replaced a friendly to watch over .flush and download it when it's missing.

I'll dd the system to test under a VM and reinstall as the server needs to go up.

Hi, We must kill these malware :D Lately i got head to head with LInux.DDOS.24, Pktmake, from China Cyber Army. Been reversing it for a few days, but most of the C&Cs were from LA and Beijing. Funny enough the main C&C server is 23.234.50.32, which seems to have IRCD, and on Windows 203 Enterprise configured in Chinese, check RDP on port 5918. If anyone has been able to fully reverse this code, please lemmie know

Hi chuk, you mention China Cyber Army, is this just a strong assumption you have that this is from them? or you have some actionable threat intel that it is in fact CCA behind these bot creations? I have also a toolkit I analyzed that may be associated with those binaries C2 and builder. Does the name "Mr.Black" ring a bell to anyone?

Thank you friends for samples you sent. All are analyzed and posted in here or in VT with good comments/indicator. For the further comments I forward the discussion to the kernel mode, access is --> here

About #MalwareMustDie!

Since malwares are becoming a serious threat in the internet and computer industry. We are now coming to the stage to admit the fact that malwares are actually winning this longest 15+ years historical battle by keep on infecting and conducting their evil scheme until now....[Read More]