The purpose of this article is to show what projects exist today for the automatic analysis of executable files for Linux. The information provided can be used to deploy a test bench for analyzing malicious code. The topic may be relevant for administrators and malware researchers.

Linux sandboxing features

The main problem of Linux sandboxes for analyzing applications is the limited support for the processors on which the operating system is running. Since it is very expensive to use its own physical machine for each architecture – virtualized solutions like Hyper-V, VMWare or VBox are used as a compromise. These solutions do their job well enough, but they only allow virtualization on the architecture on which the main host is running. To run code for ARM, MIPS, and other architectures, you will have to turn to other products that can emulate the required processor instructions. Let’s try to collect as many projects as possible and see what processor architectures are supported.

Cuckoo sandbox

The absolute leader among free automated sandboxes has long been the Cuckoo sandbox. This sandbox allows you to customize any popular platform for launching applications. The sandbox is equipped with a web interface, which is used to manage the sandbox and get the results of applications. The architecture of this sandbox allows you to write your own plugins, which can change the characteristics and behavior of the sandbox depending on the file being launched or additional settings installed. The general architecture diagram can be found below:

This sandbox is very popular for analyzing malicious software for Windows. The developers claim that it can also work with Linux. The only difference will be that instead of a virtual machine on Windows, a virtual machine on Linux should be configured. Let’s try to find more analogs.

LiSA Sandbox

Opensource sandbox for code analysis under Linux OS. The documentation says that this sandbox can parse executables from platforms:

• x86_64
• i386
• arm
• mips
• aarch64

Such emulation is possible due to the use of the Qemu emulator. The sandbox also offers static and dynamic analysis of the executable file. Static analysis is performed using the radare2 tool, and dynamic analysis due to a special kernel extension that collects events of interaction with the OS: file operations, network interactions, launching commands and processes. The documentation describes that support for such a large number of processors allows you to work with the device firmware. That is, you can see what the software is doing, which will be recorded on the IoT devices. This is a very useful feature, considering that malware can be written into the firmware image of devices and work there on an ongoing basis.

One of the features is the use of Docker containers. This qualitatively speeds up the sandbox setup. Sandbox interface:

Limon sandbox

A relatively simple set of scripts that are used to analyze applications. Has no scope for extension (except for writing new logic). It can analyze applications theoretically on any processor since the functionality is fully written in Python. The sandbox operates with the following tools:

• Yara
• ssdeep
• ldd
• strace
• Inetsim
• tcpdump
• volatility
• sysdig

It looks like this sandbox is just an automated part of the malware analyst’s job. The output of the scripts can be seen below:

drakvuf Sandbox

The only set of tools that is not specifically aimed at examining malicious code. This kit is used to study software in general. The recorded application execution artifacts are so detailed that malware can also be analyzed. The documentation states that this toolkit can work with almost all popular OSes. The only condition that needs to be met on the device is nested virtualization. All actions of the sandbox are implemented by intercepting the system functions of the OS, which is used as a host for the application under study. Unfortunately, to view the sandbox data, you need to parse the data from json yourself.

Detux

Sandbox for analyzing malicious code сan analyze the following architectures:

• x86
• x86_64
• ARM
• MIPS
• MIPSEL

The Qemu project is used as the base hypervisor. The sandbox collects traffic and compromise IDs automatically. All information is included in the report. Unlike analogs, it does not provide a beautiful interface but writes everything to a report in JSON format.

As you can see from the list above, there is still a small choice among sandboxes.

However, the set of tools is almost the same everywhere:

• radare2
• Volatility
• Yara
• custom interceptor for system calls.

Therefore, the user will have to make a choice whether he will analyze the data that the sandbox produces or not.