SaMOSA: Sandbox for Malware Orchestration and Side-Channel Analysis

Farshad Khorrami; Meet Udeshi; Prashanth Krishnamurthy; Ramesh Karri; Venkata Sai Charan Putrevu

REVIEW 3 major objections 5 minor 1 cited by

SaMOSA: Sandbox for Malware Orchestration and Side-Channel Analysis

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read SaMOSA is a Linux sandbox that captures four time-synchronized side-channels, letting analysts see malware behavior that single-channel sandboxes miss.

desk verdict Useful sandbox integration with a real gap: the 'time-synchronized' claim never says how guest and host clocks line up. read the letter →

arxiv 2508.14261 v1 pith:JJ3MBMW4 submitted 2025-08-19 cs.CR

Meet Udeshi , Venkata Sai Charan Putrevu , Prashanth Krishnamurthy , Ramesh Karri , Farshad Khorrami This is my paper · ORCID

classification cs.CR

keywords Linuxsandboxmalwareanalysisemulationoperationaltechnologysidechannelssystemcallshardwareperformancecountersmulti-architecture

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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

What would settle it

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.

Watch

Extended reading notes

Core claim

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

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

Two 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.

On 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.

Bottom 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.

Referee Report

3 major / 5 minor

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.

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 (3)

[Sections 3.3 and 3.5] 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
[Sections 4.2 and 4.3] 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 2 (Table 1) and Section 4] 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.

minor comments (5)

[Section 3.3] 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 3.5] 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.
[Figures 3, 4, 5] 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 3.1] Minor typo: 'Debain Trixie' should be 'Debian Trixie'. A small table summarizing QEMU machine types, disk devices, and tracing options would improve reproducibility.
[General] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is a systems/tool paper with no fitted-parameter derivation, and its few self-citations are background, not load-bearing.

full rationale

SaMOSA is a systems contribution: the claimed deliverable is a sandbox that captures four side-channels, and the case studies are observational demonstrations of that tool rather than predictions derived from a model. There is no equation or statistical fit whose output is defined in terms of its input; the side-channel traces are in fact external measurements of the executing malware, not quantities reconstructed from the tool's own assumptions. The only self-citations are background references on HPC-based OT monitoring and network measurement ([14], [24], [20]); none of these is used to justify a uniqueness claim, to forbid alternatives, or to supply a load-bearing premise of the sandbox design. The time-synchronization assertion is an implementation claim resting on guest/host timestamp alignment, but any weakness there is a correctness or evaluation gap, not circularity: the paper does not define the side-channel traces in terms of the conclusion, nor does it rename an input as an output. No circular step can be quoted from the text, so the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no fitted parameters or new theoretical entities. It rests on domain assumptions about emulation fidelity, clock alignment, monitor non-detection, and the realism of FakeNet responses.

assumptions (4)

domain assumption QEMU full-system emulation faithfully preserves malware execution behavior such that captured side-channels are representative.
Section 3.1; ARM64 and PPC64LE run under QEMU TCG emulation, whose timing differs from real hardware, so HPC and timing-correlated traces may not reflect native execution.
domain assumption Guest and host clocks are effectively synchronized for correlating Sysdig events with host-side HPC, network, and disk traces.
Sections 3.3 to 3.5; no synchronization procedure is described, yet the 'time-synchronized' claim and case-study correlations depend on such alignment.
domain assumption The malware does not detect or disable the in-guest Sysdig monitor before malicious behavior occurs.
Section 3.3; HPC is moved to the host to resist tampering, but syscall capture remains in-guest and is a single point of failure against evasion.
domain assumption FakeNet's uniformly positive responses trigger realistic enough network behavior for analysis.
Section 3.2; the Kinsing case study shows FakeNet led to no further payload activity, meaning the emulation can alter behavior, so conclusions drawn under FakeNet may not generalize to real-network runs.

how reviews work

0 comments

Cite this review

