Daily Blog #434: Bitlocker Experiments Part 5

Bitlocker Experiments Part 5 by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
             As I was looking at the FVE metadata header and decoding the output I realized two things.

1. There is more here than I previously understood, I didn't appreciate the layering of keys that existed.

You can read more about how this works here: https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-key-management-faq as a TLDR though there are three layers of protection that are provided. The documentation goes from the disk and up but let's go the opposite way, the way a user interfaces with Bitlocker.

The protector you have picked (TPM, Password, Pin, etc..) will be used on successful authentication to decrypt something called the Volume Master Key or VMK. As I am going through the metadata header I can see the attributes marking the VMKs that exist.

The VMK in turn once decrypted is then used to decrypt the Full Volume Encryption Key or FVEK which is what actually encrypted the data on your storage volume.  So when the protectors are disabled what is happening is that the VMK key is being decrypted, allowing the FVEK and with it the raw data to be accessed. This is how encryption can be 'paused' or 'suspended' for a windows update without decrypting the drive. Very clever and it explained the huge difference within the blocks.

I was expecting to see one key change or a key exposed, instead the rest of the block that was chaning was actually the contents being decrypted allowing any system that has the ability to support this mode to access it.

This explains why some software packages that access Bitlocker volumes fail to do so without a password/pin/recovery tool as they were not programmed to check if the decrypting keys were left decrypted based on a previous command or action.

When I get back in my lab next week I am going to see how I can get Windows Update to trigger this removal of protections for me as I think this will likely allow for the imaging of a drive that is technically encrypted but allows anything that understands it to decrypt it. I am going to focus this on the scenario of a system I don't have credentials for as if I did I could just log in and get manage-bde to provide me the recovery-key I needed.

This also means for those doing onsite acquisitions if you don't want to rely on extracting the key from memory you could just get manage-bde to get you the recovery key prior to imaging and be able to access the drive in your lab.

2. I need to write what I'm doing manually into a Python script to really do this effectively. I could make an 010 template but it would seem that a Python script to parse these fields would lead to better long term results and testing.

This is likely going to start next week as well as tomorrow is a Forensic Lunch day and then I'll be reviewing the Sunday Funday submissions on the 16 hour flight home.

Thanks for reading this far and frankly for reading this at all. Forcing myself to research, test and document things everyday is already making me feel more engaged again and clearing out old lingering questions I never made time to answer. I would hope others have already discovered most of this (Jesse Kornblum and Joachim Metz have documented these things in their work) but I find a lot of value in doing it yourself if you really want to understand whats possible.

Post a Comment