Case Study 2 — The Sandbox That Wasn't

A small IT firm took on its first incident-response engagement after a client was hit by ransomware. Trying to understand the malware, the firm detonated a live sample in a "sandbox" that was wired straight into its own network — and watched the sample encrypt the only forensic image of the client's server, the firm's production files, and a NAS the firm had been calling its "backup." Every single failure was one the chapter names by name. This is the cautionary mirror of the lab that could show its work.

Background

A six-person managed-services provider (MSP) had a respectable IT shop but no real forensic lab — just two technician workstations, a few external drives, and a network-attached storage box that served as the firm's file share. When a long-standing client, a small manufacturer, was hit by ransomware overnight (the situation of anchor #3, the ransomware recovery), the client asked the MSP to "figure out what it was and get us back up." The MSP had never run an investigation, but the money was good and the client was loyal, so they said yes.

They got two things half-right and everything else wrong. Half-right: a technician knew enough to grab a copy of the encrypted server and a copy of the ransomware executable "before anyone touched anything." Wrong: how they stored those copies, and what they did next.

The forensic copy of the client's server went onto the firm's NAS — the same NAS that held the firm's own production files and that the firm described to clients as its backup. The NAS was a four-bay box in RAID 5, which the owner believed meant "our data is safe." There was no off-site copy, no immutability, no encryption at rest, and no separation between "evidence," "production," and "backup": all three were the same volume.

Then, to identify the malware, the technician spun up a Windows VM in VirtualBox on his own workstation, copied the live sample into it, and ran it.

What happened

The VM's network adapter was configured as bridged — it appeared on the firm's physical LAN as just another machine, exactly as if a second laptop had been plugged into the wall. There was no isolated virtual switch, no host-only network, no simulated internet, no clean snapshot to revert to. The technician's mental model was "it's a VM, so it's contained." It was not. A VM with a bridged adapter is contained from nothing; it is on the network.

The sample was a network-aware ransomware variant. On execution it did three things in quick succession.

   DETONATION-DAY TIMELINE  (reconstructed afterward)
   --------------------------------------------------------------
   14:02  sample executed inside "sandbox" VM (bridged NIC)
   14:02  sample enumerates network shares reachable from the VM
   14:03  begins encrypting mapped/discoverable SMB shares
   14:07  firm NAS shares encrypting  (production + "backup" + the
          forensic copy of the client's server — all one volume)
   14:19  technician notices files renaming; pulls VM network
   14:21  too late: NAS volume largely encrypted; no off-site copy
   --------------------------------------------------------------

By the time the technician realized what the renaming files meant and yanked the VM's connection, the damage was done. Because the firm's evidence, production, and "backup" were the same RAID 5 volume, encrypting it once destroyed all three. RAID 5 did exactly what RAID is for — it would have survived a dead disk — and exactly nothing of what the firm needed: it has no defense against a process that simply overwrites the files. There was no off-site copy, no read-only snapshot, no WORM tier. The only forensic image of the client's server was gone, encrypted by the very investigation meant to study it.

The client's own recovery then played out as anchor #3 always does without good backups: shadow copies had been deleted by the original ransomware, an old external backup was two months stale, and the rest was partial carving of whatever survived. The MSP's mistake did not cause the client's original incident — but it destroyed the cleanest evidence of it and converted the investigators into a second victim.

It got worse on the legal side. Months later, when the client's cyber-insurer and an outside counsel reviewed the matter, they asked the MSP to demonstrate that its surviving artifacts had been handled soundly. They could not. The server copy had been made by plugging the drive into a running technician workstation — no write-blocker, no validation record, no hash computed at acquisition, working on the original rather than a verified image. Whatever evidentiary value the surviving fragments might have had was now eminently challengeable. The firm had no SOPs to point to, no tool-validation log, no chain-of-custody record beyond a few emails.

The analysis

  1. A "sandbox" on the network is not a sandbox. The single decision that caused the disaster was the bridged adapter. The chapter's rule is absolute: the detonation zone must be an isolated island — an internal-only/host-only virtual switch with no route to the physical network, a clean snapshot to revert to, and a simulated internet (INETSIM/FakeNet-NG), never the real one. "It's a VM" contains nothing by itself.

  2. Collapsing evidence, production, and backup onto one volume is a single point of total failure. The chapter's tiering exists precisely so that one bad event cannot take everything. Evidence belongs on its own protected tier; it must never share a volume with the lab's day-to-day files, and a "backup" that lives on the same box as the thing it backs up is not a backup at all.

  3. RAID is not backup — and this is how that abstract warning becomes a real fire. RAID 5 survives a drive failure; it offers zero protection against ransomware, deletion, fire, or theft. The firm needed the 3-2-1 discipline (three copies, two media, one off-site) and, for evidence, an immutable/WORM copy a rogue process cannot overwrite. A read-only ZFS snapshot or an offline copy would have survived 14:07 untouched.

  4. Containment is the one mistake you cannot afford even once. Network isolation is not a nicety you add when you have time; a single escape can encrypt irreplaceable evidence, spread to production, and beacon to the attacker. The firm treated isolation as optional and lost the case file, its own files, and its credibility in nineteen minutes.

  5. Even the surviving evidence was indefensible, because the acquisition skipped every safeguard. No write-blocker, no acquisition hash, no working-on-a-copy, no SOP, no validation log, no custody record. The chapter's other half — protect the original, document everything — was ignored too. A lab is the whole set of properties; honoring none of them, the firm had IT equipment, not a forensic lab.

Discussion questions

  1. Walk through the minimum changes that would have prevented the catastrophe at 14:07 without spending much money: which network setting, which storage separation, and which one off-site or read-only copy. Why are these "free or nearly free," and why did the firm skip them anyway?

  2. The MSP's instinct to grab a copy of the server and the sample "before anyone touched anything" was correct. Diagnose exactly where good instinct met bad infrastructure, and rewrite the firm's next ten minutes as they should have gone, from "we have a sample" to "it is contained."

  3. The firm believed "RAID 5 means our data is safe." Script the two- or three-sentence correction you would give a peer who says this — distinguishing what RAID does protect against from what it does not, and naming the principle that closes the gap.

  4. The MSP did not cause the client's original ransomware incident, yet it made the overall outcome far worse. Argue how much professional responsibility the firm bears for destroying the cleanest evidence, and what it implies about taking on forensic/IR work without first building (even a modest) lab to the chapter's four properties.

  5. ⭐ Contrast this case directly with Case Study 1. Both involved a serious matter and a live or sensitive artifact; one lab's build answered every question and the other's build caused the loss. Identify the three or four specific architectural decisions that diverged (isolation, storage tiering, immutability/backup, acquisition discipline) and argue the chapter's thesis in your own words: that "a modest lab with a flawless record beats an opulent lab with a gap" — and that the reverse, an informal setup with good intentions, can lose everything in minutes.