Sunday, June 15, 2014

MMD-0025-2014 - ITW Infection of ELF .IptabLex & .IptabLes China #DDoS bots malware

The background

I think some of Linux sysadmins and malware researchers already know this issue well by reading references in sysadmin/linux forums or reported incident in works, or maybe facing this problem them self. Since the wave of attacks are still spotted and hitting several services with the known webapp vulnerabilities, yet there are no complete verdict details of the threat (yet), we feel it's important to raise an alert on this subject in MMD post as advisory to help fellow admins who may google info of this threat with hoping this may help giving thorough explanation. The recent vulnerability that was exploited to spread this malware infection is a per tweeted here:

Maybe some of us think that DDoS tools are just only infiltrating victim sites with some kids attemting to hack on unattended sites & installing their bots written in IRC Perl/PHP DDoS'er scripts. This post is a good reading for you who think that way, since it explained a more serious threat using ELF DoS binaries specifically built to conduct DDoS action in hacked Linux servers via serious root exploitation method in each infection. This threat is known as the infection of .IptabLex and .IptabLes ELF #DDoS backdoor trojan (malware). The infection was coming from China, and is world-wide now, hitting various Linux based services with new flaws in vulnerability and giving problems to some of us.
Here goes the details..

The worldwide incidents reported

First, how is the coverage of this infection? Below is the list of reported incidents of the current threat world wide, I followed & collected in chronological basis, all are referring to the same binary sets and similar infection modus operandi. Infected server's distributions are varied like Debian, Ubuntu, Slackware, CentOS to Redhat, via vulnerability in server application like Tomcat, Elasticsearch, Apache struts etc. But all of them are informing same vector of hack in code injection vulnerability.
FYI. No, we have not seen any FreeBSD or Mac OS X based server as victim (yet).

Jan 13 2014 at 15:26 (CHINA) [link]
Jan 18 2014 at 19:11 (EUROPE) [link]
Apr 10, 2014 (N/A) [link]
Apr 25, 2014 (N/A) [link]
May 4 2014 (HUNGARY) [link]
May 8 2014 (USA) [link]
May 12 2014 (US) [link]
May 25, 2014 (N/A) [link]
May 27, 2014 (VIETNAM) [link]
May 27, 2014 (N/A) [link]
Jun 3, 2014 (EUROPE) [link]
Jun 4, 2014 (N/A) [link]
Jun 8 2014 (EUROPE) [link]

Source of threat

The origin of the threat is coming from China, which can be technically described in the next analysis sections, but there are so many report posted about the threat in China sites with this reference -->>[here]

The symptoms of infection

An infected linux host will suffer the root privilege escalation and installed with the malware sets as per below details.

Malware main files will be located in either /boot or /usr as per below. It firstly tried to write in /boot , if fail the malware will be saved in /usr.


The malware will be accompanied by the autostart script:

$ ll -a /boot/Ip*
IptabLes -> /etc/rc.d/init.d/IptabLes
IptabLex -> /etc/rc.d/init.d/IptabLex
$ sudo cat /etc/rc.d/init.d/IptabLex
exit 0

$ sudo cat /etc/rc.d/init.d/IptabLes
exit 0
The PID locked files will be detected:
$ ll -a /[InfectedPath]/
↑In most cases we found these files spotted in root (/) directory.

In the case that I was handled, the binaries and autostart scripts is having these size:

-r----x--x   1 xxx xxx 1103207 Apr 25 16:38 .IptabLes*
-r----x--x   1 xxx xxx  722392 Apr 25 16:38 .IptabLex*
-r----x--x   1 xxx xxx      33 Apr 25 16:IptabLes*
-r----x--x   1 xxx xxx      33 Apr 25 16:IptabLex*
While the first two are the malware binaries them self, following by the autostart scripts. Usually the infected host is having both binaries. The bigger size one is the newer and "advanced version", and the smaller one is limited version.

In some cases the "advanced" versions is having runtime problem and created segmentation fault (crash) as per lsof below:

