Tamer: A Sandbox for Facilitating and Automating IoT Malware

Analysis with Techniques to Elicit Malicious Behavior

Shun Yonamine, Yuzo Taenaka and Youki Kadobayashi

Nara Institute of Science and Technology, 8916-5 Takayama, Ikoma, Nara 630-0192, Japan

Keywords:

Sandbox, IoT, Malware, Dynamic Analysis, Automated Analysis, ARM.

Abstract:

As malware poses a signiﬁcant threat to IoT devices, the technology to combat IoT malware, like sandbox,

has not received enough attention. The majority of efforts in existing researches have focused on x86-ﬂavored

binaries that are not used for IoT devices. In fact, we have witnessed that many samples of IoT malware that

can be observed in the wild are ARM binaries. In this paper, we propose a novel sandbox for analyzing Linux

malware including IoT malware. Our sandbox system, called Tamer, supports dynamic analysis for ARM

binaries and has some features to automate and facilitate IoT malware analysis, like the automated interaction

mechanism and the fake network environment for dynamic analysis. In addition, our system adopts features,

like dynamic binary instrumentation and virtual machine introspection, which may allow retrieving further

insights from malware. With the dataset of real-world malware, we demonstrated that our sandbox system can

analyze IoT malware which is speciﬁcally designed for infecting IoT devices. Through an analysis experiment

on a large number of IoT malware samples, we demonstrate a possibility that our system could facilitate a large

scale analysis in an automated manner and retrieve further insights from IoT malware.

1 INTRODUCTION

With the spread of IoT devices, IoT malware has been

increasingly sophisticated time by time. Some recent

studies have promoted awareness of the threats from

IoT malware (Cozzi et al., 2018; Cozzi et al., 2020;

Carrillo-Mond

ejar et al., 2020). Sandbox is one of

the malware analysis methods that enable extracting

the details of malware behavior. As sandbox lets mal-

ware run on a real system, it is useful to investigate

various malware behavior on certain conditions of the

system. In addition to this feature, sandbox attracts

attention as the solution of analyzing a large number

of malware samples systematically and automatically.

These features are expected to contribute to follow-

ing the trend of IoT malware growing and changing

quickly.

In past, researchers have proposed novel sandbox

systems that are capable of automated dynamic mal-

ware analysis, and each of them handles speciﬁc use-

cases (Cuckoo, 2013; Willems et al., 2007; Bayer

et al., 2006; Monnappa, 2015). However, the ma-

jority of previous works have focused on analyzing

conventional malware, and the sandbox for IoT mal-

ware has not received enough attention and not been

explored in detail. In particular, existing sandbox sys-

tems (Cuckoo, 2013; Monnappa, 2015) mainly target

on x86 architectures but do not support architectures

like ARM that are majorly used by IoT. While meth-

ods for facilitating dynamic analysis have matured

through previous studies, these are mainly adjusted

for x86 architectures. Since the execution environ-

ment of ARM is different from x86 architectures, it

requires additional features to facilitate IoT malware

analysis.

In this paper, we propose a novel sandbox, called

Tamer, for analyzing IoT malware. Different from

existing sandboxes which mainly target on x86 ar-

chitectures, our sandbox system supports architec-

tures that are used by IoT devices, such as ARM. As

a feature to elicit network behavior from the target

malware sample, we construct a fake network envi-

ronment where a sandbox machine and pseudo-C&C

server are connected. The fake C&C server allows

observing network data that could be exchanged be-

tween malware and the C&C server. Further, by lever-

aging expect

utility, Tamer automatically operates

the Linux machine where is the execution environ-

ment of IoT malware. In addition, Tamer supports

advanced binary techniques like dynamic binary in-

https://linux.die.net/man/1/expect

Yonamine, S., Taenaka, Y. and Kadobayashi, Y.

Tamer: A Sandbox for Facilitating and Automating IoT Malware Analysis with Techniques to Elicit Malicious Behavior.

DOI: 10.5220/0010968300003120

In Proceedings of the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022), pages 677-687

ISBN: 978-989-758-553-1; ISSN: 2184-4356

677

strumentation (DBI) and virtual machine introspec-

tion (VMI).

For evaluation, we conduct several malware anal-

ysis experiments on the dataset of real-world malware

samples. We show that our sandbox system promotes

deeper details about the malware behavior. The eval-

uation supports evidence that how Tamer sandbox can

serve as a choice for IoT malware analysis.

This paper makes the following contributions:

• We propose a novel sandbox, called Tamer, for an-

alyzing IoT malware. Tamer supports analyzing

binaries for ARM, an architecture mostly used in

IoT devices. In addition, Tamer has key features

to facilitate IoT malware analysis: The fake net-

work is a dedicated environment to facilitate ana-

lyzing the network behavior of malware using the

fake C&C server. The auto-manipulation mecha-

nism using the expect allows to performing be-

havior analysis in an automated manner. More-

over, to the best of our knowledge, Tamer is the

ﬁrst sandbox that attempts to combine advanced

binary analysis techniques such as DBI and VMI.

• Through the experimental evaluation on the

dataset of real-world malware, we demonstrated

that our system can analyze IoT malware which is

dedicated to infecting IoT devices. Moreover, the

result of an analysis experiment on a large volume

of samples suggests that our system can analyze a

huge amount of IoT malware samples in an auto-

mated manner, and may highlight recent trends in

IoT malware families.

• We will release the details of the implementa-

tion of Tamer as open-source, and the list of md5

hashes of malware samples in the dataset, at the

following link

. We expect that some outcomes

we observed through analyzing a large number

of samples could be interesting to security re-

searchers. This is for promoting to replicate our

experiments and obtain the same observations.

2 RELATED WORKS

2.1 Observing Landscape of IoT

Malware

Why the ARM based Linux Malware Matters: In

this study, we focus on the Linux malware for the

ARM architecture since this architecture is popular

for consumer IoT devices and commonly targeted by

IoT malware. In fact, our position can be supported

https://github.com/shun-yo/Tamer

by some studies. In the recent study (Cozzi et al.,

2020), they explored a large number of malware sam-

