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
Physical View of Hiberfil.sys on Fully Decrypted BitLocker Volume
Hibernation Recon Processing Hiberfil.sys Extracted Physically from Fully Decrypted BitLocker Volume
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
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.
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.
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.
So, if you need to access EFS-encrypted files, you do not have the user’s Windows password, and you may even be dealing with an “IT gone rogue” (i.e. you cannot rely on help from IT – e.g. one or more may be suspects!) scenario, what are your options?
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.
or (617) 277-3625
Terms & Conditions