Friday, September 18, 2015

MMD-0043-2015 - Polymorphic in ELF malware: Linux/Xor.DDOS


A share of knowledge I have, hopefully to make internet safer - @unixfreaxjp

The threat of Linux/XOR.DDoS, a China-made ELF backdoor & ddoser malware, a rather specific threat compares to other Chinese ELF ddosers, and it's still on going. I just received a good question (from I assumed from a victim of infection or a researcher) about why the found malware binary is not the same as what was firstly executed one. Well, this writing is short and covering the answer for the asked question only. But, the information maybe important for the mitigation and detection, and also various methodology I use for the sharing to other NIX mates, so I write this post with three processes I conduct to every ELF malware investigation: in reversing, debugging and forensics ways. Please bear with the poor english since I had few time to check, or to the lack of the explanation.

Polymorphic is a behavior of malware during self-reproduction constantly changes ("morphs") the file characteristic (size, hash, etc), and it may not be the same with the previous copy or as previous pre-infection state. The goal of this changes is to makes it difficult for signature-based antivirus software programs to recognize and detect the polymorphed malware.

Polymorphic method in malware is an usual practise in windows malware. In UNIX malware maybe it is not as commonly heard as in Windows; but since the nature of NIX malware are coming from networking, either to be "extracted" from encoder/infector files, downloaded or dropped by other malware from the beginning, so..I guess we have many hashes by default. But in this post, we are actually dealing with a polymorphic behavior malware just like ones infecting Windows during the self-copy method.. so I guess it is worth to write a bit.

The reported case was a real infection, a case of known gang/crooks, I am allowed to post the the attack log as per following:

Yes, it is a recent attack, please block the IP addresses.

The above log is typical Linux/Xor.DDOS ssh brute attack pattern. I announced the case not so long ago here (different cases, same attacker)-->[link] and the recent incident was reported too in here-->[link]. I uploaded this ELF malware sample into Virus Total w/the link is here-->[link].

Polymorphic PoC

When Linux/XOR.DDoS malware was executed, it will come to the stage that it seeks the place to self-copy it self, in my case the linux system call can show us the effort to write file like:

open("/usr/bin/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777) ; depends, in mine is -1 EACCES (Permission denied)
open("/bin/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777)     ; depends, in mine is -1 EACCES (Permission denied)
In a well-hardened linux system and if the malware is not executed as root you should see the same result as per pasted above. And that time the malware will aim to the only their favorite heavenly place to copy: /tmp :
open("/XOR.DDOS.SAMPLE", O_RDONLY)      ; initial exec malware open itself
lseek(3, 0, SEEK_SET);                  ; set LSET to OFFSET to READ
open("/tmp/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777); open self-copy target w/perm 777
read(3, "\177ELF\1\1\1\0\..");          ; read the malware bin
lseek(4, 0, SEEK_SET)                  ; set LSET to OFFSET to WRITE
14878 read(3, "\177ELF\1\1\1\0\…       ; copy process read..
14878 write(4, "\177ELF\1\1\1\0\…      ; copy process write

By reverse engineering the ELF malware, after seeking for a while, the assembly procedure below is responsible for the above operation: (the bigger picture click-->>THIS )

You can see the cascade of jumps during each error that might occur until it ends up to the accessed one for the self-copy purpose, starting from /usr/bin to /bin , and in my case it is ended with /tmp/[randomname]. The filename is random and the full path with the directory aimed is to be "fired" via an original API to execute the execve(), but we will go to this topic later on.

In Linux memory forensics the blob data copied can be seen clearly with some beautify effort, a good old hexdump is still a favorite in dealing with raw hex data:

## Copy process illustration (read and write of copy process) in the end of file:
00098bd0  6d 65 00 5f 64 6c 5f 6d  61 70 5f 6f 62 6a 65 63  |me._dl_map_objec|
00098be0  74 5f 64 65 70 73 00 5f  6e 6c 5f 43 5f 4c 43 5f  |t_deps._nl_C_LC_|
00098bf0  49 44 45 4e 54 49 46 49  43 41 54 49 4f 4e 00 5f  |IDENTIFICATION._|
00098c00  64 6c 5f 6e 73 00 5f 6e  6c 5f 6c 6f 61 64 5f 6c  |dl_ns._nl_load_l|
00098c10  6f 63 61 6c 65 5f 66 72  6f 6d 5f 61 72 63 68 69  |ocale_from_archi|
00098c20  76 65 00 77 63 74 72 61  6e 73 00                 |ve.wctrans.|
And the copy process was ended gracefully, as per debug check shows in the system call below:
read(3, "", 4096):   ; EO/termination w/no space
close(3);            ; end of copy (reading)
close(4);            ; end of copy (writing)

Nothing so special about operation above, but it is related to the next steps, let's go forward.. Now, we can see up to here that the malware was self copied! But why the file gets different?
The next system's call showing the effort to open the written file afterward with flag to write.. What's going on?

open("/tmp/lgjgjmkkgd", O_WRONLY); ; opening the copied file
lseek(3, 0, SEEK_END) = 625707 <==size  ; set LSET to the EOF for writing
; SEEK_END = *)    ; note the size of original malware
It looks like the pointer of LSET used to write is pointing to the end of the file itself, noted the SEEK_END flag. For the illustration see the paste "*)" position below:
## Illustration of the LSET set in the end of file..

00098bd0  6d 65 00 5f 64 6c 5f 6d  61 70 5f 6f 62 6a 65 63  |me._dl_map_objec|
00098be0  74 5f 64 65 70 73 00 5f  6e 6c 5f 43 5f 4c 43 5f  |t_deps._nl_C_LC_|
00098bf0  49 44 45 4e 54 49 46 49  43 41 54 49 4f 4e 00 5f  |IDENTIFICATION._|
00098c00  64 6c 5f 6e 73 00 5f 6e  6c 5f 6c 6f 61 64 5f 6c  |dl_ns._nl_load_l|
00098c10  6f 63 61 6c 65 5f 66 72  6f 6d 5f 61 72 63 68 69  |ocale_from_archi|
00098c20  76 65 00 77 63 74 72 61  6e 73 00 *<====          |ve.wctrans.*) <==
And then we have these two operation called timeoftheday() and writing the specific strings in the end of the file:
gettimeofday({1442479267, 397488}, NULL) ; for randomid() seed..
write(3, "wlpvpovdvi\0", 11) ; 'size is set to 11'
    ; write string "wlpvpovdvi\0"-
    ; in the LSET position (EOF)
So this is what happened for BEFORE and AFTER the writing:

So we see the file was added to 11 characters, which means we should have 11 bytes bigger for the size of file after this self-copy process, we'll get there..hang on!

Following the calls of the malware process, we can see the new file was saved:

close(3)  ; end of writing process..
And executed! Noted: execve() function is used to spawn the shell command.
execve("/tmp/lgjgjmkkgd", ..); ; main running process of XOR.DDOS in new PID
                               ; with new size (& hash)
You can see how it was executed in the saved process data in the /proc :-), so believe me, it doesn't really any fancy tools for UNIX forensics, since UNIX gods already provided us openly with everything:
lgjgjmkkg 14881 MMD  cwd   DIR  8,6     4096        7209106 /TESTDIR
lgjgjmkkg 14881 MMD  rtd   DIR  8,1     4096              2 /
lgjgjmkkg 14881 MMD  txt   REG  8,1   "625718 <== NEW SIZE" 829 /tmp/lgjgjmkkgd
lgjgjmkkg 14881 MMD    0u  CHR  1,3      0t0           1028 /dev/null
lgjgjmkkg 14881 MMD    1u  CHR  1,3      0t0           1028 /dev/null
lgjgjmkkg 14881 MMD    2u  CHR  1,3      0t0           1028 /dev/null per seen here it runs in new PID , not clone nor forking/threading since execution used the shell spawning. See the new size, it gets bigger by 11 bytes.

Below is the illustration of malware samples original and after copy-injected.

$ md5sum XOR.DDOS.SAMPLE lgjgjmkkgd
"7642788b739c1ee1b6afeba9830959d3"  XOR.DDOS.SAMPLE
"df50d096fb52c66b17aacf69f074c1c3"  lgjgjmkkgd

$ ls -l XOR.DDOS.SAMPLE lgjgjmkkgd| awk '{print $5, $6, $7, $9}'
"625718" Sep 17 lgjgjmkkgd
"625707" Sep 17 XOR.DDOS.SAMPLE
We have different hash and size.

Okay, we're done with the debugging and forensics. Let's see how the reverse engineering goes for this ELF malware binary for the above processes.

This is the part where the malware self-copy process was executed in my sample case. Noted: there are so many cases to trail with the similar codes in copying, write files and randomizing them, I counted about more than 4 scenarios prepared for this operation and the author really calculate every possibilities in his code to make sure the malware will run.

the jump to 0x804dfc2 will take you to the next process.

The assembly snip below is explaining the writing process to the done-copied file by the malware, it is not using the randomizing 11 characters but the malware was picking a hard coded xor crypt strings that is saved in 0x080cf120 (symbol: str.__Ff3VE._7).

The snprintf() is an API function that will lead (in the VERY end) to SYS_write at sys/syscall, since we deal with the statically compiled ELF many libc trails will appear in reversing the function, we may see more of these, sorry to say, unnecessary codes.

The timeoftheday() result which was shown during debugging is caused by the function which was called, named function randomid().

↑Obviously, is a self-explanatory that the timeoftheday() is fetching the system time as the seed needed in randomid() function.

There is an additional information too actually: I think maybe it is good for our community to know too: Linux/XOR.DDoS ELF malware is using a uncommon seen function to execute the shell command, it was called: LinuxExec_Argv() and LinuxExec_Argv2(), which was called to act as an API to execute non direct syscall basis commands by the malware (well, this is a static compiled binary), these functions are typical in characteristic, it is a very simple in use, easy to spot (smile) and these are responsible to call execve(), a linux system call commands (with the environment parameter parsed) to be executed during an infection, and also to call execvp() for the file execution purpose (with parsing the file path), i.e. shown in the code below:
You may want to see the reference of exec method with UNIX C library (libc) on execve, execvp at man(2) pages, and yes, UNIX gods are also providing us with good reference too.

Conclusion & reference

Yes, Linux/XOR.DDoS malware after copied and executed (read: successfully infecting us) will have a different size (11 bytes bigger..depends.. I only check one binary for this), and have a different hash. So this means that the malware spotted in the panel may not be detected by the scanner used inside of the Linux box if only detecting by the hash.

Many of us still think, Yeah..ELF malware..won't harm us or end users much.. But remember, IoT are mostly linux basis, take a look of the most of router's OS now. Also, the infection method and volume of ELF malware is getting better and bigger by days. As proof: We have about 6 of new ELF malware for 2 and half years span only! As MMD (read: MalwareMustDie, NPO), we suggest to be prepared to update the ELF malware detection quality as earliest as possible, once an ELF malicious binary hit a server the impact can be way much bigger than a PE hit a PC.

Below are links to the previous Linux/XOR.DDoS analysis:.

The "new" CNC of the threat:

Oh btw,the CNC is very alive even now...and sending the download/payload too. here's the pcap snips for a hard proof:

Kudos folks for convincing me to upgrade to git version from /usr/ports one:

Stay safe folks! Hope this short writing helps!


Sunday, September 6, 2015

MMD-0042-2015 - Hunting Mr. Black IDs via Zegost cracking

This is a short writing, Please bear the straight forward detail w/very few of explanation.
During investigating ELF malware I met this Windows PE binary, it contains an important infrastructure information used by Mr. Black actor (the one who loves attacking our MIPS routers), so I decided to check and post a bit here.

Win32/Zegost.rfn [link] (according to Microsoft)

The malware is sitting in the panel waiting to be distributed by the time I spotted:

The actor who put the PE binary in the picture was attacking my "router" with the other ELF binary one, a MIPS architecture of Linux/Mr.Black, a family of Linux/AES.DDoS, a China ELF backdoor and DDoS'er variant, with the source IP of attacker and CNC lead to that panel's address.

Seeing the panel, knowing that the PE (exe file) malware wasn't being distributed yet by the actor, so I decided to grab, analyze and expose it first, and then I may consider it being "even" for their attacking effort to my "router" (noted the quotes).

The PE is a Win32/Zegost variant, the dropper/backdoor type, I uploaded it in VT here --> [link], It drops, self deleted, auto-start set in registry, starting service (also set in many of the other boring stuff, and the point of interest of I am writing here is contacting mother hosts as backdoor.Below are some reversing snips I did during ID-ing the threat..

The infrastructure

The PE has the CNC hostname permutated DGA function and I managed to extract some of them:

Noted: The callback hostnames increased after we allow several CNC downloads. The malware DGA is generating many other fake domains.. For the botnet dissection, please focus is with the actual CNC established IP addresses only.

And each domains I checked as per snipped picture below:

I use the Kelihos fast flux milking script to milk IP addresses of the above domains:

$ cat domains.txt | bash
Kelihos FLUX check script by @unixfreaxjp
Sun Sep  6 01:04:57 JST 2015








The result of the IP milking is some of static legit IDC IP addresses in Beijing, China :-) as per listed below... At the first sight I thought these are CNC, but later on I found it very weird :-)||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | Beijing Qihu Technology Company Limited||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network
I investigated to find the IP addresses listed above IDC are belong to, a legit service in PRC/China.

But there's only one IP address that shows different network, this leads us into a malicious utilized host in South Korea, and this is the malware panel's IP address itself..||4766 | | KIXS-AS | KR | | Sudokwonseobubonbu
The GeoIP confirmed:
"country":"Korea Republic of"
"isp":"Korea Telecom"

Shortly, that IP address (port 8086) is the only IP communicated with the malware via hostname: Law enforcement may prefer to have this PCAP traffic as PoC/evidence. The callback traffic was replied by the CNC and was sent in encrypted form as per recorded in traffic below, I am sorry, I didn't have energy to crack this further..

..and get the ID :-)