Pith. "Pith review of SaMOSA: Sandbox for Malware Orchestration and Side-Channel Analysis." pith.science (2026). https://pith.science/paper/JJ3MBMW4

@misc{pith2026250814261,
  author       = {Pith},
  title        = {Pith review of: SaMOSA: Sandbox for Malware Orchestration and Side-Channel Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JJ3MBMW4}},
  note         = {Machine review of arXiv:2508.14261}
}

read the original abstract

Cyber-attacks on operational technology (OT) and cyber-physical systems (CPS) have increased tremendously in recent years with the proliferation of malware targeting Linux-based embedded devices of OT and CPS systems. Comprehensive malware detection requires dynamic analysis of execution behavior in addition to static analysis of binaries. Safe execution of malware in a manner that captures relevant behaviors via side-channels requires a sandbox environment. Existing Linux sandboxes are built for specific tasks, only capture one or two side-channels, and do not offer customization for different analysis tasks. We present the SaMOSA Linux sandbox that allows emulation of Linux malwares while capturing time-synchronized side-channels from four sources. SaMOSA additionally provides emulation of network services via FakeNet, and allows orchestration and customization of the sandbox environment via pipeline hooks. In comparison to existing Linux sandboxes, SaMOSA captures more side-channels namely system calls, network activity, disk activity, and hardware performance counters. It supports three architectures predominantly used in OT and CPS namely x86-64, ARM64, and PowerPC 64. SaMOSA fills a gap in Linux malware analysis by providing a modular and customizable sandbox framework that can be adapted for many malware analysis tasks. We present three case studies of three different malware families to demonstrate the advantages of SaMOSA.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Ransomware 3.0: Self-Composing and LLM-Orchestrated
cs.CR 2025-08 conditional novelty 8.0 of 10

A prototype LLM-orchestrated ransomware successfully executes reconnaissance, payload selection, encryption/exfiltration/destruction, and personalized extortion across three environments, with open-source models.

Reference graph

Works this paper leans on

30 extracted references · 28 canonical work pages · cited by 1 Pith paper

[1]

Amr S Abed, T Charles Clancy, and David S Levy. 2015. Applying bag of system calls for anomalous behavior detection of applications in linux containers. In 2015 IEEE globecom workshops (GC Wkshps). IEEE, 1–5

work page 2015
[2]

Mohannad Alhanahnah, Qicheng Lin, Qiben Yan, Ning Zhang, and Zhenxiang Chen. 2018. Efficient signature generation for classifying cross-architecture IoT malware. InIEEE Conference on Communications and Network Security (CNS)

work page 2018
[3]

Omar Alrawi, Miuyin Yong Wong, Athanasios Avgetidis, Kevin Valakuzhy, Bo- ladji Vinny Adjibi, Konstantinos Karakatsanis, Mustaque Ahamad, Doug Blough, Fabian Monrose, and Manos Antonakakis. 2024. SoK: An Essential Guide For Using Malware Sandboxes In Security Applications: Challenges, Pitfalls, and Lessons Learned. arXiv:2403.16304 [cs.CR] https://arxiv.o...

work page Pith review arXiv 2024
[4]

AQUASEC. [n. d.]. Kinsing V2. https://www.aquasec.com/blog/threat-alert- kinsing-malware-container-vulnerability/. Accessed: 2025-06-07

work page 2025
[5]

Jano Bermudes. 2023. Mitigating cyber risks in industrial control sys- tems. www.marsh.com/en/industries/manufacturing/insights/mitigating-cyber- risks-in-industrial-control-systems.html Accessed: 2025-06-07

work page 2023
[6]

CAPE. [n. d.]. CAPE Sanbox. https://github.com/kevoreilly/CAPEv2

work page
[7]

Carrillo-Mondéjar, J.L

J. Carrillo-Mondéjar, J.L. Martínez, and G. Suarez-Tangil. 2020. Characterizing Linux-based malware: Findings and recent trends.Future Generation Computer Systems110 (2020), 267–281. https://doi.org/10.1016/j.future.2020.04.031

