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.


The files I gathered were:

SHA256 File Name
6b7fbe2823a38b186d63c8d22514a6a55d01d1694048c6b1a4318e8815a975a4 malware.aarch64
1627c3a82d3847ef82869be0ab773bae0e1f75e285d7747d2c9e45a0d6cc6101 malware.aarch64be
cd5fd0a3613e1d89603f71cde89aff0c13081827136a7758823bb394f27daaf4 malware.arc
67381a5f586e457785b7c0960cc78e87a36fb76b41e6fdbfb342ec73a38abd1f malware.arcle-750d
a75df2bb4227b5b119e91f9892ff60a92436454d24f10f81b003c0206a293096 malware.arcle-hs38
d133cade798f6327d1221cab9b5b414ebcbadccbda041a33846bf86aa4080a5b malware.arm7
a1b5d42e3828dc32859c6df7575f7e6ddfd3ecb13d6bda3551dee31b9a1b70a1 malware.m68k-68xxx
17ad4483d28345ec86d2f73b346daa0515d0bfbbb8aba3415fb57105f75516a5 malware.microblazebe
b17f7771197365405256ce557c6455871b2b0519dd0c7a2d5897f97d5b0e86d3 malware.microblazeel
4cbbc7ccfbc4eea461ba373dac71a5f6f49ea36bf28400dbc372b75f850b49be malware.nios2
89506d19b31ed1dc1fc829a4b99229fcbb68acb8e007c3c10d36351e5c6bf642 malware.openrisc
980c9eced00bb38e1bd8110c191ab0f90f8b8bfb3f6f20f88bc5b11de48b195a malware.riscv64
e871a6c1153cb8cb994a8c2ec1efca409bce9bc8579c928112d5f3586bc4b035 malware.x86
96076f8295e82f1f0613a3126a35a4647d2ad40d237bcf5da99f3a95d32da7da malware.xtensa


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:

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

$ rabin2 -s malware.nios2 

nth paddr       vaddr      bind   type   size  name
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
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
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

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 uses the same compiler as malware.nios2, but targets the /lib/ld-uClibc.so.0 interpreter.


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:

While malware.riscv64 uses these:


The malware.arc* line uses the following:





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?

My main questions are:

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


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

Iot · Malware · Mirai