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!
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.
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]
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 :-)
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.
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:
MMD-0023-2014 pscan & ssh-bruter package (pic)
Old built, but the hacks still kicking... pic.twitter.com/Yxgm3ffDCz
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
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.
DUE TO THE RECENT PROGRESS OF NEW USER USING MAYHEM WE DO NOT SHARE THIS VIDEO OPENLY ANYMORE, PLEASE CONTACT @MALWAREMUSTDIE (TWITTER) FOR ACCESS,
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.
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.
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!
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: