V-Sandbox for Dynamic Analysis IoT Botnet

With the increasing use of resource-constrained IoT devices, the number of IoT Botnets has exploded with many variations and ways of penetration. Nowadays, studies based on machine learning and deep learning have focused on dealing with IoT Botnet with many successes, and these studies have required relevant data during malware execution. For this, the sandbox environment and behavior collection tools play an essential role. However, the existing sandboxes do not provide adequate behavior data of IoT botnet such as the C&C server communication, shared libraries requirements. Moreover, these sandboxes do not support a wide range of CPU architectures, data is not exhaustively collected during executable file runtime. In this paper, we present a new practical sandbox, named V-Sandbox, for dynamic analysis of the IoT Botnet. This sandbox is an ideal environment for IoT Botnet samples that exhibit all of their malicious behavior. It supports the C&C servers connection, shared libraries for dynamic files, and a wide range of CPU architectures. Experimental results on the 6141 IoT Botnet samples in our dataset have demonstrated the effectiveness of the proposed sandbox, compared to existing ones. The contribution of this paper is specific to the development of a usable, efficient sandbox for dynamic analysis of resource-constrained IoT devices.


I. INTRODUCTION
In recent years, the security of IoT devices has been of great interest to many researchers since a large number of IoT devices have been attacked and exploited vulnerabilities [1]- [6]. With the rapid growth in number [7] and less attention to information security [8]- [10], IoT devices gradually become an attractive target for attackers.
There are many criteria for classifying IoT devices, such as device connectivity, device manufacturers, etc. In this paper, based on Bencheton's classification approach [11], IoT devices are divided into resource-constrained and high-capacity ones. Furthermore, we propose a sandbox to deal with resource-constrained IoT devices for the following reasons: • Due to resource-constrained (such as CPU, RAM, Flash memory, etc.), it is not trivial to integrate threat detection/protection solution in these devices.
Resource-constrained devices have become an attractive target for hackers with many new variants of Botnets. Therefore, this field is a big challenge for researchers to deal with IoT Botnet detection for these devices.
The associate editor coordinating the review of this manuscript and approving it for publication was Chunhua Su .
• Using machine learning/deep learning in dynamic analysis of IoT botnet, researchers need to collect malicious behavior. However, existing sandboxes do not provide fully behavior data of this malware, especially the C&C servers connection, shared libraries for dynamic files, and a wide range of CPU architectures. Malware on IoT devices not only spreads on individual personal devices but also targets businesses, organizations, and governments with increasing severity [12]. Kaspersky's statistics show that there were more than 100 million attacks on IoT devices in the first half of 2019, a 7-fold increase compared to the same period in 2018 [13]. Addressing the risks above, malicious researchers have developed new methods and frameworks to effectively analyze and detect malware samples on IoT devices [14]- [25]. These studies can be divided into two main groups, which are static analysis [14]- [19] and dynamic analysis [20]- [25].
As in [19], [25], authors have presented the static analysis method, which allows full control of the control flow (CFG) and data flow (DFG) to detect malicious code by specific analytical techniques such as byte code, system calls API or Printable Strings Information (PSI) [19], [26]. This method allows a detailed analysis of files and gives the activation capabilities of malicious code [27]. However, the static analysis method is challenging to apply to malicious code using complicated techniques (obfuscation) or difficult to collect samples because malicious code is only stored on the device's Random Access Memory (RAM) [7]. According to Andreas Moser [28], the static analysis method should be used as a complement to the dynamic analysis method.
Dynamic analysis is a method of monitoring, collecting, and analyzing system behaviors to detect malicious code [29]. One of the most popular approaches nowadays is to use machine learning/deep learning. These approaches are necessary to collect relevant data during malware execution. In general, this step requires an adequate sandbox to monitor the behaviors of executable files. Collected data plays an essential role in the accuracy of detecting malicious behaviors.
There are many studies on building sandboxes for IoT devices, but most focus on IoT devices running Android operating systems (smartphones, smart TVs, etc.) [26]- [30]. The reason is that Android devices have powerful and sufficient resources (CPU, RAM, Disk, GPU) to easily create simulation environments for dynamic analysis (Android SDK, Virtual Box, VMware, KVM, etc.). The problem of building a sandbox for resource-constrained IoT devices has not been given much attention.
There are several researched and developed sandboxes for IoT devices that can be mentioned, such as [35]- [41]. The survey of these IoT sandboxes is presented in section II-C. However, these sandboxes have some limitations, such as they do not support a wide range of CPU architectures, and data is not fully exhaustive collected during executable file runtime; the emulation environment does not provide crucial components such as C&C server simulator and shared libraries dynamically. In this paper, we focus on developing sandbox for resource-constrained IoT devices targeting IoT Botnet detection.
To overcome the above limitations, the proposed IoT Sandbox meets the following criteria: • Support for a wide range of CPU architectures; • Autoconfiguration of emulation environment to run executable files; • No effect on the external environment; • Provision libraries (shared objects) that the executable file requires; • Provision a fully simulated network environment for IoT malware such as connecting to the C&C server, transmitting and receiving commands from the C&C server; • Behavior monitoring of IoT malware affecting the sandbox environment (system calls, files, folders, network traffic, hardware performance, etc.).
Our main contributions are: • Summarize a set of dynamic features needed to detect IoT Botnet based on surveying research results by using machine learning to detect IoT botnet dynamically. After that, assess the existing IoT Sandboxes based on the proposed set of dynamic features, thereby proposing a sandbox architecture to overcome the existing shortcomings.
• Develop an adequate IoT sandbox for IoT Botnet detection.
• Evaluate and prove the effectiveness of the sandbox on the data set of 9069 samples obtained with 6141 malware and 2928 benign samples.
The structure of this paper is as follows: section II consists of the background and survey of related works, section III describes the proposed architecture, section IV experiments and evaluates the results, section V discusses the results, and section VI concludes the paper.

II. RELATED WORK AND BACKGROUND
In this section, we will discuss the characteristics of IoT Botnet as well as the researches related to applying machine learning to the dynamic analysis of IoT Botnet and sandboxes for existing IoT devices.

A. OVERVIEW OF IoT BOTNET
According to Cisco forecasts, by 2020, there will be about 50 billion devices connected to the Internet, and this number will increase to even more [7]. As its number is increasing, IoT devices gradually become an attractive and accessible environment for hackers to attack. In the world, many studies have shown the danger from malicious code on IoT devices (IoT Botnet) such as Bashlite, Mirai, Tsunami, Psyb0t [8]. In particular, with more than 1 million infected devices, including IP cameras, DVRs, and routers, Bashlite malicious code can launch DDoS attacks up to 400 Gbps through simple techniques like UDP or TCP Flood [8]. Bashlite malicious code is considered the precursor to Mirai, and the malicious code affects a wide variety of IoT devices. The Mirai Botnet network used in the DDoS attacks reached a record of 1.1 Tbps, with more than 100,000 IoT devices for home use [10].
By focusing on analyzing 16 families of IoT Botnet, discovered from 2008 to 2018, Vignau et al. [42] identified IoT Botnet as a significant threat to the IoT ecosystem, and malicious behaviors focused on launching a DDoS attack, characterized by Botnet. Nguyen et al. [19], Angrishi [8], and Kolias et al. [1] also presented behavioral features of the IoT Botnet, including: • Scan for appropriate targets: Malware performs a random scan of IP addresses with commonly targeted service ports, such as Telnet or SSH.
• Gain access to other vulnerable devices: Bots engage in brute force attacks to discover the default login credentials of weakly configured IoT devices.
• Infect IoT devices: After logging into the device, the bot infects the loader used to download and execute the corresponding binary version of the botnet, usually via FTP, HTTP, etc.
• Communicate with the C&C server via IP address or URL: IoT Botnets try to connect and relay various device VOLUME 8, 2020 features, such as IP address and hardware architecture, to the reporting server via another port.
• Wait and execute commands: The bot goes into the main execution loop first, which establishes a connection with the C&C server and keeps it alive, waiting for the next commands. If an attack command is received, the corresponding routine is called, and the attack is executed.
With these characteristics, many researchers have come up with methods to analyze and detect IoT Botnet. Section II-B focuses on analyzing research findings using dynamic analysis of the IoT botnet.

B. RELEVANT FEATURES FOR IoT BOTNET DETECTION
In this section, we present a survey on IoT Botnet for both resource-constrained as well as high-performance IoT devices. The dynamic analysis could be classified into two main family methods: network-based intrusion detection system (NIDS) and host-based intrusion detection system (HIDS) method.
Dynamic analysis studies to detect IoT Botnet mainly focus on network traffic analysis to find out the characteristics for building NIDS [43]- [48], similar to traditional malware analysis running on i386. The drawback of these studies is that malware is only detected when the device has been successfully infected and becomes part of the IoT Botnet network. To overcome the above disadvantages and to detect the possibility of an early attack, it is recommended to monitor the behavior of malicious code from the beginning of affecting the target device to infection using HIDS. Traditional HIDS can monitor software activities on computers to detect whether or not it is malicious. However, traditional HIDS is ineffective with resource-limited IoT devices (such as IP cameras, smartwatches, smart lamps). There are not many studies analyzing IoT Botnet behaviors on IoT hosts to build IoT HIDS [25], [49], [50]. Building an environment for IoT behavioral analysis Botnet's impact on IoT devices restricts resources with difficulties such as diverse and inconsistent IoT hardware platforms, the firmware of the closed device comes with the device or is available via the manufacturer's website.
The sandbox for these IoT devices is in the research and development stage (presented in section II-C). In this section, we will discuss the most relevant researches related to the use of machine learning in dynamic analysis of IoT Botnet. We also study behavioral analysis studies affecting a host of IoT malware to be applied to research problems. From there, we are orienting the requirements to be able to build the sandbox for analyzing IoT Botnet dynamically.
Doshi et al. [51] proposes a NIDS model for DDoS detection in network data streams connecting IoT devices by low-cost machine learning algorithms (including KN, LSVM, DT, RF, NN) with more than 98% accuracy. Doshi recommends using network stream characteristics such as Packet size, Inter-packet Interval, Protocol, Bandwidth, IP destination address cardinality, and novelty.
Indre and Lemnaru [52] proposes a solution that combines features extracted from network packets, focuses on analyzing data from the URI and RESTful methods, and proposes features based on the characteristic set of the KDD99 dataset. 1 Experimental results show that the typical set of Indre proposes to use with Passive Aggressive Classifier [53] achieves 98.4% accuracy. However, the KDD99 dataset has mainly collected data on computer network attacks since 1999. At this time, IoT Botnet has not appeared yet. Therefore, identifying the IoT Botnet based on the KDD99 dataset is not adequate.
Prokofiev et al. [43] presents the NIDS model using logistic regression for IoT devices with an accuracy of 97.3%. To create the logistic regression model the following network traffic features were selected: destination port, source ports, number of requests, even number of requests, mean interval between requests, requests on other ports, mean size of packets, delta for packet size, mean entropy of packets, alphanumeric.
Wu et al. [48] uses the IoTBOX sandbox [36] to execute IoT Botnet samples in the dataset, and proposes the model of learning sequential sequences of Shell commands to detect IoT Botnet with approximately 90% accuracy. The limitation of Wu's proposed model is that the use of a large deviation training data set (300 Gayfgt logs, 51 log nttpd, 2430 log Zorro) results in inaccurate prediction models. The IoTBOX sandbox, with the weakness shown in the section below, is presented as the second limitation of this study.
In addition to the above NIDS, studies using HIDS for detection of IoT botnets will be discussed below.
Breitenbacher et al. [56] presents a practical HIDS that requires low power for IoT devices to detect malicious code. Hades-IoT IDS uses data about system calls to detect malicious behavior with 100% accuracy. But, this experimental result is only applied on limited data sets (2 types of IoT devices with 7 device models and two malicious samples are too few to prove). Features used in Hades-IoT IDS include names, addresses, and parameters of system calls.
Ham et al. [21] applies the SVM classification algorithm to detect malware on Android devices with 99.7% accuracy. In this paper, Ham selects 32 features from the 88 features that Shabtai presents [32]. However, collected data agents are installed directly onto real devices to collect data, resulting in restrictions on expansion for many different hardware devices and operating system versions. In addition, 32 selected features are only suitable for 14 families of malware in the Dataset, which reduces detection with newly emerging malware samples.
Shabtai et al. [32] introduces a malware detection framework, named Andromaly, on Android mobile devices with 98.18% accuracy. The advantage of this framework is that it is lightweight, can run on real devices, consume fewer resources, and is almost transparent to the system. The author has selected useful features for malware detection through the results of testing the samples included in the data set. However, the small number of samples in the dataset (4 malware and 40 benign) leads to the selection of non-optimal features (88 features selected for detection). Besides, many features are only allowed to collect for real devices such as Keyboard_Backlight, LCD_Backlight, Blue_Led, Green_Led, Red_Led, Camera, USB_State, Standard Print_Calls, Out Send_Calls, Missed_Calls, Out send_Non_CL_Calls.
Azmoodeh et al. [57] proposes a machine learning model to detect ransomware attacks by monitoring the power consumption of IoT nodes. The machine learning algorithm used is KNN in combination with DTW for accuracy of 95.65%. The proposed Azmooded method allows ransomware to be detected on real ARM devices (Samsung Galaxy SIII, Samsung Galaxy S Duos, Asus Padfone Infinity). However, this study has two limitations: the dataset used has too few samples (6 ransomware and 12 benign), and the collection characteristics are required to be extracted from real devices, challenging to implement in replication in reality.
Ficco et al. [58] proposes machine learning models that use API call sequences for the classification of the IoT Botnet. This model with an F-measure is 89% (Naive Bayes algorithm) on a dataset. In this model, Ficco collects API calls from executed applications to build Call Dependency Graph and Calls tree. From there, Ficco extracts the appropriate feature into the Markov Chain behavioral model to classify the IoT Botnet. However, using the mobSF tool [59] to extract features that lead to a limitation of this study is only suitable for devices running Android, challenging to extend to other embedded operating systems of IoT devices.
From the above studies, an adequate sandbox must provide at least the following main feature types: system calls, extended information of system calls (EXINFO), network traffic, host performance. Based on the accuracy of machine learning algorithms applied by the authors on these features, we summarize a set of practical dynamic features for analyzing and detecting IoT Botnets described in Table 2. Particularly for network traffic features, the author chooses the features of the UNSW-NB15 data set [55] based on Janarthanan's results [60].

C. OVERVIEW OF IoT SANDBOX
A survey of the characteristics, advantages, and disadvantages of IoT sandboxes is presented in the following content: Yan and Yin [30] presents DroidScope, an Android malicious code analysis platform. The architecture of the Droid-Scope is shown in Fig. 1. The entire Android software system runs on the QEMU emulator, and the analysis is done from the outside. DroidScope extracts OS-level semantic knowledge: system calls and running processes, including threads and memory maps, with Java level getting the current Dalvik virtual machine program counter and frame pointer, all virtual registers. (its operands and their values). To analyze Android malware, it has implemented four analysis plugins such as API tracer, Native instruction tracer, Dalvik instruction tracer, and Taint tracker.
Bläsing et al. [31] proposes an Android Application Sandbox (AASandbox), monitors the name of system calls, and library calls on ARM architecture, including their arguments and return value. However, the effectiveness of AASandbox has not been clearly demonstrated with only 150 test samples. Also, using the Android SDK to build the simulation environment and Android Monkey to allow interaction with the template results in the ability to customize the running environment and collect the full range of malicious behavior. In Fig. 2, the system monitoring results of AASandbox are described. Each line has five values, including timestamp, used system call, return value, an ID of the process, and ID its parent. The author describes the architecture of AASandbox in Fig. 3.  Oktavianto and Muhardianto [35] develops Cuckoo Sandbox, which is a dynamic analysis system consisting of two main components: Cuckoo Server, and Cuckoo Host. The architecture of Cuckoo Sandbox is described in Fig. 4. The analysis is performed using the automated scripts available that Cuckoo Host required to perform during the analysis of the target application. Cuckoo is heavily dependent on Python, and there are some Python applications needed to run Cuckoo properly (Magic, Pydeep, Yara, Pefile). Therefore, using Cuckoo with environments that do not fully support Python will face a few difficulties. Cuckoo Sandbox gives good results analysis for the X86 architecture. For analyzing Linux malware, Cuckoo Sandbox shows a lack of features.
Liu et al. [61] uses Cuckoo Sandbox to perform dynamic analysis to extract host behaviors and network behaviors of IoT botnet samples (Mirai, Satori, OMG, and Wicked). However, the results extracted from Cuckoo Sandbox mainly obtained network behaviors.
Pa et al. [36] proposes an IoT honeypot (IoTPOT) and sandbox (IoTBOX), which attracts and analyzes Telnet-based attacks against various IoT devices running on eight different CPU architectures such as MIPS, MIPSEL, PPC, SPARC, ARM, MIPS64, sh4, and X86. The architecture of the IoT-BOX Sandbox shown in Fig. 5. Yin uses QEMU [62] to build cross-compilation environments for different CPU architectures and the respective OpenWrt platform to run on the FIGURE 1. DroidScope's architecture [30].  emulated CPU environment. Then, the virtual bridge and the access controller are used to create a virtual networking environment. Through this virtual networking environment, IoTBOX can collect network traffic generated by the samples. In practice, the author only ran 52 samples on 3 CPU platforms, of which five samples failed to run. IoTBOX has only focused on monitoring network behavior, and the remaining behaviors are not mentioned.
Uhricek [43] raises the limitations of Sandbox such as Limon [38], REMnux [39], Detux, Padawan [40] including  support for less CPU architecture, incomplete information gathering, etc. That is the motivation for Daniel Uhricek to introduce Linux Sandbox LiSa [41], which helps analyze Linux malware on MIPS, ARM, Intel 80386, x86-64, Aarch64 architectures. By tracking behaviors such as system calls, opening or deleting files, creating processes, network traffic of 150 IoT botnet samples (mostly for ARM and MIPS architectures), Uhricek demonstrates the efficiency of LiSa. LiSa uses SystemTap to collect system information to create process trees, trace syscalls, and mark open or deleted files. To collect network data, Uhricek uses Scapy and dpkt libraries. However, the role of a C&C server that is very important to demonstrate the behavior of IoT Botnet fully is not developed by Uhricek. Therefore, the behaviors of IoT botnet samples collected from LiSa are incomplete. Additionally, dynamically linked templates running on LiSa often fail due to the lack of proper libraries.
In Table 3, we summarize the descriptions and supported features (described in Table 2) of these IoT sandboxes. The main drawbacks of above sandboxes are:  Table 2) are not fully exhaustive collected during executable file runtime; 2) Do not support communication with the C&C server; 3) Do not provide shared libraries. Therefore, we will build an adequate sandbox that addresses these drawbacks. The proposed approach is presented in the next section.

III. THE PROPOSED V-SANDBOX
To give a better understanding of our proposed sandbox, we use a sample of IoT Botnet Mirai through each step of the data collection process. Mirai is one of the most popular IoT Botnet families, causing DDoS attacks with ground up to 1.1 Tbps of traffic in September 2016 [1]. Mirai easily infects IoT devices such as webcams, DVRs, routers, and IP cameras. There are times when the number of simultaneously infected devices ground to 400000.

A. OVERVIEW
Resource-constrained IoT devices play an important role in trend Internet of Things and are vulnerable to attacks. When analyzing and defending against these attacks, C&C servers connection, shared libraries for dynamic files and a wide range of CPU architecture and other capabilities and indicators are very necessary. However, the existing sandbox cannot satisfy them. Therefore, V-sandbox is proposed to solve this problem. The proposed approach described in Fig. 6 This information can be extracted from the metadata of the input file. The environment in which our V-Sandbox focuses on Unix includes GNU/Linux and BSD. The format of executable files in this environment is ELF, the Executable and Linkable Format. The basic architecture of the ELF file is shown in Fig. 7. ELF files are divided into three types [63]: • Executable files: containing code and data suitable for execution. This specifies the memory layout of the process image of the program.
• Relocatable (object) file: containing code and data suitable for linking with other object files to create an executable or a shared object file.
• Shared object files (shared library): containing code and data suitable for the link editor (ld) at the link-time and the dynamic linker (ld.so) at runtime. In particular, metadata of ELF is recorded mainly in the header. The ELF header is 32 bytes long and identifies the format of the file. It starts with a sequence of four unique bytes that are 0 × 7F followed by 0 × 45, 0 × 4c, and 0 × 46 which translates into the three letters E, L, and F. Among other values, the header also indicates whether it is an ELF file for 32-bit or 64-bit format, executable or not, uses little or big endianness, shows the ELF version as well as for which operating system the file was compiled for in order to interoperate with the right application binary interface (ABI) and cpu instruction set. An illustrative example of the ELF header values described in Table 4.
To read the values in the ELF header, Linux provides many powerful tools such as ''Readelf'', '
Elfdump is a command-line utility that provides detailed information about ELF binaries. 3 It works with executables, shared libraries and even relocatable object files. Wiederseiner [65] uses ''elfdump'' to generates the symbol table of the code-base and source code line data of the ELF file. Wong et al. [66] uses ''elfdump'', ''objdump'' and ''readelf'' Objdump is similar to readelf, but focuses on object files. 4 It provides a similar range of information about ELF files and other object formats. However, it is inefficient to support CPU architectures like MIPS, ARM, and PPC. In Fig. 8, this tool does not detect the CPU architecture of our sample.
Elfutils is a collection of utilities, including eu-ld (a linker), eu-nm (for listing symbols from object files), eu-size (for listing the section sizes of an object or archive file), eu-strip (for discarding symbols), eu-readelf (to see the raw ELF file structures), and eu-elflint (for checking for well-formed ELF files). 5 It provides alternative tools to GNU Binutils, and also allows validating ELF files. Note that all the names of the utilities provided in the package start with eu for ''elf utils''.
Pax-utils is a set of utilities that provide some tools that help to validate ELF files. 6 Scanelf is one of this set utilities. In Fig. 9 showed how scanelf work with an option ''-a''.
There is also a software package called ''Elfkickers'' which contains tools to read the contents of an ELF file as well as manipulate it. 7 Unfortunately, the number of releases is rather low, and that is why we mention it and do not show further examples.
''File'' utility displays information about ELF files, including the instruction set architecture for which the code in a   relocatable, executable, or shared object file is intended. 8 In Fig. 10 shows that our sample is a 32-bit executable file following the Linux Standard Base (LSB), dynamically linked, and built for the MIPS architecture.
With the required information from SE, the author chooses to use the ''readelf'' utility for two reasons. First, the ''readelf'' utility provides complete information required by the EMF. Second, the ''readelf'' utility is built into the easy-touse versions of Linux, without having to install additional external packages.
Use the ''Readefl'' utility to determine the file attributes shown in Figs. 11 and 12. Fig. 11 shows that the malware sample is a 32-bit executable ELF file following the Little Endian, and built for the Unix -System V, MIPS architecture. Fig. 12 shows a list of shared object requirements. Note that this is a list of shared objects that ELF requires when reading the file header, so it is incomplete. This issue will be discussed further in section III-D. This information is sent to the ''Sandbox Configuration Generation component'' to select the appropriate virtual machine to execute the ELF 8      file. The output of the EME component is a file ending in ''argconfig'' as illustrated in Fig. 13.

