MMD-0020-2014 - Analysis of Linux/Mayhem infection: A shared DYN libs malicious ELF: libworker.so

08 May 2014 This is the analysis story based on the incident handling on the server side incident, caused by a hack to perform some malicious attack to a compromised server, so it is the server side malware analysis, with using the rather sophisticated method of LD_PRELOAD, with the summary as per below:

In the end of March 2014 I helped a friend who has problem with his service perimeter from a hack case. The attack was a classic WordPress hack using the vulnerability scanner on certain user's directory of ".../wp-content/uploads", which was set with the unrecommended UNIX permission on some layer of services by the users. The service was using FreeBSD with the Linux binaries compatibility environment installed, and the tools used for this attack is meant to aim the both platforms.

The attack was successfully exploiting the shell and the attacker was compromising the server's wordpress related user's privilege by injecting the WSO shell and through it we have some malicious PHP scripts which the attacker was using it to perform attack to other services, dropping malicious binaries and implementing the "patch" to the system using the LD_PRELOAD scheme to execute the malicious binary as the backdoor to some services.

I was lucky can perform the overall analysis for this incident and this is the share of what was investigated in a chronological basis which hoping the information can be used for prevention and mitigation for the further attacks. All of the holes was covered, incident was mitigated and followed well and now I can write (with permission) for a share.

A flash Update1: Recent Analysis of Incident between July 25 to August 5th 2014 is compiled in Kernel Mode posts

Recent #ELF #Mayhem analysis: http://t.co/vmmaMhT1UA http://t.co/4B5ezPZDe2 http://t.co/1p6wIgkgy8 http://t.co/qwBAdFPTDE #MalwareMustDie

— (@unixfreaxjp) August 6, 2014

A flash Update2: Video PoC & global infection data of the ELF .so malware (libworker.so) infection is disclosed, please help to block & clean these!

Answering some requests about this post due to the threat, I was asked to hint a how-to detect the global wordpress sites infected by this malware. The good news: It is searchable. Bad news is: Tons of them now.

So I made the video of based on list on the CURRENT infected sites we detected so far (is not all infection, you can help to add the list). Below is the video:

The infected sites list is here-->>[MMD Pastebin] and the "recent" libworker.so downloadable URL list is here -->>[MMD Pastebin] < There are a lot more of these, and mostly the installer of malware library are dated from March 2014. The clean up also operations are in progress too, please bear for the 404 that might occur in some sites. You can use the list as the hint to detect the rest of infection in world wide web.

View of many infection URL in global sites as evidence:

#Block these URL for having ELF .so library #malware pls (pic) Text: http://t.co/zMiBuFWdJB #MalwareMustDie! @_MDL_ pic.twitter.com/gHRAez90Wx

— MalwareMustDie, NPO (@MalwareMustDie) May 10, 2014

The malware and its components (PHP script for dropper. installer and companion malicious scripts) were uploaded from remote via WSO PHP Shell. In all infected cases I found the WSO up and alive, WSO shell script is obfuscated under camouflaged common PHP filename so is a bit hard to spot which one, below is the video PoC of this statement:

Please check your perimeter & territorial CMS sites/server for the cleaning purpose. Refer to the analysis below:

The Compromised Wordpress

The version is recent, I was expecting older version but it is not the case, and I confirmed it myself. Since I am not using wordpress even though handling many incident of WordPress hacks, I am actually still wondering why it has the permission #777 on "wp-content/uploads" directory which was suspected to be the only "gate" for the attack to get in. Maybe is the user settings? I just can't be sure..

Anyway, using the same methodology to search for the injected codes in WordPress as per described in here -->[ 1 ] [ 2 ] and the malicious files injected were fetched successfully as per below snapshot:

Some "accompanied" malicious injected codes

Based on the attack log, history and time stamped we know that the checkandall.php is the first file injected into the system, and contains the below code:

Obviously this is the script file used by the attacker to check the overall environment of the entered directory and its files after compromising, the value of $all_files will be the contents parsed in an array, as per shown in below illustration:

The next files are the point of this post, the nextstyles.php, oldstyle.php and stylered.php, which are files coded with a one-liner PHP obfuscation in eval/gzuncompress/base64 php code as per illustrated below:

A quick decoding will reveal the actual code, which is a WSO shell, as I pasted in pastebin here-->[decoded]
Dealing with WSO hack case, three points that you should know for reporting the incident are, the version, password and how you can successfully access it by understanding the condition needed to access this web-shell "hack" tool. All are summarized as per illustration below:

Understanding these points will make you and the handler guy to know what step to do next.
In additional, the below illustration are the most function that WSO being used for scanning for vulnerable service:

The other file, which was actually was last injected, is the rss-info.php an obfuscated PHP script with the snapshot below:

This script was beautified with the note in here -->[pastebin], and decoded by our friends (Denis of SucuriLabs and @jseidl in--> [here] and [here] which is an attack script with acessing URL: counterstar .ws / c / counter .php which is a rotator to perform the active redirection (TDS) to some un-welcomed sites like one of the snapshot below:

The rotator script is currently active and is worth to takedown. Additionally, I really do took time to silently monitor this rotator to get the any chance for the malware redirection or infection through it, but somehow the result still negative for an infection, they're lucky.

So now we know how they scan for directory and using the WSO for the remote access, using some malicious purpose on implementing redirection to a rotator site. Up to this point we can assume that the attacker can upload any script files with code to be remotely executed under the WordPress privileges, and that was the timing where the attacker uploaded the function_php.php and tempstyle.php, which are the point of this blog.

LD_PRELOAD - An introduction & PoC

I assume if you know and mostly you are using Linux, yes? Then you are familiar with the command of LD_PRELOAD, no? Below is the explanation about LD_PRELOAD for they who want to know:

One could override the C standard library's functions used in Linux (such as printf, fopen, open, rand, etc) with your own version of these functions, with or without calling the real library's functions after executing the overrided function.

Since the attack for this vector is already in the wild since March 2014 and many got hit by this threat too, I think it is important to disclose the fact of the threat for mitigating further. For the easy example I roughly typed the PoC in C code for "faking" or "infecting" an original UNIX fopen() command that can be "override" with one's coded program, but also to "intercept" it by executing a malicious codes (or program) before calling the original fopen():

It's not not a new stuff & most of unixmen shold know this fact.That "#define _GNU_SORCE" directive instructs compiler to enable non-standard calls, in this case I need the RTLD_NEXT (at dlfcn.h) to be enabled to call the original version of "fopen()" calls.

If the code above is saved and compiled as a shared library like below command

gcc -Wall -fPIC -shared -o evilfopen.so evilfopen.c -ldl

The result of the C code above is we compiled a shared library (evilfopen.so) that can be used to intercept the fopen() with our own (fakes) code added with some malicious actions and then forcing the execution back to the original fopen(). The "evilfopen.so" can't be self-executed and need to be loaded to the provided enviromental API to intercept and to override, and the command for that is LD_PRELOAD. So, with the simple command line like below:

export LD_PRELOAD=$PATH/evilfopen.so

..the LD_PRELOAD command above will trigger "evilfopen.so" to intercept the fopen() (or other any function..depends on the attacker needs) to perform the malicious act, with or without executing the real function afterward.
And this is actually exactly what had happened in this case, a malicious shared library dynamic ".SO" ELF shared library was dropped, installed & "LD_PRELOAD executed" to the targeted system to perform malicious action without the trace of its installation, which it may causing some headache.

What happened is: The LD_PRELOAD forces a defined libraries to be loaded for a program (library in our case) even if the program/binary itself does not ask for it. FYI, it is not a security flaw, since this scheme will work under one condition that if and only if ruid == euid (Real and Effective user ID), or, it is secured by the fact that the loader (ld.so) will ignore LD_PRELOAD if ruid != euid . In English: the only possibility to execute this attack is the gaining access of the shell with the existing user ID during the execution.

The installation of LD_PRELOAD "libworker.so" malware spotted

The latest version installer

The installation roles are executed by the files function_php.php and tempstyle.php which are identically coded with the malicious code as per below full code snapshot:

In the line 18 and 19 there are two variables contains big blob of the hexbin strings like below which is actually malware files, so I took a liberty to cut it for the explanation purpose:

The explanation is as per follows:

Preparing the file_put_contents function to be used to inject hexbins..

This command will kill the host binary if it runs..

Hexbin in text strings for the 32bit ($so32) and 64bit ($so64) malware library SO files..

Checking whether the system is 32bit or 64bit architecture and assigning the $so variables to the blob hexbins string mentioned above (noted, the default is x64)..

How this malware script detecting the OS with reading the byte structure of /usr/bin/host binary:

And injecting the picked up hexbins to the file ./libworker.so

If the file extracted well, in my case it will show below output:

STDOUT;
SO dumped 26848  .... for x32
SO dumped 27288  .... for x64

The malware script detecting whether Mayhem (my favorite, kudos!) tools installed, if so it will quit here.. (read: chicken out), noted: be sure to run the tool under diferent environment settings :-)

