SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-sandbox

re-sandbox

Data & analytics

View repository

Updated 10-16 08:36

About this skill

Sandbox Environment Setup

When to Use / When Not to Use

  • Use: any dynamic analysis involving running samples (behavior analysis, callback observation, unpacking verification, dynamic API monitoring) — dynamic analysis is a mandatory prerequisite, and defaulting to a sandbox is the highest principle (see [[re-analyze/platform-tips]])
  • Use: when you need a clean, rollback-capable isolated environment to execute untrusted programs
  • Don't use: pure static analysis ([[re-triage]] / [[re-format-pe]] / [[re-ghidra]], etc.) can skip the sandbox
  • Don't use: when the sample already has a trusted execution environment and the user explicitly requests running it on the local machine (still explain the risks first)

Tool Preparation

Verify all tools before use. This skill is the executor of the highest principle in [[re-analyze/platform-tips]] (default to sandbox, dynamic execution is a mandatory prerequisite) — all tools serve only to make "running samples" safer and more controllable.

firejail — lightweight application sandbox (lowest isolation level, Linux only)

  • Linux: apt install firejail / dnf install firejail / pacman -S firejail
  • macOS/Windows: not supported (use Docker or a VM instead)
  • WSL: Linux packages work directly
  • Verify: firejail --version；firejail --list can see active sandboxes
  • Note: firejail is user-space isolation (a combination of namespace/seccomp), not a security boundary — it does not protect against kernel exploits and privilege escalation; still use a VM for high-threat samples (see pitfall 3); common parameters --private(temporary home, discarded on exit),--net=none(no network),--dns=<ip>(DNS pointing)

docker — container isolation (intermediate)

  • Linux: apt install docker.io / dnf install docker / pacman -S docker(or the official Docker script)
  • macOS: brew install --cask docker(Docker Desktop, must be started manually) or brew install docker + brew install colima + colima start
  • Windows: choco install docker-desktop(Docker Desktop); inside WSL2 use the Linux version
  • Verify: docker --version；docker run --rm hello-world runs successfully
  • Note: containers share the kernel and are not fully isolated (see pitfall 3)

VirtualBox / VMware — virtual machine + snapshots (highest isolation level)

  • VirtualBox:
    • Linux: apt install virtualbox / dnf install VirtualBox(RPMFusion repo) / pacman -S virtualbox
    • macOS: brew install --cask virtualbox
    • Windows: choco install virtualbox
    • Verify: VBoxManage --version
  • VMware Workstation/Fusion: commercial license; Windows choco install vmware-workstation; Verify: vmrun list or vmware --version
  • Snapshot commands (VBoxManage example): 
    VBoxManage snapshot <vm> take clean      # 建立快照
VBoxManage snapshot <vm> restore clean   # 恢复快照

INetSim — simulate network services (mainstay of network isolation)

  • Linux: Debian/Ubuntu apt install inetsim(or the official .deb; for other distributions build from source, which has many Perl dependencies — a dedicated Debian VM is recommended)
  • macOS/Windows: not recommended to install locally — run it inside a Linux VM
  • Verify: inetsim --version; after starting, the inetsim log shows services such as HTTP/SMTP/DNS/FTP listening

Cuckoo / CAPE — automated malware sample analysis sandbox

  • Cuckoo (old, still usable): pip install cuckoo; Verify: cuckoo --version
  • CAPE (active successor): 
    git clone https://github.com/kevoreilly/CAPEv2
cd CAPEv2 && pip install -r requirements.txt
    Verify: python cuckoo.py --help or the cape subcommand can list
  • Depends on virtual machines and network isolation configuration; initial setup cost is high — for one-off manual analysis, prefer the VM snapshot approach

Operating Steps