$ sudo lsof -p 27322
.IptabLes 27322 root  cwd    DIR  253,0     4096       2 /
.IptabLes 27322 root  rtd    DIR  253,0     4096       2 /
.IptabLes 27322 root  txt    REG  104,1  1103243    5905 /boot/.IptabLes
.IptabLes 27322 root    0u   REG  253,0        5   98310 /
.IptabLes 27322 root    1u   REG  253,0        5   98313 /
.IptabLes 27322 root    2u  sock    0,5      0t0 3442424 can't identify protocol
.IptabLes 27322 root    3u   raw             0t0 3445564 00000000:00FF->00000000:0000 st=07
.IptabLes 27322 root    4u   raw             0t0 3445565 00000000:00FF->00000000:0000 st=07
.IptabLes 27322 root    5u   raw             0t0 3445566 00000000:00FF->00000000:0000 st=07
Where the smaller size mostly runs well, as per reported lsof:
$ sudo lsof -p 2013
.IptabLex 2013 root  cwd    DIR   253,0     4096     2 /
.IptabLex 2013 root  rtd    DIR   253,0     4096     2 /
.IptabLex 2013 root  txt    REG   104,1   722580  5906 /boot/.IptabLex
.IptabLex 2013 root    0u   REG   253,0        5 98309 /
.IptabLex 2013 root    1uW  REG   253,0        5 98311 /
.IptabLex 2013 root    2u  IPv4 3479690      0t0   TCP x.x.x.x:10038-> (ESTABLISHED)
The netstat connection upon started upon malware success running and connected to the backdoor can be seen like this:
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0    157 x.x.x.x:53534      ESTABLISHED 20543/.IptabLex     
There will be also some UDP ports opened as per below:
udp  0   0*  20595/.IptabLes
udp  0   0*  20595/.IptabLes
udp  0   0*  20832/.IptabLes
udp  0   0*  20832/.IptabLes
udp  0   0*  20832/.IptabLes
udp  0   0*  20832/.IptabLes
And the SYN packet generated from the infected host will look like this:
tcp  0   1 x.x.x.x:52831       SYN_SENT    20539/.IptabLes
tcp  0   1 x.x.x.x:36089      SYN_SENT    20389/.IptabLes
tcp  0   1 x.x.x.x:36089      SYN_SENT    20389/.IptabLes
tcp  0   1 x.x.x.x:34365         SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:34365         SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:34365         SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:35443      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:35443      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:35443      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:58164       SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:36720      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:36720      SYN_SENT    20595/.IptabLes
tcp  0   1 x.x.x.x:55258      SYN_SENT    20613/.IptabLex
tcp  0   1 x.x.x.x:55258      SYN_SENT    20613/.IptabLex
tcp  0   1 x.x.x.x:55389      SYN_SENT    20860/.IptabLex
tcp  0   1 x.x.x.x:34994         SYN_SENT    20832/.IptabLes
tcp  0   1 x.x.x.x:55389      SYN_SENT    20860/.IptabLex
tcp  0   1 x.x.x.x:34994         SYN_SENT    20832/.IptabLes
tcp  0   1 x.x.x.x:55389      SYN_SENT    20860/.IptabLex
tcp  0   1 x.x.x.x:34994         SYN_SENT    20832/.IptabLes

Definition of the Malware

This malware is the DDoS bot ELF malware variant, with a bot backdoor function connected to the CNC which sending them instruction to attack targeted hosts by SYN Flood or DNS Flood DoS techniques. It was autostarted as daemon everytime the host's services started.

So far we see no RAT (Remote Access Trojan) functionality spotted unless for the specific DoS bot functions, and also no sign of rootkits/system environment deletion detected except the additional of autostart scripts.
The deletion process of this malware can be performed safely by execution of the below commands:

$ sudo rm -f /.mylisthb*  
$ sudo  rm -f /boot/.IptabLex
$ sudo  rm -f /boot/.IptabLes
$ sudo  rm -f /usr/.IptabLex
$ sudo  rm -f /usr/.IptabLes 
$ sudo  rm -f /etc/rc.d/init.d/IptabLex
$ sudo  rm -f /etc/rc.d/init.d/IptabLes
The further observation of the binaries we know that it was originated in China Linux environment.

According to the reported cases it has backdoors connected to China IP addresses as per recorded data below:||4134 | | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK  ||23724 |   | CHINANET-IDC-BJ | CN | - | FOREST ETERNAL COMMUNICATION TECH. CO.LTD

Binary Analysis

ELF file type:

IptabLes: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
IptabLex: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
With noted:
- There is no dynamic section in this file.
- There are no section groups in this file.
- There are no relocations in this file.
- There are no unwind sections in this file.
The 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
  Start of program headers:          52 (bytes into file)
  Start of section headers:          648072 (bytes into file)
  Flags:                             0x0
  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:         39
  Section header string table index: 36
