The instruction I gave myself was short: this drive is for malware and viruses only, and nothing on it ever escapes. I had a spare 1TB laptop disk sitting idle and a growing need for a real research corpus — historical samples, malicious source code, detection rules, labelled datasets — in one place I could study without re-downloading dangerous files every time.

The interesting part of this project was never the collecting. Anyone can download malware. The whole engineering problem is the opposite of a normal drive: I needed one that is deliberately bad at being a disk. It must not run anything, must not mount itself, must not be reachable from the network, and must prove it stays that way. This is a write-up of that containment, the test that convinced me it works, and the migration that quietly broke it when I wasn’t looking.

The threat is the files, not an attacker

Normal storage hardening assumes the danger comes from outside — someone trying to read your data. Here the danger is inside, and my own machine is the thing I’m protecting. A corpus like this contains live ransomware binaries, worm source, and nation-state tooling. The failure mode isn’t theft; it’s one of those files running, even by accident — a double-click, a script that globs a directory and executes what it finds, a backup job that copies an infected file somewhere live.

So I built the containment in layers, on the principle that no single control should be the only thing standing between a sample and execution.

Encrypted at rest. The whole disk is a single encrypted volume. Powered off or unplugged, it’s meaningless noise — if it’s ever lost or stolen, nobody inherits a ready-made malware library. One detail worth knowing: the system’s password-quality checker refused to let me set the passphrase in an automated run, because it was being “helpful” about weak passwords. For full-disk encryption that check is misguided — length is the defence, not dictionary rules — so overriding it was correct, not a shortcut. The passphrase itself lives only in my password manager, with no reset path. That’s the point.

It never mounts by itself. The drive is marked so the desktop will never auto-mount it or even pop up the usual “removable disk” prompt when I plug it in. It’s also kept out of the boot-time mount list entirely. The only way it comes online is one explicit command I run on purpose, and the matching command to seal it again. A malware vault that mounts itself the moment it’s connected is a vault with the door propped open.

It physically cannot execute anything. This is the control I trust most. The volume is mounted with the flags that tell the kernel: nothing here may run as a program, nothing may gain elevated privileges, and no device files are honoured. On top of that, every file on the drive has its execute permission stripped. Belt and braces — because the mount flag and the file permission defend against different mistakes.

It is offline by design. There is no network path to this drive and nothing on it reaches out. The samples are inert data behind an encrypted door that only opens by hand. Acquisition of new samples happens in a separate staging area, from reputable research feeds, and those files only ever land on the vault when I’ve deliberately mounted it — never automatically, never while it’s sealed. The corpus and the internet never meet.

Samples stay packaged and inert. Following the convention the malware-research community has used for years, individual samples live inside password-protected archives, so even a careless file browser can’t preview or hand one off to something that would run it. They’re unwrapped only inside an isolated analysis environment, never on the host.

The test that convinced me

Controls you haven’t tested are decoration. The one I most wanted to prove was the “cannot execute” claim, because it’s the last line of defence.

So I ran the attack against myself, in miniature. I took a known-safe program, copied it onto the drive, and deliberately set its execute permission — simulating the worst case where a file somehow arrives marked runnable. Then I tried to run it.

The kernel refused: permission denied, even though the file was clearly marked executable. The “no-execute” mount flag overrode the file’s own permission bit — exactly as designed. And to make sure I wasn’t fooling myself with a test that would pass no matter what, I ran the same safe program from a normal location first and watched it execute fine. That’s the part people skip: a test that only checks the failure case can pass because the whole thing is broken. You need a positive control — prove you can run it somewhere normal, so that “cannot run it here” actually means something.

That pairing — the thing that should be blocked is blocked, and the thing that should work still works — is the difference between a test and a comforting ritual.

There’s a tarball I never unpack

One item gets stricter handling than everything else: a large archive of tens of thousands of live virus binaries from a historical collection. I keep it exactly as it arrived — a single sealed, integrity-checked archive — and the rule written next to it is blunt: never extract this outside the isolated detonation lab. Unpacked onto a normal filesystem, it’s thirty-odd thousand loaded weapons lying around. Sealed, it’s one inert blob I can verify hasn’t changed. Some things are safest when you refuse to make them convenient.

Proving it hasn’t rotted or been tampered with

A long-lived collection of dangerous files raises a quieter question: how do I know, months later, that nothing has changed — no bit-rot, no silent tampering, no file that isn’t what its name claims?

Every file has its cryptographic fingerprint recorded in a manifest, and after every single time I open the drive I re-verify the whole set against it. Tens of thousands of fingerprints, all matching, exit code zero — that’s my evidence the corpus is bit-for-bit what it was when I sealed it. This caught a subtlety worth passing on: a verification run on a huge file set can be killed partway through by the system reclaiming memory, leaving a truncated manifest that then “passes” because it’s only checking the files it got to. The fix was to make the process resumable and to only ever accept a manifest whose line count exactly matches what it should be. An incomplete check that reports success is worse than no check, because you trust it.

Sealing, finally, is verified too. When I close the drive, I confirm the encrypted volume shows no open mapping and nothing is mounted — the door isn’t just shut, I’ve checked it’s locked.

The lesson: containment belongs to the system, not the disk

Here’s the part that stung, and the reason I’m writing this instead of just quietly running it.

I moved my work to a new machine. The drive came with me, of course — same disk, same encryption, same files. But the containment didn’t. Every control I described above lived in configuration on the old machine: the don’t-auto-mount rule, the no-execute mount settings, the by-hand open/seal commands. None of that is stored on the drive. It’s a property of the host.

So the first time I plugged the vault into the new laptop, the desktop did what desktops helpfully do: it auto-mounted it — without the no-execute protection — and sat there with the door wide open. For a window, the single most important control was simply gone, and nothing warned me. The drive was behaving perfectly; the machine around it wasn’t the machine I’d hardened.

I caught it, rebuilt every layer on the new host, re-verified the whole corpus from the properly-locked-down path, and sealed it. But the lesson reframed the whole project for me. Containment is not a thing you do to a dangerous object once. It’s a property of the environment that handles it, and it has to be re-established every time the environment changes. The drive is just a drive. The safety was always in the host — which means the safety is only ever as portable as I make it, and I now treat “does the containment actually exist here?” as the first question every time it’s connected, not an assumption.

A malware vault is a good forcing function for that kind of thinking. When the cost of a mistake is running ransomware on your own machine, you stop trusting that things are configured the way you left them, and you start proving it.