Execute in order, and record the result of each step.

  1. Choose isolation level(integrity requirements from high to low: VM snapshot > container > firejail):

    • The middle and low tiers apply only to known low-risk samples: containers and firejail Shared host kernel—as long as the sample has a kernel attack surface (privilege escalation, kernel exploits, driver/kernel module payloads), these two tiers do not constitute an isolation boundary.The default for hosting unknown/high-threat samples is the VM snapshot; treating containers as a "fallback isolation layer" for general malicious samples is a common tier misuse
    • VM snapshot (VirtualBox/VMware): requires full restore + prevention of sample outbound connections/escape; the default choice for analyzing unknown high-threat samples
    • Container (Docker): quick testing of Linux binaries, low-risk samples
    • firejail: when you only need to restrict the filesystem and network, for a quick temporary run
    • Decision record: write down the chosen tier and the rationale, and prepare in advance the "restore snapshot after analysis" command (step 5)

  2. Network isolation(three tiers, from strong to weak):

    • Disconnected: set the VM network mode to Host-only / Internal (NAT allows outbound connections by default and cannot be used for disconnection); for firejail use --net=none
    • fake DNS: point suspicious domains to the local machine via /etc/hosts or dnsmasq; or firejail --dns=127.0.0.1
    • INetSim: point the sandbox DNS to the INetSim host, simulate HTTP/SMTP/FTP/DNS services and record all requests from the sample—the standard practice for C2 analysis (in conjunction with [[re-netcap]] in [[re-protocol]])
    • Verification: inside the sandbox ping 8.8.8.8 is unreachable;curl http://example.com hits the INetSim simulated response

  3. Snapshot creation：

    # VirtualBox
VBoxManage snapshot <vm> take clean
# VMware
vmrun snapshot <vm> clean
# Docker: 提交运行中容器为镜像
docker commit <container> sandbox-image:v1
# firejail 无快照概念——靠 --private/--private-etc 临时目录，退出即清理

    The snapshot content should at least include: clean OS + analysis tools (procmon / sysdig / bpftrace) + network isolation configuration.

  4. Sample transfer in/out (isolated channel)：

    • In: read-only shared directory; disable clipboard/drag-and-drop sharing in the VM (to prevent the sample from reading back into the host); or scan with antivirus before transferring in
    • Out: take artifacts (logs/memory dumps/config) out via a dedicated output directory, stored separately from the sample for evidence
    • Before transfer in, preserve the original sample sha256sum as evidence (see [[re-triage]]), keeping one copy of the original hash on the host and one inside the sandbox
    • Disable Guest Additions clipboard/drag-and-drop sharing, enable only Host-only networking—for countermeasures against VM escape detection see Pitfall 4

  5. Restore snapshot after analysis：

    VBoxManage snapshot <vm> restore clean
# Docker
docker rm -f <container>
# firejail——没有 --clean 选项（0.9.80 实测报 invalid option），按名/PID 关停：
firejail --shutdown=<name|pid>   # 沙箱名/pid 用 `firejail --list` 查
# 或直接退出 firejail 进程，--private 临时目录退出自动清理

    Verification after restore: VBoxManage snapshot <vm> list confirm it is back to clean; inside the sandbox ps aux no residual processes. Not restoring the snapshot = environment contamination (see Pitfall 1).

Cross-domain combination

  • [[re-malware]]: step 1 of this gateway workflow is mandatory as a prerequisite—the default highest principle for sandboxes ([[re-analyze/platform-tips]]), all dynamic analysis of malicious samples starts here
  • [[re-anti-analysis]]: dynamic verification of unpacked artifacts must be rerun inside the sandbox (to determine whether the packer has been fully unpacked)
  • [[re-protocol]]: C2 traffic capture relies on this skill's INetSim / fake DNS network isolation environment
  • [[re-binary-core]]: its dynamic phases ([[re-tracing]] / [[re-gdb]] / [[re-x64dbg]] / [[re-memdump]]) reference this skill as a runtime prerequisite
  • [[re-evasion]]: the adversarial surface when a sample detects the sandbox/VM environment (escape and anti-sandbox)—detection point location and bypass are handled according to that domain