Now, it's assigning remote requested URI to this evil script file($AU),
initiating of the "host" binary name ($HBN) and current path ($SCP)

This is the very important part, the assembly of evil shell script file "1.sh" for the initiation of the evil library files dropped in previous process:

The self-generated script is below, with my comments for explanation:

The below codes are to make the script above to be injected into 1.sh file and make it full access with the world's executable privilege:

The below part of codes are explaining how the 1.sh is executed. It uses three ways to execute, by "at now" and "crontab" (with deleting its execution traces in at or crontab afterward) and additionally using common direct execution using "@system" PHP command, Noted: the comment was made by malware coder, not me.
You will see how persistent the attacker in making sure the installation gone well..

Additional: The older version installer of malware shared library (libworker.so)

I was reported the older version installation script of the same attack series of libworker.so with LD_CONFIG, by using the different PHP installer, without using any 1.sh executable shell script. The overall "older" installer script itself can be viewed as per snapshot below:

The difference between the older version to the recent one is, it has many /* DEBUG */ comments which was written by the bad actor, and it has the additional that is having more functions, like autorun and FreeBSD ldd patch. The rest of the functions are similar to the recent codes in the "latest installer" section above. Below, I will explain these two differences with the arranged snippet code to make it more understandable:

Firstly, for FreeBSD system it added the "$extra" command parameter before executing the libworker.so in LD_PRELOAD. This can be assumed that the attacker want to make sure that the ELF shared library can be executed even in the FreeBSD servers.

The second difference is, the older version makes "autorun" scheme by injecting a command to itself in the rc.local, that can be implemented in both Linux and FreeBSD system. The snippet codes below is self explanatory:

Binary extracting sample scripts for IR & research purpose

For the Incident Handing folks of this threat, you can utilized the malware installer script to get as many .SO sample to extract to be submitted to Virus Total, below is the lazy script I assemble in PHP that fit to the purpose:

if (! function_exists('file_put_contents')) {
 function file_put_contents($filename, $data) {
  $f = @fopen($filename, 'w');
  if (! $f)
   return false;
  $bytes = fwrite($f, $data);
  fclose($f);
  return $bytes;
 }
}
$so32 = "\x7f\x45..."
$so64 = "\x7f\x45..."
$mo32 = "\x7f\x45..."
$mo64 = "\x7f\x45..."
$no32 = "\x7f\x45..."
$no64 = "\x7f\x45..."

$so = $so32;
print "SO x32 dumped ".file_put_contents("./sample1-32.so", $so)."\n";
$so = $so64;
print "SO x64 dumped ".file_put_contents("./sample1-64.so", $so)."\n";
$so = $mo32;
print "MO x32 dumped ".file_put_contents("./sample2-32.so", $so)."\n";
$so = $mo64;
print "MO x64 dumped ".file_put_contents("./sample2-64.so", $so)."\n";
$so = $no32;
print "NO x32 dumped ".file_put_contents("./sample3-32.so", $so)."\n";
$so = $no64;
print "NO x64 dumped ".file_put_contents("./sample3-64.so", $so)."\n";
?>

↑Please put the hexbin blobs from the $so32 or $so64 variables in malware installer PHP script into above template's $so*/$mo*/$no* accordingly and run it to get the extracted malware library sample files. The shell output in my case is as follows:

$ php sodump.php

X-Powered-By: PHP/x.x.x

SO x32 dumped 26848
SO x64 dumped 27288
MO x32 dumped 26848
MO x64 dumped 27288
NO x32 dumped 26848
NO x64 dumped 27288

$ ls -alF sample*

-rw-r--r--   1 mmd   mmd 26848 May  8 21:57 sample1-32.so
-rw-r--r--   1 mmd   mmd 27288 May  8 21:57 sample1-64.so
-rw-r--r--   1 mmd   mmd 26848 May  8 21:57 sample2-32.so
-rw-r--r--   1 mmd   mmd 27288 May  8 21:57 sample2-64.so
-rw-r--r--   1 mmd   mmd 26848 May  8 21:57 sample3-32.so
-rw-r--r--   1 mmd   mmd 27288 May  8 21:57 sample3-64.so 

That's it for the installation, what do you think of this threat so far? :-) Hold the thoughts and let's go to the "hexed" part..

Binary Analysis and Reversing

I will take x32 malware libs to analyze this malware shared lib binary.
It is a statically linked shared library SO format binary. Below is the information:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, "little endian"
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              "DYN (Shared object file)"
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0xd54
  Start of program headers:          52 (bytes into file)
  Start of section headers:          26952 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         15
  Section header string table index: 12
"Noted:"
"Error: Unable to read in 0x258 bytes of section headers"

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x060f0 0x060f0 R E 0x1000
  LOAD           0x0060f0 0x000070f0 0x000070f0 0x007f0 0x061ac RW  0x1000
  DYNAMIC        0x0060f0 0x000070f0 0x000070f0 0x00090 0x00090 RW  0x4

Dynamic section at offset 0x60f0 contains 14 entries:
  Tag        Type                         Name/Value
 0x00000004 (HASH)                       0x94
 0x00000005 (STRTAB)                     0x5e0
 0x00000006 (SYMTAB)                     0x220
 0x0000000a (STRSZ)                      457 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x7180
 0x00000002 (PLTRELSZ)                   472 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x7bc
 0x00000011 (REL)                        0x7ac
 0x00000012 (RELSZ)                      16 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   2
 0x00000000 (NULL)                       0x0

Histogram for bucket list length (total of 37 buckets):
 Length  Number     % of total  Coverage
      0  8          ( 21.6%)
      1  13         ( 35.1%)     22.0%
      2  7          ( 18.9%)     45.8%
      3  6          ( 16.2%)     76.3%
      4  2          (  5.4%)     89.8%
      5  0          (  0.0%)     89.8%
      6  1          (  2.7%)    100.0%

↑So few data, and my ELF reader meets another error too during analysis:

Error: Unable to read in 0x28 bytes of section headers. 

Don't worry about this since the "malform" of the stripped binary itself is causing these annoying error messages. The malcoder (I can't stand it.. read:moronz) surely know how to strip clean a Linux binary.

Some notes in reversing: The binary is obfuscated divided in a row of dd calls like in below address (or section..or etc the name is..):

