BitLocker and VMware Shared Folders

February 02, 2018

When I’m working on an assessment, I consume and generate a pile of data: IP lists, vuln scanner output, pentest notes, whatever. I’m grepping and awking and doing all sorts of awful things to text files in the hunt for shells.

My organizational skills and general workflow are a constant work in progress, but one thing I never screw around with is keeping everything safe.

Any data I have that I’d be worried about becoming public I store in an encrypted container. This way, no matter what I forget or how many different files I generate, I’ll know where the important stuff is and will be able to regularly review and delete unneccesary information. I used to use TrueCrypt for this, but these days I’m using BitLocker.

Complicating things is the fact that I also tend to be using at least two machines (one Windows and one Linux) while testing. This makes keeping all of my sensitive information under control a bit tricky so I spent a bit of time thinking and tinkering and came up with a pretty OK solution.

This post is equal parts workflow and process. I’m going to cover the technical aspects of setting things up and then talk a bit about how I use it.


The Nerdy Bits

First, set yourself up an encrypted container. Choose whatever side suits your needs; I went with 10GB. Pick a nice strong passphrase (20+ characters).

Enable shared folders for the VM of your choice. This is going to make the folder available for mounting in the guest OS.

Finally, mount the folder in your guest. This part was by far the trickiest for me because I didn’t RTFM and instead went spelunking through the forums of the internet to find the answer.

Straight from, here’s how to mount all shared folders.

/usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o subtype=vmhgfs-fuse,allow_other

But what if you want it to be mounted all the time? I got you, fam.

.host :/ /mnt/hgfs vmhgfs defaults 0 0.

If you’re exceptionally lazy, or very efficient (same thing?), I’ve bundled the above into an open-vm-tools Ansible role.


I really like understanding why things work a certain way. It’s neat to see how someone uses something, but if you know why you can customize it to suit your needs a little better.

If you followed the steps above, you have a Windows machine exposing the root of a folder structure to a Linux guest. The guest is configured to mount every shared folder it can see under /mnt/hgfs.

When I start an engagement, I’ll fire up a folder for the client. Let’s say I’m doing two different jobs, one for EVILCORP, one for HALOCORP. This is how BitLocker is set up:


What you do inside your folders is your business. We’re only concerned with the two top level ones.

When I configure my shared folders in VMware, I do one for each. This allows me to toggle the folder on and off under VM settings as I see fit. This works while the VM is running.

On the Linux end of things, since we’ve specified that all shared folders should be mounted, the folders I’m using will appear or disappear under /mnt/hgfs as I enable or disable them using shared folders. When I’m working on a client, I’ll usually jump into their folder on my Linux guest and redirect all tool output there. Nice and clean.

As an added bonus, when it’s time for reporting (ffffffuuuuuuuuuuuuuuuuuuuu), I can browse through all my screenshots and raw data from my host OS without having to copy and paste a bajillion files around. It’s almost idiot proof.


When I’m done, I just delete the folder and remove the shared folder from VM settings. Nothing else to worry about and my testing machine remains clean. Of course, not all tools allow for arbitrarily redirecting output, so you’re not totally off the hook. I’ve started a collection of these over here.