MalwareMustDie!

Semper legerent Salve Regina ante venatione malware

© MalwareMustDie,NPO 2017. All rights reserved.
Built by Jekyll, based on Poole and BlackDoc on FreeBSD, posts are in Markdown and Rouge highlighter with templates coded in Liquid.

MMD-0051-2016 - Debunking a tiny ELF remote backdoor (shellcode shellshock part 2)

03 Feb 2016

The background

In September 2014 during the ShellShock exploitation was in the rush I analyzed a case (MMD-0027-2014) of an ELF dropped payload via ShellShock attack, with the details can be read in-->[here]

Today I found an interesting ELF x86-32 sample that was reported several hours back, the infection vector is also via ShellShock, the reporter seems not so sure whether the ELF binary is malicious or not..nor can he figure which kind of malware it is.. if it's malicious, so I decided to dissect it upon received the sample, hoping this information will help security community to use it as reference for the similar case.

The ELF binary looks like this:

It is a statically compiled 155 bytes ELF binary in Intel 32bit architecture, by the result of its compilation I can tell that was in a form of shellcode for linux compiled in C template on a GCC compiler.

Studying the sample

As I fond of shellcode myself as a hobby, seeing the hex and stripping the ELF header parts, I can see the shellcode inside started from 31 db f7 e3 53 43 53 6a 02 b0 66 ..until.. cd 80 ff e1.

Compared to the previous mentioned case, this shellcode is a way much shorter, could be part of something bigger that was cut to whatever purpose, or a partial module of the threat series, or it's just small. Anyhow I decided to check it out, and of course, with my beloved radare. Firing up, it looks plain and simple assembly as per below, as per disassembled which each opcodes correctly in 80386(x86-32) machine language:

In a glimpse, this shellcode looks the same to what we had before, but it is slightly different on several patys and again, shorter. So now all we have to do is to describe how dos it work.

Dissection of the evil opcodes

I breakdown the codes into its calls & processes, took a while of work and reading many syscall references, but it was all worth and the result is as per pictured below:

What it says from line number 3 to 25 (xref: 0x08048054 to 0x0804807a) in plain English is:
Firstly this ELF/shellcode part called the socket, set it with as internet connection used socket (PF_INET) to a certain IP address and port number (both are hard coded in hex, see the picture above), assuming the back connection is going to being made to the remote machine. I see the same procedure is used in same reverse-shell malware or some malicious shellcode itself. This part is happened more or less similar as previous case I reported and dissected in September 2014 (linked above).

However, the rest of the lines is the interesting point of this threat.

in 0x0804807c it strictly set the memory space (in the stack) to the value of 7, and this can be only mean that the stack setting(PROT_READ, PROT_WRITE, PROT_EXEC) flag is set to readable, writeable and executable ( xref: codes from 0x0804807e to 0x0804808d is all about this setting..called syscall sys_mmap2 w/def size 4096 and called syscall sys_mprotect..in C is similar to make a malloc() part).

Up to this point the badness is smelled stronger. The next codes will explain its bad activity very well. In 0x0804808f it restores the socket and then reads the data from the socket (ref 0x08048095 in executed syscall0x03 sys_read) and it's saved the data to the stack (which is read/write/exec-able now).
The described current process is up to 0x08048097 now (we are here). So, an explanation in better English up to this process is: this malware connects to the defined IP address and port and listened to what will be sent and save the sent data in the memory.

The next, the last code is in address 0x08048099 is a jump command to ecx register which contains the pointer to the saved data in she stack, Yes, which can also mean the execution of the whatever data saved in the allocated stack (memory).

In overall, in short; this backdoor is back-connecting to a hardcoded remote host, it listens to the connected socket and retrieving the data sent through it, and saved the data in the stack (memory), and to then it can execute whatever form of executable data sent to the infected host.
And all of these can be performed in a tiny-savvy-little 155 bytes ELF file we have, nasty is it? To be clear, it doesn't fetch any binary, it doesn't contain any shell. as engineer one should be precise in defining this malicious definition.

The implementation for this backdoor can be widely applied as component to many further form of badness if it s installed/sent to any successful compromised host. We'd better to take more attention awareness of these type of small and unusual ELF files inside of our system.

The most commonly imaginable follow-up scheme for this ELF infection is the injection of the shell binary (mostly an "sh" or "bash" file, etc) ELF binary via this backdoor. But that is not necessarily to be the shell binary. IT can be rootkit installer or further malicious shellcode.