ples that have been submitted to VirusTotal over a pe-

riod of almost four years (from January 2015 to Au-

gust 2018). In their dataset, the ARM 32-bit malware

accounted for the largest number of samples, 39.05%

of the total 93,652 samples.

Furthermore, according to the VirusShare dataset

(VirusShare, 2020), a repository of malware sam-

ples, the ARM architecture accounted for the ma-

jority of Linux malware samples collected in the re-

cent period (from Feburary 2019 to April 2020). In

detail, from our survey on the dataset referred to

VirusShare ELF 20200405, the ARM accounted for

one-third or 13,963 out of a total of 43,553 samples.

In short, based on these observations, we claim that

the anti-malware methodology that focuses on ARM

malware is worth considering.

2.2 Existing Sandbox Systems

To date, various sandbox systems have been proposed

and each of these focuses on various use-cases to

combat the malware. In general, the purpose of sand-

boxes has focused on behavioral analysis and the in-

formation obtained from the analysis is used for up-

dating intrusion detection system’s signatures or re-

moving malware from an infected machine, and so

on (Willems et al., 2007). Although various methods

have been explored as sandbox systems have evolved,

we have witnessed that sandbox systems for analyz-

ing IoT malware have not received enough attention.

As an example, Willems et al. designed CWSand-

box (Willems et al., 2007), a sandbox that aims to

generate the machine-readable report to initiate auto-

mated responses. However, their sandbox is for ana-

lyzing malware targeting Windows systems, not IoT

malware. In addition, as the authors admitted that

CWSandbox might cause some harm to other ma-

chines connected to the network, their sandbox does

not have some tricks to make the sandbox separated

from the Internet.

Regarding a limitation of CWSandbox, here we

could suggest that the network setting should be paid

more cautious in IoT malware analysis. The reason

is, in many cases, network activity by IoT malware

involves destructive functions (e.g. DDoS attack,

Brute-force attack to propagate through SSH/Telnet).

Therefore, to construct a dedicated network setting

for malware analysis, it is also necessary to set up a

server that serves as a listener for the C&C connec-

tion.

Bayer et al. proposed Anubis (Bayer et al., 2006),

a novel sandbox for automated malware analysis. Un-

ForSE 2022 - 6th International Special Session on FORmal methods for Security Engineering

678

Table 1: Setting for 32-bit ARM Linux.

Hardware ARM Versatile/PB(ARM926EJ-S)

Architecture ARM v5

Kernel Linux 3.2.1

Memory 256MB

Virtual Disk debian squeeze armel standard.qcow2 (Debian.org, 2014)

Table 2: System speciﬁcation inside Tamer.

OS CPU Memory

Host machine Ubuntu14.04(x86 64)

Intel

Xeon Silver

@1.80GHz*4

16GB

Sandbox

machine

32-bit ARM Linux

(kernel ver: 3.2.1)

QEMU 256MB

Fake C&C

server

Linux

(Debian 9.12 i386)

QEMU 1 GB

fortunately, their sandbox is for analyzing Windows

malware. Besides, their work is not motivated to mon-

itor network behavior. As with Willems et al., their

study does not care about the network environment

for monitoring network behavior by malware. In de-

tail, while the purpose of their sandbox is to under-

stand functionalities of a given malware sample, their

aim is to get the knowledge about the functionality of

malware for removal.

While CWSandbox (Willems et al., 2007) and

Anubis (Bayer et al., 2006) focus their scope on Win-

dows malware, Limon (Monnappa, 2015) is a sand-

box for analyzing Linux malware. Limon has a min-

imal mechanism for observing network behavior. It

uses simulated network services with the inetsim

(inetsim, 2020) on the analysis machine and allows

monitoring network behavior by malware (like they

analyzed Tsunami (Monnappa, 2015)). However,

Limon does not support analyzing ARM binaries.

In detail, analysis methods used by Limon leverage

features of VMware that are for x86 architectures,

and are not applicable to ARM. Similarly, Cuckoo

(Cuckoo, 2013) is an open-source sandbox, but it does

not support analyzing ARM binaries.

Overall, to the best of our knowledge, at the time

of writing, sandbox systems for IoT malware have

not received enough attention. Even though several

works aim to handle Linux malware that could relate

to IoT, they do not take into account some features

that are necessary to facilitate IoT malware analysis

(e.g. ARM support, dedicated network settings).

3 SYSTEM OVERVIEW OF

TAMER SANDBOX

First of all, to be able to run and analyze ARM bina-

ries, we need dedicated platforms for ARM, including

CPU and OS. Thus, we choose to use QEMU emula-

tor to run a dedicated ARM based Linux on an emu-

lated CPU. For 32-bit ARM Linux machine, we use

Debian Linux where the kernel was cross-compiled

for ARM architecture, as we describe in Table 1. In

our setting, we use qemu-system-arm in accordance

with options “-M versatilepb” to emulate ARM

board for general-purpose Linux target. To analyze

the dynamic behavior of IoT malware, our proposed

system, Tamer, has three components. There are, 32-

bit ARM Linux machine for a sandbox where a target

sample is executed, the fake network where a sand-

box machine locates, an analysis tool to analyze the

execution trace log which can be obtained after exe-

cuting malware is ﬁnished. The execution trace log

records the full system activities and allows replay-

ing it for analysis. To support analysis using execu-

tion trace log, our system leverages PANDA (Dolan-

Gavitt et al., 2015), a framework that is built upon

the QEMU emulator, while we slightly modiﬁed it

for our purpose. Note that PANDA supports dynamic

binary instrumentation (DBI) and virtual machine in-

trospection (VMI). Thus, the current design of Tamer

leaves analysts an option to use advanced binary anal-

ysis techniques like taint analysis.

The fake network is a network whose setting is

controlled for malware analysis. This is a host-only

network and mainly serves two purposes. First, by

setting it as a closed network, it promises to prevent

attacking packets from going outside the network.

This feature is preferable to maintain safety for mal-

ware analysis. Second, since network routing in the

fake network is controllable by iptables, it allows

redirecting network connections from the sandbox to

the fake C&C server we set up. In short, these features

