Image: malware analysis sandbox cybersecurity code dark screen
—
All analysis described here is for defensive security purposes — understanding malware to build better detection and response capability. Never analyze suspected malware on production systems or outside an isolated environment.
—
Dynamic malware analysis — running a suspicious sample and observing its behavior in a controlled environment — is one of the highest-value activities in incident response and threat intelligence. It tells you what the malware actually does rather than what you think it might do based on static indicators. A sandbox collapses analysis time from hours to minutes and provides behavioral IOCs that static analysis frequently misses.
Here’s the practical workflow, including both cloud-based and self-hosted options.
Cloud Sandboxes: Fast and Zero-Setup
For most analysts, cloud sandboxes are the right starting point. Zero infrastructure, instant results, and most are free for individual use.
Any.run (any.run)
The most interactive cloud sandbox available. Any.run runs samples in a real Windows VM (7, 8.1, 10, 11) or Linux environment and provides a live interactive session — you can click, type, and interact with the malware’s UI in real time, which is critical for samples that require user interaction to detonate (phishing documents that need a macro enabled, installers that need clicks through a wizard).
The free tier is public (your sample and results are visible to other users — critical consideration for sensitive or internal files). The paid tier provides private analysis. For malware from the wild, public analysis is generally fine and contributes to the community.
What Any.run gives you:
- Process tree (what processes were spawned and by what parent)
- Network activity (DNS queries, HTTP/S requests, IP connections)
- File system changes (files written, modified, deleted)
- Registry changes
- MITRE ATT&CK technique mapping
- Extracted indicators (IPs, domains, hashes)
- Downloadable PCAP
Joe Sandbox (joesandbox.com)
More automated and less interactive than Any.run, but extraordinarily detailed reporting. Joe Sandbox’s reports include behavioral signatures, YARA rule matches, Sigma rule matches, network IOCs, and a full behavioral graph. The free community tier has limits but is useful. Joe Sandbox is the choice when you want depth over interactivity.
Hybrid Analysis (hybrid-analysis.com)
Powered by CrowdStrike Falcon Sandbox. Free tier is generous. Reports include VxStream behavioral analysis, network IOCs, extracted strings, and threat scoring. Integrates well with VirusTotal lookups. Good general-purpose option.
Triage (tria.ge)
Run by Hatching, which was acquired by Recorded Future. Fast analysis, strong community data integration, and good API access on the free tier. Particularly strong for ransomware and banking trojan families.
When to Use a Cloud Sandbox vs. Self-Hosted
Use cloud for:
- Commodity malware, phishing samples, samples you pulled from public sources
- When speed matters more than privacy
- When you don’t need to modify the environment
Use self-hosted for:
- Internal samples or files that contain sensitive organizational data
- Malware that detects cloud environments and refuses to execute
- Samples requiring custom configurations (specific software installed, domain-joined VM, specific network topology)
- High-volume analysis where API limits or per-sample costs matter
Self-Hosted: Cuckoo Sandbox
Cuckoo Sandbox is the standard open-source dynamic analysis platform. It runs samples in isolated VMs, captures network traffic via tcpdump, hooks API calls via its monitoring agent, and generates detailed reports.
Architecture:
- Host machine (Linux, runs the Cuckoo controller)
- Guest VMs (Windows or Linux, snapshot-based, restored after each analysis)
- Networking: usually an internal network with the host routing traffic and running inetsim or FakeNet to simulate internet connectivity without actual external access
Quick deployment with Cape Sandbox (CAPEv2):
Cuckoo’s actively maintained fork, Cape (Automated Payload Extraction), adds unpacking and config extraction capabilities. The recommended installation:
# On Ubuntu 22.04
git clone https://github.com/kevoreilly/CAPEv2.git
cd CAPEv2
sudo bash installer/kvm-qemu.bash <username>
# Follow the setup guide in the documentation
Cape adds automatic unpacking of packed malware, config extraction for known families (Emotet, Qakbot, Cobalt Strike, etc.), and YARA rule integration.
Windows VM preparation:
The analysis VM must be configured carefully:
- Install common software (Office, Adobe Reader, Chrome, 7-Zip) to avoid “environment looks wrong” sandbox evasion
- Disable Windows Defender and automatic updates
- Set a realistic wallpaper and hostname
- Take a clean snapshot from which analysis runs are restored
- Install the Cuckoo/Cape agent
The Analysis Workflow
Step 1: Collect and preserve the sample.
Hash the sample immediately (SHA256) before any analysis. This is the authoritative identifier.
sha256sum suspicious_file.exe
# Also:
md5sum suspicious_file.exe
Check the hash against VirusTotal first — if it’s a known sample, you may have all the intelligence you need without running it. If it’s novel, proceed.
Step 2: Static pre-analysis.
Before running anything, extract what you can statically:
# File type identification
file suspicious_file.exe
exiftool suspicious_file.exe
# String extraction
strings -n 8 suspicious_file.exe | grep -E "(http|https|ftp|cmd|powershell|regsvr)" -i
# PE analysis
pestudio suspicious_file.exe # Windows tool, excellent for PE inspection
# or: python3 -m pefile suspicious_file.exe
Static indicators (hardcoded IPs, domains, registry keys, mutex names) sometimes give you IOCs without executing anything.
Step 3: Submit to sandbox.
For Any.run: upload via web interface, select OS and configuration, enable MITM if you want TLS decryption, start analysis. Watch the interactive session.
For Cuckoo/Cape:
cd CAPEv2
python3 utils/submit.py --timeout 120 /path/to/suspicious_file.exe
Step 4: Collect and triage results.
Network IOCs: domains, IPs, user agents, URL patterns. These are your fastest-value takeaways — block them at the firewall and DNS level immediately.
Process behavior: What did it spawn? powershell.exe spawned by winword.exe is a macro execution indicator. cmd.exe spawned by svchost.exe in unusual paths is a process injection indicator.
Persistence mechanisms: Registry run keys, scheduled tasks, service installation — document these for detection rules.
Dropped files: Secondary payloads the initial dropper wrote to disk. Hash and analyze each one.
Step 5: Produce detection artifacts.
Turn behavioral IOCs into detection rules:
- Suricata/Snort rules for network patterns
- Sigma rules for Windows event log patterns
- YARA rules for file signatures
- EDR exclusion reviews (if the malware mimics legitimate tools)
Malware Analysis Reference: Practical Malware Analysis by Sikorski and Honig on Amazon — the standard textbook for malware analysis, covering static and dynamic analysis methodology, disassembly, and debugging in depth. Essential reading for anyone doing regular analysis work.
Sandbox analysis is not a replacement for manual reverse engineering — sophisticated malware evades sandboxes, and sandbox reports don’t explain why malware does what it does. But for the 90% of malware that’s commodity or semi-commodity, sandbox analysis produces actionable IOCs faster than any alternative. The workflow above, run consistently on suspicious samples entering your environment, builds threat intelligence that directly improves detection before the next sample arrives.