..and Section Headers:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .note.ABI-tag     NOTE            080480d4 0000d4 000020 00   A  0   0  4
  [ 2] .init             PROGBITS        080480f4 0000f4 000017 00  AX  0   0  4
  [ 3] .text             PROGBITS        08048110 000110 0695a8 00  AX  0   0 16
  [ 4] __libc_freeres_fn PROGBITS        080b16c0 0696c0 00100f 00  AX  0   0 16
  [ 5] __libc_thread_fre PROGBITS        080b26d0 06a6d0 0001db 00  AX  0   0 16
  [ 6] .fini             PROGBITS        080b28ac 06a8ac 00001c 00  AX  0   0  4
  [ 7] .rodata           PROGBITS        080b28e0 06a8e0 01554c 00   A  0   0 32
  [ 8] __libc_atexit     PROGBITS        080c7e2c 07fe2c 000004 00   A  0   0  4
  [ 9] __libc_subfreeres PROGBITS        080c7e30 07fe30 000030 00   A  0   0  4
  [10] __libc_thread_sub PROGBITS        080c7e60 07fe60 000008 00   A  0   0  4
  [11] .stapsdt.base     PROGBITS        080c7e68 07fe68 000001 00   A  0   0  1
  [12] .eh_frame         PROGBITS        080c7e6c 07fe6c 00b4fc 00   A  0   0  4
  [13] .gcc_except_table PROGBITS        080d3368 08b368 00010c 00   A  0   0  1
  [14] .tdata            PROGBITS        080d4474 08b474 000014 00 WAT  0   0  4
  [15] .tbss             NOBITS          080d4488 08b488 000018 00 WAT  0   0  4
  [16] .ctors            PROGBITS        080d4488 08b488 000008 00  WA  0   0  4
  [17] .dtors            PROGBITS        080d4490 08b490 00000c 00  WA  0   0  4
  [18] .jcr              PROGBITS        080d449c 08b49c 000004 00  WA  0   0  4
  [19]      PROGBITS        080d44a0 08b4a0 00002c 00  WA  0   0  4
  [20] .got              PROGBITS        080d44cc 08b4cc 000008 04  WA  0   0  4
  [21] .got.plt          PROGBITS        080d44d4 08b4d4 00000c 04  WA  0   0  4
  [22] .data             PROGBITS        080d44e0 08b4e0 000900 00  WA  0   0 32
  [23] .bss              NOBITS          080d4de0 08bde0 0041f8 00  WA  0   0 32
  [24] __libc_freeres_pt NOBITS          080d8fd8 08bde0 000014 00  WA  0   0  4
  [25] .comment          PROGBITS        00000000 08bde0 000398 00      0   0  1
  [26] .debug_aranges    PROGBITS        00000000 08c178 000120 00      0   0  1
  [27] .debug_pubnames   PROGBITS        00000000 08c298 000850 00      0   0  1
  [28] .debug_info       PROGBITS        00000000 08cae8 0079a5 00      0   0  1
  [29] .debug_abbrev     PROGBITS        00000000 09448d 0014a8 00      0   0  1
  [30] .debug_line       PROGBITS        00000000 095935 0018a2 00      0   0  1
  [31] .debug_frame      PROGBITS        00000000 0971d8 000cfc 00      0   0  4
  [32] .debug_str        PROGBITS        00000000 097ed4 0016f2 01  MS  0   0  1
  [33] .debug_loc        PROGBITS        00000000 0995c6 0046d9 00      0   0  1
  [34] .debug_ranges     PROGBITS        00000000 09dc9f 000300 00      0   0  1
  [35] .note.stapsdt     NOTE            00000000 09dfa0 000230 00      0   0  4
  [36] .shstrtab         STRTAB          00000000 09e1d0 0001b8 00      0   0  1
  [37] .symtab           SYMTAB          00000000 09e9a0 009700 10     38 948  4
  [38] .strtab           STRTAB          00000000 0a80a0 0085f4 00      0   0  1
The smaller size and big size is different in Symbol table '.symtab' entries, if you diff the table functions, the newer version (the bigger in size) is suggesting the "advanced mode" version with the "pro" features:
  2030: 08049750   130 FUNC    GLOBAL DEFAULT    3 CheckPro
  1946: 08049820    40 FUNC    GLOBAL DEFAULT    3 AddProList
  1022: 080496c0    39 FUNC    GLOBAL DEFAULT    3 FreeProList
  1671: 08049850   106 FUNC    GLOBAL DEFAULT    3 CreateProlist