of the fake network allow observing network behavior

of malware in a safer manner, besides the fake C&C

server serves functionality to elicit network behavior

of malware. Finally, we show the speciﬁcations of the

machines inside our system in Table 2.

Figure 1 shows that how our system works by

combining those components described above. In our

system, ﬁrst, a target malware sample is put into the

sandbox machine or Linux. Then, the malware is

launched during a ﬁxed timeout (currently set 3 min-

utes) and the execution trace log is retrieved. To be

more precise, our proposed system allows observing

network behavior by using the fake C&C server even

if a C&C server where the target is supposed to con-

nect has already been closed. Finally, our analysis

tool analyzes execution trace and obtains dynamic in-

formation of malware.

In the rest of this section, we describe details to

make our system follow our concepts.

Tamer: A Sandbox for Facilitating and Automating IoT Malware Analysis with Techniques to Elicit Malicious Behavior

679

Host machine (ubuntu 14.04)

QEMU

Fake network

With iptables,

connections by malware are

redirected to the honeypot.

Tool analyzes execution trace

and obtains dynamic information.

After executing malware has finished,

execution trace log is obtained.

put

binary

(2) Execute malware on the sandbox in the Fake network

(3)

(4)

(5)Obtains output

Sandbox

(32-bit ARM Debian

Linux)

Fake C&C

server

(cowrie honeypot)

C&C channel

execution

trace

Analysis

result

Output

Analysis tool

(arm_syscallmon)

malware

input

(1)

Figure 1: Inside Tamer and analysis ﬂow.

172.20.0.1

xxx.xxx.xxx.xxx:8000

* fakedns redirects any traffic to this honeypot

* cowrie simulates SSH and Telnet

* inetsim simulates major network services

eth0

br0

172.20.222.240 172.20.100.100

Only access to the malware repository

is allowed.

tap1 tap2

Fake network

172.20.0.0/16

Host machine

(Malware repository)

Virtual switch by Tap interface

(controlled by iptables)

Fake C&C

Sandbox

machine

(ARM Linux)

Figure 2: Fake network to emulate C&C server.

3.1 Fake Network Environment

The fake network is a controlled network environment

for malware analysis and isolated from the Internet.

There are two advantages to use the fake network.

First, it prevents connections by malware to propa-

gate infection from going outside the network. This is

for conducting IoT malware analysis in a safer man-

ner. Second, it redirects connections from the sand-

box to the fake C&C server. This is for inspecting the

malware’s network behavior. Commonly, malicious

behavior of malware relies on C&C communication

therefore analyzing the network behavior is important

to understand malware. To make the fake network

isolated and accessible from a sandbox machine, we

carefully designed the routing setting with iptables.

The network in which the target malware is executed

is illustrated in Figure 2.

In order to set up the fake network, we ﬁrst cre-

ate a virtual bridge using brctl (LinuxFoundation,

2020) utility as shown in Figure 2. Then we cre-

ate two TUN/TAP interfaces, namely tap1 and tap2,

and bind both of them to the br0. This setting allows

the sandbox machine to access the malware repository

Table 3: Tools installed on Fake C&C.

Software Purpose

Cowrie honeypot SSH/Telnet listener

fakedns Respond to DNS query with fake IP addr

inetsim Emulate common network services

which is located outside the Fake network. We note

that this setting is for putting a target sample into the

sandbox machine. Of course, network connections

except for access to the malware repository are not

permitted.

On the other hand, the fake C&C server emulates

network services to handle requests from the sand-

box where a malware sample has launched. As de-

scribed above, network connections from the sand-

box are redirected to the fake C&C server. Table

3 shows software or tools that are installed on the

Fake C&C server. To handle SSH/Telnet connections

that are commonly requested by IoT malware, we

use Cowrie (Michel Oosterhof, 2014) honeypot which

serves as SSH/Telnet server. In particular, the major-

ity of IoT malware attempts to propagate through SSH

or Telnet. Moreover, the proposed system leverages

inetsim to emulate common network services. This

aims to handle requests that may be sent by malware.

Moreover, fakedns respond to DNS queries with the

IP address of the fake C&C server. This allows redi-

recting network connections using domain names.

3.2 Automated Interaction Mechanism

The proposed system has a mechanism to automat-

ically manipulate the sandbox machine, in this case

ARM Linux. The manipulation can be programmed

by a user. We developed a script to achieve this mech-

anism. Speciﬁcally, the script we developed leverages

the expect to automate interaction with the sandbox.

With this script, we manipulate the sandbox in an au-

tomated manner.

The aim of this feature is, for malware analysis,

it is necessary to operate the sandbox where a tar-

get malware is to be launched. To be more precise,

it needs at least 2 steps in the sandbox. Those steps

are namely, (1)putting a target sample in the sand-

box at ﬁrst, and then (2)executing it, as shown in Fig-

ure 1. In order to manipulate the sandbox, we lever-

age sendkey which is, a command which can be uti-

lized through the QEMU console

. This command in-

vokes keyboard events in the guest machine. With this

command, we can manipulate the sandbox or Linux

through keyboard operation.

https://en.wikibooks.org/wiki/QEMU/Monitor

ForSE 2022 - 6th International Special Session on FORmal methods for Security Engineering

680

wg et http :// < re posit or y ’ s ipad dr >: 80 00 / < FI LE NA ME >

-O ./ i otm al

ch mod + x iotm al

./ i ot mal

List 1: Example of steps to launch malware for dynamic

analysis.

( qemu ) b e gi n _re cor d iotmal_ < FI LE NA ME >_ < DA TE TI ME >

.. . w ai t for 3 mi nut es ...

( qemu ) e nd_ rec ord

List 2: Operation through QEMU console to save the

execution trace log for PANDA.

3.3 Automating Steps to Launch

Malware in the Sandbox

As described before, the automated interaction mech-

anism is one of the key features of our system. This

is actually an automatic interaction mechanism using

the expect, which can be attached from external the

QEMU. In other words, this is an ad-hoc solution and

easy to attach. From that point, this feature is dif-

ferent from existing approaches that rely on the con-

trol by an agent installed in the guest machine. In the

