Dynamic Analysis Sandboxing

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Static analysis reads the file; dynamic analysis runs it and watches what it does. Detonating a sample in a controlled sandbox reveals behaviour that static analysis (especially against packed malware) can't easily show — what files it drops, what registry keys it sets, what processes it spawns, and who it talks to. This skill covers observing malware behaviour safely, which is often the fastest route to understanding a sample and extracting indicators.

When to use it

After static triage, especially when the sample is packed/obfuscated (so static content is hidden) or when you need behavioural indicators for detection and response. It runs strictly inside the isolated lab (building-a-malware-lab skill) — dynamic analysis means executing hostile code on purpose, so containment is non-negotiable.

Procedure

1. Confirm the lab is isolated and snapshotted clean. Before detonating: host-only/internal network, fake internet services (INetSim) to capture callbacks, no path to production, and a clean snapshot to revert to. This is the prerequisite — never detonate outside it.
2. Set up monitoring before you run. Start the observation tools so you capture the behaviour from the first instant:
   • Process/file/registry: Procmon (Sysinternals) records every filesystem, registry, and process operation.
   • Process tree: Process Explorer / Process Hacker shows spawned processes and injection.
   • Network: Wireshark/tcpdump on the services VM captures C2 and downloads (with INetSim answering).
3. Detonate and observe. Run the sample and watch what it does — files dropped (often to %TEMP%, %APPDATA%), registry keys created (especially Run keys and persistence locations), processes spawned, and network connections attempted. Give it time; some malware delays or waits for a trigger.
4. Capture the behavioural indicators — the artifacts that become detections and IoCs: dropped file names/hashes, registry keys, mutexes, service/scheduled-task creation, and network destinations (feeds the extracting-iocs skill).
5. Watch for evasion. Sophisticated malware detects sandboxes/VMs and behaves benignly (or not at all) when it thinks it's watched — checking for VM artifacts, few CPUs, analysis tools, or requiring user interaction. If a sample "does nothing", suspect evasion rather than concluding it's harmless.
6. Consider automated sandboxes (Cuckoo/CAPE self-hosted, or online services like any.run/Joe Sandbox) for a fast behavioural report — but understand automated sandboxes are also what evasive malware targets, and confidential samples shouldn't go to public services.
7. Revert to the clean snapshot after analysis — never reuse a detonated VM.

Cheatsheet

PREREQ: isolated lab, INetSim faking internet, clean snapshot (building-a-malware-lab)
        never detonate outside it. revert after every run.

set up monitoring BEFORE running
  Procmon              file / registry / process operations (all of them)
  Process Explorer/Hacker   process tree, injection
  Wireshark/tcpdump    network (C2, downloads) — INetSim answers the callbacks

detonate + observe -> behavioural indicators
  dropped files (%TEMP% %APPDATA%) + hashes
  registry keys (Run keys, persistence)
  spawned processes, mutexes, services/scheduled tasks
  network destinations (domains/IPs/URLs)   -> feeds extracting-iocs

evasion watch: "does nothing" often = sandbox/VM detection, not harmless
  (checks VM artifacts, CPU count, analysis tools, needs user interaction)

automated: Cuckoo/CAPE (self-host) | any.run/Joe (public — not for confidential samples)

Reading the behaviour

• Files dropped + registry Run keys + a spawned process = the malware installing and persisting; these artifacts are your primary IoCs and detection material.
• Network callbacks captured by INetSim = C2/download behaviour observed safely (nothing left the lab) — the destinations are high-value indicators (feeds c2-and-network-analysis).
• A mutex or unique artifact = often a reliable detection signature and sometimes a "already infected" marker.
• The sample doing nothing / exiting immediately = suspect sandbox evasion (it detected the VM) rather than concluding it's benign; try anti-evasion measures or manual analysis. This misread is a common trap.
• Persistence mechanism created (Run key, service, scheduled task) = exactly what IR needs to hunt and eradicate (feeds the IR eradication skill).
• Rich, captured behaviour with indicators extracted = the payoff of dynamic analysis, often faster than fully reversing the binary.

Pitfalls

• Detonating outside a properly isolated lab. The cardinal sin — a sample on a networked host spreads or phones home. Confirm isolation and INetSim first; revert after.
• Starting the sample before monitoring. You miss the initial behaviour (which is often the most important). Set up Procmon/network capture first.
• Concluding "harmless" when it does nothing. Evasive malware plays dead in a sandbox; absence of behaviour frequently means detection, not safety. Suspect evasion.
• Reusing a detonated VM. It's contaminated; every run starts from the clean snapshot.
• Sending confidential samples to public sandboxes. Convenient, but leaks the sample and may tip off a targeted attacker. Self-host for sensitive work.

References

• Practical Malware Analysis (dynamic analysis chapters)
• Sysinternals (Procmon, Process Explorer), Wireshark, INetSim documentation
• Cuckoo/CAPE sandbox; any.run / Joe Sandbox
• The building-a-malware-lab, extracting-iocs, and c2-and-network-analysis skills

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.