Common pitfalls and traps

  • Forgetting to restore the snapshot = environment contamination: Symptom — the next analysis sandbox contains remnants from the previous sample (processes/files/registry), and the two analysis results contaminate each other; Cause — snapshots are only created but never restored, leaving the sample's persistence behavior in the sandbox; Countermeasure — write down the restore command in step 1, execute it immediately after analysis, and after restoration verify there are no residual processes
  • Network not isolated, sample makes outbound connections: Symptom — the sample actually accesses an external C2 or continues to spread; Cause — skipping network isolation and running directly with internet access; Countermeasure — before any run, first isolate according to one of the three tiers in step 2, and verify where ping/curl actually land
  • Containers sharing the kernel ≠ complete isolation: Symptom — the sample exploits a kernel vulnerability or modifies global settings such as sysctl to affect the host; Cause — Docker shares the kernel with the host, isolating only via namespace/cgroup; Countermeasure — use VM snapshots rather than containers for high-threat samples, and use containers only for low-risk quick tests
  • Sample detects VM environment and escapes: Symptom — the sample detects VM characteristics (Guest Additions, vmware processes, virtual NIC names) and then sleeps/exits, so behavior analysis yields no results; Cause — anti-analysis techniques (see the [[re-anti-analysis]] domain); Countermeasure — disable Guest Additions, change virtual hardware fingerprints, and cooperate with the delay/interaction check countermeasures in [[re-behavior]] to extend observation
  • Timing detection (RDTSC / Sleep acceleration): Symptom — the sample sleeps for 30 seconds and then exits directly or behaves abnormally, or RDTSC timing reveals "the time is wrong"; Cause — sandboxes often hook/accelerate timing APIs (Sleep/GetTickCount), and the sample uses RDTSC (with CPUID to force a VM exit),Sleep+GetTickCount comparison,GetSystemTimeAdjustment etc. to detect anomalies; Countermeasure — identify the timing detection points (xref RDTSC/GetTickCount/NtDelayExecution), keep the sandbox clock real or patch the detection points and continue ([[re-anti-analysis]] domain), and when a long wait is needed use real waiting rather than an accelerated clock
  • Environment naming and resource threshold detection: Symptom — the sample does not trigger malicious behavior under the sample.exe/malware directory, and behavior differs greatly after renaming or adjusting resources; Cause — detection of analysis file names/paths, CPU core count/memory/disk capacity thresholds, and lack of mouse/keyboard interaction (ATT&CK T1497.001); Countermeasure — standardize sample naming (avoid words like sample/sandbox/malicious), ensure the sandbox has sufficient resources (≥2 cores, ≥2GB memory, normal disk capacity), and cooperate with interaction simulation (mouse movement) and delayed observation in [[re-behavior]]
  • Sandbox isolation ≠ analysis environment disguise: Symptom — the sample runs safely inside the isolated environment but still changes behavior due to time/hardware/input environment fingerprint detection; Cause — isolation ≠ disguise: time/hardware/input detection are environment fingerprints, and even a complete VM can be detected; Countermeasure — handle "isolation" and "environment disguise" separately, locate detection points one by one by fingerprint category (time/hardware/input), and then respond in a targeted way ([[re-anti-analysis]] domain), referring to the sandbox branch of [[re-analyze/platform-tips]]
  • Simple interaction simulation is seen through by statistical detection: Phenomenon—mouse movement/input events were simulated, yet the sample still determined "non-human" and did not trigger the payload; Cause—new samples such as Rhadamanthys perform statistical-level validation of interaction: sampling cursor/foreground window/timestamp 1500 times at 30ms, requiring cursor movement ≥30 times and ≥2 different foreground windows (one of which is a non-desktop process), then using Euclidean distance of the cursor trajectory to discriminate "non-human" movement patterns, with an observation period of up to 45s+; Countermeasure—simulate according to human behavior distributions (random intervals, nonlinear trajectories, real window switching) rather than fixed-pixel movement, satisfy the control sample's sampling parameters (cursor/foreground window/timestamp) one by one, and lengthen the observation window (CAPE/VMRay already have this level of interaction simulation built in)
  • The firejail cleanup option has been misreported (--clean does not exist): Phenomenon—executing according to old documentation firejail --clean reports invalid --clean command line option; Cause—neither the official man page (since 0.9.72) nor actual testing on 0.9.80 has this option, and tutorials copy the misinformation from one another; Countermeasure—sandbox list firejail --list check name/pid, use firejail --shutdown=<name|pid> to shut down; temporary directories rely on --private automatic cleanup on exit
  • Samples execute via whitelisted processes (brokered execution): Phenomenon—in the sandbox, the sample's own process behavior is almost clean, and all malicious actions occur in processes such as rundll32/mshta/PowerShell/WMI; Cause—the sample "outsources" sensitive actions to already-allowed processes via IPC (ALPC/RPC/COM/named pipes) or LOLBins—monitoring only the sample process misses the real behavior; Countermeasure—observe by "the entire process chain derived from the sample" (parent → subtree, Sysmon 1 process creation correlation), filter procmon/sysdig by the root process rather than a single process, and use kernel-side (ETW/bpftrace) to fill user-mode monitoring blind spots