following, we describe the advantage of our system.

The advantage is that our system allows automating

several steps that are needed to be performed on start-

ing malware analysis. These steps are, for example,

putting a target binary into the sandbox machine and

then executing it. We describe these steps in the fol-

lowing.

In the Linux machine, a malware sample is down-

loaded before being executed. To do this, using the

expect module, commands (as shown in List 1) are

inputted in the Linux machine and executed. In the

List, once the sandbox machine downloads a ﬁle, it

gives the exec permission to the ﬁle and executes it.

Further, before the sample is executed, the proce-

dure for logging the execution trace is invoked. After

a ﬁxed timeout, currently set to 3 minutes, it stops the

logging, as shown in List 2.

3.4 External Tool for Analyzing

Dynamic Behavior of Malware

After executing malware in the sandbox is ﬁnished,

we can obtain the execution trace log. The execution

trace log is a ﬁle that records the entire OS events that

have been invoked in the guest machine. The system

events recorded in the execution trace can be replayed

on PANDA (Dolan-Gavitt et al., 2015) built upon the

QEMU. In short, here we analyze the replayed sys-

tem events. In order to analyze malware’s behav-

Table 4: Files accessed by IoTReaper with sys open.

Path

/tmp/client.run

/dev/watchdog

/dev/misc/watchdog

/etc/hosts

/etc/resolve.conf

ior, we developed a tool, named arm syscallmon,

to analyze the execution trace log. We developed

this analysis tool as a PANDA plugin. Currently, this

prototype focuses the main functionality on examing

syscalls that a target malware sample invoked. In de-

tail, arm syscallmon leverages dynamic binary in-

strumentation (DBI) to monitor instructions that in-

voke syscall in the guest machine upon the QEMU.

On the other hand, to identify the process of target

malware, it leverages virtual machine introspection

(VMI) to reference task struct data in the kernel.

4 EXPERIMENTAL EVALUATION

In this section, through several experiments to ana-

lyze the behavior of IoT malware, we demonstrate the

capability of Tamer from multiple perspectives. In

short, we show that Tamer performs features as fol-

lows:

• It allows retrieving information for understanding

dynamic characteristics of malware.

• It allows analyzing malware which is designed for

IoT devices.

4.1 Capability for IoT Malware

Analysis

In order to show the capability of our sandbox, this

experiment analyzes a malware sample and retrieves

dynamic characteristics or runtime information, such

as syscalls, ﬁles, unique strings, etc. As a sample

of IoT malware, we analyzed a real-world malware,

IoTReaper

(FortiGuard, 2017). This malware is no-

torious as a variant that targets IoT devices. Besides,

the only binaries found were ARM executables.

4.1.1 Use Case: System Call Monitoring

Through system call monitoring, the proposed system

obtains the information that relates to the dynamic

behavior of the target malware. This use-case aims

to understand about dynamic characteristics that the

malware will pose once it has launched, e.g., kind of

MD5: ca92a3b74a65ce06035fcc280740daf6

Tamer: A Sandbox for Facilitating and Automating IoT Malware Analysis with Techniques to Elicit Malicious Behavior

681

Figure 3: Fakedns returns IP address of Fake C&C.

syscalls, ﬁles that the malware will access, and data

that will be written into the ﬁle or left on the vic-

tim’s machine. In particular, the data that malware

has left on the system can be leveraged in order to de-

tect infection and remove malware from the system

(Bayer et al., 2006). Note that behavior analysis is

performed on the execution trace log which records

the entire system activity. The analysis tool we devel-

oped will examine the execution trace log and retrieve

information on the syscalls that were invoked during

the malware was running.

Next, we present some examples of the analysis

results obtained from analysis using Tamer. Here,

we focus on the arguments of the system calls. For

this, Tamer allows retrieving information that indi-

cates characteristics of malware’s behavior. As an ex-

ample, Table 4 shows details of ﬁles that a target mal-

ware tried to access. It is likely that information on

ﬁles accessed by malware is beneﬁcial to understand

the severity of the threat that the malware poses.

From the output we obtained from the proposed

system, we expect that these information can be use-

ful to understand the dynamic characteristic of the tar-

get malware. For instance, details of the ﬁles accessed

by malware brings insights to consider countermea-

sures against malware (as Cozzi et al. have conducted

an investigation to spot the light on the recent trend

of Linux malware (Cozzi et al., 2018)). This result

shows that our system reveals the runtime behavior

invoked IoT malware.

4.1.2 Use Case: Eliciting the Network

Fingerprint

This use-case aims to observe the malware’s dynamic

behavior from the network perspective. The beneﬁt

of network behavior analysis is that it allows obtain-

ing network data that are exchanged between malware

and the C&C server. In addition, this experiment also

supports evidence that the fake C&C elicits the net-

work behavior of malware by acting as a server that

receives data sent from malware.

As shown in Figure 4, our sandbox has retrieved

network data that the target malware was supposed to

Figure 4: Network behavior of IoTReaper requests com-

mands from adversary.

Figure 5: IoTReaper notiﬁes the adversary once it has been

launched in the victim machine.

send to a C&C server. At ﬁrst glance, these data are

intending requesting commands from a C&C server

controlled by an attacker (a target sample namely

IoTReaper is requesting a Lua script). These data

are seemingly characteristic and are expected to be

used as network signatures for detection. Similarly,

these characteristics can also be seen in the packets

used to notify the attacker that the IoTReaper has been

launched on the victim machine, as shown in Figure

5. This result shows that the fake C&C server enables

handling the connection from malware to retrieve the

network data sent from malware. To be more speciﬁc,

as described before, by crafting network routing with

iptables, the network connection that a malware ini-

tiates is redirected to a fake C&C server. For this, it

allows obtaining data sent by malware. In addition,

as shown in Figure 3, fakedns commits to redirect

malware’s connections by responding to DNS queries

with an IP address of the fake C&C server.

From these results, we have conﬁrmed that our

proposed sandbox system has successfully observed

network data that the malware generates. Actually, we

have obtained data that are characteristic. Besides, the

result shows that the honeypot we set up has served as