LOAD:000071A8 off_71A8        dd offset sub_A1A
LOAD:000071AC off_71AC        dd offset sub_A2A
LOAD:000071B0 off_71B0        dd offset sub_A3A
LOAD:000071B4 off_71B4        dd offset sub_A4A
LOAD:000071B8 off_71B8        dd offset sub_A5A
[...]
LOAD:00007260 off_7260        dd offset sub_CFA
LOAD:00007264 off_7264        dd offset sub_D0A
LOAD:00007268 off_7268        dd offset sub_D1A
LOAD:0000726C off_726C        dd offset sub_D2A
LOAD:00007270 off_7270        dd offset sub_D3A
LOAD:00007274 off_7274        dd offset sub_D4A

..longing for the separated looong series of subroutines named in sub_XXX, like below, which we have to merge it one by one to know what the full code says. Snipped:

LOAD:000009B4 ; =============== S U B R O U T I N E =======================================
LOAD:000009B4 sub_9B4         proc near               ; CODE XREF: sub_48FC+4B
LOAD:000009B4                                         ; sub_5A70+30D
LOAD:000009B4                 jmp     dword ptr [ebx+10h]
LOAD:000009B4 sub_9B4         endp
LOAD:000009BA ; ===========================================================================
LOAD:000009BA                 push    8
LOAD:000009BF                 jmp     loc_994
LOAD:000009C4 ; =============== S U B R O U T I N E =======================================
LOAD:000009C4 sub_9C4         proc near               ; CODE XREF: sub_5A70+2E2
LOAD:000009C4                 jmp     ds:off_14[ebx]
LOAD:000009C4 sub_9C4         endp
LOAD:000009CA ; ===========================================================================
   [...]
LOAD:00000D44 ; =============== S U B R O U T I N E =======================================
LOAD:00000D44 sub_D44         proc near               ; CODE XREF: sub_5A70+256
LOAD:00000D44                 jmp     dword ptr [ebx+0F4h]
LOAD:00000D44 sub_D44         endp
LOAD:00000D4A ; =============== S U B R O U T I N E =======================================
LOAD:00000D4A sub_D4A         proc near               ; DATA XREF: LOAD:off_7274
LOAD:00000D4A                 push    1D0h
LOAD:00000D4F                 jmp     loc_994
LOAD:00000D4F sub_D4A         endp [...] 

The data used for operations are in (1) encoded ones starts from here...

LOAD:00007288                 db  95h ; ・
LOAD:00007289                 db 0E6h ; ・
LOAD:0000728A                 db 0BEh ; ｾ
LOAD:0000728B                 db  2Ah ; *
LOAD:0000728C                 db  9Eh ; ・
LOAD:0000728D                 db  6Bh ; k
 [...] and so on...

And onto the plain ones, started from this address..

LOAD:000077A0                 db  72h ; r
LOAD:000077A1                 db    0
LOAD:000077A2                 db  2Fh ; /
LOAD:000077A3                 db  25h ; %
LOAD:000077A4                 db  73h ; s
LOAD:000077A5                 db  0Ah
 [...] and so on...

And this is the Segment type: "Externs" contains the NIX's C system calls to be used for the malicious purpose. Too bad they won't (maybe just can't..) encrypt it. The data is as per below list. It is important to write these all for the reference of behavior analysis part:

extern:D29C ; extern
extern:D29C                 extrn chroot
extern:D2A0 ; char *strcpy(char *,const char *)
extern:D2A0                 extrn strcpy
extern:D2A4                 extrn unsetenv
extern:D2A8 ; FILE *popen(const char *,const char *)
extern:D2A8                 extrn popen
extern:D2AC ; int connect(int,const struct sockaddr *,int)
extern:D2AC                 extrn connect
extern:D2B0 ; int pthread_create(pthread_t *thread,const pthread_attr_t *attr,void *(*function)(void *),void *arg)
extern:D2B0                 extrn pthread_create
extern:D2B4 ; uid_t geteuid(void)
extern:D2B4                 extrn geteuid
extern:D2B8 ; int munmap(caddr_t addr,size_t len)
extern:D2B8                 extrn munmap
extern:D2BC ; char *getenv(const char *string)
extern:D2BC                 extrn getenv
extern:D2C0                 extrn usleep
extern:D2C4 ; pid_t getpid(void)
extern:D2C4                 extrn getpid
extern:D2C8 ; char *fgets(char *,int,FILE *)
extern:D2C8                 extrn fgets
extern:D2CC ; int execl(const char *path,const char *argv0,...)
extern:D2CC                 extrn execl
extern:D2D0 ; void *malloc(size_t size)
extern:D2D0                 extrn malloc
extern:D2D4 ; unsigned int sleep(unsigned int seconds)
extern:D2D4                 extrn sleep
extern:D2D8 ; int vsnprintf(char *,size_t,const char *,char *)
extern:D2D8                 extrn vsnprintf
extern:D2DC ; int socket(int family,int type,int protocol)
extern:D2DC                 extrn socket
extern:D2E0                 extrn ftruncate
extern:D2E4                 extrn dladdr
extern:D2E8                 extrn realpath
extern:D2EC ; off_t lseek(int fildes,off_t offset,int whence)
extern:D2EC                 extrn lseek
extern:D2F0 ; caddr_t mmap(caddr_t addr,size_t len,int prot,int flags,int fd,off_t off)
extern:D2F0                 extrn mmap
extern:D2F4 ; int dlclose(void *)
extern:D2F4                 extrn dlclose
extern:D2F8                 extrn freeaddrinfo
extern:D2FC ; int write(int fildes,const void *buf,size_t nbyte)
extern:D2FC                 extrn write
extern:D300 ; char *strcat(char *,const char *)
extern:D300                 extrn strcat
extern:D304 ; int setsockopt(int s,int level,int optname,const void *optval,int optlen)
extern:D304                 extrn setsockopt
extern:D308 ; pid_t wait(int *)
extern:D308                 extrn wait
extern:D30C ; mode_t umask(mode_t mask)
extern:D30C                 extrn umask
extern:D310 ; char *strstr(const char *,const char *)
extern:D310                 extrn strstr
extern:D314 ; _sig_func_ptr signal(int,_sig_func_ptr)
extern:D314                 extrn signal
extern:D318 ; int read(int fildes,void *buf,size_t nbyte)
extern:D318                 extrn read
extern:D31C ; int strncmp(const char *,const char *,size_t)
extern:D31C                 extrn strncmp
extern:D320 ; void *dlopen(const char *,int)
extern:D320                 extrn dlopen
extern:D324 ; int unlink(const char *path)
extern:D324                 extrn unlink
extern:D328 ; void *realloc(void *r,size_t size)
extern:D328                 extrn realloc
extern:D32C ; pid_t fork(void)
extern:D32C                 extrn fork
extern:D330 ; void *dlsym(void *,const char *)
extern:D330                 extrn dlsym
extern:D334 ; char *strdup(const char *)
extern:D334                 extrn strdup
extern:D338 ; int gettimeofday(struct timeval *p,struct timezone *z)
extern:D338                 extrn gettimeofday
extern:D33C ; int fclose(FILE *)
extern:D33C                 extrn fclose
extern:D340 ; time_t time(time_t *timer)
extern:D340                 extrn time
extern:D344 ; int strcmp(const char *,const char *)
extern:D344                 extrn strcmp
extern:D348 ; int pthread_mutex_unlock(pthread_mutex_t *mutext)
extern:D348                 extrn pthread_mutex_unlock
extern:D34C ; int sprintf(char *,const char *,...)
extern:D34C                 extrn sprintf
extern:D350                 extrn srandom
extern:D354                 extrn getaddrinfo
extern:D358 ; int pthread_mutex_lock(pthread_mutex_t *mutext)
extern:D358                 extrn pthread_mutex_lock
extern:D35C                 extrn __errno_location
extern:D360 ; int atoi(const char *nptr)
extern:D360                 extrn atoi
extern:D364 ; void exit(int status)
extern:D364                 extrn _exit
extern:D368 ; int open(const char *,int,...)
extern:D368                 extrn open
extern:D36C ; char *strchr(const char *,int)
extern:D36C                 extrn strchr
extern:D370 ; pid_t setsid(void)
extern:D370                 extrn setsid
extern:D374 ; int pthread_join(pthread_t thread,void **value_ptr)
extern:D374                 extrn pthread_join
extern:D378 ; int close(int fildes)
extern:D378                 extrn close
extern:D37C ; void free(void *)
extern:D37C                 extrn free
extern:D380 ; int getsockname(int,struct sockaddr *addr,int *)
extern:D380                 extrn getsockname 

Later on proven by the behavior analysis, but the execution of this malicious library SO file will perform the backdoor operation, which forming the local information as contents to be sent to remote host using the template with some possibility contents, the initial callback (flagged as "R") and re-send (flagged as "P") has different contents, so does the fail confition (flagged as "F"). Additionally: researchers who in daily basis deal with botnets may understand this flagging scheme as the standard callbacks to a CNC or gates, and that knowhow help me a lot in reversing it:

LOAD:000077AD 00000009 F,%s,%x\n
LOAD:000077B6 00000013 R,%d,%d,%d,%s,%s,\n
LOAD:000077C9 00000012 P,%u,%u,%u,%u,%u\n                                                                

The variables itself contains the information of:

Uptime date, Architecture of the host, user and "uname -a" data

Which unit of information is to be called via command line of:

/usr/bin/uname -a // recorded at: LOAD:000078B8 00000012

while other grabbed by the NIX's C function listed above. And sending the POST HTTP/1.0 to a specific host with the specific header with the template formatted as per below:

// partial:
POST %s HTTP/1.0
Host: %s
Pragma: 1337
Content-Length: %d

Template assembled:

POST %s HTTP/1.0\r\nHost: %s\r\nPragma: 1337\r\nContent-Length: %d\r\n\r\n%s

Below is the hex binary snips that is useful for confirming these malware:

67D0   2C 25 75 2C 25 75 2C 25 75 0A 00 50 4F 53 54 20    ,%u,%u,%u..POST
67E0   25 73 20 48 54 54 50 2F 31 2E 30 0D 0A 48 6F 73    %s HTTP/1.0..Hos
67F0   74 3A 20 25 73 0D 0A 50 72 61 67 6D 61 3A 20 31    t: %s..Pragma: 1
6800   33 33 37 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E    337..Content-Len
6810   67 74 68 3A 20 25 64 0D 0A 0D 0A                   gth: %d....

PS: For the complete reversed libworker.so in disassembler format (using IDA Free with thank you to HexRays!) access here-->[MediaFire]

There are more on the deobfuscated assembly code like deletion routines, call itself with the external LD_PRELOAD (oh..not again?! why?). Networking operations, and so on.. The more details in the next section will describe the reason for all of those operation and proving the callback operation explained in above writing too..

Behaviour Analysis

UPDATES! The Video Tutorial of the behavior analysis is released here -->>[link]

Since the subject is the shared object (DYN) library, is a bit different to analyze than a static/dynamic executables or modular binary loaded by an application like web/ssh/etc server or etc, but this is the beauty of UNIX/Linux OS, all are transparent and only by using the standard UNIX debug environment anyone will be more than enough to recognize and stop this infection processes, which I will simulate in steps in this section.

For the details, after some tests I can summarize the execution of the evil binary is as per below:

- self-executing LD_PRELOAD on himself upon matched NIX function defined - forking (clone) some child processes - self-deletion after executing the POST data - dump the core to the memory and disk (I don't know why),in the disk after execution there will be .sd0 file saved. - leaving the trace in list of files (lsof) - leaving the LD_PRELOAD unset after infection (you'll see some LD_PRELOAD ERROR on libworker.so in "env" or "lsof" or "ps" since the "buggy" of the DYN libs malware for not including call to the "unset" code in the exit routine. :-) - sending callback contains user & system sensitive information to specific mothership URL via POST HTTP/1.0

The loading method is as per follows (as per script installer does):

$ export LD_PRELOAD=./libworker.so

You can check whether this libs is loaded by:

$ env
[...]
LD_PRELOAD=./libworker.so

What happened during running the /usr/bin/host?? It is good to know whether this evil libs is really loaded during execution. The below code is the debug mode of the loading process of libworker.so executed during the execution of /usr/bin/host. You can see that libworker.so was loaded in read only mode. The bits and size of the evil library, size=27,288 is showing it too. So it is being called preloaded.

$ host -ta google.com

// debug output:
execve("/usr/bin/host", ["host", "-ta", "google.com"], [/* 18 vars */]) = 0
brk(0)                                  = 0x7fbf095f8000
open("./libworker.so", O_RDONLY)        = 3
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0x\23\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=27288, ...}) = 0
getcwd("$PWD", 128)       = 19
[...]

