SaMOSA Linux Sandbox for Malware Analysis

• SaMOSA Linux Sandbox is a dynamic malware analysis framework that emulates Linux malware across multiple architectures using synchronized system calls, network, disk, and hardware performance counters.
• It employs a three-stage pipeline with customizable hook points and FakeNet network emulation to orchestrate malware behavior and generate detailed telemetry.
• SaMOSA is tailored for OT and CPS environments, supporting x86-64, ARM64, and PowerPC 64, and extends to closed-loop digital twin experiments for cyber-physical systems.

SaMOSA is a Linux sandbox for dynamic malware analysis that allows emulation of Linux malwares while capturing time-synchronized side-channels from four sources: system calls, network activity, disk activity, and hardware performance counters. It additionally provides emulation of network services via FakeNet and allows orchestration and customization of the sandbox environment via pipeline hooks. The system is positioned toward Linux-based embedded devices used in operational technology (OT) and cyber-physical systems (CPS), supports x86-64, ARM64, and PowerPC 64, and is presented as a modular and customizable sandbox framework that can be adapted for many malware analysis tasks (Udeshi et al., 19 Aug 2025). A subsequent line of work places an unmodified controller binary inside the same sandbox and reroutes its I/O to an external plant simulator, extending SaMOSA from malware analysis to closed-loop CPS experimentation (Udeshi et al., 15 Jun 2026).

1. Research context and problem setting

Cyber-attacks on OT and CPS have increased tremendously in recent years with the proliferation of malware targeting Linux-based embedded devices of OT and CPS systems. Within that setting, comprehensive malware detection requires dynamic analysis of execution behavior in addition to static analysis of binaries. The SaMOSA work frames safe execution of malware as inseparable from observation: executing a sample in isolation is insufficient unless the environment also captures behavior through side-channels that remain informative during full-system execution (Udeshi et al., 19 Aug 2025).

The motivating gap is defined narrowly. Existing Linux sandboxes are described as built for specific tasks, as only capturing one or two side-channels, and as not offering customization for different analysis tasks. SaMOSA is introduced to address that gap by combining multi-channel capture, multi-architecture support, network-service emulation, and programmable orchestration in a single framework. This positioning is especially relevant for OT and CPS, where Linux malware often targets heterogeneous embedded platforms rather than a single workstation-class ISA.

A plausible implication is that SaMOSA treats malware analysis not as a single instrumentation problem but as a coordination problem across execution environment, network emulation, and time-aligned telemetry. That emphasis recurs throughout the design.

2. Core architecture and execution pipeline

SaMOSA is organized as three consecutive stages: Orchestration, Execution, and Analysis (Udeshi et al., 19 Aug 2025). Its core deployment consists of a full-system QEMU VM running Ubuntu or Debian, a host-side Python orchestrator, and a FakeNet service running inside a Docker container on the host. The orchestrator spawns QEMU, FakeNet, sysdig, perf, tcpdump, and QEMU-tracing, and invokes user-supplied commands at four hook points.

The module interactions are explicitly staged. The orchestrator first clones a “golden” VM snapshot, boots it under QEMU, and then invokes hook scripts. During execution, sysdig runs inside the VM, perf measures the QEMU process on the host, tcpdump listens on the host tap, and FakeNet answers or reroutes all outgoing sandbox traffic. QEMU’s built-in trace subsystem records disk I/O. After the malware halts, the orchestrator collects data artifacts and tears down the VM.

The sandbox core is implemented as QEMU full-system emulation. The paper describes realistic, up-to-date Ubuntu/Debian environments on three architectures, with KVM acceleration on x86-64 using 4 cores and 4 GB RAM, Cortex-A72 on ARM64, and Power9 CPU on PPC64LE. The orchestrator engine automates the full pipeline and generates a run-directory containing JSON metadata, VM snapshot, pcap, scap, CSV, QEMU-trace logs, FakeNet logs, stdout/stderr, and utility logs. In practice, this makes the sandbox both an execution environment and an artifact-production pipeline.

3. Side-channel instrumentation and synchronization

SaMOSA captures four time-synchronized streams using host timestamps to ease cross-correlation (Udeshi et al., 19 Aug 2025). System calls are collected with sysdig inside the VM and written to a .scap file of timestamped syscall events and arguments. Network activity is recorded with tcpdump on the sandbox tap interface and stored as a standard pcap with all inbound and outbound packets. Disk I/O is obtained through QEMU’s trace subsystem on the host, which records NVMe or virtio block device read and write events with logical block numbers and host timestamps. Hardware performance counters are measured with perf on the host against the QEMU process, including instructions, cycles, cache loads and misses, branch-misses, and dTLB loads.

Time synchronization is central to the design. Every stream is annotated with a host epoch timestamp $t$, and all monitors are started and stopped under orchestrator control so that traces can be aligned by trimming to the “Execute Binary” to “Halt Execution” interval. For fine-grained alignment, the paper gives the normalized cross-correlation between two time series $x(t)$ and $y(t)$ as