a fake C&C server. Those malicious network behav-

ior are not observable without the effort of the fake

C&C server, since in many cases, real C&C servers

ForSE 2022 - 6th International Special Session on FORmal methods for Security Engineering

682

Table 5: Dataset (family names are referenced from labels

by TrendMicro).

Malware family Number of samples

Trojan.Linux.MIRAI.SMMR1 100

Backdoor.Linux.GAFGYT.SMMR3 100

Backdoor.Linux.BASHLITE.SMJC 100

Total 300

wg et http :// < re posit or y ’ s ipad dr >: 80 00 / < FI LE NA ME >

-O ./ i otm al

ch mod + x iotm al

st rac e - tt -f - s 2 04 8 - y -o log . tx t ./ iot ma l

cu rl -T log . txt http :// < rep os it or y ’ s ipaddr > :8 000 /

lo g_i ot ma l_ < FILENAME > _ < D AT ET IM E >. tx t

List 3: Logging syscall with strace command for large scale

analysis.

where the malware connects to are already closed at

the time of analysis. In short, the fake C&C server

successfully served as a C&C server where the mal-

ware was supposed to connect. This result shows that

Tamer can retrieve network data generated by mal-

ware without the presence of an original C&C server.

4.2 Capability for Automation:

Example of Large Scale Analysis

One of the use cases of automated approach in mal-

ware analysis is to analyze a large number of sam-

ples and understand their population characteristics.

In this section, we show that the automation mecha-

nism of our system can analyze trends in IoT malware

characteristics.

On the dataset available from VirusShare, which

is namely referred to as VirusShare ELF 20200405,

we analyzed 100 samples for each family consisting

of Mirai, Gafgy, and Bashlite. Table 5 shows the de-

tails of our dataset consisting of Mirai, Gafgyt, and

Bashlite. According to searching VirusTotal with the

MD5 hash of ELF ﬁle, TrendMicro labeled each cat-

egory of samples as shown in the table. In total, we

have analyzed 300 samples.

Our analysis experiment is based on analyzing

system calls invoked by malware. First, once a target

malware sample fetched from our malware repository

is executed, syscalls are logged for a ﬁxed timeout

(set to 2 minutes). For monitoring system calls, we

use strace

, a utility that is appropriate for a large

scale analysis from the aspect of time efﬁciency and

the ease of setting. Next, after syscall logging is ﬁn-

ished, the output ﬁle by strace will be sent to the

repository to be saved. Then, the sandbox will be re-

stored to the original state using a snapshot. These

strace: linux syscall tracer. https://strace.io