work page doi:10.1016/j.future.2020.04.031 2020
[8]

Daming D Chen, Maverick Woo, David Brumley, and Manuel Egele. 2016. To- wards automated dynamic analysis for linux-based embedded firmware.. In Networked and Distributed Systems Security (NDSS)

work page 2016

Show all 30 references

[9]

Qian Chen and Robert A. Bridges. 2017. Automated Behavioral Analysis of Malware: A Case Study of WannaCry Ransomware. In2017 16th IEEE Inter- national Conference on Machine Learning and Applications (ICMLA). 454–460. https://doi.org/10.1109/ICMLA.2017.0-119

2017 doi
[10]

Emanuele Cozzi, Mariano Graziano, Yanick Fratantonio, and Davide Balzarotti
[11]

Cuckoo. [n. d.]. Cuckoo Sandbox. https://github.com/cuckoosandbox/cuckoo
[12]

Detux. [n. d.]. Detux Sandbox. https://github.com/detuxsandbox/detux
[13]

ELFEN. [n. d.]. ELFEN Sandbox. https://github.com/nikhilh-20/ELFEN
[14]

Prashanth Krishnamurthy, Ali Rasteh, Ramesh Karri, and Farshad Khorrami. 2024. Tracking Real-time Anomalies in Cyber-Physical Systems Through Dynamic Behavioral Analysis. arXiv:2406.12438 [eess.SY] https://arxiv.org/abs/2406.12438

2024 arXiv
[15]

Mandiant. [n. d.]. FakeNet-NG. https://github.com/mandiant/flare-fakenet-ng
[16]

Alessandro Mascellino. 2022. Chaos RAT Used to Enhance Linux Cryptomining Attacks. https://www.infosecurity-magazine.com/news/chaos-rat-used-linux- cryptominingva/ Accessed: 2025-06-07

2022
[17]

K. A. Monnappa. 2015. Automating Linux Malware Analysis Using Limon Sandbox. BlackHat Europe. https://www.blackhat.com/docs/eu-15/materials/eu- 15-KA-Automating-Linux-Malware-Analysis-Using-Limon-Sandbox.pdf

2015
[18]

Tran Nghi Phu, Kien Hoang Dang, Dung Ngo Quoc, Nguyen Tho Dai, and Nguyen Ngoc Binh. 2019. A novel framework to classify malware in MIPS architecture-based IoT devices.Security and Communication Networks2019, 1 (2019), 4073940

2019
[19]

Santiago Pontiroli, Gabor Molnar, and Kirill Antonenko. 2025. From open-source to open threat: Tracking Chaos RAT’s evolution. https://www.acronis.com/en- us/cyber-protection-center/posts/from-open-source-to-open-threat-tracking- chaos-rats-evolution/ Accessed: 2025-06-07

2025
[20]

Venkata Sai Charan Putrevu, Subhasis Mukhopadhyay, Subhajit Manna, Nanda Rani, Ansh Vaid, Hrushikesh Chunduri, Mohan Anand Putrevu, and Sandeep Shukla. 2024. Adapt: Adaptive camouflage based deception orchestration for trapping advanced persistent threats.Digital Threats: Rese...

2024
[21]

QEMU. [n. d.]. QEMU Emulator. https://www.qemu.org/docs/master/about/ index.html
[22]

Redcanary. 2025. Kinsing Saltstack. https://redcanary.com/blog/threat- intelligence/kinsing-malware-citrix-saltstack/. Accessed: 2025-06-07

2025
[23]

Sysdig. [n. d.]. Sysdig. https://github.com/draios/sysdig
[24]

Meet Udeshi, Prashanth Krishnamurthy, Ramesh Karri, and Farshad Khorrami
[25]

Daniel Uhrıcek. 2020. Lisa – multiplatform linux sandbox for analyzing IoT malware

2020
[26]