..and also having more additional "features":
   424: 0806816e    13 FUNC    LOCAL  DEFAULT    3 _L_lock_30
   425: 0806817b    10 FUNC    LOCAL  DEFAULT    3 _L_unlock_120
  1022: 080496c0    39 FUNC    GLOBAL DEFAULT    3 FreeProList
  1081: 08068190   159 FUNC    GLOBAL DEFAULT    3 __getdents
  1162: 08049950   191 FUNC    GLOBAL DEFAULT    3 FindPtr
  1242: 080676f0   107 FUNC    GLOBAL DEFAULT    3 __strncasecmp
  1258: 0804ca20   442 FUNC    GLOBAL DEFAULT    3 killpeofnames
  1379: 080680c0   174 FUNC    WEAK   DEFAULT    3 readdir
  1381: 080d40c0 0x5aadd OBJECT  GLOBAL DEFAULT   22 filebyte
  1438: 080676f0   107 FUNC    WEAK   DEFAULT    3 strncasecmp
  1632: 08049a10    57 FUNC    GLOBAL DEFAULT    3 FindCptr
  1670: 080680c0   174 FUNC    GLOBAL DEFAULT    3 __readdir
  1760: 08049be0   208 FUNC    GLOBAL DEFAULT    3 WriteToFiles
  1785: 08050060   325 FUNC    GLOBAL DEFAULT    3 __deallocate_stack
  2041: 080d40a0     4 OBJECT  GLOBAL DEFAULT   22 constfilesize
  2052: 0804c720   106 FUNC    GLOBAL DEFAULT    3 tttaaa
  2209: 0804c6c0    82 FUNC    GLOBAL DEFAULT    3 mystristr
  2212: 0812ebc0   576 OBJECT  GLOBAL DEFAULT   22 tttxsa

Reverse Engineering Highlights

These are the source codes file list of this malware in C language:

Reversing this malware is interesting, and overall reverse effort was taking longer time than I thought. In this highlight I will guide you to the best way to go to the malicious code PoC the verdict the DoS activities. After choosing your best disassembler, I suggest you start trailing the function in address .text:0804DA40 called startmain() to find the good trail that can lead you to the DDoS functions (the verdict) soon:
public startmain
startmain   proc near 
var_18      = dword ptr -18h
var_14      = dword ptr -14h
var_10      = dword ptr -10h
arg_0       = dword ptr  8
push    ebp
mov     ebp, esp
push    edi
mov     edi, offset aBoot_iptables ; contains "/boot/.IptabLes or Iptablex"
push    esi
push    ebx
You should find the PID and its locking can be followed afterwards from .text:0804DAF5 (for the checking are you trailing the right path..):
mov     [esp+18h+var_18], offset LOCKFILEX ; "/.mylisthbS"
call    promutex
sub     eax, 1
call    getpid
call    fork
Followed by the fork function at .text:080533B0 below:
fork    proc near           
        push    ebp         
        mov     ebp, esp
        pop     ebp
        jmp     __libc_fork
fork    endp
Seek the calls lead to this function's start addeess (0x80533B0) and you will see the main DDoS function directly referring to it:
The above functions are DoS function which can be reversed as per here-->>[Pastebin] and here-->>[Pastebin], which can be breakdown deeper in how the SYN or UDP packets were formed, randomization of size and the build then followed by the sending thread. The details of those sub functions I will not cover here since it is going to be very long (but please feel free to comment for requests), and the pastebins showed enough evidence of the attack act performed by this flooder.

Let's moving on. In the .rodata:080B3360 you'll find the URL that the malware use for "test purpose", which can help PoC'ing the origin of this malware w/o much heavy reversing:

As you can see, three of the listed sites are Chinese web sites. The other things that can help to ID is the multilanguage Linux trace detected and the way it compiled the binaries (based on previous reference of similar threat from same origin, it is typical)

More malicious activities on the update server's data (link) which clearly show the fetch for updates then save it and deleting those upon done, infected host's sensitive information taken (link), getting networking information of the infected host (link), and hard coding installation of autostart scripts and installation steps (link) which PoC'ed all of the symptoms written above. For the own data handle itself this malware uses a compression logic with the decompression logic that's so "spaghetti coded" like the image below:

..with the code can be viewed here (link) ; Note: All reversed snips can be viewed in each shown disassembler links.

Analysis Samples & Virus Total

Samples are all in Virus Total already with the below hashes, under detection ratio between 3/54 to 8/54:

(thank's to "Angel Hun" for the last two samples!)
For fellow researchers, sysadmins or IR friends, I am sharing samples below:
2014/04/25  16:38         1,103,207 boot-.IptabLes
2014/04/25  16:38           722,392 boot-.IptabLex
2014/04/25  16:39                33 etc-rc.d-init.d-IptabLes
2014/04/25  16:39                33 etc-rc.d-init.d-IptabLex
2014/01/19  16:09         1,103,245 src-IptabLes
2014/01/19  16:09           722,582 src-IptabLex
That can be downloaded here-->>[MMD Mediafire] with the usual password.


For the questions and comments are welcome. I need more samples of the recent incidents, if you happen to know ones please help to send us the sample via the DropBox link in the right panel in our (this) blog menu. The comment with the sensitive information or privacy will not posted. With thank you in advance.



  1. Hi Thanks at least someone trying to get behind the story and not flogging "party lines"

    My file server has been compromised. So I'll be sending my files soon as I don't have Apache or Elastic on the server.

    1. That's interesting, this attacker went into system using two methods only (1) weak accounts and (2) exploits (Apache/Struts/Elastic..)
      It would be very nice if you may kindly share the vulnerable vector aimed.

  2. Hi unixfreak, I was wondering if you were able to get your hands on pcaps associated with the possible DDoS capabilities of this binary?

    1. Due to the nature of ddos'er is hard to achieve w/o behavior test, is hard to control privacy of private server used for the test, no sharable pcaps can be provided here, I am so sorry.

    2. That's fine, thanks for your work. I have been slowly reversing the command protocol of this binary. I got most of the basic commands down. When ti comes to the DDoS commands, things get a little more difficult because the commands get decompressed when received. Then the spiral of data decompression becomes very convoluted and long. I haven't been able to verify what the network signature for these DDoS commands yet.

    3. In that case, let me see what I can do from our side.
      Will ping you offline, please send me email address or etc contact info for the messaging purpose, that information will not be posted automatically.

  3. ( >:-( ok retype everything. My son of 1 1/2 deleted everything.)

    While scratching under the bonnet trying to fix samba I found a couple of interesting things.

    1. smbd and nmbd disappeared of the system.
    2. I found .flush in the /tmp/ directory and in /usr/.
    3. Running #strings /tmp/.flush gives me the IPs and a couple of other interesting things.

    Apr 26 2014
    MlCROS0FT|%s %s %s|%s
    Accept: */*
    Accept-Language: zh-cn
    UA-CPU: x86
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2;SV1; TencentTraveler ; .NET CLR 1.1.4322)
    Connection: Keep-Alive
    GET %s HTTP/1.1
    %sHost: %s


    4. I've installed auditd and sysdig, to trace the samba issue, but they aren't very useful as .flush appears and then a couple of hours later I'm reinfected showing how getsetup.rar is downloaded.
    5. I left the server on overnight sans firewall, Iptables/x, .flush and the PIDs only to get the server reinfected the following morning.
    6. Removing just IptabLes/x and the PIDs gets the system reinfected after a couple of hours.
    7. Removing and installing samba gets the smbd and nmbd binaries +/-8 min of life with .flush on the system.
    8. Auditd cannot tell me who deleted smbd even when watching /usr/sbin/smbd. I only get a entry of .flush and 1 or 2 entries later samba errors.
    9. The logs I have checked in /var/log/ have amnesia.
    10. My bash logs for all the users are squeaky clean.
    11. Cron does have jobs, but I cannot find them if .flush is on the system. If I delete .flush I find the jobs.
    12. Rebooting the server after I deleted .flush gets me a couple of minutes then it reappears.
    13. Adding a country code block in CSF for China doesn't get the server infected.
    14. Leaving it like that for a hour or 2 still no infection, then switching of CSF and bang in a couple of minutes .flush reappears and auditd and sysdig cannot tell me how. ( backtracing what process created .flush in the first place)
    15. Blocking the IPs in .flush and the IPs I have found on the net for Iptables/x and removing China's country codes, .flush will reappear, but no IptabLes/x.
    16. .flush runs with a UID 0.
    17. Rkhunter and Chkrootkit come up blank though I have found forum posts as far back as 2007 relating to IptabLes/x.

    Either I get hacked everytime, or there is a friendly that downloads .flush or .flush has replaced a friendly to watch over .flush and download it when it's missing.

    I'll dd the system to test under a VM and reinstall as the server needs to go up.

    1. Analyzed with the snapshot --> here, added VT comment -->here.
      It is a new variant, this ELF is the installer, they deleted the debug flags this time.

  4. Can you suggest me for tools investigate? I'm interested in reverse engineer technique.

    1. Not specific tools used, mostly I use what UNIX OS provided tools