I run lsof & grep rapidly monitorng the libworker.so, they look like also affecting trigger of malicious libs, so "by accident" it was forked as per below.. the size and memory allocated flag is a PoC of loading :-)

$ lsof | grep libworker
COMMAND   PID   TID  USER  FD     TYPE  DEVICE SIZE/OFF       NODE NAME
host      32351      xxx   mem    REG   9,2    27288   29753475 $PWD/libworker.so
lsof      32339      xxx   mem    REG   9,2    27288   29753475 $PWD/libworker.so
grep      32517      xxx   mem    REG   9,2    27288   29753475 $PWD/libworker.so

Breaking the myth (smile), below I lsof'ed the self forked process (32517) of this evil libs triggered by the "grep" command. I have my own reason since "grep" is using not so much shared libs during execution, it is good for the comparison & seeking of malicious calls or libs used by the evil library. Please see it carefully, I am in purpose grouping the output data:

$ lsof -p 32517
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
grep    32517  xxx  cwd    DIR    9,2     4096 29753382 $PWD
grep    32517  xxx  rtd    DIR    9,2     4096        2 /
grep    32517  xxx  txt    REG    9,2   175488 23330835 /bin/grep
grep    32517  xxx  mem    REG    9,2 12582912 29753480 $PWD/.sd0
grep    32517  xxx  DEL    REG    9,2          29753475 $PWD/libworker.so

grep    32517  xxx  mem    REG    9,2    80712 38800333 /lib/x86_64-linux-gnu/libresolv-2.13.so
grep    32517  xxx  mem    REG    9,2    22928 38800338 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
grep    32517  xxx  mem    REG    9,2    47616 38800348 /lib/x86_64-linux-gnu/libnss_files-2.13.so

grep    32517  xxx  mem    REG    9,2  1599504 38800331 /lib/x86_64-linux-gnu/libc-2.13.so
grep    32517  xxx  mem    REG    9,2    14768 38800346 /lib/x86_64-linux-gnu/libdl-2.13.so
grep    32517  xxx  mem    REG    9,2   136936 38800354 /lib/x86_64-linux-gnu/ld-2.13.so
grep    32517  xxx    0r   CHR    1,3      0t0     1027 /dev/null
grep    32517  xxx    1r   CHR    1,3      0t0     1027 /dev/null
grep    32517  xxx    2r   CHR    1,3      0t0     1027 /dev/null
grep    32517  xxx    3r   CHR    1,3      0t0     1027 /dev/null

Below is the original "uninfected" grep command itself in lsof, please seek for the difference the output below with the lsof result above, and you will see that libresolv-2.13.so, libnss_dns-2.13.so and libnss_files-2.13.so are loaded for the malicious purpose, which I don't think is needed in "grep" o.O? And so does the above's pts terminal socket which was replaced by the malware from "/dev/pts/x" into "/dev/null".. doh..I bet those malcoders think this can hide the mess they made from NIX admin's eyes..