So..I have collected the first three (3) DGA generated basis domains from malware sample which are:
but the #1 and #3 are legit services.

There is only one domain that is really being used as CNC (see the PCAP), the other domains are just being used as decoys to confuse the investigation. And the real CNC hostname is :

"" w/Registrant email: ""
So now we learn more about the nature of Zegost in generating DGA and faking CNC domains.

Malware is served under domain which is having a super bad reputation in being used by Mr.Black ELF attacks and many more ELF attacks, for example:

Thanks to reddit folks to inform that the is a part of a Chinese dynamic hostname/DNS (DDNS) service provider.

We didn't know this detail until now. So it looks like that their services is used by the malware activities. It means the actor can be traced via contacting the abuse accordingly. We're on it for we have long list of malicious subdomains used now.


Thursday, September 3, 2015

MMD-0041-2015 - Reversing PE Mail-Grabber Spambot & its C99 WebShell Gate

I don't know about the origin of the infection, but when I talked with Mr. Christopher Lowson while examining the CNC of the threat, I guessed a PC was infected with this malware and the callback is why me and Mr. Lawson talked. Beforehand, thank's to the Emerging Threat to allow me to write this up, I will start this report from the malware analysis to its CNC gates, in as secure manner as possible.

The unknown SFX RAR .Net PE malware (sounds lame enough?)