[ [96 mB OT J OI NED [97 m] Ar ch : [96 m AR M4T [9 7 m ||

Ty pe : L I TTL E_E N DI A N ]

[* ] N 0D 3 1 NF3 CT 3D | |

\33 [0 ;32 mCo nne cte d | IP : < IP ADDR > | Type : S ER VER

| V ers io n : Buil d 2

List 4: Example of printable strings in notiﬁcation banner

(Bashlite).

PO ST /cgi - bi n / V iew Log . asp HTTP /1.1 H os t : < IP ADDR

>: 80 C onn ect ion : ke ep - ali ve Ac ce pt - Enc od i ng :

gzi p , de fl ate A cc ep t : */* Use r - A gent :

py thon - r equ est s / 2. 20. 0 Content - Len gt h : 227

Co nt ent - Type : a ppl ica t io n /x - www - fo rm -

url enc ode d / bi n / b usy bo x wg et ht tp :// < IP

ADD R > / l o ckf ile bin s . sh ; chmod + x l ock f il e bi n s .

sh ; ./ l ock f il e bin s . sh

List 5: Example of printable strings in HTTP requests (by

Bashlite).

steps are repeated for all samples. As a result, we can

be prepared to analyze system calls for all 300 target

samples.

In system call monitoring, we mainly focus on

system calls that relate to ﬁle access and network ac-

tivity. Thus, here we analyze invoked system calls

focusing on open, access and send. Our position is

that the details of ﬁles accessed by the malware are

important, since many malicious behaviors involve

ﬁle activity. Therefore, from the perspective of ﬁle

access behavior, we examine ﬁles opened or used by

malware. On the other hand, from the perspective of

network activity, we focus on the data that were sent

by malware. The reason is that oftenly network data

is characteristic and may indicate signs to infer the

adversary’s intention. In this experiment, the network

behaviors we focus on are namely notifying the suc-

cessful infection and HTTP requests. This is because

these two network behaviors are commonly exhibited

by IoT malware and oftenly indicate the printable data

that are characteristic. As examples, List 4 and List 5

show the network data that are sent by malware when

it has been executed in the victim machine.

To be more speciﬁc, our analysis is based on

examining arguments of syscalls. To analyze ﬁles

needed by malware, we examine arguments of open

and access. In particular, malware oftenly invokes

access to check if a speciﬁc ﬁle exists in the infected

machine. Further, to obtain the network data, we ex-

amine send to retrieve the data used in an argument.

The results of this experiment highlight what kind

of characteristics each family of IoT malware is likely

to exhibit. We describe examples as follows: First,

Table 6 summarizes ﬁles that the samples have ac-

Tamer: A Sandbox for Facilitating and Automating IoT Malware Analysis with Techniques to Elicit Malicious Behavior

683

Table 6: Interesting File paths in open by Mirai, Gafgyt and

Bashlite.

Path Mirai(%) Gafgyt(%) Bashlite(%)

/dev/misc/watchdog 67 80 19

/dev/watchdog 67 80 19

/dev/FTWDT101 watchdog 49 0 0

/proc/ 48 4 3

/proc/net/tcp 47 4 3

/dev/FTWDT101 watchdog 43 0 0

/proc/<PID>/fd 30 1 0

/proc/<PID>/exe 25 0 0

/proc/stat 23 0 11

/sbin/watchdog 20 0 0

/proc/<PID>/maps 19 3 3

/dev/watchdog0 15 0 0

/etc/default/watchdog 15 0 0

/dev/FTWDT101/watchdog 12 0 0

/bin/watchdog 11 0 0

/etc/watchdog 9 0 0

/proc/net/route 3 100 83

/etc/ld.so.cache 3 0 12

/etc/rc.d/rc.local 1 6 17

/etc/resolv.conf 0 0 16

Table 7: Files used in access.

Path Mirai(%) Gafgyt(%) Bashlite(%)

/usr/bin/python 2 80 43

/etc/ld.so.nohwcap 3 0 12

/etc/resolv.conf 0 0 16

/usr/sbin/telnetd 0 0 1

/usr/bin/apt-get 0 0 2

Table 8: Printable strings found in send for network activ-

ity.

Mirai(%) Gafgyt(%) Bashlite(%)

Notiﬁes infection 0 12 64

HTTP requests 0 8 21

/proc/stat

/bin/watchdog

/proc/<PID>/maps

/proc/net/tcp

/etc/watchdog

/proc/<PID>/exe

/dev/misc/watchdog

/dev/FTWDT101_watchdog

/dev/FTWDT101\ watchdog

/proc/<PID>/fd

/dev/FTWDT101/watchdog

mirai_01,1,0,1,1,0,0,1,1,0,1,0

mirai_02,1,1,1,0,0,0,1,1,1,0,0

mirai_03,1,0,1,0,0,0,1,1,1,0,0

mirai_04,1,1,1,0,1,0,1,1,1,0,1

mirai_05,0,1,0,0,1,0,1,1,0,0,1

mirai_06,1,0,0,0,0,0,1,1,1,0,0

mirai_07,1,0,0,1,0,0,1,1,1,0,0

mirai_08,1,0,1,0,0,0,1,1,1,0,1

mirai_09,0,0,1,1,0,0,1,1,1,1,0

Monitored ﬁles

(in the infected machine)

Features for each sample

(represents whether if opened a ﬁle or not)

Figure 6: Example of features used for hierarchical cluster-

ing.

cessed with “open”. For each ﬁle opened in the in-

fected machine, the table shows the number of sam-

ples which have accessed those. This table shows

the trend that Mirai variants tend to access various

ﬁles for the watchdog. On the other hand, as for

a ﬁle /proc/net/route including network informa-

tion, all the Gafgyt samples have accessed it. Such

a trend is also seen in the majority of Bashlite sam-

Figure 7: Example of hierarchical clustering in Mirai vari-

ants, split into three clusters.

ples. This result suggests that the details of ﬁles ac-

cessed by malware may be used to distinguish char-

acteristics for each family. Next, Table 7 summarizes

ﬁles that the samples accessed by invoking “access”.

From the table, it indicates that Gafgyt is more sensi-

tive to the presence of a ﬁle “/usr/bin/python” in

all families. In other words, this characteristic may

differentiate Gafgyt from other families. Next, Table

8 describes how many of the samples in each family

have posed the network behaviors speciﬁc to IoT mal-

ware. Note that these network behaviors handle net-

work data like List 4 and List 5. As shown in Table 8,

from network perspective, Bashlite tends to indicate

more characteristics than Mirai and Gafgyt. Overall,

this result indicates that the presence of network be-

havior differentiates Bashlite from other families.

Finally, we apply a hierarchical clustering method

to the features we obtained through a large scale anal-

ysis. This aims to retrieve further information on

the IoT malware family. As an example, we take 9

samples of Mirai and visualize their relationship as

a dendrogram. For this purpose, we ﬁrst focus on

some ﬁles opened by these Mirai samples as features.

Speciﬁcally, for each sample, we make a sequence

of binary representing whether if the sample opened

each ﬁle. Then, we use these sequences as features

(Figure 6) and apply hierarchical clustering to make a

dendrogram. To measure distances between samples,

we use Jaccard distance, like some studies (Jang et al.,

2011), since this is adequate in cases where binarized

data are used. Eventually, as shown in Figure 7, Mirai

variants can be split into multiple clusters. This re-

sult shows a possibility that our system can identify a

group of samples having similar dynamic characteris-

tics. Besides, this visualization indicates the charac-

teristics that malware may exhibit. The ﬁgure shows

that even though some malware samples are given the

same label (Trojan.Linux.MIRAI.SMMR1, actually),

they are slightly different from each other. Moreover,

ForSE 2022 - 6th International Special Session on FORmal methods for Security Engineering

684

!"!!!!#$%&''!()!*!+,''-./'012'31

!"!!!!#$%)''!!(&%(+#''1435'6712'012'892'1):

!"!!!!#$;!''!<=!<)+%''34='712'012'<

!"!!!!#$;<''><(!<(+%''34='312'312'!"><'''

!"!!!!#$;&''?!!!!=+$''3@9'9!2'A/*9B?!5C''

!"!!!!#$;)''&)!!#7+$''8(9'9!2'3@9D5@@13EBB8-F@7GD).-BBHB5.IB@.BJJJK

L5@@13EMM8-F@7GD).-MNHO5.IP@.PJJJL'QO'R+=30@+'31+)070+('=G'-*8I*9+'

*4@5.9

!"!!!!#$<!''7<7+77+=''=8'3G-D0-1D14@3''

!"!!!!#$<<''?!;!,=+$''8(9'9;2'A/*9B?!5C''

!"!!!!#$<&''!!;!#;+$''8(9'9;2'A9;C

!"!!!!#$<)''%(%!<=+%''34='9%2'712'!"%(

!"!!!!#$$!''!;!!*!+,''-./'9!2'9;

!"!!!!#$$<''!%,!*!+,''-./'9,2'9%

!"!!!!#$$&''!#7777+=''=8'3G-D0-1D9+*81*@5

Figure 8: A portion of the identiﬁed code block of Amnesia

(This example uses radare2 for the display.).

this result actually supports evidence that analyzing

a large number of samples allows retrieving more in-

sights than a case only analyzing a single IoT malware

binary. We expect that, by focusing on the character-

istics that malware is likely to exhibit, it allows ana-

lysts to understand the severity of the threat.

4.3 A Case Study of DBI/VMI: Identify

the Malware Behavior

This experiment shows advantages of DBI/VMI that

Tamer can support. For this experiment, we take the

analysis of Amnesia

, an IoT malware. According

to experts (Unit42, 2017), this malware has the de-

structive functionality to delete all ﬁles once it de-

tects the analysis environment by checking for spe-

ciﬁc ﬁles(e.g. /sys/class/dmi/id/sys_vendor) .

Identifying malware behavior automatically is in-

sufﬁcient to traditional analysis methods. Traditional

analysis methods, like monitoring system calls and

network data, focus only on information about indi-

vidual actions. There is a challenge that a single ac-

tion is not insufﬁcient, and it is necessary to take mul-

tiple actions into account. Therefore, we expect that

such a situation requires using advanced binary tech-

niques like DBI/VMI.

For this experiment, in order to identify malware

behavior by taking multiple system actions into ac-

count, we apply dynamic taint analysis (Schwartz

et al., 2010) that is based on DBI/VMI. Speciﬁcally,

we hooked a invokation of system call when the mon-

itored ﬁle(/sys/class/dmi/id/sys_vendor) was

read, and set that data to be tracked. By tracking data

ﬂow using taint analysis, instructions related to op-

erations on the data in the monitored ﬁle can be col-

lected. As a result, we obtained information about

instructions that are included in a basic block of the

destructive function of Amnesia. This result supports

evidence that, by tracking data ﬂow, it is feasible to

extract information to identify the type of malware

MD5: 1497740fa8920e4af6aa981a5b405937

behavior. Finally, Figure 8 shows an example of the

outcome extracted by Tamer. This ﬁgure shows the

code block involved in operating the monitored ﬁle.

5 DISCUSSION

5.1 Applications for Generating Dataset

Our sandbox serves functionalities that can ﬁnd ap-

plications in some security ﬁelds. We describe some

cases in the following: First, one example is based on

a perspective of network-level detection. We assume

that our sandbox can be leveraged to collect network

ﬁngerprints. As described in Section 4, our system is

capable of observing some parts of network interac-

tion between the malware and the C&C. In particular,

the characteristics of the network trafﬁc generated by

malware can be applied to build a signature for de-

tection. Next, from a perspective of host-based detec-

tion, we expect that the researcher uses our sandbox to

generate a dataset about host-based behavior. For in-

stance, as shown in Section 4, we have demonstrated

that our sandbox allows retrieving a list of syscalls

that the target malware invoked.

5.2 Limitations

Our sandbox system is based on QEMU emulator.

This means that, if malware detects being executed

inside the QEMU, it may change the behavior to hin-

der behavioral analysis. While the evasion malware

problem is out of scope for this paper, some previous

works have explored insightful knowledge (Bulazel

and Yener, 2017). On the other hand, the drawbacks

against VM evasion malware are an inevitable subject

on debating about malware analysis methods. There-

fore, we hope that our approach will also be consid-

ered as an alternative method for analyzing malware.

Besides, regarding evasion techniques of mal-

ware, there is a possibility that our system could be

thwarted when malware detects PTRACE used by

strace. As for this, we acknowledge that collect-

ing system behavior using strace is straightforward.

Thus, it is necessary to keep considering another tech-

nical option that could complement the disadvantages

of our technical choice. For instance, eBPF (eBPF,

2020), installed in the modern Linux kernel, allows

running monitoring programs in the kernel so that it

may be expected as a more advanced system monitor-

ing method than strace.

Moreover, as for network behavior analysis by

Tamer, we acknowledge that the analysis outcomes

for network behavior (like shown in Section 4.3) are

Tamer: A Sandbox for Facilitating and Automating IoT Malware Analysis with Techniques to Elicit Malicious Behavior

685

Table 9: The differences of functionalities between Tamer and Linux-based sandboxes.

Support

ARM

Support

Multi-architecture

Support

C&C listener

Support

DBI/VMI

Limon(Monnappa, 2015) No No Yes No

Cuckoo(Cuckoo, 2013) No No No No

IoTBOX(Pa et al., 2016) Yes Yes No No

V-Sandbox(Le and Ngo, 2020) Yes Yes Yes No

Tamer Yes No Yes Yes

only a part of the network data of the malware and the

current design of our fake network is simple. Thus, to

elicit deeper conversation between malware and C&C

server, it could require more elaborate efforts, like

the protocol reversing to generate the exact command

data accepted by the target malware.

5.3 Comparison with Similar Studies

We describe the differences between Tamer and ex-

isting studies. First of all, while the sandbox for

IoT malware has received less attention, we witnessed

some studies that handled the analysis environment

for IoT malware. Pa et al. (Pa et al., 2016) have

proposed IoT sandbox (IoTBOX) which analyzes the

Telnet-based attacks against various IoT devices run-

ning on various CPU architectures including x86,

ARM, MIPS, and so on. Their work mainly aims for

analyzing network behavior, however, our aim is on

analyzing IoT malware characteristics from perspec-

tives of network-level and host-level. Le et al. have

proposed V-Sandbox (Le and Ngo, 2020) for dynamic

analysis of IoT botnet. Besides, V-Sandbox supports

analyzing binaries for various CPU architecture, and

provides C&C server simulator to support the abil-

ity to make C&C connections. We acknowledge that,

different from IoTBOX and V-Sandbox, our system

does not support multi-architecture CPUs. However,

Tamer combines advanced binary analysis techniques

such as DBI and VMI that are not supported by pre-

vious works.

Further, though they are not necessarily referred

to as sandboxes, related to dynamic analysis for IoT

systems, Avatar (Zaddach et al., 2014) and its succes-

sor Avatar2 (Muench et al., 2018) are sophisticated

frameworks to tackle complex problems in dynamic

analysis for embedded system ﬁrmware. In particu-

lar, Avatar(s) act as a software proxy between QEMU

and the physical hardware in order to allow analyz-

ing embedded system’s behavior involving operation

to the physical device. But, we assume that Avatar(s)

are not necessarily suited for automated analysis since

they require to be conﬁgured for situations depending

on the physical devices.

Overall, Tamer serves another perspective from

existing studies. We acknowledge that this study ben-

eﬁts from existing technologies, but we have assem-

bled these into a unique combination. Thus, we as-

sume that Tamer may act as another option for IoT

malware analysis. Furthermore, in the current proto-

type, Tamer supports IoT malware analysis only for

the ARM. But, we believe that our approach based

on the auto-manipulation using expect can be gener-

alized to other architectures, like we conduct analysis

with strace in Section 4.3. Finally, a summary of the

diffrerences between Tamer and existing Linux-based

sandboxes are shown in Table 9.

6 CONCLUSION

This paper presents a sandbox system for analyzing

Linux malware samples that infect IoT devices. Our

sandbox, called Tamer, has some features to auto-

mate and facilitate IoT malware analysis, like the au-

tomated interaction mechanism using the expect util-

ity and the fake network environment that we care-

fully designed. Moreover, Tamer adopts features

like DBI and VMI in a unique combination, which

may allow more advanced analysis. We demonstrated

that our sandbox system can analyze IoT malware

(e.g. IoTReaper, Amnesia) that are designed to in-

fect IoT devices. Through a large scale analysis,

we have demonstrated that our system can analyze a

large amount of IoT malware samples in an automated

manner, and highlight recent trends in IoT malware.

From the analysis result, we have suggested a pos-

sibility that our system can identify a group of sam-

ples having similar dynamic characteristics. We ac-

knowledge that further development and evaluation is

needed to support our claim. In our future work, we

will extend performing analysis on a large volume of

malware and focus on extracting useful information

for malware countermeasure in more detail. We hope

that our study fosters discussion about the methodol-

ogy to understand the dynamic characteristics of IoT

malware.

ForSE 2022 - 6th International Special Session on FORmal methods for Security Engineering

686

REFERENCES

Bayer, U., Moser, A., Kruegel, C., and Kirda, E. (2006).

Dynamic analysis of malicious code. Journal in Com-

puter Virology, 2(1):67–77.

Bulazel, A. and Yener, B. (2017). A survey on auto-

mated dynamic malware analysis evasion and counter-

evasion: Pc, mobile, and web. In Proceedings of the

1st Reversing and Offensive-oriented Trends Sympo-

sium, pages 1–21.

Carrillo-Mond

ejar, J., Mart

ınez, J., and Suarez-Tangil, G.

(2020). Characterizing linux-based malware: Find-

ings and recent trends. Future Generation Computer

Systems, 110:267–281.

Cozzi, E., Graziano, M., Fratantonio, Y., and Balzarotti, D.

(2018). Understanding linux malware. In 2018 IEEE

symposium on security and privacy (SP), pages 161–

175. IEEE.

Cozzi, E., Vervier, P.-A., Dell’Amico, M., Shen, Y., Bilge,

L., and Balzarotti, D. (2020). The tangled genealogy

of iot malware. In Annual Computer Security Appli-

cations Conference, pages 1–16.

Cuckoo (2013). Automated Malware Analysis. https:

//www.cuckoosandbox.org/.

Debian.org (2014). “Debian Squeeze and Wheezy

armel images for QEMU”. https://people.debian.org/

∼

aurel32/qemu/armel/.

Dolan-Gavitt, B., Hodosh, J., Hulin, P., Leek, T., and Whe-

lan, R. (2015). Repeatable reverse engineering with

panda. In Proceedings of the 5th Program Protection

and Reverse Engineering Workshop, page 4. ACM.

eBPF (2020). “eBPF - Introduction, Tutorials & Commu-

nity Resources”. https://ebpf.io/.

FortiGuard (2017). Reaper: The Next Evolution of IoT Bot-

nets. https://www.fortinet.com/blog/threat-research/

reaper-the-next-evolution-of-iot-botnets.

inetsim (2020). “INetSim: Internet Services Simulation

Suite”. https://www.inetsim.org/.

Jang, J., Brumley, D., and Venkataraman, S. (2011). Bit-

shred: feature hashing malware for scalable triage and

semantic analysis. In Proceedings of the 18th ACM

conference on Computer and communications secu-

rity, pages 309–320.

Le, H.-V. and Ngo, Q.-D. (2020). V-sandbox for dynamic

analysis iot botnet. IEEE Access, 8:145768–145786.

LinuxFoundation (2020). “networking:bridge [Wiki]”.

https://wiki.linuxfoundation.org/networking/bridge.

Michel Oosterhof (2014). “Cowrie SSH/Telnet Honeypot”.

https://github.com/cowrie/cowrie.

Monnappa, K. (2015). Automating linux malware analysis

using limon sandbox. Black Hat Europe 2015.

Muench, M., Nisi, D., Francillon, A., and Balzarotti, D.

(2018). Avatar2: A multi-target orchestration plat-

form. In Proc. Workshop Binary Anal. Res.(Colocated

NDSS Symp.), volume 18, pages 1–11.

Pa, Y. M. P., Suzuki, S., Yoshioka, K., Matsumoto, T.,

Kasama, T., and Rossow, C. (2016). Iotpot: A novel

honeypot for revealing current iot threats. Journal of

Information Processing, 24(3):522–533.

Schwartz, E. J., Avgerinos, T., and Brumley, D. (2010). All

you ever wanted to know about dynamic taint anal-

ysis and forward symbolic execution (but might have

been afraid to ask). In Security and privacy (SP), 2010

IEEE symposium on, pages 317–331. IEEE.

Unit42, P. A. N. (2017). New IoT/Linux

Malware Targets DVRs, Forms Bot-

net. https://unit42.paloaltonetworks.com/

unit42-new-iotlinux-malware-targets-dvrs-forms-botnet/.

VirusShare (2020). “VirusShare”. https://virusshare.com/.

Willems, C., Holz, T., and Freiling, F. (2007). Toward au-

tomated dynamic malware analysis using cwsandbox.

IEEE Security & Privacy, 5(2):32–39.

Zaddach, J., Bruno, L., Francillon, A., Balzarotti, D., et al.

(2014). Avatar: A framework to support dynamic se-

curity analysis of embedded systems’ ﬁrmwares. In

NDSS, volume 23, pages 1–16.

Tamer: A Sandbox for Facilitating and Automating IoT Malware Analysis with Techniques to Elicit Malicious Behavior

687