Exotic Mirai Targets

Here’s a quick note on some malware targeting exotic processor architectures. I hope to do more investigation of this, but wanted to put out some info in case others have been looking for the same thing, or have more info.

JayTHL posted about some IOT malware they saw earlier today, and I finally found something I’d been looking for for a while now. In late 2018/early 2019, I had seen someone post a screenshot of some Mirai binaries, one of which had the extension .nios2.

Nios II is a processor architecture made by Intel designed to run on FPGAs. Devices that run this are pretty rare and would be used for highly custom or experimental applications, so they would be running a version of Linux made for that architecture. Nios II Linux is a fairly common project for Nios II based devices, but there are many variant OSes that have been created for it.

In the binaries JayTHL was talking about, there were not only Nios II bins, but binaries targeting other FPGAs as well, Xtensa, and Microblaze. There were also other architectures I’d never seen targeted before. ARC, OpenRISC, RISCV64, and AARCH64. I was super excited to finally answer some questions about these binaries, and what specific devices they would actually be run on.

Analysis

The files I gathered were:

malware.nios2

Let’s start by looking at malware.nios2:

$ file malware.nios2 
malware.nios2: ELF 32-bit LSB executable, Altera Nios II, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux-nios2.so.1, for GNU/Linux 4.1.0,
not stripped

So we can confirm this is a Nios II binary, let’s see what rabin2 has to say:

$ rabin2 -I malware.nios2 
Unsupported relocs type 38 for arch 113
Unsupported relocs type 38 for arch 113
arch     x86
baddr    0x2000
binsz    51440
bintype  elf
bits     32
canary   false
class    ELF32
compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.0
crypto   false
endian   little
havecode true
intrp    /lib/ld-linux-nios2.so.1
laddr    0x0
lang     c
linenum  true
lsyms    true
machine  <unknown>: 0x71
maxopsz  16
minopsz  1
nx       false
os       linux
pcalign  0
pic      false
relocs   true
relro    partial
rpath    NONE
sanitiz  false
static   false
stripped false
subsys   linux
va       true

Radare2 supports Nios II, but rabin2 has trouble understanding what the machine type is. We now know:

• The compiler is GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.0
• The interpreter is /lib/ld-linux-nios2.so.1
• The binary is not statically linked
• It is not stripped

Let’s examine some symbols to see if there’s anything we can learn from that.

$ rabin2 -s malware.nios2 
[Symbols]

nth paddr       vaddr      bind   type   size  name
―――――――――――――――――――――――――――――――――――――――――――――――――――
...snip...
65   ---------- 0x00000000 LOCAL  FILE   0     scanner.c
66   0x00006a78 0x00008a78 LOCAL  FUNC   296   add_auth_entry
67   0x00005ef8 0x00007ef8 LOCAL  FUNC   540   get_random_ip
68   0x00005dbc 0x00007dbc LOCAL  FUNC   316   setup_connection
69   0x00006ba0 0x00008ba0 LOCAL  FUNC   192   random_auth_entry
70   0x00006114 0x00008114 LOCAL  FUNC   724   consume_iacs
71   0x00006528 0x00008528 LOCAL  FUNC   616   consume_user_prompt
72   0x00006790 0x00008790 LOCAL  FUNC   444   consume_pass_prompt
73   0x000063e8 0x000083e8 LOCAL  FUNC   320   consume_any_prompt
74   0x0000694c 0x0000894c LOCAL  FUNC   300   consume_resp_prompt
75   0x00006c60 0x00008c60 LOCAL  FUNC   332   report_working
76   0x00006ee0 0x00008ee0 LOCAL  FUNC   84    can_consume
77   0x00006dac 0x00008dac LOCAL  FUNC   308   deobf
78   ---------- 0x00000000 LOCAL  FILE   0     util.c
...snip...
95   0x00002440 0x00004440 GLOBAL FUNC   584   killer_kill_by_group
96   0x00003d1c 0x00005d1c GLOBAL FUNC   320   ackattack
98   0x00003010 0x00005010 GLOBAL FUNC   256   connection
99   ---------- 0x0000c190 GLOBAL OBJ    4     RavaugeCumSock
100  0x00001b94 0x00003b94 GLOBAL FUNC   172   decrypt_for_recv
101  0x0000169c 0x0000369c GLOBAL FUNC   424   encrypt_array
102  0x00009000 0x0000c000 WEAK   NOTYPE 0     data_start
103  0x000019b4 0x000039b4 GLOBAL FUNC   336   encrypt_by_name
104  0x00007518 0x00009518 GLOBAL FUNC   384   util_itoa
107  0x00005d7c 0x00007d7c GLOBAL FUNC   64    scanner_kill
...snip...
221  ---------- 0x0000c174 GLOBAL OBJ    4     TotalKilled
223  ---------- 0x0000c1b8 GLOBAL OBJ    4     auth_table
224  ---------- 0x0000c19c GLOBAL OBJ    4     rand_str
225  0x00001d1c 0x00003d1c GLOBAL FUNC   444   killer_kill_by_deleted
227  0x00002b5c 0x00004b5c GLOBAL FUNC   1204  cmd_parse
228  0x00003e5c 0x00005e5c GLOBAL FUNC   320   urgattack
229  ---------- 0x00010e04 GLOBAL OBJ    40    savesysproc
230  0x00003bdc 0x00005bdc GLOBAL FUNC   320   synattack
231  ---------- 0x0000c1d0 GLOBAL OBJ    4     scanner_pid
...snip...