The sample is a PE (6222e15ed2c71429c472e5f0fa40d727) and it was reported a week ago (2015-08-27 15:10:48 UTC). A grep info in pescanner will show you:

File:    ./Release.exe
Size:    263514 bytes
Type:    PE32 executable (GUI) Intel 80386, for MS Windows
MD5:     6222e15ed2c71429c472e5f0fa40d727
SHA1:    a9316503ad6dd9e10fa8506fe69cc5aa7cc4eafe
Date:    0x54E0521F [Sun Feb 15 08:00:31 2015 UTC]
EP:      0x41d7cb .text 0/4
CRC:     Claimed: 0x0, Actual: 0x4a8a2 [SUSPICIOUS]

The CRC differences is showing packed/archives or both, I tend to check further the insides for sure with my beloved UNIX shell reversing tool, the almighty radare:

..this is showing overlay of SFX Rar file. A test (t command) in unrar shows the contents safely:

Testing     MAPIEx.dll                            OK
Testing     NetMAPI.dll                           OK
Testing     aa.exe                                OK
Oh, it seems there are two run time dll to run the aa.exe, Let's check again what is the aa.exe:
MD5 (aa.exe) = fa056e635791f18b21898bc0ff6a9978
aa.exe: PE32 (GUI) Intel 80386 Mono/".Net assembly", for MS Windows

