so you've downloaded something sketchy and you want to see what it does without turning your pc into a botnet node. welcome to sandboxing.
what even is a sandbox
a sandbox is basically a contained environment where you can run untrusted code without it touching your actual system. think of it like a quarantine room for software. whatever happens inside stays inside (in theory).
there's different levels to this:
- browser sandboxes (chrome tabs are sandboxed from each other)
- application sandboxes (like windows sandbox or sandboxie)
- virtual machines (full isolated operating system)
- bare metal analysis (dedicated hardware you don't care about)
for malware analysis, you typically want a vm at minimum. anything less and you're playing with fire.
setting up a basic analysis environment
my go-to setup is virtualbox or vmware with a windows 10/11 vm. here's the important bits:
before you do anything:
- snapshot your clean vm state. seriously. do it now. you'll be reverting to this constantly
- disable shared folders between host and guest
- disable clipboard sharing
- use host-only or internal networking (no internet access for the malware)
- disable any vmware/virtualbox guest additions if you're analyzing vm-aware malware
tools to have inside the vm:
- process monitor (procmon) - watches file/registry/network activity
- process explorer - like task manager but actually useful
- wireshark - network traffic capture
- x64dbg or ida free - if you want to dig into the binary
- pestudio - quick static analysis
- fakenet-ng - simulates network services so malware thinks it's online
the basic workflow
- take a snapshot of your clean vm
- copy the sample into the vm (disable network first)
- run your monitoring tools (procmon, wireshark, etc)
- execute the malware
- watch what happens
- document everything
- revert to snapshot
- repeat if needed
sounds simple but the execution matters. some malware won't do anything interesting until it phones home, others detonate immediately. some check if they're in a vm and just exit.
vm detection is everywhere
modern malware isn't stupid. it checks for signs of virtualization before doing anything malicious:
- vmware/virtualbox registry keys
- specific hardware ids
- timing attacks (vm operations are slower)
- checking for analysis tools running
- looking for suspiciously clean systems (no documents, no browser history)
ways to counter this:
- use vmware workstation's "hide vm" features
- populate the vm with realistic looking files and browsing history
- install random software that a real user would have
- rename analysis tools to something generic
- there's scripts that patch common vm detection checks
honestly though, some malware is so paranoid that you'll need bare metal for proper analysis. that's when you break out the sacrificial laptop.
network analysis without getting owned
you want to see what the malware tries to connect to without actually letting it connect. options:
fakenet-ng - simulates dns, http, smtp, etc. malware thinks it's online but traffic goes nowhere. this is usually enough.
inetsim - similar concept, runs on linux. set your vm's dns to point to it.
actual internet but monitored - risky but sometimes necessary. use a separate network segment, capture everything, and be ready to pull the plug.
for c2 analysis you might need to actually let it connect to see the protocol. just make damn sure your analysis network is isolated from anything important.
static vs dynamic analysis
static analysis = looking at the binary without running it. strings, imports, entropy, packing detection. good for quick triage and safe.
dynamic analysis = actually running it and watching behavior. way more informative but obviously riskier.
usually you do static first to get an idea of what you're dealing with, then dynamic to confirm.
quick static analysis checklist:
- what's the file type actually? (don't trust extensions)
- is it packed/obfuscated?
- what does
stringsshow? any urls, ips, crypto strings? - what dlls does it import? (networking = probably phones home)
- check virustotal but don't rely on it
when vms aren't enough
some scenarios where you need to step up:
- bootkit/rootkit analysis (needs bare metal or specialized tools)
- vm-aware malware that refuses to run
- hardware-specific malware (pos systems, iot devices)
- anything that checks timing aggressively
for these, either:
- use dedicated analysis hardware you don't care about
- use a more sophisticated setup like drakvuf (xen-based introspection)
- sometimes you can patch out the vm checks manually if you're comfortable with a debugger
automated sandboxes
if you don't want to do this manually, there's services:
- any.run (interactive, free tier available)
- hybrid analysis (free)
- joe sandbox (paid but good)
- cuckoo sandbox (self-hosted, open source)
these are great for quick triage. upload your sample, get a report. but for serious analysis you'll still want your own environment.
don't be an idiot
some obvious things that people still mess up:
- don't analyze malware on your daily driver
- don't use shared folders
- don't copy files out of the vm carelessly
- don't assume the malware can't escape the vm (it's rare but vm escapes exist)
- don't upload sensitive samples to public sandboxes (they get shared)
- keep your vm software updated (vm escape vulns get patched)
my actual workflow
when i get a sample:
- quick virustotal check - see if it's already known
- pestudio for static analysis - get a feel for what it is
- spin up a snapshot, disable network
- run with procmon/process explorer watching
- see what files it drops, what registry keys it touches
- enable fakenet, run again, see what it tries to contact
- if interesting, dig deeper with x64dbg
- document findings, revert snapshot
most commodity malware isn't that sophisticated. the interesting stuff is the targeted attacks that actually try to evade analysis. those are the ones that keep you up at night.