A forensics and research lab, off the corporate network

What the team actually needed

An analyst’s work stops at a boundary more often than the job description suggests. A phishing message points at a site the enterprise proxy blocks — correctly, for everyone else. A sample needs to be run rather than read. A claim about an address, a host, or a messaging service needs checking against the thing itself, not against someone else’s summary of it.

Doing any of that from a corporate workstation is poor practice on two counts, and neither is a secret. Detonating hostile code inside the enterprise network asks the controls you are trying to understand to contain the thing you are trying to understand. And research traffic leaving from corporate egress is itself a disclosure: it tells whoever is on the other end that someone at that organization is paying attention, which is not information worth giving away for free. The conventional answer, taught in every forensics course and practised by most mature teams, is to do the work somewhere else — on hardware that is not part of the enterprise, over a connection that is not the enterprise’s.

The Dow SOC did not have that workspace. I built it.

What I built

An independent workstation with its own dedicated internet connection, kept off the enterprise network, running a set of VMware virtual machines: Windows 11, Windows 10, Red Hat, SANS SIFT, and Kali.

The loadout is deliberately unremarkable. Between them, those guests cover the three jobs the team needed: detonating malware somewhere the blast radius ends at a discarded snapshot, reaching web infrastructure that enterprise filtering blocks and should keep blocking, and collecting open-source intelligence without the employer’s name attached to every request.

None of that is a novel toolchain, and the value was never supposed to come from the toolchain. It came from where the tooling sat. A virtual machine on a managed corporate laptop is a convenience; the same virtual machine on separate hardware behind a separate connection is a different category of thing, because the isolation is no longer a setting that a misconfiguration can quietly undo. The design decision that mattered was the boring one — separate hardware, separate line — and everything above it is standard.

What it made possible

Most of what it does is routine, and that is the point. Automated analysis environments are fingerprintable — a site that suspects it is being examined can serve something harmless, or nothing at all, and the report comes back clean because the site decided it should. When the automated path is degraded that way, a manually driven environment is what you fall back to. That is the lab’s steadiest job: somewhere to look when the usual route stops returning useful answers.

The rest is occasional, and one example I can describe in general terms.

While investigating an emerging threat actor, the team needed to reach a closed channel the group used for its own coordination. That is not something you can responsibly open from a corporate desktop, and it is not something the enterprise network would have let through in the first place. Because the forensic environment existed, the access was possible, and the material found there informed how the team understood the group.

What was in the channel is not for this page. It belongs in threat intelligence reporting, not on a personal website, and describing it would help the group more than it would help any reader here. The point that is mine to make is narrower: an investigative capability the team did not previously have became available because someone had built the plumbing in advance. The environment was not built for that investigation. It was already there when the investigation needed it, which is generally the only way infrastructure like this is useful.

What I would build differently

This is the part I would want to read, so it is the part I will not soften.

The isolation rests on a desktop operating system. The environment runs as virtual machines on a Windows host. That works, and it is how a great many labs are built, but it means the boundary between a detonated sample and everything else depends on a general-purpose consumer OS and a hypervisor running as an application on top of it. That is a wider attack surface than the job needs. If I rebuilt it today I would use Proxmox on bare metal: a smaller host, a hypervisor that is the system rather than a program running on one, and network segmentation between guests as a first-class configuration instead of something layered on afterwards.

The separation between the virtual machines is weaker than the separation from the enterprise. I was careful about the outer boundary — off-network hardware, its own connection — and less rigorous about the internal ones. A detonation guest and a collection guest have genuinely different threat models and should not be able to see each other by default. Getting the outer boundary right and leaving the inner ones loose is a familiar mistake, and I made it.

I built the environment and not the capability. A lab is only worth what the people using it can do with it, and deep forensic examination and malware reverse engineering are not skills anyone acquires by being handed a virtual machine. What is missing is a training path: a deliberate program that takes an analyst from triage work into those techniques, with the lab as the place the practice happens. Without it, the environment’s usefulness tracks whoever happens to already know how to use it, which is a fragile way to hold a capability. Of the three, this is the one I would fix first — the hypervisor change is an afternoon of rebuilding, and this is not.

None of this makes the first version a mistake. The team needed somewhere to work and now has it, and the version that exists has already earned its keep. But the gap between “this works” and “this is built the way it should be” is usually where the useful part of the review is, and I would rather write that gap down than leave it implied.