All of these symbols point to this being a Mirai variant. Particularly the use of auth_table and deobf, which are related to decrypting values from a 4 byte xor obfuscated table in Mirai variants.

So now we know that, let’s check out the other FPGA targets.

malware.xtensa

malware.xtensa uses the same compiler as malware.nios2, but targets the /lib/ld-uClibc.so.0 interpreter.

malware.microblaze*

malware.microblazebe seems to use microblaze-buildroot-linux-uclibc 7.3.0 as it’s compiler, and also appears to target uClibc. rabin2 wasn’t able to pick that up though, so I confirmed with rabin2 -s malware.microblazebe. The little endian version malware.microblazele has the same characteristics, except that it uses little endian format.

This symbol popped out at me that didn’t appear in the others:

165  ---------- 0x1002d310 LOCAL  OBJ    4     been_there_done_that

malware.openrisc & malware.riscv64

malware.openrisc uses the following compiler and interpreter:

• compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 5.4.0
• intrp /lib/ld-uClibc.so.0

While malware.riscv64 uses these:

• compiler GCC: (Buildroot 2018.11-rc2-00003-ga0787e9) 8.2.0
• intrp /lib/ld-linux-riscv64-lp64.so.1

malware.arc*

The malware.arc* line uses the following:

malware.arc

• compiler ??
• intrp /lib/ld-uClibc.so.0
• machine ARC Cores Tangent-A5
• static false
• stripped true

malware.arcle-750d

• compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.1 20180319
• intrp ??
• machine ARC Cores Tangent-A5
• static true
• stripped false

malware.arcle-hs38

• compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.1 20180319
• machine Synopsys ARCompact V2
• static true
• stripped false

Thoughts

The most telling symbol of all is “RavaugeCumSock”, which was found in most of the binaries. I wasn’t able to find this string in any of the collected malware sources that I have, so if anyone has any info please let me know!

So what have we learned?

• None of the exotic devices use the uclibc.org compilers that most of the classic Mirai variants use. Instead they use buildroot.

• Not all of these binaries are statically compiled as previous versions of Mirai are. This means that they could possibly be even LESS portable than other Mirai binaries.

• Not all of the binaries are packed or stripped.

My main questions are:

• What devices are they targeting, if anything? There are very few devices I know of that run say, Linux on Nios II, and of those devices, they are all SCADA devices.
• Has there ever been any success with them? Has a bot ever come back and reported the CPU arch as any of the FPGA/RISC/ARC architectures? I am not doubting that devices with these arches exist online, but has anyone been able to infect with these bins?
• What is the infection mechanism? Are there any exploits used? With all of these rare systems, are there any specific public exploits? It could just be SSH / Telnet bruteforcing too.

I’ll have to take a closer look later this week to do some dynamic analysis. The x86 and ARM bins are packed with some packer that isn’t UPX (shocker), and I haven’t had a chance to emulate some of these devices before, so I might just set up Linux on Nios II with my Altera DE0-Nano.

If you want to see more of the Mirai sources I’ve compiled, check out TL-BOTS

Shoutouts

Shoutout to JayTHL for making me fly off my couch to pull these apart. Also hermit for always sharing botnet binaries with me, grenlith for looking out for these binaries for me, and aneilan for doing that as well. <3