$ grep a &
[3] 25991
$ lsof -p 25991
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
grep    25991  xxx  cwd    DIR    9,2     4096 29753382 $PWD
grep    25991  xxx  rtd    DIR    9,2     4096        2 /
grep    25991  xxx  txt    REG    9,2   175488 23330835 /bin/grep
grep    25991  xxx  mem    REG    9,2  1599504 38800331 /lib/x86_64-linux-gnu/libc-2.13.so
grep    25991  xxx  mem    REG    9,2    14768 38800346 /lib/x86_64-linux-gnu/libdl-2.13.so
grep    25991  xxx  mem    REG    9,2   136936 38800354 /lib/x86_64-linux-gnu/ld-2.13.so
grep    25991  xxx    0u   CHR  136,9      0t0       12 /dev/pts/9
grep    25991  xxx    1u   CHR  136,9      0t0       12 /dev/pts/9
grep    25991  xxx    2u   CHR  136,9      0t0       12 /dev/pts/9

This is the trace of the DELETION (executed by the unlink command in the malcode) already executed against the malware library file itself (libworker.so) in lsof. At "this" point the self-deletion was occured, to check it again , see the DEL in "type" column..

$ lsof | grep libwork
COMMAND   PID   TID  USER  FD     TYPE  DEVICE SIZE/OFF       NODE NAME
grep      32517      xxx   mem    DEL   9,2    27288   29753475 $PWD/libworker.so

You can "ldd" the binary that having function to trigger the malware libs, but in this malware program you can use it only one time and then you'll get this error:

/bin/uname: symbol lookup error: $PWD/libworker.so: undefined symbol: dladdr
ERROR: ld.so: object '$PWD/libworker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '$PWD/libworker.so' from LD_PRELOAD cannot be preloaded: ignored.
   [same contents as above... ]
ERROR: ld.so: object '$PWD/libworker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '$PWD/libworker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '$PWD/libworker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '$PWD/libworker.so' from LD_PRELOAD cannot be preloaded: ignored.

Yes, the libs was deleted, but the LD_CONFIG only being unset one time in the installation script, nevertheless the libworker.so was self-executing the fork of itself by LD_CONFIG'ing which explains the above errors.

The rest of malicious operation performed:

After being loaded as per traced in debug code above. Malware library executed itself after the original binary runs, I patched the debug trace during it runs with my comments as per follows:

Querying the time..

time(NULL) = 1399591316

Trace the path of the library SO file:

lstat("/MYPATH", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/MYPATH/MYPATH", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/MYPATH/MYPATH/MYPATH", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/MYPATH/MYPATH/MYPATH/libworker.so", {st_mode=S_IFREG|0755, st_size=27288, ...}) = 0

Change the directory to the same as malware libs:

getcwd("/MYPATH/MYPATH/MYPATH", 4096)= 19

Creating temporary file 1.12564 and write the contents ELF executable:

open("/MYPATH/MYPATH/MYPATH/1.12564", O_WRONLY|O_CREAT|O_TRUNC, 0777) = 6
write(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0`\200\4\0104\0\0\0"...,106) = 106
close(6) = 0

Self created its child process and pause to give time new process started & executed, then stop the child process:

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f077d6c89f0) = 12600
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 99}], 0, NULL) = 12600
--- SIGCHLD (Child exited) @ 0 (0) ---

Deleting 1.12564 file:

unlink("/MYPATH/MYPATH/MYPATH/1.12564")    = 0

Making a DNS query to hard coded Google DNS IP (8.8.8.8):

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
getsockname(6, {sa_family=AF_INET, sin_port=htons(38502), sin_addr=inet_addr("MY-IP-ADDRESS")}, [16]) = 0

After creating more new child process, initiating the pipes, it grabbed the current user name and system name for the callback purpose. Yes, I know that I let this moronz know that we're on him..:

pipe2([7, 8], O_CLOEXEC)                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f077d6c89f0) = 12604
[...]
"geteuid() = 0"
read(7, "MYSYSTEM xxxx.malwaremustdie.org"..., 4096) = 87
close(7) [...]

At this point the network socket is created and we can see the network traffic as result in network analysis. Then this new child process was killed too:

close(7)                                = 0
wait4(12604, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 12604
--- SIGCHLD (Child exited) @ 0 (0) ---

And then it self-delete the malware lib module & saved the dump data into file .sd0 after deleting prev one if exist.

unlink("/MYPATH/MYPATH/MYPATH/libworker.so") = 0
open(".sd0", O_RDWR) = -1 ENOENT (No such file or directory)
unlink(".sd0")  = -1 ENOENT (No such file or directory)
open(".sd0", O_RDWR|O_CREAT|O_TRUNC, 0666) = 7
ftruncate(7, "12582912")                  = 0
mmap(NULL, "12582912", PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0x7f07777c0000

It is executed as the patch, with dirty way to exit makes the traces in list of files:

rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f077b8304f0}, {SIG_IGN, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7f077bb98030}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_IGN, [CHLD], SA_RESTORER|SA_RESTART, 0x7f077b8304f0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTSTP, {0x7f077d4200c2, [TSTP], SA_RESTORER|SA_RESTART, 0x7f077b8304f0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x7f077d4200c2, [INT], SA_RESTORER|SA_RESTART, 0x7f077b8304f0}, {0x7f077c1df950, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7f077bb98030}, 8) = 0
rt_sigaction(SIGTTOU, {SIG_IGN, [TTOU], SA_RESTORER|SA_RESTART, 0x7f077b8304f0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTTIN, {SIG_IGN, [TTIN], SA_RESTORER|SA_RESTART, 0x7f077b8304f0}, {SIG_DFL, [], 0}, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f077d6c89f0) = 12736
exit_group(0)

There you go :-) I think you'll get a bit more idea by the above explanation about the malicious activities conducted. So let's see the PoC of those reversing and behavior analysis in its sent traffic :-). Let's move forward to networking parts!

Network Analysis

Either by reversing or network analysis, you will get the exact same values from one sample. Since this malware was hard-coded to have only static value per binary. For the best of all, let's capture the traffic gained by one malware, let's make sure whether this mess is really making a callback or not..Then I'll use one other sample to compare the result.

The first call, like we always face in the botnet cases, is very important and many initiation can be made, so I was very careful not to online the sample in the new environment until everything settled up. Everything? I mean you have the tcpdump, and you're good to go. You can capture this outside or inside the box (none of my analysis ever using inside the box traffic recording except for some testing though, my highly recommended: always discipline yourself to trap outside of the box)

..and this is the first call looks like:

Yes I test-installed this malware in some systems Linux and BSD in various versions, I have a lot of traffic like:

Only initial calls will get the flag R during the sent of the data, and the rest will be P flag like this:

Sometimes the malware itself got deleted during the operation by other fork.. so you'll see some "incomplete" traffic like this:

By testing the different sample I got the different traffic that goes to the same remote host in the different URL as per below:

As per expected, each dropped SO library file is hard coded the specific CNC callback url :-)

I've mentioned in the installer part, there was an older version. That version was making a different CNC callback that can be shown in the below PCAP snapshot:
The url is aiming a rotator script implemented in another hacked sites that can be used for many evil purposes.., and for your information the rotator is till UP.

In the infection that (still) occured recently (May 27th, 2014) we saw the attacker came from the OVH, France IP as per described in details in here-->[link]. Below is the callback image snapshot:

How to spot and stop the on-going infection?

I think I missed this part, so I added this now:

This malware, during the infection will make the dump data saved in the hard drive on the installed/executed directory with the file name of .sd0 , you can find with grep ".sd0" to your CMS directories to check whether your system is infected or not. There are cases where the hacked WordPress directory dropped by the malware .SO library (libworker.so) and not being executed, in this case there will be no ".sd0" file, instead you may can find the LD_PRELOAD installer script file of "1.sh" in compromised path. So searching for "1.sh" in the assumed compromised WordPress or etc CMS environment is good deed. Additionally, you can search for the "libworker.so" or "1.sh" by Google (Dork) since they are all accessible. Please see the video posted in the top of this post for the demonstration PoC for searching/confirming an infection from the remote using by a text editor and browser.

Below is the snapshot PoC of the searchable infection via Google search:

You can seek using (or make a signatre for this ELF malware .SO library) by these strings:

To dissect this running malware in a compromised server, you must find the installer script first, to find which library filename it will be executed. The name of the library will be made as lame as possible to fool us. Like in this case is as per below pic:

If you find the installer PHP file, please remove it right away since that can be executed from the remote in anytime and will disturb the further cleaning processes.Together you can "secure" the other garbage that was being injected.

If you know the malware library name form the installer PHP file/script (i.e. libworker.so), then the rest is easier, just execute the below command:

$ lsof | grep 'libworker'

↑this should leaving you the PID of the processes that are utilized to execute the malware DYN library. You can kill (kill -9) that process' PID after beforehand making sure there are no vital services affected, to kill its "main malicious modules. You can do this after (or before) you check the enviromental setting in your box (env), and see whether the LD_PRELOAD is there or not, with or without error IF LD_PRELOAD is there execute the below command:

$ unset LD_PRELOAD

- right away, and repeat it again if you need to make sure no LD_PRELOAD exists in environmental variable anymore. Yes, by unsetting LD_PRELOAD and killing the affected PID will stop the overall malicious process respectively, so please DO NOT ever think to reboot the system with hope cleaning things up. :-))

A note for .sd0 "drops" file

Some people will think that the .sd0 file is malware drops or component of the malware, in my observation it is not it, is the garbage of malware dumped data, likely is in the coredump forms. When the malware .SO library is running, the .sd0 dump will fill the memory and the hard drive, it some systems I found the CPU resource was used because of this.

In some systems I investigated I found some .sd0 dropped in the directory where the malware .SO library was executed. In some systems I found some multiple execution of the .SO library malware files so I found more than one .sd0 files too. These .sd0 file' size is getting bigger each days, the biggest one I found was 16GB in size :-), so you don't want these files, if you find it please delete it. The good thing is this malware library (at the current version) always drops .sd0 files, so find this file if you want to be sure your system is infected or not infected.

Bad actor's CNC server:

All of the traffic lead to the IP address of 37.59.5.67 with sending POST command as per above PCAP information to the URL of:

http:// hennersy .com/the-henner/hennesystuff .php HTTP/1.0   http:// hennersy .com/sears/sears .php HTTP/1.0

IP information;

Reversed: ns3002507.ip-37-59-5.eu.
ASN: 16276
Network Prefix: 37.59.0.0/16
ISP: OVH | OVH.COM | OVH SAS 
Country: FRANCE

GeoIP checked:

The domain hennersy .com itself is registered with data :

   Domain Name: HENNERSY.COM
   Registrar: BIZCN.COM, INC.
   Whois Server: whois.bizcn.com
   Referral URL: http://www.bizcn.com
   Name Server: A.DNSPOD.COM
   Name Server: B.DNSPOD.COM
   Name Server: C.DNSPOD.COM
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Updated Date: 22-dec-2013
   Creation Date: 27-nov-2013
   Expiration Date: 27-nov-2014
Last update of whois database: Wed, 07 May 2014 15:17:16 UTC

The status of the both CNC URL as per today (Tue, 13 May 2014 08:23:06 GMT) i as per below snapshot:

The IP address of France IS: OVH: 37.59.5.67 is still serving CNC of this malware until NOW.

The URL http:// hennersy .com/sears/sears .php is down, good work!

The URL http:// hennersy .com/the-henner/hennesystuff .php is still UP and alive :-(

We urge to "related" law enforcement together to OVH to investigate this matter properly.

The disclosure of attacker IP Information

The ELF .so malware library's attacker IP address is easy to be identified after we know what pages in the WordPress that actually had been injected with malware code, or contains the WSO shell code inside. We are recording the attacker IP addresses from 15th February 2014 until today 13th February 2014, and with permission, we "masked" disclosing the attacker information in this section, as the next paragraphs stated in details. The point of this section is to pledge the help from the abuse team and law enforcement related to conduct the proper investigation and suspend the services that can be related to this attack.
Full log of each attack IP is saved and can be used as evidence by the request from law enforcement agency only by the policy of the related entity.

OK. These are the IP addresses recorded in chronological sort:

ip-static-94-242-216-183.as5577.net (94.242.216.183)
nowa.nl (212.204.192.14)
ns220038.ip-188-165-238.eu (188.165.238.180)
ns3002507.ip-37-59-5.eu (37.59.5.67)
ns38119.ip-91-121-10.eu (91.121.10.229)
static.181.238.63.178.clients.your-server.de (178.63.238.181)
c-76-30-159-18.hsd1.tx.comcast.net(76.30.159.18)
static.4.40.9.176.clients.your-server.de (176.9.40.4)
5-248-80-16-broadband.kyivstar.net (5.248.80.16)
176-8-90-64-lvv.broadband.kyivstar.net (176,8,90,64)
ec2-23-23-222-104.compute-1.amazonaws.com.(23.23.222.104)
lw930.ua-hosting.com.ua (37.48.81.37)

The network information of the IP addresses above, we can notice the VPS IP are mostly listed:

94.242.216.183 | ip-static-94-242-216-183.as5577.net.|5577 | 94.242.192.0/18 | ROOT | LU | ROOT.LU | ROOT SA
212.204.192.14 | nowa.nl.|12573 | 212.204.192.0/18 | WIDEXS | NL | WIDEXS.NL | WIDEXS B.V.
188.165.238.180| ns220038.ip-188-165-238.eu.|16276 | 188.165.0.0/16 | OVH | FR | OVH.COM | OVH SAS
37.59.5.67     | ns3002507.ip-37-59-5.eu.|16276 | 37.59.0.0/16 | OVH | FR | OVH.COM | OVH SAS
91.121.10.229  | ns38119.ip-91-121-10.eu.|16276 | 91.121.0.0/16 | OVH | FR | OVH.COM | OVH SAS
178.63.238.181 | static.181.238.63.178.clients.your-server.de.|24940 | 178.63.0.0/16 | HETZNER | DE | IT-NETWORKS.NET | INTERNET TECHNOLOGIES
76.30.159.18   | c-76-30-159-18.hsd1.tx.comcast.net.|7922 | 76.16.0.0/12 | COMCAST-7922 | US | COMCAST.NET | COMCAST CABLE COMMUNICATIONS INC.
176.9.40.4     | static.4.40.9.176.clients.your-server.de.|24940 | 176.9.0.0/16 | HETZNER | DE | HETZNER.DE | HETZNER ONLINE AG
5.248.80.16    | 5-248-80-16-broadband.kyivstar.net.|15895 | 5.248.0.0/16 | KSNET | UA | KYIVSTAR.UA | KYIVSTAR PJSC
176.8.90.64    | 176-8-90-64-lvv.broadband.kyivstar.net.|15895 | 176.8.0.0/16 | KSNET | UA | KYIVSTAR.UA | KYIVSTAR PJSC
23.23.222.104  | ec2-23-23-222-104.compute-1.amazonaws.com.|14618 | 23.22.0.0/15 | AMAZON-AES | US | AMAZON.COM | AMAZON.COM INC.
37.48.81.37    | lw930.ua-hosting.com.ua.|16265 | 37.48.64.0/18 | FIBERRING | NL | LEASEWEB.COM | LEASEWEB B.V.

The GeoIP of the above IP addresses, just in case:

IP Address, City, Country Name, Latitude, longitude
94.242.216.183, , Luxembourg, 49.75, 6.1667
212.204.192.14, Amsterdam, Netherlands, 52.35, 4.9167
188.165.238.180, , France, 48.86, 2.35
37.59.5.67, , France, 48.86, 2.35
91.121.10.229, , France, 48.86, 2.35
178.63.238.181, , Germany, 51.0, 9.0
76.30.159.18, Bellaire, United States, 29.7078, -95.4657
176.9.40.4, , Germany, 51.0, 9.0
5.248.80.16, , Ukraine, 49.0, 32.0
176.8.90.64, , Ukraine, 49.0, 32.0
23.23.222.104, Ashburn, United States, 39.0437, -77.4875
37.48.81.37, Amsterdam, Netherlands, 52.35, 4.9167 

For the wordpress access log, for the research and evidence purpose, I share the latest attack data detected as per today 13th May 2014 coming from Leaseweb Netherland (37.48.81.37, lw930.ua-hosting.com.ua) and Amazon AES, United States (23.23.222.104 , ec2-23-23-222-104.compute-1.amazonaws.com) as per below credential's masked records of two servers logs.
// To be noted:
// neostyle.php = malware installer PHP script
// maink.php = WSO Shell version 2.5.1

Attack came into one server:

lw930.ua-hosting.com.ua - - [13/May/2014:01:28:49 +0900] "GET /wp/wp-login.php HTTP/1.1" 200 4573 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:28:51 +0900] "POST /wp/wp-login.php HTTP/1.1" 302 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:28:53 +0900] "GET /wp/wp-admin/ HTTP/1.1" 200 36540 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:28:56 +0900] "GET /wp/wp-admin/ HTTP/1.1" 200 72035 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:28:59 +0900] "GET /wp/wp-admin/theme-editor.php HTTP/1.1" 200 52316 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:01 +0900] "GET /wp/wp-admin/theme-editor.php?file=archive.php&theme=XXXX HTTP/1.1" 200 37031 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:03 +0900] "POST /wp/wp-admin/theme-editor.php HTTP/1.1" 302 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:05 +0900] "GET /theme-editor.php?file=archive.php&theme=XXXX&scrollto=0&updated=true HTTP/1.1" 301 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:06 +0900] "GET /theme-editor.php?file=archive.php&theme=XXXX&scrollto=0&updated=true HTTP/1.1" 404 22963 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:09 +0900] "POST /wp/wp-content/themes/XXXX/archive.php HTTP/1.1" 200 57 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:11 +0900] "GET /wp/wp-content/themes/XXXX/neostyle.php HTTP/1.1" 200 95 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:13 +0900] "GET /wp/wp-admin/theme-editor.php HTTP/1.1" 200 52487 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:16 +0900] "GET /wp/wp-admin/theme-editor.php?file=archive.php&theme=XXXX HTTP/1.1" 200 38361 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:18 +0900] "POST /wp/wp-admin/theme-editor.php HTTP/1.1" 302 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:19 +0900] "GET /theme-editor.php?file=archive.php&theme=XXXX&scrollto=0&updated=true HTTP/1.1" 301 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:21 +0900] "GET /theme-editor.php?file=archive.php&theme=XXXX&scrollto=0&updated=true HTTP/1.1" 404 22977 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:23 +0900] "POST /wp/wp-content/themes// HTTP/1.1" 200 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:25 +0900] "GET /wp/wp-content/themes//neostyle.php HTTP/1.1" 301 5 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:27 +0900] "GET /wp/wp-content/themes/neostyle.php HTTP/1.1" 404 21777 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:29 +0900] "POST /wp/wp-admin/plugin-install.php?tab=upload HTTP/1.1" 200 35181 "-" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:34 +0900] "POST /wp/wp-admin/update.php?action=upload-plugin HTTP/1.1" 200 29352 "http://****/wp/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:35 +0900] "GET /wp/wp-content/uploads/2014/05/maink.php HTTP/1.1" 200 132 "http://****/wp/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181Version/12.00"
ec2-23-23-222-104.compute-1.amazonaws.com - - [13/May/2014:01:29:36 +0900] "GET / HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0"lw930.ua-hosting.com.ua - - [13/May/2014:01:29:36 +0900] "POST /wp/wp-content/uploads/2014/05/maink.php HTTP/1.1" 200 11517 "http://****/wp/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
ec2-23-23-222-104.compute-1.amazonaws.com - - [13/May/2014:01:29:37 +0900] "GET / HTTP/1.1" 200 17317 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:40 +0900] "POST /wp/wp-content/uploads/2014/05/maink.php HTTP/1.1" 200 12812 "http://****/wp/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"
lw930.ua-hosting.com.ua - - [13/May/2014:01:29:41 +0900] "GET /wp/wp-content/uploads/neostyle.php HTTP/1.1" 200 95 "http://****/wp/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.0); U) Presto/2.10.181 Version/12.00"

Attack came into another server:

lw930.ua-hosting.com.ua - - [13/May/2014:01:54:32 +0900] "GET /wordpress/wp-login.php HTTP/1.1" 200 2937 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "-"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:34 +0900] "POST /wordpress/wp-login.php HTTP/1.1" 302 5 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:36 +0900] "GET /wordpress/wp-admin/ HTTP/1.1" 200 37247 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:38 +0900] "GET /wordpress/wp-admin/ HTTP/1.1" 200 37016 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:40 +0900] "GET /wordpress/wp-admin/theme-editor.php HTTP/1.1" 200 40680 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:41 +0900] "GET /wordpress/wp-admin/theme-editor.php?file=footer.php&theme=XXXX HTTP/1.1" 200 28610 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:42 +0900] "POST /wordpress/wp-admin/theme-editor.php HTTP/1.1" 302 5 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:43 +0900] "GET /theme-editor.php?file=footer.php&theme=XXXX&scrollto=0&updated=true HTTP/1.1" 404 5978 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:45 +0900] "POST /wordpress/wp-content/themes/XXXX/footer.php HTTP/1.1" 200 57 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:50 +0900] "GET /wordpress/wp-content/themes/XXXX/neostyle.php HTTP/1.1" 200 95 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:51 +0900] "GET /wordpress/wp-admin/theme-editor.php HTTP/1.1" 200 41049 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:53 +0900] "GET /wordpress/wp-admin/theme-editor.php?file=footer.php&theme=XXXX HTTP/1.1" 200 29996 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:54 +0900] "POST /wordpress/wp-admin/theme-editor.php HTTP/1.1" 302 5 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:56 +0900] "GET /theme-editor.php?file=footer.php&theme=XXXX&scrollto=0&updated=true HTTP/1.1" 404 5999 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:57 +0900] "POST /wordpress/wp-content/themes// HTTP/1.1" 200 5 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:58 +0900] "GET /wordpress/wp-content/themes//neostyle.php HTTP/1.1" 301 5 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:54:59 +0900] "GET /wordpress/wp-content/themes/neostyle.php HTTP/1.1" 404 5992 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:55:01 +0900] "POST /wordpress/wp-admin/plugin-install.php?tab=upload HTTP/1.1" 200 29495 "-" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:55:03 +0900] "POST /wordpress/wp-admin/update.php?action=upload-plugin HTTP/1.1" 200 21992 "http://****/wordpress/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:55:04 +0900] "GET /wordpress/wp-content/uploads/2014/05/maink.php HTTP/1.1" 200 132 "http://****/wordpress/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:55:05 +0900] "POST /wordpress/wp-content/uploads/2014/05/maink.php HTTP/1.1" 200 11614 "http://****/wordpress/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676"
lw930.ua-hosting.com.ua - - [13/May/2014:01:55:06 +0900] "POST /wordpress/wp-content/uploads/2014/05/maink.php HTTP/1.1" 200 11717 "http://****/wordpress/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "wordpress_test_cookie=WP+Cookie+check; wordpress_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wordpress_logged_in_6912e7af91d1592086078bc94363cf0f=admin%xxxx; wp-settings-1=mfold%3Df%26ed_size%3D486%26editor%3Dtinymce; wp-settings-time-1=1399913676; 71fb293439b826ef79a9caed64624f32=63a9f0ea7bb98050796b649e85481845"
lw930.ua-hosting.com.ua - - [13/May/2014:01:55:07 +0900] "GET /wordpress/wp-content/uploads/neostyle.php HTTP/1.1" 200 95 "http://****/wordpress/wp-admin/plugin-install.php?tab=upload" "Opera/9.80 (Windows NT 6.1); U) Presto/2.10.181 Version/12.00" "-" 

Attack also coming from FTP vector

Today we received the evidence from the very different service that is infected with the same malware in their web service. This time the attack was spotted coming from the compromised FTP account. The libworker.so malware PHP installer script and the WSO version 2,5,1 PHP obfuscated script was spotted uploaded to a compromised site from the IP address IP: 5.39.222.141 (HOSTKEY.RU, Netherlands IP, NL-HOSTKEY-20120516) as per below report:

This fact of evidence explains that only site with the Wordpress flaws aimed by the attacker, but the FTP leaked or hacked credentials are also aimed.

The moral of the story

This post is indeed an exhausting analysis writing, spent almost 3h testing, coding/decoding, with the rest of time for just writing it down..wow..English is hard, I even am trying to remember to make the title goes in right letter as per Martijn Grooten taught, but, most of all, I am so happy to do it :-). For the sake of the fellow UNIX administrator & security folks to get a good clue of what had hit them, and we can all think together on the best way to mitigate this. So I hope this post helps. But if somehow you find it not useful, don't mock but please try to advise on how we can improve with the idea or pointers, by writing the comment in the below of this post, which will be welcomed.

I really hope that the friends in Emerging Threat reading this to help in releasing the block rules for the traffic sent to the CNC since the header information are "very" unique and easy to block (will mail you later after cleaning some mess here, ok?).
Additional: Thank's for releasing the rule, friends!

2 new Open signatures, 4 new Pro. Anubis Sinkhole, Zbot, Win32.Banker. Thanks, Kevin Ross and @MalwareMustDie http://t.co/p52KwgW9Ro

— Emerging Threats (@EmergingThreats) May 8, 2014

Please tune your system, don't leave it un-attended, if you use UNIX service please learn what the "do's" and "don'ts" of the services, and for Christ sake please NEVER open any directory with permission of #777, ok? Contact WordPress folks properly for some guidance, help and support if you have problem with the uploads directory with default permission.

If you got hit by the files described in illustration at the top of this post, your system is practically compromised, if you find the injected files in WordPress directory working area means your CMS is compromised. If you find WSO or other nasty things like C99 shell installed in your CMS area, the damage can be worse, you should audit the system right away. You can not think is secure to continue the service anymore unless you clean up the injected files, killing malicious process, fix the security holes, run security audit to make sure everything is in a proper way. So please make announce, then store backup system up to replace the compromised one and get the compromised system offline for the clean up purpose. I knew some systems that has to be rebuilt for having a terrible damage too :-(

To be sure to know WHY the attacker can get in is very important to fix the security holes, and for that, read all related logs is the best! Also search internet for the stuff you find in the logs or injected files, it helps you to clean up the mess. After everything clean, you can run it again. If you don't fix the security holes now, you are not just opening the risk for the attacker or next attackers will come to visit you again and may bring more damage to you, but you are ALSO risking your server to be utilized to damage others too via malicious activities like unwanted traffic redirection, exploitation, and malware infection.
So please conduct as per described above. If you have any question, leave it in the comment please, myself of other from our team may reply you properly.

Virus Total detection and Samples

Friends, please do not hope or count much on the UNIX/Linux AntiVirus Scanner for scanning the threat's files since the detection ratio of this binary series is very low (as per stated in following samples/lines) and the way I observed after seeing nearly 40 units of infection, I think in every campaign it has different ".SO" binaries and injected PHP installers. Since the CNC's URL is different in some binaries..which "currently" lead us to the hacked server used as CNC, we can assume that the bad guys is now re-compiling more and more malware library to avoid signature detection by just changing the URL string and hit one gcc command line, hence a new low or FUD (Full UnDetected) malware library will be released easily.. :-(

Therefore, I wrote this long post. Understanding the how it works is very important. By this information a professional NIX admins you can build a scheme for mitigation and prevention method to secure their system. And you can write about that know-how in your blog to share the knowledge to help others too. :-)

Anyway I uploaded the samples to the Virus Total:

x32 binary at VirusTotal, URL --> [here]

SHA256: 9b45ede71823a041386ceeded598d7c7c27a46370f0f0151bcb172191a01ccaa
File name: libworker32.so
Detection ratio: 1 / 50
Analysis date: 2014-05-06 10:48:56 UTC ( 1 day, 4 hours ago )
   Sophos               ELF/Roopre-A 20140506

x64 binary at VirusTotal, URL --> [here]

SHA256: 9a3080c635199ec57405db4945b37176243d82e6da90a2183db37921d7aa5657
File name: libworker64.so
Detection ratio: 6 / 52
Analysis date: 2014-05-06 10:55:37 UTC ( 1 day, 4 hours ago )
   Avast                ELF:Effusion-B [Trj]      20140506
   GData                Linux.Trojan.Agent.0BOYS8 20140506
   Ikarus               Backdoor.Linux.Roopre     20140506
   Kaspersky            Backdoor.Linux.Roopre.a   20140506
   Sophos               ELF/Roopre-A              20140506
   TrendMicro-HouseCall TROJ_GEN.F47V0309         20140506

More samples I uploaded to VT and can be searched by the hashes below:

"Malware PHP installer hashes:"

bb73bdf5c20b6614bf2e0a90f5119f17 atom-conf.php
79fca73775eba2d2086788add6a370e8 exostyle.php
8fd38d60e214129afa2e5c5c08fd4cda function_php.php
8fd38d60e214129afa2e5c5c08fd4cda tempstyle.php
2e9d840422eed5629fc2e04d6522690e sears.php
81feb18560aae54a143e8b8fbef1e940 oldstyle.php

 ".SO malware ELF-libraries dropped:"

2994c02d1af6c40b65448c4f6b41d862 libworker32.so
7dd65093e2817261841ba1ef58fdd63a libworker64.so
ce91cd455af378cdd20ff8845577cdaa libworker1-32.so
8cf854c15f5de3607019a4877ff790cb libworker1-64.so
2994c02d1af6c40b65448c4f6b41d862 libworker2-32.so
7dd65093e2817261841ba1ef58fdd63a libworker2-64.so
4821764e30efb1b8eac19ea312204efd libworker3-32.so
d1fa49ac024bf67a5ed9d751e05cff6e libworker3-64.so
ad28e7a4a65e31af354ce51b9d62258d rss-aggr-32.so
09d3ce840dff07e4691e0e68a1fd1758 rss-aggr-64.so

Want to know how low VT ratio on #Linux malware installer? https://t.co/XLrDNnhXsE https://t.co/c67HIo2vdF https://t.co/i0AtNuP4sx #Samples!

— MalwareMustDie, NPO (@MalwareMustDie) May 8, 2014

Thank's for the help in making this writing finish, goes to:

To loyal friends who keep on motivating MMD spirit in research, thank's & won't let you down! :-)
@wirehack7 for renting testing environment since my systems are all BSD basis only.
@jseidl & Denis (of UnmaskParasites or SucuriLabs) for helping decoding accompanied obfs. redirector. PS: Share the script friend!
To fellow admins in IDC & Mr. Shohei Maeda for allowing me to disclose this malware fact to the world.
To the open source community & wonderful *NIX/Linux people who provide good reading for research.
And to my family for patiently letting (or ignoring) me by sitting almost 12h for writing this..

Stay safe friends! #MalwareMustDie!