{"id":"ddeeacac-c7dc-42d7-9f97-f3168129fb54","arxiv_id":"2508.14261","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A modular Linux sandbox that simultaneously captures syscall, network, disk, and hardware-counter traces across three architectures, demonstrated on ransomware, a remote-access trojan, and a cryptominer.","lead":"SaMOSA is a Linux malware analysis sandbox that records four time-synchronized activity traces (system calls, network traffic, disk access, and hardware performance counters) while running suspicious binaries in an emulated virtual machine. It supports x86-64, ARM64, and PowerPC64, and lets analysts inject custom setup hooks before, during, and after each run.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Clock-skew between guest Sysdig timestamps and host-side perf/tcpdump/QEMU traces is never addressed; the paper's central 'time-synchronized' claim rests on an unstated guest-host clock alignment.","rationale":"The paper's strongest claim is that SaMOSA captures 'time-synchronized side-channels from four sources.' The four sources are gathered in two different clock domains: Sysdig runs inside the emulated guest, while perf, tcpdump, and QEMU tracing run on the host. The manuscript explicitly states that QEMU traces record host-side timestamps, but it never explains how the guest timestamps in Sysdig captures are aligned to the host clock. The 'Execute Binary'/'Halt Execution' timestamps in Section 3.5 help discard events outside the execution window, but they do not by themselves convert guest timestamps to host time unless the guest clock is synchronized to the host clock throughout the run. This missing mechanism is load-bearing because the case-study interpretations ('at 20 seconds,' the 260-270s window, the 430s event) presuppose that a timestamp in the Sysdig trace and a timestamp in tcpdump or perf refer to the same instant. The reader identified this same assumption as the weakest point, and I agree. The proposed calibration test is directly actionable: it would reveal whether the offset is negligible, constant, or drifting, and therefore whether the 'time-synchronized' claim can be substantiated as written or needs a correction. I do not see a stronger concern: the multi-architecture, host-side monitoring choices are reasonable, and the absence of released code/data, while limiting reproducibility, is secondary to the clock-alignment question. The verdict should remain CONDITIONAL pending the calibration evidence.","tokens_in":10051,"tokens_out":3961,"duration_ms":44735,"concrete_test":"Add a calibration step and rerun one case study: at a known offset, from inside the guest execute a short burst that is visible in all four channels (e.g., write a file to disk, call a distinctive syscall, and send a UDP packet). Compare the event's timestamp in the Sysdig capture to the timestamps in tcpdump, perf, and QEMU disk trace. Repeat at 60s and 300s into the run to measure drift. If all traces place the marker within one sampling window and the offset is constant or correctable, the time-synchronized claim holds; if not, the paper must describe a clock-alignment mechanism or qualify the claim.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.3 collects syscalls with Sysdig running inside the guest, while HPC (perf), network (tcpdump), and disk (QEMU trace) are collected on the host. Section 3.5 says 'Execute Binary' and 'Halt Execution' record timestamps, but it does not state whose clock those timestamps use or how guest timestamps in the Sysdig capture are mapped to the host timeline. The only synchronization statement is for QEMU traces ('host-side timestamps'), not for Sysdig. For x86-64 with KVM, kvm-clock may keep guest time close to host time, but for ARM64 and PPC64LE the paper does not describe the guest clock source, QEMU RTC configuration, or drift compensation. The case-study conclusions ('at 20 seconds', 260-270s, 430s) depend on cross-channel alignment; if guest and host clocks drift by even a few seconds over a 400-500s run, the correlations in Figures 3-5 could be shifted and the claimed 'time-synchronized' property is not established. This is the load-bearing assumption behind the central contribution.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"SaMOSA is presented as a QEMU-based Linux malware analysis sandbox supporting x86-64, ARM64, and PPC64LE. It captures four side-channels: syscalls (Sysdig in the guest), hardware performance counters (perf on the host QEMU process), network traffic (tcpdump on the host tap), and disk activity (QEMU tracing). It provides FakeNet network emulation, NAT mode, and four hook points for orchestration. Three case studies illustrate the tool: GonnaCry ransomware on PPC64LE, CHAOS RAT on x86-64, and Kinsing cryptominer on ARM64. The central claim is that the four side-channels are time-synchronized, allowing cross-channel correlation and deeper behavioral insights.","tokens_in":10331,"tokens_out":6852,"duration_ms":66860,"significance":"If the synchronization claim is established, SaMOSA fills a genuine gap: existing Linux sandboxes (Limon, Detux, Padawan, LiSa, ELFEN) capture at most a couple of channels and are not easily customizable. The design follows the SoK guidelines of Alrawi et al. and provides multi-architecture support relevant to OT/CPS. The paper also gives concrete orchestration examples (file generation for GonnaCry, C2 setup for CHAOS, SSH re-enablement for Kinsing) that show the framework's flexibility. However, the central time-synchronization claim is not backed by a described mechanism or a validation experiment; the reported cross-channel correlations in the case studies depend on an unstated guest-host clock alignment. The manuscript's comparative claim is also supported only by a feature matrix, not by experiments.","major_comments":[{"comment":"The central contribution (item 3 in Section 1) is the capture of 'time-synchronized' side-channels, but the manuscript never describes the clock model or synchronization mechanism. Sysdig runs in the guest and logs guest timestamps; perf, tcpdump, and QEMU disk traces run on the host and log host timestamps. Section 3.5's 'Execute Binary' and 'Halt Execution' steps record timestamps without saying whose clock is used or how guest timestamps are mapped to the host timeline. For x86-64 with KVM the guest clock may track the host via kvm-clock, but the paper does not state the guest clock source for ARM64 (virt machine) or PPC64LE (pseries), nor any drift compensation. Without a defined alignment procedure and a measured bound on skew, the 'time-synchronized' claim is not established. Please add a synchronization section (clock sources, offset estimation, drift correction) and, ideally, a v","section":"Sections 3.3 and 3.5"},{"comment":"The case-study conclusions rely on exact cross-channel temporal coincidences: 'At 20 seconds' (Section 4.2), 'Between 260 to 270 seconds' and 'At 270 seconds' (Section 4.3). These compare syscall events (guest clock) with network, HPC, and disk events (host clock). If the guest and host clocks drift by even a few seconds over the 400-500 s runs, the observed co-occurrences could be shifted or spurious. The current presentation does not show that a common timeline is used for the plots or that the quoted timestamps were taken from one master clock. Please either (a) provide the synchronization/validation evidence, (b) show that the quoted correlations are robust under plausible clock skew, or (c) downgrade the claims to 'coarsely synchronized' with quantified error bounds.","section":"Sections 4.2 and 4.3"},{"comment":"The abstract and Section 5 claim that SaMOSA captures more side-channels than existing Linux sandboxes and thereby provides deeper insights. However, the evidence is a feature matrix (Table 1) and three qualitative case studies; there is no comparison with any existing sandbox and no ablation showing what would be missed with fewer side-channels. For example, the Kinsing analysis (Section 4.3) would be more convincing if the authors ran the same binary with, say, only syscalls or only network capture and showed which behaviors (e.g., the 270-second mining onset or the 430-second persistence download) would be invisible. Without such a comparison, the incremental contribution over Limon, LiSa, or ELFEN is asserted rather than demonstrated. Please add at least one controlled comparison or ablation.","section":"Section 2 (Table 1) and Section 4"}],"minor_comments":[{"comment":"In the provided version, several tool names are rendered as replacement characters ('������', '����', '����'). If this is not a PDF-conversion artifact, the final version must restore the actual names (Sysdig, perf, tcpdump are inferred from context).","section":"Section 3.3"},{"comment":"Specify how the binary is halted (SIGKILL, SIGTERM, guest-side command) and what happens to processes it spawned; this affects the tail of the syscall and disk traces.","section":"Section 3.5"},{"comment":"The captions do not list axes or units. Add legends and a common time axis with an explicit clock source. Also, Figure 4's caption does not mention an HPC panel, yet Section 4.2 refers to HPC activity; please clarify what is shown.","section":"Figures 3, 4, 5"},{"comment":"Minor typo: 'Debain Trixie' should be 'Debian Trixie'. A small table summarizing QEMU machine types, disk devices, and tracing options would improve reproducibility.","section":"Section 3.1"},{"comment":"No artifact availability statement or repository link is provided. Given the paper's modularity/extensibility claims, an open-source release or at least a public repository reference would strengthen the contribution and aid reproducibility.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper is best treated as a systems/tool contribution rather than an empirical detection study. The main technical risk is the unvalidated guest-host time synchronization, which is load-bearing for the central claim. The author self-citations on hardware performance counters and network measurement (refs [14], [24], [26], [27]) are noticeable but I do not see an inappropriate citation pattern; the editor may still want to verify novelty relative to the authors' own prior work. Also, the visible replacement characters in Section 3.3 may indicate a corrupted source file; the submitted PDF should be checked."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: SaMOSA does something genuinely useful — it wires together QEMU, Sysdig, perf, tcpdump, FakeNet, and QEMU's trace mechanism into one automated Linux sandbox that captures four side-channels at once, on three architectures. That's more than Limon, LiSa, ELFEN, etc. offer, and the orchestration hooks are a practical addition for tailoring runs. The three case studies are illustrative but do show the kind of cross-channel correlation the tool is meant to enable. Design choices like capturing HPC from the host QEMU process and disk traces from QEMU's built-in tracing are sensible: they keep monitoring outside the guest and make tampering harder.\n\nThe soft spot is precisely the \"time-synchronized\" claim. Section 3.3 says QEMU traces have host-side timestamps, but the paper never says how the guest-side Sysdig capture is aligned to the host timeline. The execution pipeline notes that Execute and Halt steps record timestamps, but not whose clock. For x86-64 with KVM, kvm-clock may keep things close; for ARM64 and PPC64LE under emulation, there's no described clock source or drift handling. All the interesting conclusions — 'at 20 seconds' in CHAOS, the 260–270s and 430s correlations in Kinsing — depend on that alignment. If guest and host clocks drift by even a few seconds over a 400–500s run, those correlations shift and could mislead. This is fixable: document the clock source, disable drift-prone RTCs, or provide a synchronization marker in both traces. But as written, the central 'time-synchronized' feature is asserted, not demonstrated.\n\nTwo smaller issues. No code or data is released — for a tool paper that's a real limitation, and easily fixed. And the case studies have no baseline or error analysis; they show the tool works on three samples, but don't establish that four side-channels beat two for any specific detection task. That's acceptable for a systems demonstration, but the advantages are argued, not measured.\n\nOn the citation pattern: there are several self-citations, but they're on networked measurements and HPC-based detection, which are directly relevant. Nothing that smells like padding.\n\nBottom line: this is a solid, useful integration paper for the Linux malware analysis community. It deserves a serious referee, with the expectation that the clock synchronization question gets answered and the code gets released.","headline":"Useful sandbox integration with a real gap: the 'time-synchronized' claim never says how guest and host clocks line up.","tokens_in":10818,"tokens_out":2062,"would_cite":true,"duration_ms":22851,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SaMOSA is a Linux sandbox that captures four time-synchronized side-channels, letting analysts see malware behavior that single-channel sandboxes miss.","keywords":["Linux sandbox","malware analysis","malware emulation","operational technology","side channels","system calls","hardware performance counters","multi-architecture"],"falsifier":"Boot a SaMOSA VM and run a loop that performs one disk write every second while recording Sysdig timestamps and host QEMU disk-trace timestamps; if the offset between the two streams changes measurably across a run, the synchronized-correlation claim fails. A direct version is to read the guest clock and host clock at the same instant before and after execution and check whether any observed drift exceeds the time windows used to call activity correlated.","tokens_in":10003,"feed_emoji":"🛡️","tokens_out":8884,"duration_ms":91367,"temperature":0.7,"pith_summary":"The paper sets out to show that Linux malware analysis, particularly for operational technology and cyber-physical systems, benefits from a sandbox that records several kinds of execution evidence at once, locked to a shared time base, rather than purpose-built sandboxes that capture only one or two channels. The SaMOSA sandbox wraps full-system emulation with four collectors: system calls, hardware performance counters, network traffic, and disk reads/writes. The authors claim this is more side-channel coverage than existing Linux sandboxes, and that the synchronized streams let an analyst see correlations, such as a syscall burst at the same moment as disk and network activity, that reveal what a binary is doing. They demonstrate the approach on three malware families across three architectures: GonnaCry ransomware, the CHAOS remote access trojan, and the Kinsing cryptominer. If the claim holds, SaMOSA fills a gap in dynamic malware analysis for Linux systems in OT and CPS settings.","feed_headline":"Sandbox tracks Linux malware through four synchronized side-channels","feed_subtitle":"One tool lines up syscalls, network, disk, and CPU counters so ransomware, RATs, and miners reveal what they do.","key_machinery":"The central mechanism is the execution pipeline: a QEMU full-system emulator hosts a real Ubuntu or Debian VM, and four collectors are started around the binary run, Sysdig inside the guest for system calls, perf on the host QEMU process for hardware performance counters, tcpdump on the host tap interface for network traffic, and QEMU's built-in tracing for disk block reads and writes. Timestamps from the host-side collectors and the guest-side Sysdig are treated as a shared timeline after discarding data outside the recorded execute and halt window. Orchestration hooks, placed at pre-setup, pre-run, post-run, and post-shutdown, let analysts tailor the environment, for example by generating","core_discovery":"On the paper's own terms, the discovery is that one modular sandbox can simultaneously capture system calls, hardware performance counters, network traffic, and disk activity, all time-synchronized, while emulating full Linux systems on x86-64, ARM64, and PPC64LE. This combination produces execution plots in which a malicious action appears as a coordinated spike across channels: file enumeration followed by encryption in GonnaCry, a C2 command that triggers password-file reads and network exfiltration in CHAOS, and a switch to cryptocurrency mining visible as HPC, disk, and network activity in Kinsing. The broader claim is that this correlated, multi-channel view provides deeper insight int","pith_inferences":["If the time-synchronized traces are reliable, the same pipeline could be used to generate labeled multi-modal training data for Linux and OT malware detectors, since every run yields aligned syscall, network, disk, and HPC sequences with a known binary.","The cross-channel hotspot analysis shown in the case studies is performed by inspecting plots by eye; automating the search for coordinated spikes across syscall, disk, network, and HPC streams is a natural extension the paper leaves implicit.","Because disk and HPC monitoring already sit at the hypervisor level, adding further host-side collectors, such as memory access patterns or emulator-level instruction traces, would fit the same architecture without changing the guest.","The orchestration hooks could also support active deception or interaction experiments, where the analyst changes the environment mid-run in response to observed malware actions, rather than only pre-configuring files and services."],"forward_implications":["An analyst running a Linux binary in SaMOSA gets a single aligned dataset containing syscall traces, network packets, disk block accesses, and CPU counter series, so behaviors like reading password files and then sending them out are visible at exact timestamps rather than reconstructed from separate logs.","The same sandbox can be reconfigured for different malware families without rewriting the monitoring stack, as the case studies show with a file-generation hook for ransomware, a C2 server hook for a RAT, and an SSH re-enable hook for a miner.","Because HPC and disk traces are captured host-side, guest-resident tampering with monitoring tools does not directly affect those two channels, which the paper argues makes them more reliable than in-guest measurements.","The pipeline supports both emulated-network and real-internet modes, so a malware family that behaves differently under FakeNet versus NAT, as Kinsing did, can be studied in both conditions with the same workflow.","The captured data product, including packet captures, sysdig files, HPC CSVs, disk logs, FakeNet reports, and VM snapshots, is intended to support both automated statistical or ML-style detection and deep manual packet and syscall inspection."],"supporting_citations":[{"why":"SoK on malware sandbox design whose guidelines (modular, monitor outside the VM, emulate network, collect from multiple components) are the checklist SaMOSA claims to meet.","marker":"[3]"},{"why":"QEMU supplies the full-system multi-architecture emulation and the built-in tracing that records disk activity.","marker":"[21]"},{"why":"Sysdig is the in-guest system call capture tool whose trace files form one of the four side-channels.","marker":"[23]"},{"why":"FakeNet emulates network services so malware that waits for C2 or downloads payloads will act inside the sandbox.","marker":"[15]"},{"why":"Padawan is an existing multi-architecture Linux sandbox capturing kernel and userspace events, used as a comparison baseline for one-or-two-channel coverage.","marker":"[10]"},{"why":"ELFEN is a recent automated Linux sandbox using eBPF-based syscall capture, serving as the contrast for the Sysdig-based capture approach.","marker":"[13]"},{"why":"LiSa is a recent Linux sandbox capturing syscalls and network activity, representing the two-channel coverage that SaMOSA extends to four.","marker":"[25]"},{"why":"Limon is an early Linux sandbox whose outdated scripts illustrate the maintenance problem that existing tools face.","marker":"[17]"}],"fun_headline_variants":["One sandbox, four synced side-channels reveal Linux malware","SaMOSA syncs syscalls, network, disk, and CPU counters","Multi-channel sandbox catches ransomware, RATs, and miners","Time-synced side-channels unmask Linux malware","Modular sandbox aligns four traces to track malware"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The four channels are only 'time-synchronized' if the guest-side Sysdig clock and the host-side perf, tcpdump, and QEMU clocks stay aligned during a run, and the paper does not describe any mechanism that synchronizes or corrects for drift between the VM's internal clock and the host clock.","fun_headline_variants_meta":{"raw":{"variants":["One sandbox, four synced side-channels reveal Linux malware","SaMOSA syncs syscalls, network, disk, and CPU counters","Multi-channel sandbox catches ransomware, RATs, and miners","Time-synced side-channels unmask Linux malware","Modular sandbox aligns four traces to track malware"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001159,"raw_usage":{"total_tokens":4654,"prompt_tokens":779,"completion_tokens":3875,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":523,"completion_tokens_details":{"reasoning_tokens":3786}},"tokens_in":523,"tokens_out":3875,"duration_ms":29018,"temperature":1.0,"reasoning_tokens":3786,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T18:39:24.960139+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Boot a SaMOSA VM and run a loop that performs one disk write every second while recording Sysdig timestamps and host QEMU disk-trace timestamps; if the offset between the two streams changes measurably across a run, the synchronized-correlation claim fails. A direct version is to read the guest clock and host clock at the same instant before and after execution and check whether any observed drift exceeds the time windows used to call activity correlated.","supporting_citations":[{"cited_title":"SoK: An Essential Guide For Using Malware Sandboxes In Security Applications: Challenges, Pitfalls, and Lessons Learned","cited_arxiv_id":"2403.16304","evidence_quote":"SoK on malware sandbox design whose guidelines (modular, monitor outside the VM, emulate network, collect from multiple components) are the checklist SaMOSA claims to meet."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"QEMU supplies the full-system multi-architecture emulation and the built-in tracing that records disk activity."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Sysdig is the in-guest system call capture tool whose trace files form one of the four side-channels."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"FakeNet emulates network services so malware that waits for C2 or downloads payloads will act inside the sandbox."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Padawan is an existing multi-architecture Linux sandbox capturing kernel and userspace events, used as a comparison baseline for one-or-two-channel coverage."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"ELFEN is a recent automated Linux sandbox using eBPF-based syscall capture, serving as the contrast for the Sysdig-based capture approach."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"LiSa is a recent Linux sandbox capturing syscalls and network activity, representing the two-channel coverage that SaMOSA extends to four."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Limon is an early Linux sandbox whose outdated scripts illustrate the maintenance problem that existing tools face."}],"review_version":1}