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 x32 sample that was reported several hours back, the infection vector is also ShellShock, the reporter seems didn't know whether the ELF binary is malicious or not..nor knowing which kind of malware it is, so I decided to dissect it, hoping this information will help security community to use as reference for similar sample.
The ELF binary looks like this:
It was statically compiled ELF in Intel 32bit architecture.
Studying the sample
As I fond of shellcode myself as a hobby, seeing the hex and stripping the ELF header, 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, anyhow I decided to check it out, and of course, with radare. Firing up, it looks plain and simple assembly as per below, which disassembled the opcodes correctly in 80386(x86-32) language:
In a glimpse, this shellcode looks the same to what we had before, but it is slightly different 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, and the result is as per 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 being made to the remote machine. I see the same procedure is used in same reverse-shell malware shellcode basis or some malicious shellcode itself. This part is happened more or less similar as previous case I dissected in Sept 2014 (linked above).
However, the rest of the lines is the interesting point of this threat.
in 0x0804807c it strictly setting the memory space (in the stack) to be set to 7, and this means the stack setting(PROT_READ, PROT_WRITE, PROT_EXEC) flag is set to readable, writeable and executable (code from 0x0804807e to 0x0804808d is about this setting..called sys_mmap2 w/def size w4096 and called sys_mprotect..in C is a malloc part).
Up to this point the badness is smelled strong. The next operation will explain the bad activity very well, in 0x0804808f it restores the socket and then reads the data from the socket (ref 0x08048095 in executed syscall0x03 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).
The next, the last code in address 0x08048099 is a jump to ecx register which contains the pointer to the saved data in she stack, Yes, which can mean the execution of the whatever data saved in the alloc'ed stack (memory).
The implementation for this backdoor can be widely used for so many further badness to be installed/sent to any successful injected host. We'd better to take more attention awareness of it. i.e. The most imaginable followup for this threat is the injection of the shell ELF binary itself via this backdoor. The threat is already in the wild folks, awareness is a must, there is no need to hush hush about this ,natter which making our fellow sysadmins (like a friend who got this in his server) doesn't know much info about this threat.
Behavior analysis
During the run sysadmins in any infected machine will see the operations triggered by the malware as per below in kernel space:
And of couse, the segmentation fault will occur for the obvious reason, which I will not stated in here for the security reason.
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 in here -->[here]
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) but I am sure the overall analysis is correct.
#MalwareMustDie! | analysis by @unixfreaxjp
SOCIAL SHARE CARD GENERATOR