Xueyang Wang, Sek Chai, Michael Isnardi, Sehoon Lim, and Ramesh Karri. 2016. Hardware Performance Counter-Based Malware Identification and Detection with Adaptive Compressive Sensing.ACM Trans. Archit. Code Optim.13, 1, Article 3 (March 2016), 23 pages. https://doi.org/10.1145/2857055

2016 doi
[27]

Xueyang Wang, Charalambos Konstantinou, Michail Maniatakos, Ramesh Karri, Serena Lee, Patricia Robison, Paul Stergiou, and Steve Kim. 2016. Malicious firmware detection with hardware performance counters.IEEE Transactions on Multi-Scale Computing Systems2, 3 (2016), 160–173

2016
[28]

Luxin Zheng, Jian Zhang, Faxin Lin, and Xiangyi Wang. 2023. Feature-Fusion- Based Abnormal-Behavior-Detection Method in Virtualization Environment. Electronics12, 16 (2023). https://doi.org/10.3390/electronics12163386 A Appendix A.1 Analysis Data SaMOSA captures time-synchroni...

2023 doi
[2018]

In2018 IEEE symposium on security and privacy (SP)

Understanding linux malware. In2018 IEEE symposium on security and privacy (SP). IEEE, 161–175
[2025]

https://doi.org/10.1109/TNSM.2024.3512180

Tamper-Proof Network Traffic Measurements on a NIC for Intrusion Detection.IEEE Transactions on Network and Service Management22, 2 (2025), 2214–2224. https://doi.org/10.1109/TNSM.2024.3512180

2025

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.

[1] [1]

Amr S Abed, T Charles Clancy, and David S Levy. 2015. Applying bag of system calls for anomalous behavior detection of applications in linux containers. In 2015 IEEE globecom workshops (GC Wkshps). IEEE, 1–5

work page 2015

[2] [2]

Mohannad Alhanahnah, Qicheng Lin, Qiben Yan, Ning Zhang, and Zhenxiang Chen. 2018. Efficient signature generation for classifying cross-architecture IoT malware. InIEEE Conference on Communications and Network Security (CNS)

work page 2018

[3] [3]

Omar Alrawi, Miuyin Yong Wong, Athanasios Avgetidis, Kevin Valakuzhy, Bo- ladji Vinny Adjibi, Konstantinos Karakatsanis, Mustaque Ahamad, Doug Blough, Fabian Monrose, and Manos Antonakakis. 2024. SoK: An Essential Guide For Using Malware Sandboxes In Security Applications: Challenges, Pitfalls, and Lessons Learned. arXiv:2403.16304 [cs.CR] https://arxiv.o...

work page Pith review arXiv 2024

[4] [4]

AQUASEC. [n. d.]. Kinsing V2. https://www.aquasec.com/blog/threat-alert- kinsing-malware-container-vulnerability/. Accessed: 2025-06-07

work page 2025

[5] [5]

Jano Bermudes. 2023. Mitigating cyber risks in industrial control sys- tems. www.marsh.com/en/industries/manufacturing/insights/mitigating-cyber- risks-in-industrial-control-systems.html Accessed: 2025-06-07

work page 2023

[6] [6]

CAPE. [n. d.]. CAPE Sanbox. https://github.com/kevoreilly/CAPEv2

work page

[7] [7]

Carrillo-Mondéjar, J.L

J. Carrillo-Mondéjar, J.L. Martínez, and G. Suarez-Tangil. 2020. Characterizing Linux-based malware: Findings and recent trends.Future Generation Computer Systems110 (2020), 267–281. https://doi.org/10.1016/j.future.2020.04.031

work page doi:10.1016/j.future.2020.04.031 2020

[8] [8]

Daming D Chen, Maverick Woo, David Brumley, and Manuel Egele. 2016. To- wards automated dynamic analysis for linux-based embedded firmware.. In Networked and Distributed Systems Security (NDSS)

work page 2016