Monday, September 29, 2014

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

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

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

The infection

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

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

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

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

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

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

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

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

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

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

Below is the result:

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

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

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

The POC of this hack is the payload below:

The payload

The header looks very "fine":

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

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

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


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:||59270 | | CLOUD 

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.


(A reserved section for additional and updates)



  1. New Attack-Steps:

    The attackers are spreading a "new" ELF-binary masked as "3502_s.rar". The binary is spreaded without downloading a shellscript first.

    They are still using the same one-line shell-command as mentioned in the report above. Even the IPs didn't changed. This could be a reaction on MalwareMustDie's report about this new type of malware.

    The via one-line shell-command downloaded and with debugging symbols compiled ELF-Binary is the same as the Linux/XOR.DDoS. The CNC-Server didn't changed too.

    I don't know why they changed their attack steps. Maybe they had some complications with the downloaded shell script. So they are downloading the binaries directly now.

  2. The updated attack installer shell-script as per mentioned in previous comment can be seen here-->MMD-Pastebin < for cleaning up purpose.

  3. New "3503" binary detected. Downloaded via as "3503.rar" masked POSIX-Shellscript. So same attack steps as at the beginning. The "3503"-binary has different crypto so lower detection rate but same malware type: Linux/XOR.DDoS:

    CNC-Server didn't changed. Its the same as in the report above. CNC-Server is still up and alive.

  4. Do you know how to stop/clean this. I try to kill the process but process and appears again in a loophole

    1. You might want to seek the parent process PID and take it down, not the child or the thread/workers. Seek the /boot and your system's autostart (xinetd..the ones with /etc/init.d/rcX, crontab, rc.local) for the autostart entries.
      As root pls take snapshot regularly for the list of files (lsof) grep to the known user/PID or directory that you suspect related to malware and use the result to obtain the source of infection by PID or by path name.
      Also please, as root, check the netstat, see for the unusual traffic.
      Don't worry, UNIX makes us see everything we need to know of unknown process, this malware has weakness in usage of random filen|process names, in some reported cases it makes it easier to spot.

      Please feel free to ask more. If you need the reply in private, please comment with mention your email address, one of us will contact you back, and your post with email will never be posted here.

    2. The malware binary will be autocopied to /boot/[a-z]{10} < please remove it.
      Check the crontab, rc.local and unusual symbolic links. Most of the components files should be created in new dates, that can be sorted with ls command.

      Trace the source of unsusual connection with netstat, ss, and lsof with hooked to the process filename or PID that causing it.
      Let us know if you need further assistant.

    3. I have the same malware on OpenSuse 11.3 and cleaned by pause the process, then delete files on /boot, /etc/init.d, etc.
      Also I removed lines from crontab and delete cron.hourly/

      I will check the server in the next days.
      Thanks for the info.

    4. You're welcome! It's always nice to help others, specially fellow sysadmins.
      If you would be kind to please retweet our video report on effort to fight these ELF malware HERE would be greatly appreciated.

  5. I know that, is that is why i'm asking. I can't find parent process, i look all process i know and i not see anything wierd only the malware process.

    The process, i can't show more in a single image so i will show you multiple images


    a) Here, the top process is the malware installed and is in /etc/init.d/ /boot if i kill the process, is appaers again with new name process, also, if i delete the file store in /etc/init.d/ /boot the process is killed and appers again with new name.

    b) On bottom, you will see other process same as the top, the problem with these process is random restarted with a new name every 3 seg (new PID), so in little works those process is not static always is a new process (5 process)

    2. Because the tradicinal top not show this, i using htop and you will see strange process is in exec

    a) look ifconfig, cd /etc, ps -ef, who
    b) look ifconfig, grep "A", bash, ps -ef
    c) look who, ps -ef, netstat -an, echo "find", uptime, ifconfig
    d) look ifconfig, sleep 1, grep "A", id. su

    There is another process but you can figure out what i mean.

    This is the strings for the malware pleas not include in the comment

    1. hi,bro, I just met the same questions as you , can anybody provide some detail solution to clean this malware up? #malwaremustdie# i hate malware!

    2. Here's what I tried. YMMV :

  6. I just sucessfully cleaned this from a server, but I'm still not clear what the vulnerability was that allowed them to inject the command via an ssh connection in the first place. Is there a related CVE or other information about what might need to be patched up to prevent this from happening again?

    1. hi, bro ,can you tell me how to clean this up , malreware's parent process alway be 1, the process is killed and appers again with new random name,so does filename.

  7. We released the way they do the attack in the newest post. Stay tune.

  8. One of the two mentioned servers above is still up:

    inetnum: -
    country: PT

    Not shown: 995 closed ports
    22/tcp filtered ssh
    53/tcp open http nginx 1.6.1
    80/tcp open http nginx 1.6.1
    443/tcp open http nginx 1.6.1
    445/tcp filtered microsoft-ds

    The server is still serving this malware:

    All files are hidden and on port 80 via nginx.
    There is a good chance that there are more files.

  9. We successfully removed the malware from some of our servers which were infected for about 30 hours. During the process we made a few interesting observations and also caught a payload binary doing syn-flood attacks on certain servers.
    The interesting part is, only one of the infected servers was active runnign this attack, while the others just kept quiet. As soon as we stopped the attack on one server, a second one tried to start an attack binary.
    We were able to extract the running binary from kernelspace.

  10. I just found a similar attack on my server which is not shellshock vulnerable.
    It only had a simple website running and ssh open to the outside.

    I found a binary in /lib/udev/debug also managed by the cron script, I found a dynamic created binary in /boot.
    I could not find a possible attack vector, I could not find any sort of scripts on the server.

    The server was running a 800mbps attack to a chinese network.

    Are there any new known attacks that botnet uses ?

    Btw, the developer of the attack might be called xinwei
    The binary is not properly stripped:
    I found "/home/xingwei/Desktop/ddos" in it

  11. My Debian server was recently hijacked and root password was changed. So I could not log in. Debian root pass can be reset by grub what I did.
    Afterwards I saw a lot of ports open and spam mails being from enim4 mailserver and postgreqsl database was installed.

    I disabled root login in SSH. And login as another user and then type su to become root.
    in ps -ef I could see someone trying to issue commands whoami, ifconfig, etc.
    But stranger could not gain root access anymore.

    /etc/rc.1 - rc.5 had files to execute them. I deleted them.

    Had files with random names appear in /boot/.
    Making /boot read-only did not help.
    Files had random names constant length. Deleting file it reappeared under another name.
    File size was constant 662840 bytes. Searched on HDD files with this length.
    find / -type f -size 662840c -exec ls {} \;

    this file size was also 662840 same as for files in /boot
    after renaming it and killing running virus processes they did not reappear.
    It was great to learn methods of hacking.

  12. Make directories unmodifiable: chattr -R +i /bin /

  13. Some random italian guys reverse that too:

  14. Allow the following script to run for an day. When the file /root/tenkilled gets to be more than an hour old, you are clean. Its a little overkill and the script may have some nasty side effects (killng all running processes that are 10 char long) but it works.

    # suspect file and process killer
    while true; do
    find /etc/init.d/ -name S90[a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z] -print|xargs -i rm -f {}
    find /etc|grep deleted|xargs -i rm {}
    find /etc/init.d/ -name ?[0-9][0-9][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z] -print|xargs -i rm {}
    rm -f /boot/[a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z]
    rm -f /etc/init.d/[a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z]
    ps xao comm |grep [a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z]|grep -v khu|grep -v kinte >> /root/tenkilled
    ps xao comm |grep [a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z]|grep -v khu|grep -v kinte|xargs -i pgrep {}|xargs -i kill -9 {}
    sleep 10

    1. What horrible advice! If you have legit binaries that are 10 characters long, you'll remove those too!

    2. Well, is an gruesome process but is direct to the fix.

    3. well i must say Ottho your script helped me after hours and hours of messing with trying to get all the files deleted. chattr +i crontabs and uploading a text file in place of to keep it from replicating your script allowed me to eradict it from our server thanks.

  15. No, legit binaries will not be removed, although they might be temporarily killed, but you can reboot, and then those legit binaries will reload and your system will be clean. The location for the bad binaries is very specific, and those files should not be there. Legit files live elsewehre in the tree. Furthermore, killed and removed files are logged to the file /root/tenkilled, you can check it to see if any legit executable was killed and/or removed. Finally, in lines 9 and 10 of the script you can add exceptions, in the form |grep -v "Processname" or regex pattern, which for example I did excluding all proceses begining with the pattern khu and kinte, which were legit processes on my system.

  16. I had to deal with this malware during thanksgiving... what a wonderful time, wiping and reinstalling VMs that got infected. Fail2ban became my best friend that day.

    1. Most of these attacks are coming from china or calling back to china for payload or the malware control center communication during infection stage. If you or your entity don't have anything to do with them I suggest you block all of their network segments, euther in the TCP wrapper (hosts.allow at DENY rule), iptables/ipchains. ipfw, ufw firewall rules.

      I collect all of their network data actually and share it for them who want to block as per suggested above, and maintain this data weekly basis, feel free to use it.

      Here is the link--> China & Hongkong IP addresses to block

  17. I found a variant of the two reported, in the VPS of a customer. CentOS 6.6 x86_64. The vector was SSH brute force.

    The file is: (binary file)

  18. I released latest incident advisory MMD-0033-2015 of of the Linux/Xor.DDoS contains new infection approach they are using, spotted few days before.

    CNC, payload list, United States & Hongkong server infrastructure & domain abuse information was released too. The Linux/XOR.DDoS sample was calling back to 4 different CNC in this new version.

    The bad guy was leaving the trail, so we know who he is now.
    The link is here --> MMD-0033-2015

  19. Guys i still have a problem. Please help. What i did was:
    - Removed all virus related files in /init.d/rc0-6 (links)
    - Removed all files he created in /usr/bin (becouse my /boot/ and /bin/ was clean)
    - After i did this i did chattr -R +i /usr/bin/ . When i killed the process, it created links in /etc/rc0-6 again and becouse it couldn't write in /usr/bin/ it created files in /bin/
    i tried to do chattr -R +i /bin/ but then it created files in /tmp/ when i killed it....
    Can you please help me with this big problem... (i dissabled a gateway on my server so it cant go online until i fix this)

    1. As the fallback effort the malware will use /tmp
      I have trick that I use myself when they are starting to save payload copies & exec it from /tmp, which is I chmod 600 /tmp, kill -KILL all process while watching the lsof (I run for this lsof mostly) with specific grep that can indicate malware process.
      Without place to write for new process' used binary the malware will die.
      When it died you can restore back the /tmp permission to previous state.

      Good luck!

    2. Of course this is assuming that the malware is NOT run as root.. If it is, please apply the root user adjustment to prevent any writing on the /tmp for the killing purpose.

  20. Thank you for replaying so fast,
    Unfortunately, malware is runing as root... What than?
    And if i do the same thing for /tmp wont malware find some other location like in previus cases?

  21. ps. while im' doing this process is paused (so it would not use 100% of mu CPU)

    1. Two advise:
      1. Make directories unmodifiable: chattr -R +i /bin /boot /tmp / and kill the process of malware, then restore previous permission.
      2. If the above (1.) not working, switch to init 1 and do the backup, then delete the malware files in their known directories ( /boot /bin/ usr/bin /home/[YOU] /root /tmp )
      3. Build new system using the backed up data is VERY advisable, if the malware runs as root, XOR.DDOS always paired with some rootkits, morelike your system may get compromised more than you reralized, rebuilt it clean one is faster and less riskier. And this time do not run web/ftp services on root and not allowing root as terminal (ssh, telnet etc) login please.

  22. Please read information about latest infection of XOR.DDOS here. So you will know the combination of malware and rootkit used by those crooks for a single infection and what is on their CNC to get the bigger picture with whom we are dealing with here. We are unixmen, we're better than these bandits.

  23. XOr.DDoS is using a kind of "Polymorphic" in post-infection, it measn after it infects you the hash is changed, I made -->report and analysis <--about that.

  24. Today I found a version of this malware running in my ARM linux cubietruck miniPC I use for audio/torrenting/storage. It caught my eye a /tmp/.javaxxx file running (hating java pays off, finally)
    lsof -p inmediatelly showed what I was fearing; here is the output.
    I am still perplex of how it got in since it is running Debian 8.x which ships ssh root logins disabled by default.
    I couldn't get /tmp/.javaxxx since it had deleted itself.

    I can see a ton of direct ssh root access, and sadly the initial infection login, if it brute forced its access is lost to logrotate.
    root@cubie:~# zgrep "Accepted password for root from " /var/log/auth.log*|wc -l
    Tinkering (cat, cut, sort, uniq) with the IPs in the auth.log files, I got
    root@cubie:~# wc -l /tmp/lista
    118 /tmp/lista
    unique IPs from where they got access at some point.

    However this seem to be different
    - I don't see any of the automatic starting methods you describe. Nothing at /etc/cron.*, crontabs, or init.d rc.d, etcs. I rebooted the server and nothing started by itself. No config files seem to be added or modified.
    - I found many different binary files at /root/
    # ls
    e38sd.1 e38sd.3 i9js i9os.1 i9os.3 i9os.5 i9os.7 i9os.8 s36oa s36oa.2
    e38sd e38sd.2 f6ho i9os i9os.2 i9os.4 i9os.6 i9os.7.1 i9os.8.1 s36oa.1 s36oa.3
    Odd enough they are i386 binaries
    # file e38sd.1
    e38sd.1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
    This is the VirusTotal analysis:

    - This particular strain seems to also do spam, since my exim is clogged with 60k emails that it was unable to deliver.

    Wait.. Now that I am piecing the pieces together, it might be that these are two different infections. Or maybe the pushing server compiles i386 and ARM at the same time. Who knows.
    I will update if I find something else.
    Thanks for the quality post.

  25. The posted info is the Linux/Xor.DDoS infection, same malware we mentioned in

    I saw your post in MalwareMustDie post. Infection method are varied, but mostly they use the ssh bruting instead exploitation, but exploitation like bash shellshock, old web server are also spotted. Make sure your ARM appliance doesn't have other obsolete services, and up to date. If your appliance is common brand, the default password is the most commonly way to enter for these crap.

    By reading your report I know your stage of infection of this malware was so deep. Cleaning up will be hard since Xor.Ddos hackers from China are using several rootkit during post infection of original trojan. So any further binaries could be in replaced state by ow in your appliance, pleae make it offline if you want to investigate further. Please reset the appliance to the original state if you need to use it later, practically you can not trust its security after this incident as per its current state.

    The sample you post in VT is the Xor.DDoS self-copied after post infection state, it does polymorphic method to protect its original hash (by changing itself) for prevention in seeking its sources, see: this occurred if initial infection was success.

    The traces for the infection is not only in initrd not crond, but it is firstly aiming /root if possible, and you were hacked this deep.