The Interesting Case of Windows Hibernation and BitLocker

Mark Spencer

April 24, 2020

Windows hibernation and BitLocker are two technologies that are quite interesting on their own, and some might say even more interesting (or, frustrating) when combined. A key concept you should be aware of before we continue is that unlocking a BitLocker-protected volume essentially results in encrypted data being decrypted as needed. In other words, unlocking a BitLocker volume does not result in the BitLockered data being decrypted in place, but the decryption of that data in memory and passage “up the stack.” Accordingly, if you are on a live Windows system with its BitLocker volume unlocked and obtain a logical copy of its hibernation file (thereby invoking BitLocker decryption), you will see the hibernation data you expect followed by “junk” which is the result of BitLocker decrypting the remnants of in-file TRIM… but if you obtain a “physical” copy (bypassing BitLocker decryption), you will only see encrypted data.

Many digital forensics practitioners are aware of the impact of what we will refer to as “in-file TRIM” on SSDs (we recommend learning about SSD concepts which include garbage collection and “deterministic read zero after TRIM” (DZAT), if you are not familiar with them already).… for example, what happens to hibernation files when in-file TRIM is run against them. Digital forensics practitioners may not be aware of the nuances of what happens when introducing various BitLocker activities into the mix of hibernation and in-file TRIM.

I’m going to keep this Insights article very brief by relying on the screenshots you are about to see.

Let’s have a screenshot we shared long ago speak for itself:

Remnants of In-File TRIM on BitLocker Volumes

I began writing this article when I realized the screenshot above was not sufficiently accounting for all the situations in which our customers using Hibernation Recon were sending us “broken” or “encrypted” hibernation files.

So, let’s get to it!

Our first situation involves exporting the hibernation (hiberfil.sys) from a live Windows system whose BitLocker-protected volume has been unlocked. We can see the expected hibernation data (essentially just the header, because this is a modern Windows system that has resumed from Fast Boot hibernation and in-file TRIM has occurred) followed by the “junk” data I referred to above which is the result of BitLocker decrypting the zeroed-out remainder.

Logical View of Hiberfil.sys on Unlocked BitLocker Volume

Hibernation Recon Processing Hiberfil.sys from Unlocked BitLocker Volume

Our second situation involves logically exporting the hibernation from a live Windows system whose BitLocker-protected volume has just been fully decrypted. Some might find this next screenshot surprising, in the sense that BitLocker is no longer in play but the “junk” data remains. It appears that during the full BitLocker decryption, the “junk” data has been made official in the sense that it has been committed to the hibernation file on disk.

Logical View of Hiberfil.sys on Fully Decrypted BitLocker Volume

Hibernation Recon Processing Hiberfil.sys Extracted Logically from Fully Decrypted BitLocker Volume

Our third situation involves physically exporting the hibernation from a live Windows system whose BitLocker-protected volume has just been fully decrypted… which confirms our previous finding.

Physical View of Hiberfil.sys on Fully Decrypted BitLocker Volume

Hibernation Recon Processing Hiberfil.sys Extracted Physically from Fully Decrypted BitLocker Volume

Our fourth situation involves exporting the hibernation from a disk image which was obtained after the Windows system, whose BitLocker-protected volume was just fully decrypted, was shutdown. You may find this screenshot the most interesting, as you are now looking at a valid Fast Boot hibernation followed by many gigabytes of the “junk” data. Remember, the “junk” data is the result of BitLocker earlier (possibly, much earlier) decrypting zeroes (in-file TRIM) with a nice salt and then that data being committed to the hibernation on disk (hiberfil.sys) during the full BitLocker decryption. This is one of the situations brought to us by our customers which we felt was worthy of writing this article.

Hiberfil.sys Extracted from Disk Image After BitLocker Volume Fully Decrypted and Windows Shutdown

Hibernation Recon Processing Hiberfil.sys Extracted from Disk Image After BitLocker Volume Fully Decrypted and Windows Shutdown

Finally, our fifth situation involves exporting the hibernation from a live Windows system whose BitLocker-protected volume was fully decrypted, then shutdown, then started up again. All is well in the world of hibernation again, as we see exactly what we would expect if BitLocker had never been in play – the hibernation header which indicates the hiberfil.sys has been used for a resume followed by zeroed-out data per in-file TRIM.

Physical View of Hiberfil.sys after BitLocker Volume Fully Decrypted and Windows Rebooted

Hibernation Recon Processing Hiberfil.sys Extracted Physically from Fully Decrypted BitLocker Volume after Windows Reboot

Here are the MD5 and SHA1 hash values for these various hibernation files which you may find useful as you contemplate their state across various BitLocker actions:

Hash Values of all Hiberfil.sys Files Mentioned in this Insights Article

I hope you enjoyed this Insights article and that you find Windows hibernation and BitLocker as interesting as we do!

Did you know that Arsenal Image Mounter (AIM) makes interacting with BitLocker-protected volumes reliable and efficient? Whether moving between various BitLocker states as a disk image is mounted by AIM in write-temporary mode or fully decrypting BitLocker-protected volumes and saving new disk images, you will find AIM indispensable in your casework. Please keep in mind that AIM’s Professional Mode also has many other powerful and unique features, which include launching virtual machines (even in the most challenging situations) and bypassing Windows authentication within them.

Related Articles

An Inside View of Office Document Cache Exploitation

An Inside View of Office Document Cache Exploitation

Once you think through the implications of what can be done not only with multiple document versions extracted from FSD files as ODC Recon has always done, but what can be done with the granular revision information that can be found within FSD files and temporary collaboration data, you should be having a “lean back in the chair” moment.

Quick Tour of New Features in Arsenal Image Mounter v3.1.101

Quick Tour of New Features in Arsenal Image Mounter v3.1.101

The workflow for launching virtual machines has been significantly improved in Arsenal Image Mounter v3.1.101! You will now see a single dialog box (rather than a series of prompts) which consolidates important options related to launching virtual machines.

Arm Yourself!

Join our mailing list to arm yourself with updates about Arsenal tools, training, and research. Our mailing list is double opt-in so you will need to check your email and confirm your subscription before receiving our mailings.

Chelsea, Massachusetts

sales@ArsenalRecon.com

(617) ARSENAL

or (617) 277-3625

Site Map

\

Home

\

Products

\

Pricing

\

Training

\

Testimonials

\

Insights

\

Contact

\

FAQ

Legal

\

Privacy Policy

\

Terms & Conditions

\

Cookie Policy

Follow Us

LinkedIn

Twitter

Facebook

Share This