The above result is a self explanatory. The point is: Always do static analysis beforehand, it is very important to recognize which binary we are dealing and how is the best way to deal with before we start firing some disassemblers to check its bits or opcodes.

Okay, since now we know how it's developed, let's decompile it in the same way it was built. You'll find these loaded resources:

OutlookContactsViewer.Form1.resources (Embedded, Public)
OutlookContactsViewer.Properties.Resources.resources (Embedded, Public)

The above resources is having the code to execute the malware, so the rest of this reversing is just depending on our skill to read that code.. I will cover the important parts only to PoC the badness of this binary and won't share the full code for the security purpose, as follows..

Peeling the malcode :-)

This is how the malcode was started... by initiation some variables and starting the main function to call to its loading-form:

And the loaded form has the main code of main functions for overall malcode operation:

As you can see it has two commands of "extract" and "spread". Between the "===" delimeter string, the data/text will be filled by email addresses grabbed from functions: GetMailsFromContacts(), GetMailsFromHeaders() and GetMailsFromMessages().

Functions called due to the "extract" command is the text formulation of the strings following by the POST command to send data to the web gates with URL defined in the initialization variable part.

Now we know the purpose of the runtime file is; NetMAPI library was used to perform email-grabbing act i.e. as per snipped below code in GetMailsFromContacts()

..and it is added with the regex to grep the email addresses in GetMailsFromHeaders() and GetMailsFromMessages() parts:

The same library also being used to spread spam via "spread" command (below), is a PoC that we also have a kind of spambot too here. Noted that the subject, body message and the attachment variables hard coded in the initiation part was stored here:

I snip some significant codes (only) that's utilizing HTTP protocol for uploading grabbed emails to the gate as per below, to understand and to figure ways to mitigate the threat further:

To be noted this malware reads the multipart encoded part of an email too:

A sample traffic captured for the uploads is here:

So we have the good idea what the malware is doing, yes? It sends spam, it grabs email address and uploaded them to the remote gate.

The gate

The gate is a hacked sites, I spotted the c99shell by the first time I see it. I spent much time studying c99shell before, the link is here-->[link]. This one looks injected to the compromised web site via PHP vulnerability that allows remote file uploading.

It is the latest standard version noticing this command list:

This is the up.php gate's code:

So this is how the up.php works in receiving the request, using GeoIP (by Maxmind) API to check the location of POSTed IP, making directory of that country code (if not exist) and writing files with the list of grabbed emails in it (if succeeded), it explains many directories with country code names. It also make logs of access and has the ban access function too, the details for that is written in the included func.php.. Please noted the "Nothing to do.." decoy.

It's not being used but below is snipped for the logging and banning codes, I "secured" it a bit:-)

This is what files were injected and created in that panel, if you see the same files in your servers please delete or secure them all + fix the PHP flaw that caused the file upload.

The email data of the victims that has been grabbed was plenty.. thanks to Mr. Lowson to clean this threat's gate to stop this badness. Below is the snip per 4 lines each data in the CO (randomly picked) directory..

Unknown threat with zero detection

I don't think we had any PE detection signature for this malware (in VT check): [Release.exe] [aa.exe]

A saying in my country says: "What we don't know, even small mater, may hurt us badly" ..I guess this is the case. Don't say about VirusTotal result can not represent detection in this case since several AV products installed in PC was letting infection happened without having detection either.

See this case well, even a simple .NET malware using a straight new DLL abuse vector calls for malicious purpose, if it is unknown, it's just lethal enough to damage us. So firstly please rely more on our own security common sense than just letting automation made by industries 100% control the way we must think and act, WHAT IF things went wrong? The risk is always be in our hands as users/victims < the moral of this story.

Just another saying: "One who admit the FAILURE has the chance to IMPROVE. One who just making EXCUSES will NEVER improve.."