How I Built a 4TB Encrypted Portable Pentest Drive (Part 1: Architecture & Threat Model)

Why Carry a Full Pentest Platform? Link to heading

Offensive security work is mobile by nature — sometimes you’re on-site, sometimes remote, sometimes jumping between clients, machines, or even air-gapped setups. Cloud-hosted platforms introduce risk, and carrying a laptop for every use case is overkill. I wanted a drive that could:

• Store my persistent Kali VM
• Archive all my sessions, notes, and tools
• Boot a live Kali system if needed
• Sync logs between Windows, Linux, Mac
• Stay fully encrypted, stealthy, and usable on the move

So I turned a 4TB external SSD into a multi-partition hacker platform. Here’s how I built it.

Partition Layout Link to heading

Encrypting the Shared Vault Partiton (sdx2) Link to heading

1. Create the encrypted volume Link to heading

sudo cryptsetup luksFormat /dev/sdX2

2. Open and format it Link to heading

sudo cryptsetup open --key-file=/home/<user>/keys/usb.key /dev/sdX2 secureusb
sudo mkfs.ext4 /dev/mapper/secureusb

3. Mount it Link to heading

mkdir -p ~/secureusb
sudo mount /dev/mapper/secureusb ~/secureusb

GPG-Based Unlocking (On Trusted Machines) Link to heading

Instead of storing a plaintext keyfile, each of my secure machines has a GPG encrypted key, which is decrypted in memory only when needed. The exception is my portable Kali doesn’t need the GPG side of things as it’s completely secure at boot with only a single user account (my attack login).

Setting up the keyfile Link to heading

You can create a keyfile to unlock the drive without typing a password.

dd if=/dev/urandom of=~/.keys/usb.key bs=1024 count=4
chmod 600 ~/.keys/usb.key
sudo cryptsetup luksAddKey /dev/sdX2 ~/.keys/usb.key

then to open the drive you simply pass the key

cryptsetup oepn --key-file=/home/<user>/.keys/usb.key

but this means anyone on your machine with root access can access this file so I encrypted using my GPG key which is managed by my gnome keyring which unlocks upon my login.

gpg --quiet --batch --decrypt ~/.keys/usb.key.gpg > /tmp/usb.key
cryptsetup open --key-file=/tmp/usb.key /dev/sdX2 ~/secureusb
scrub -u /tmp/usb.key

Sharing GPG Link to heading

I didn’t want to maintain separate GPG identities across machines. Instead, I exported my public/private keypair to a secure USB, imported it on each trusted host, and then scrubbed private keys from the USB post-import:

gpg --export-secret-keys <keyid> > portable.key
# import on new machine
gpg --import portable.key
# scrub from USB
shred -u portable.key

This way, I retain a single GPG identity across my environments. Just make sure you shred your key as soon as it’s imported just incase you misplace that pendrive.

Shared exFAT Partition Link to heading

This is an unencrypted share that is deliberate to allow for portability when not needing my full encrypted system for protection. For everyday personal files or non-sensitive transfers.

For compatibility:

• /dev/sdX1 is exFAT
• Mountable on Linux, Windows, Mac
• Use for low-risk transfer files (e.g., screenshots, drop reports, blog drafts)

Hosting My Kali VM Link to heading

I keep my .vbox, .vdi, and session folders directly on the encrypted partition:

/mnt/kaliusb/
├── vm/
│   └── Kali-Ghost.vbox
├── ops/
│   ├── sessions/
│   └── tools/
└── backups/

I’ll cover more of this setup will be in a future post.

This means:

• My VM is portable
• All sessions are persistent, encrypted
• No trace remains on the host

Bootable Partition Link to heading

I made /dev/sdX3 a standalone boot partition. It contains a permemnant GRUB installation that loads the encrypted Kali OS from /dev/sdX4

• Works on any x86 machine. Bring your OS with you.

Encrypted Kali instance Link to heading

The fourth partition /dev/sdX4 contains a full encrypted Kali Linux install. It is unlocked at boot by GRUB (from /dev/sdX3) and drops me into a single user attack environment. This OS binds ~/secureusb the same way my VM does, so my session data is always available – whether I’m running Kali in VirtualBox or booting it natively from the drive.

Why This Setup Works Link to heading

• 🔐 Portable across machines
• 🔒 Fully encrypted, stealthy, and isolated
• 💻 Bootable when needed
• 🔄 Compatible with Linux, Mac, Windows
• 🧠 Nothing decrypts unless I unlock it
• 🧳 Minimal footprint

I don’t need a cloud VM. I don’t need a platform. I just need my drive and a USB port.

Final Thought Link to heading

If you want to carry your entire pentest world on a drive — not just tools, but your identity, session history, and kill switch — this is the cleanest way to do it.

Let them keep their cloud labs. I’ve got a 4TB ghost system that follows me only when I want it to and ensures:

• My data stays encrypted unless I unlock it
• My ops data is always segregated
• My host machine is just a launcher

Coming Up in the Series Link to heading

1. Part 2: Building and partitioning the drive (bootloader, Kali install, encryption)
2. Part 3: Automation scripts for trusted machines and portable boot
3. Part 4: Folder layout, bind mounts, and VM sync strategy