C. SANDBOX CONFIGURATION GENERATION COMPONENT
With the EME component output (''.argconfig'' file), the ''Sandbox Configuration Generation component'' (SCG) proceeds to generate the initial configuration (''.config'' file) to launch the ''Sandbox Engine component'' for the first time. These configuration parameters will be passed to QEMU to initialize the sandbox engine along with some other default environment parameters. Default configuration parameters of the sandbox engine shown in Table 5. Also, the list of shared libraries in the ''.argconfig'' file was also added to the ''.config'' file with the default path of ''/lib/. . . '' to be able to automatically add the Shared object from the database to the Image virtual disk after starting QEMU. The architecture of the ''.config'' file is illustrated in Fig. 14.

D. SANDBOX ENGINE COMPONENT
The IoT Botnet is built to run on many different CPU architectures to suit the variety of IoT devices. To be able to run and analyze IoT Botnet models on different CPU architectures in a simulation environment, we choose to use QEMU [62]. The open-source project QEMU supports many CPU architectures such as ARM, MIPS, PowerPC, SPARC, etc. Inside each of the Sandbox Environment, there is a built-in Debian image of Aurel [67] with QEMU host, the agents that manage, monitor, and collect ELF files are executed (illustrated in Fig. 16).
The configuration parameters to launch the QEMU host, are read from the ''.config'' file, including command, emulated machine type, Kernel, virtual disk image, RAM, file name, and path of the shared library, IP address of the C&C server. The C&C simulator uses these IP addresses to create a connection between the QEMU host and the C&C server simulation. The file name and path of the shared library are used to add the missing shared libraries from the shared object database to the virtual disk image. The QEMU host VOLUME 8, 2020 starts running with the configuration parameters, as shown in Fig. 15.
The agents are programmed based on the C language and cross-compiled by Toolchains 9 to the corresponding CPU architectures. A Toolchain is a set of distinct software development tools that are linked (or chained) together by specific stages such as GCC, Binutils and Glibc (a portion of the GNU Toolchain). Optionally, a toolchain may contain other tools such as a debugger or a compiler for a specific programming language, such as C language. Quite often, the toolchain used for embedded development is a cross toolchain, or more commonly known as a cross compiler. All the programs (like GCC) run on a host system of a specific architecture (such as x86), but they produce binary code (executables) to run on a different architecture (for example, ARM). This is called cross compilation and is the typical way of building embedded software. Verma et al. [68] demonstrates how to use Toolchains to create applications that run on IoT devices with different CPU architectures.
With the features of the IoT botnet presented in the subsection II-A, the sandbox environment will be integrated with tools to monitor malware behaviors, including system-calls, file and directory activity, host performance requirements, shared library, and network behaviors. For this, we have agents in each Sandbox Engine, including: • The controller agent: managing common tasks of information gathering agents, activating ELF file execution, receiving and transmitting collected information to the ''Analysis behavior'' block.  ''Inotify'' in ''inotify-tools''' is part of the Linux kernel that triggers events on watched files, directories, or even the contents of entire directories. 11 These tools are command-line utilities that tap into the capabilities of inotify and allow you to use them, for example, in your shell scripts. ''Fswatch'' is a free, open-source multi-platform file change monitor utility that notifies us when the contents of the specified files or directories are modified or changed. 12 Using ''fswatch'' can easily monitor the changes being made in files and/or directories. We choose to use the ''lsof'' utility to monitor the interaction with files and directories of ELF files for two reasons. It is also quite useful to figure out what files are being accessed by what processes. Also, ''lsof'' is easy to use on different CPU architecture platforms because it is built into the Linux kernel. The monitoring results of the ''file agent'' are illustrated in Fig. 17.
• Host performance agent: collects behaviors related to using system resources such as CPU, RAM (base on ''top'' utility). To monitor host performance, there are various tools such as ''top'', 13 ''iostat'' 14 and ''mpstat'', 15 etc. However, ''top'' utility is more suitable for this problem. ''Top'' utility displays Linux processes. It provides a dynamic real-time view of the running system, id est actual process activity. By default, it dis- plays the most CPU-intensive tasks running on the server and updates the list every five seconds (result monitor by ''top'' command showed in Fig. 18). ''Iostat'' utility report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions, and network filesystems (NFS). ''Mpstat'' command displays activities for each available processor, processor 0 being the first one. Command ''mpstat -P ALL'' is used to display average CPU utilization per processor. With the ability to provide all the necessary information and ease of use with many different CPU architectures, the host performance agent is built on top of the ''top'' utility.
• SystemCall agent: collects system-call of ELF file (based on ''strace'' utility 16 ). To better understand the behavior of the ELF file when executed, the most useful information is its own system-calls. In Linux, there are many tools that support collecting system-call of an executable file (such as ftrace, 17 ptrace, 18 etc.) but basically function like ''strace'' utility. ''Strace'' monitors the system calls and signals of a specific program. It is helpful when you do not have the source code and would like to debug the execution of a program. This tool provides the execution sequence of a binary from start to end. The result of collecting the system calls of the ''ls'' program by Strace is illustrated in Fig. 19. In the Limon sandbox, Monnappa uses ''Strace'' for tracing system calls.
• Shared library requirement agent: In particular, when building lists of shared libraries in addition to ''readelf'' we also use the ''ldd'' utility [66]. Command ''ldd'' prints the shared objects (shared libraries) required by each program or shared object specified on the command line. Unlike the ''readelf'' utility in the EMF block (section III-B) that only analyzes static ELF file content to identify shared libraries, ''ldd'' executes the ELF file right in the sandbox environment to identify 16   the shared libraries required by ELF. This has resulted in higher efficiency for identifying shared libraries and has been demonstrated experimentally on Dataset when compared to other sandbox capabilities (such as LiSa [41]). The results of the list of shared libraries by ''ldd'' and ''readelf'' are illustrated as shown in Fig. 20 and Fig. 21 (note that ldd identifies two more shared libraries required is libc.so.6 and ld-uClibc.so.0 and the full directory path rather than using readelf ).  • Network agent: collects network behavior of the ELF file (based on program ''TCPdump'' 19 ). One of the critical behaviors of IoT Botnet malware is connecting to a bot network and receiving commands from Bot master (C&C server) -these are typical network behaviors of IoT Botnet. So the ''Network agent'' is built to collect the network behavior of the input ELF file using the ''TCPdump'' utility, which is a simple tool that dumps and reads traffic on a network. This tool has been used in many network intrusion detection systems (NIDS) [69]- [72]. The result of the network traffic dump using this tool is shown in Fig. 22.

E. RAW DATA PREPORCESSING COMPONENT
In this paper, the type of IoT malware we focus on analyzing is the IoT Botnet. As stated in section II-A, Angrishi [ • Host performance: Extract CPU and RAM information such as total resource utilization rate, resource utilization rate of each process related to the ELF file over time. The analysis results for this com have been updated to ''.config'' file, as shown in Fig. 23.

F. SANDBOX RECOMPUTATION COMPONENT
The ''Sandbox Recomputation component'' uses data from the output of the RDP component including total system calls (ts), total network traffic packets (tntp), total file name request (tfr), the average percentage of CPU used (avgCPU ), the average percentage of RAM used (avgRAM ). Every time we run the ''Sandbox Engine component'', these values are extracted from behavioral data. If the total of these values does not increase, we will decide to stop running the SE again. The result of this function is whether or not it is necessary to rerun the ''Sandbox Engine component'' again or not to serve the purpose of collecting more information about ELF file behavior. The algorithm of the ''Sandbox Recomputation component'' is described in Algorithm 1.

G. THE C&C SIMULATOR
The command and control (C&C) server is an essential component in a botnet in general and IoT botnet in particular. The C&C server provides the botmaster with a centralized management way to monitor botnet status and order new DDoS attacks to be carried out. The protocol used to connect between the C&C server and the bot is usually IRC, HTTP, P2P, etc. The illustration of the connections of components in the IoT botnet is illustrated by Angrishi as shown in Fig. 24. In order for the IoT bot to display its entire behavior, it is necessary to create a connection between the bot and the if v t ≤ v t−1 or t = n then 8: d ← false 9: end if 10: end while 11: return d C&C server. The C&C server must then transmit the appropriate commands for the IoT bot to execute. These actions are the main contribution of the C&C simulator. The C&C simulator proceeds to generate C&C servers based on the set of IP addresses in the ''.config'' file (showed in Fig. 23). A database of C&C commands is gathered from various sources, such as source code for IoT Botnet [73], [74], and studies [36], [42], [48]. If the listed C&C server's IP address is not empty, the automatic script creates C&C servers with these IP addresses. When a bot is connected to this C&C server, C&C commands which form our database will be sent to bot. We are not sure what C&C commands are useful for this bot. We are sending all commands and hope to activate some of the botnets next behavior. Experiment results show this way to be effective.

H. THE SHARED OBJECT DATABASE
The Share Object Database proceeds to add the ''so'' library files from the database to the Sandbox environment based on the set of ''Shared library'' in the ''.config'' file. The database of shared objects is collected from shared sources on the Internet and images of IoT device firmware (Router, IP camera, Smart TV, etc.) that manufacturers publish on the network. The C500-Reverse tool [49], published by our team, is used to extract library files from the firmware. Usually, the ''so'' files will be in the ''lib'' directory packaged in the firmware. For devices that do not find the firmware image online, it will be extracted directly from the device with the help of the C500-Extractor [49]. C500-Extractor hardware equipment shown in Fig. 25.

I. REPORT GENERATION
Finally, when the ''Sanbox Recomputation component'' returns ''false'' value, the system will automatically generate a summary report of ELF file behavior from ''Behavior data.'' Illustrations of the content of the report can be found in Section IV-C.

A. DATASET
In order to experiment and evaluate V-Sandbox's analysis results, 9069 samples (6141 IoT botnet and 2928 IoT benign samples) are chosen to analyze. Dataset is collected from IoT-Pot [36], VirusShare, 20 and the Internet. 21 The architecture of samples in the dataset is shown in Table 6.

B. IMPLEMENT
The experiment is conducted on server with an Intel Xeon E5-2689 processor running at 2.6GHz, 32GB memory.  V-Sandbox supports many different CPU architectures, basically including ARM, MIPS, MIPSEL, i386, x86-64, Pow-erPC (can be extended with many other architectures). A view of this implementation is shown in Fig. 26. All of these QEMU virtual machines are connected to a virtual switch for management, providing a simulated network environment as well as the ability to connect to the C&C server, monitor network traffic, and add missing libraries. The Main Controller is responsible for managing tasks including receiving and transferring ELF files to virtual hosts, determining the CPU architecture of the ELF to run the corresponding virtual host, activating the ELF file and monitor agents, providing Share Object (''so'' file) when ELF request, make a connection with dummy C&C server as needed and synthesize analysis report from agent monitor. The C&C simulator provides the ability to communicate between ELF and the C&C server by navigating the connection of the virtual switch combined with a set of command lists gathered from the Internet, paper [36], [42], [48], etc. The Shared Object database is used to provide ''.so'' files when required by the ELF. This Shared Object database collected from sources including the Internet, extracted from IoT device firmware (Router, IP camera, TV-box, etc.) provided by the manufacturer on the internet, OpenWrt images, etc.

C. EXPERIMENTAL RESULTS
The results of running Dataset on V-Sandbox are shown in Table 7. Experimental results show that with Dataset    containing 9069 samples, V-Sandbox ran and successfully analyzed 4779 samples with different CPU architectures. Notably, the proportion of static samples reached more than 60%, and dynamic samples were more than 30%. This result is an advantage when combining the C&C server and Share Object repositor in V-Sandbox. The results of comparison with other IoT Sandboxes (focusing on LiSa [41] and Cuckoo

V. DISCUSSION
A comparison of the results of an analysis of samples in our Dataset with LiSa Sandbox [41] is shown in Table 8. The results were executed by Lisa Sandbox with our dataset showing that this sandbox does not support PowerPC architecture. Also, the number of successfully executed statically and dynamically linked files in Lisa Sandbox is mostly less than our results. Because IoTBOX [36] is not open source, it is not easy to install and test the effectiveness of this sandbox on our data set. Functionally, IoTBOX only focuses on network behavior. Therefore, this sandbox does not provide other behaviors like system calls and host performance. Also, the Cuckoo Sandbox [35] has been tested and installed by us, but it only provides support for X86 architectures and the installation of other CPU architectures is complicated. Therefore, to compare, we selected a few random samples to evaluate the effectiveness of the Cuckoo Sandbox in Table 10, 11. An overview of the functions of the IoT sandbox with V-Sandbox shown in Table 9. Functionally, most of the compared sandboxes do not support the C&C server simulation. This is why the IoT Botnet has not yet revealed adequate behavior. Only Lisa and our sandbox support dynamically libraries. For that reason, it increases our successful execution rate of input files. Our sandbox supports multi-architecture CPU (ARM, MIPS, PowerPC, etc.) like Lisa, Cuckoo, Padawan, and IoTBOX.
In Table 10, we describe 12 randomly selected samples to compare the effectiveness of the proposed sandbox with the two currently highly rated sandboxes, Cuckoo and LiSa sandbox. With the results of running selected samples in Table 11, our sandbox collected more information about system calls and network traffic than Lisa and Cuckoo sandbox.

VI. CONCLUSION
This paper presents a V-Sandbox for dynamic analysis of IoT Botnet. This sandbox is capable of supporting multiple CPU architectures, the C&C servers connection, shared libraries so that the IoT Botnet exhibits more behavior than existing IoT sandboxes. The set of agents collects different behaviors (such as system calls and network traffic) of analytical samples that automatically integrated into virtual machines with the corresponding CPU architecture. The V-Sandbox has been tested through our dataset. Experimental results have shown that the proposed sandbox allows collecting behavioral data better than existing sandboxes. The source code for the V-Sandbox is shared on Github [76]. In the future, we will expand the capabilities of supporting more CPU architectures, adding data about C&C commands, and shared object libraries to the database for a more efficient sandbox.