Malware Analysis in a Sandbox: The Basic Workflow
Questo articolo è disponibile solo in inglese per ora.
Malware analysis is one of the areas where getting the setup wrong has real consequences — this is about the workflow that keeps it safe, not just informative.
Isolation comes before analysis
Never run a suspected malware sample outside an isolated virtual machine with no access to your real files, network, or credentials. This isn't excessive caution — some malware actively scans for and attempts to spread to any reachable network resource.
A reasonable minimum setup: a dedicated VM, snapshotted before analysis (so you can revert cleanly), with networking disabled or routed through a monitored, isolated virtual network rather than your real connection.
Step 1: Static analysis first
Before running anything, examine the file without executing it:
- Strings — readable text embedded in the file (URLs, file paths, error messages) often reveal a surprising amount about intent before you've run anything.
- File structure/headers — tools that parse the file format can reveal what kind of executable it is, what libraries it expects, and sometimes flag known-suspicious structural traits.
- Hash lookup — checking the file's hash against public malware databases (VirusTotal and similar) can immediately tell you if it's a known, already-analyzed sample, saving significant time.
Step 2: Dynamic analysis, inside the sandbox
Once you've done what you can statically, run the sample inside the isolated VM and observe:
- File system changes — what gets created, modified, or deleted.
- Network activity — connection attempts, even if the network is simulated/isolated, reveal intended command-and-control behavior.
- Registry/system changes (Windows) — persistence mechanisms, scheduled tasks, service creation.
- Process behavior — spawned child processes, injected code into other running processes.
Step 3: Revert, don't reuse
After analysis, revert the VM to its clean snapshot rather than trying to manually undo whatever the sample did. Malware can leave subtle changes that are easy to miss manually, and a fresh snapshot removes that risk entirely.
A minimal, reasonable toolset
| Purpose | Example tools |
|---|---|
| Isolated environment | A dedicated VM (VMware/VirtualBox), snapshotted |
| Static analysis | strings, PE viewers, hash lookup (VirusTotal) |
| Dynamic monitoring | Process Monitor, Wireshark (on an isolated network) |
| Disassembly (deeper analysis) | Ghidra |
This covers the workflow shape, not a full malware analysis course — treat any real sample with real caution, and if the goal is understanding an active incident rather than learning, that's a digital forensics situation with its own process considerations, not a casual analysis exercise.
Domande frequenti
Is it safe to analyze malware on my normal computer?
No — always use an isolated virtual machine with no access to your real files, network, or other systems. Malware can and does detect and exploit careless setups, and some strains actively try to spread to any reachable network resource.
Should the sandbox VM have internet access?
Generally no by default — many malware samples behave differently (or refuse to run at all) without network access, and connecting them to the real internet risks the sample contacting live command-and-control infrastructure or spreading. Use a simulated/monitored network only if you specifically need that behavior and understand the risk.
What's the difference between static and dynamic analysis?
Static analysis examines the file without running it (strings, structure, disassembly). Dynamic analysis runs it in a controlled environment and observes its actual behavior (file changes, network attempts, registry modifications). Both are normally used together — static analysis first to plan safely, dynamic analysis to confirm actual behavior.