$$R_{xy}(\tau) = \frac{\sum_t (x(t)-\bar x)\,(y(t+\tau)-\bar y)}{\sigma_x\,\sigma_y}\,,$$

with the optimal delay defined as

$\Delta = \arg\max_t R_{xy}(t)\,.$

This formulation is presented as a mechanism for correcting residual skews after host-controlled start and stop events. The design therefore separates two alignment problems: coarse synchronization by orchestration and residual correction by signal processing. A plausible implication is that SaMOSA is intended not merely to log heterogeneous events, but to support cross-channel temporal reasoning about malware phases.

4. Orchestration, customization, and network-service emulation

Customization is exposed through four hook points: Pre Setup, Pre Run, Post Run, and Post Shutdown (Udeshi et al., 19 Aug 2025). Pre Setup runs on the host before VM cloning. Pre Run runs on the host or guest after VM boot and before measurement start. Post Run runs on the host or guest after measurement stops and before VM shutdown. Post Shutdown runs on the host after the VM has shut down. Hooks are defined in a JSON or YAML run-config, and the orchestrator invokes each entry in sequence, optionally inside the guest via SSH.

The workflow customizations named in the paper are operational rather than declarative. They include installing or uninstalling packages, generating or seeding files for the malware to act upon, launching or tearing down C2 servers, monitoring agents, or NAT rules, and modifying firewall rules or environment variables prior to exec(). The examples are concrete: generating thousands of random .doc/.pdf/.ppt files for GonnaCry, starting a Python-based C2 server and scripted RAT interaction for CHAOS RAT, and re-enabling SSH service after Kinsing so investigators can log back into the infected VM.

FakeNet supplies the network-service emulation layer. It runs inside a Docker container on the host, is connected to the VM’s tap interface via a bridge, intercepts all sandbox-origin traffic, and answers common services such as HTTP, DNS, and FTP with benign placeholders to trigger C2 logic. The design does not assume that service emulation is always sufficient. If real Internet access is needed, the orchestrator disables FakeNet and configures iptables NAT on the host bridge. This distinction matters because some samples can be stimulated by synthetic responses, whereas others require live payload retrieval or interaction with external infrastructure.

5. Architectural support, fidelity, and comparative position

SaMOSA supports three architectures predominantly used in OT and CPS: x86-64, ARM64, and PowerPC 64 (Udeshi et al., 19 Aug 2025). The detailed configurations are x86-64 with QEMU plus KVM and an NVMe block device, ARM64 with a QEMU virt machine and virtio-blk, and PowerPC64LE with a QEMU pseries machine, NVMe, and a Debian image in which Sysdig is compiled from source. The architectural scope is narrower than a generic “all Linux targets” claim, but broader than many Linux sandbox deployments oriented around a single ISA.

The paper characterizes the emulation trade-offs explicitly. Full-system QEMU emulation provides high fidelity, in the sense of a real OS and real libraries, at the cost of approximately $2\times$ slowdown versus bare metal. KVM on x86-64 recovers performance at near-native speeds, whereas ARM64 and PPC64LE run in pure emulation. QEMU tracing and perf are reported to incur only single-digit percentage overhead on typical malware runs.

The comparative argument against six prior Linux sandboxes emphasizes four differentiators: all four side-channels rather than at most two, support for three OT-focused ISAs rather than often only x86 or MIPS, full FakeNet support rather than none or partial support, and fully user-programmable pipeline hooks rather than fixed workflows. The paper also gives quantitative metrics where available:

$$T_{\text{sandboxed}} \simeq (1+\epsilon)\,T_{\text{native}},$$

with $\epsilon \lesssim 0.5$ for non-KVM emulation and $\epsilon \lesssim 0.1$ under KVM. Data fidelity is summarized as QEMU tracing accuracy greater than 99% of disk events and perf counter measurement error below 2%. Within the paper’s framing, these figures support the claim that SaMOSA fills a gap in Linux malware analysis by combining fidelity, breadth of instrumentation, and experimental control.

6. Malware case studies and behavioral observability

The paper presents three case studies of three different malware families to demonstrate the advantages of SaMOSA, and all plots align four channels on a shared time axis (Udeshi et al., 19 Aug 2025). The case studies are not presented as a benchmark suite in the narrow statistical sense; rather, they serve as exemplars of how synchronized channels expose phase structure and execution semantics.

For GonnaCry ransomware on PPC64LE, a Pre Run hook generated random files before execution. The observed phases were enumeration, encryption, and shredding. Enumeration was associated with statx, readlinkat, and getdents64. Encryption showed hardware-performance-counter spikes in dTLB loads and L1 data loads together with getrandom calls. Shredding showed repeated reads and writes to identical logical blocks in disk scatter plots and write-intense syscalls. The interpretation advanced by the paper is that no single channel gives the full picture: syscall semantics, memory-related counters, and block-level I/O each expose a different portion of the ransomware workflow.

