The Lab: Detonating Without Burning Down the House

Years ago a new analyst on my team detonated an invoice-themed loader on a VM with bridged networking. Nothing got infected — the VM did its job. But the loader beaconed out through our corporate NAT, the operator saw a callback from a security vendor's address block, and within the hour the C2 we'd been quietly tracking for two weeks went dark. The damage wasn't code. It was intelligence. That's the first thing to internalize: a lab contains signal, not just malware.

Threat model your lab

Three things actually go wrong, in order of how often I've seen them:

1. Leakage — the sample reaches the real internet from an IP that identifies you. The operator learns they've been caught; worse, a spambot or fraud module does real damage from your address space.
2. Contamination — you run sample B on a VM still dirty from sample A, and attribute A's persistence to B. Your report is now wrong and nobody can tell.
3. Escape — code reaches the host or LAN. Hypervisor escapes are expensive exploits, not commodity loader features. Your real escape paths are shared folders, the shared clipboard, and you double-clicking things on the host.

The reference layout

host  (no shared folders, no clipboard, no drag-and-drop)
 └─ host-only net 10.0.0.0/24  — no route to the LAN or internet
     ├─ win10-analysis  10.0.0.20   FLARE-VM tooling, snapshot "clean-baseline"
     └─ remnux          10.0.0.1    INetSim + Wireshark; gateway AND DNS for the victim

VBoxManage modifyvm "win10-analysis" --nic1 hostonly --hostonlyadapter1 vboxnet0
VBoxManage modifyvm "win10-analysis" --clipboard-mode disabled --draganddrop disabled
VBoxManage snapshot "win10-analysis" take "clean-baseline" --description "FLARE-VM, tools, no samples"

On REMnux, INetSim plays the internet. Every DNS name resolves to the sinkhole, every HTTP request gets a canned answer, and every attempt lands in the log:

# /etc/inetsim/inetsim.conf
start_service dns
start_service http
start_service https
start_service smtp
service_bind_address  10.0.0.1
dns_default_ip        10.0.0.1

Handling samples like they're loaded

sha256sum invoice_0412.exe | tee -a case-2291/hashes.txt
mv invoice_0412.exe 7f3a9c41e2b8d05f6a1c9e7d3b42f08a6e5d1c3b9a7f2e4d8c6b0a1f3e5d7c9b.bin
7z a -tzip -pinfected case-2291-samples.zip *.bin      # "infected" is the industry convention

Rename to the hash with a dead extension so nothing executes on double-click. Defang every URL in tickets and chat (hxxps://cdn-telemetry-update[.]top) — chat clients unfurl links, which means fetching them from your corporate IP.

When you genuinely need live internet

Some second stages are only served to "real" victims. Going live is a decision, not a toggle: separate egress (a throwaway cloud box or commercial VPN, never corporate), sign-off from the IR lead, a time box, and a note in the case log. Assume the operator sees you.

Field notes

• Revert to the clean snapshot after every detonation. "I'll just try one more thing" is how run two inherits run one's registry keys.
• Disable Defender's automatic sample submission in the analysis VM — otherwise it quietly uploads your targeted sample before you've decided whether to share it.
• Keep a timestamped analysis log. IR will ask "when did you first execute it?" and the answer goes in the incident timeline.
• The host is not your lab. Never refang a URL on the host "just to check something".