The threat is already in the wild folks, before you yell me of the OPSEC I'd say awareness is a must too!!, there is no need to be hush hush about this matter which making our fellow sysadmins clueless (like a friend who got this in his server) and doesn't know much info about this threat. They are the ones who can lose their jobs for not knowing these details, They need to know the correct definition.

Behavior analysis

During the "run" process, sysadmins in any infected machine will see some operations triggered by the malware in the kernel space as per processed called below:

And of course, in this particular file, due to the stupidity of the lamer who copy-pasta and wrongly compiled its codes, the segmentation fault will occur for the obvious silly reason, which I will not explain in here for the security reason.

Naming of the malware

I must protest to antiviruses that was saying this is as a "downloader", since clearly there is no direct/undirect downloading codes in its binary. The correct fact is, a backdoor, with the malicious verdict of: a remote attacker is pushing via TCP the binary to be executed in the compromised machine via this backdoor .

Other antivirus products named this malware with "GetShell", ...umm..well... it is about okay, since "mostly" what will be pushed via this backdoor are shell binaries, but noted: this malware is NOT making any GET action to receive that binary, it is just sitting there connecting to an IP and waiting for the push. Moreover.. the payload itself doesn't have to be a shell binary either, could be a rootkit for example, or etc badness installer, and so on..

For those antivirus products that named this malware as "ShellLoader"..sorry, it is just too different in meaning, firstly, the binary is NOT loading anything except itself, and there is no single shell is loaded too, furthermore, there is a shellloader ELF malware which is operated differently to this one, let's not mixing them, and please, do not suggest a wrong assumption to your market or customers, educate them with real technical fact instead! Come on, you can do better than this!

Congratulations to ONE product who named this correctly, you did a good work! A hat tip!

Sometimes it takes efforts to explain what actual names for this malware :-)
FYI, this is only 155 bytes of codes, lesser of that size is in shellcode bytes, mustn't be that hard to be read, specially with a good resources, manpower and budget.

I am a field fellow, I work from IDC to IDC, servers to servers, even now, my mates are all sysadmins and I am one of them, a NIX admin for 20+ years experience now, and I know them very well. And UNIX sysadmins CAN NOT AFFORD TO MAKE ANY MISTAKE, and yes, we don't. Services and daemons work are depending on us. For us, everything related to an incident like this, is technical, and we depend and trust the technical outcome, like the names of the malware, is the first result we will see, and sysadmin's actions will be based on those names after AntiVirus scanned it (if they installed it), this is why some of us paying license fee to AntiVirus yearly, and they (AV) should not making wrong judgement nor just do a pattern matching checks only for naming a ELF malware, especially for this tiny small dangerous stuff!!

When I speak the truth advising right information and name of this malware & showing some bad namings as the output of virus cannning, what I got is a "WHAT?" from a "younger" friend in an "industry" :-(
Obviously there is no respect of the efforts of what has been done here.. :-|
READ THE CODES, Bro, your SERVER SIDE customers in the field are REALLY counting on your skill in naming of ELF malware, UNIX servers are not a PC in its management. And again, people like us are losing jobs for the hacking incident like this, while AV may "only" lose some numbers of income from a list of customer. So, sorry for I can not be NICE for this silly mistakes.



May☩Lord always gives strength to those who can read codes, and reveal the truth as per it is.

The sample, epilogue & follow up

The sample is in Virus Total that can be accessed in here-->[link]
I am also added the Shellshock Shellcode compiles malware to its thread in kernelmode [link]

The radare.org [link] dev team is proven rock, by only reading this post they added feature to check the ip address [link] & also adding the syscall table information [link] for FreeBSD x86-32 on Linux ELF analysis purpose.
For your information I use radare since "radare", was 1st version (used it since /usr/ports), and our team is the "official" (smile) user for so long[link] w/thank you, and keep on using it happily in all my beloved Demon clusters[link]. Please support them with improvement reports!

Thank you for your participating to the vote[link] & feedback about to this post:

NOTE: The follow up of this case will be posted in here. To be noted, there are few opcodes that might have slight different translation, please bear to some small miss (if any), and kindly inform about it, but I am sure the overall analysis is correct.

#MalwareMustDie! | analysis by @unixfreaxjp 



"Then you will know the truth, and the truth will set you free.”

☩John 8:32

Recent Posts