For CHAOS RAT on x86-64, Pre Setup launched the C2 server on the host and Pre Run invoked a scripted interaction. An early lull of about 30 seconds showed futex, nanosleep, and tgkill, indicating sleeping threads. At about 20 seconds, the traces showed syscalls modifying /etc/passwd and group files, correlated hardware counters and disk writes at low block addresses, and network bursts to the C2 associated with user creation and password change. Between 30 and 180 seconds, directory browsing and file downloads produced aligned transmit and receive bursts, read syscalls, and modest hardware-counter activity. After 180 seconds, the malware exhibited a periodic heartbeat every 15 seconds.

For Kinsing on ARM64, the first run used FakeNet and captured C2 URLs including /kinsing_aarch64, /libsystem.so, and /ce.sh. A second run with NAT showed downloads of real payloads between 100 and 120 seconds, secondary downloads between 260 and 270 seconds including the rootkit libsystem.so, and network connections to 185.154.*.* and 31.184.*.*. From 270 seconds onward, hardware counters peaked in branch instructions and memory stores, corresponding to cryptomining loops. At 430 seconds, a network burst and disk writes were observed as cron.sh was pulled for cleanup of competitors and persistence. Continuous low-amplitude network chatter was interpreted as seed exchanges and heartbeat.

Taken together, these studies suggest that SaMOSA is particularly effective when malware behavior depends on staged interactions with files, network services, or external infrastructure. The framework is therefore oriented toward temporal decomposition of malicious activity rather than simple verdict generation.

7. CPS digital-twin extension and later use

A later framework uses SaMOSA as the execution substrate for a sandbox-enabled digital twin for cyber-physical systems (Udeshi et al., 15 Jun 2026). In that design, an unmodified controller binary is hosted inside a guest VM running a stock Ubuntu or Debian distribution, while a host-side plant simulator such as PandaPower or Isaac Sim is attached to the same virtual network bridge. The framework captures the same four time-synchronized controller side-channels alongside plant state, and uses the same four orchestration hooks for repeatable, parameterized runs. This suggests a shift from open-loop malware execution to closed-loop controller-plant co-simulation without changing the underlying instrumentation model.

The I/O redirection mechanisms are specified at the QEMU interface. Networked I/O such as Modbus/TCP, OPC UA, ROS DDS, and MQTT is rerouted at the -netdev tap interface, so guest TCP/IP packets are delivered to the host simulator listening on the corresponding port. For serial-based protocols including Modbus RTU and DNP3, QEMU’s -serial chardev with a host UNIX socket backend is used. Disk I/O remains exposed through virtio-blk with QEMU block-device tracing enabled. Security and isolation are described in terms of full-system VM isolation, Linux cgroups limiting CPU and memory, seccomp filters on the QEMU process, and filesystem and network namespace isolation; optional namespace pairing and chroot inside the guest are also mentioned, though the paper focuses on VM-level isolation.

The synchronization model is extended formally. If $$c \in \{\text{HPC}, \text{SC}, \text{Disk}, \text{Net}\}$$ and $x(t)$0 is the $x(t)$1th recorded event, each event is tagged with host timestamp $x(t)$2. Plant-state snapshots $x(t)$3 are logged at host times $x(t)$4, and alignment is expressed by extracting all events such that $x(t)$5, with $x(t)$6 chosen smaller than the controller scan cycle. In practice, the paper states that host-clock resolution of approximately microseconds yields sub-millisecond alignment, and reports synchronization accuracy as

$x(t)$7

The principal case study places the OpenPLC runtime inside an ARM Cortex-A72 guest VM running Ubuntu 24.04 and connects it over Modbus/TCP to a PandaPower model of the IEEE 14-bus system. OpenPLC implements a PI governor on Generator 2 at Bus 2, reading frequency and electrical power, computing the PI control law, and writing back regulated mechanical power. At $x(t)$8, an orchestration hook injects a 20 MW load step at Bus 14. The reported observations are steady cycles-to-instructions ratios with occasional OS-driven spikes, dominant periodic syscalls such as pselect6, sendto, recvfrom, ioctl, and clock_nanosleep at the scan-cycle frequency of approximately 0.5 Hz, near-zero disk activity, periodic network bursts every two seconds, and simulator signals showing generator-frequency dip and recovery. The measured end-to-end scan-cycle latency increase is below 5%.

The same paper discusses extension to robotics and other CPS domains by replacing the OpenPLC binary with a ROS node or flight-controller binary, rerouting ROS DDS or ROS topics over the same network bridge into Isaac Sim or Gazebo, and correlating the same four side-channels with robot state such as joint angles, camera frames, and LiDAR scans. The framework is therefore presented not only as a malware sandbox, but also as an observability substrate for online testing, coverage analysis, and anomaly detection in controller software.