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, 2014A 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, 2014The 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:
↑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\nThe 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 00000012while 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: %dTemplate assembled:
POST %s HTTP/1.0\r\nHost: %s\r\nPragma: 1337\r\nContent-Length: %d\r\n\r\n%sBelow 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.soYou 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/nullBelow 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.soYou 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) = 1399591316Trace 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
$ 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, 2014Please 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, 2014Thank'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!
