When analyzing connected computers, one may be tempted to pull the plug and bring the PC to the lab for in-depth research. This strategy carries risks that may overweigh the benefits. In this article we’ll discuss what exactly you may be losing when pulling the plug.

Is it powered on, sleeping, or hibernated?

Is the computer powered on, sleeping, or hibernated? If it’s powered on, do you have access to an authenticated user session? Your approach may be different depending on the answers.

Note: this article addresses the various sleep modes in desktop computers only. Laptops, ultrabooks and 2-in-1 capable of “modern standby” or “connected standby” have different forensic implications and are protected in a different manner (via BitLocker Device Encryption).

If the computer is running with an authenticated user session, we strongly recommend scanning the PC for encrypted (and mounted) disks and virtual machines before you do anything else. If there is encryption present, you may lose access to encrypted disks and/or virtual machines once you pull the plug, shut down the computer, log off the current user, allow the computer to sleep or hibernate or even allow the computer’s screen to lock after a timeout.

The reason for this are the security settings available in many crypto containers and encrypted VM apps that unmount encrypted data and delete the encryption keys from the computer’s memory on certain events. Depending on the settings, such events may include:

1. Computer reboot or shutdown, whether clean or forced. Most crypto containers (except BitLocker in TPM mode) will lose the encryption key and require the user to enter the password to unlock encrypted disks or VMs.
2. Sleep or hibernation. The default setting for many crypto containers (including BitLocker in all configurations) is resuming seamlessly after sleep or hibernation. This means that, by default, BitLocker disks will be kept mounted after the computer resumes, and there is no easy way to alter this setting other than modifying the system’s group security policy. VeraCrypt containers, on the other hand, have a handful of settings that, once selected, make VeraCrypt automatically lock encrypted disks and wipe the encryption keys from the memory when the computer enters a pre-configured state. By default, all of these settings are off, so VeraCrypt default behavior is similar to BitLocker.
3. User session is locked. This is a separate state that has a separate configuration setting. By default, no crypto container app unmounts encrypted disks once the user session is locked. However, VeraCrypt has a dedicated setting that does unmount the disk(s) on this condition. The default for this setting is “off”.

The difference between Sleep, Hybrid Sleep, Hibernation and Fast Startup in Windows

There are several low-power options in Windows desktop computers, each carrying certain forensic implications.

Sleep

Sleep is the first-engaged low-power mode in Windows. By default, Windows 10 computers come pre-configured with Hybrid Sleep (see screen shot).

If the “hybrid” option is not selected, when entering this low-power state, the computer will not save the contents of the RAM onto non-volatile media. This results in near-instant transition between active and sleep phases, and near-instant wake. However, if the power is lost while the computer is sleeping (which is exactly what happens when you pull the plug), the entire content of the computer’s RAM is lost.

To prevent this situation, Microsoft developed a so-called “Hybrid sleep” option.

Hybrid sleep

This option attempts to combine the benefits of sleep and hibernation. Once the computer begins transitioning into this low-power state, Windows saves the content of the computer’s RAM into a hibernation file. This file contains, among other things, on-the-fly encryption keys used by crypto containers and encrypted VM apps to access encrypted data on the fly.

If the computer is left connected to a power source, resuming from hybrid sleep is just as fast as resuming from normal sleep. If the power is cut (you pull the plug), the computer resumes from the saved hibernation file without losing the user’s authenticated session or the encryption keys (unless the crypto container is specifically configured to wipe such keys when entering low-power mode).

Hibernation

When hibernating, Windows saves the content of the computer’s RAM into a hibernation file, then switches the computer to the lowest low-power state, in which the computer’s RAM content is not maintained. The hibernation file contains, among other things, on-the-fly encryption keys used by crypto containers and encrypted VM apps to access encrypted data on the fly. Resuming from hibernation takes longer than resuming from the regular sleep mode.

Fast startup

Fast Startup is a feature of Windows 10 designed to reduce the time it takes for the computer to boot up after a gracious shut down (the feature is not engaged between reboots). When enabled, Fast Startup saves a small hibernation file onto the disk. That file basically contains kernel memory and not the user session. Specifically, this file should not contain any encryption keys such as BitLocker’s.

While most crypto containers do not distinguish between the various low-power states, there is one exception: VeraCrypt. In its main Settings dialog, the auto-dismount option is described simply as “Entering power saving mode”, which makes no distinction between the various sleep and hibernation modes. The exception here is buried deep under the “More settings” button:

If you don’t see any mentions of hibernation on that screen, you’re not alone. The affected setting is the last one on the very bottom of the screen, named “Activate encryption of keys and passwords stored in RAM”.

Once the user enables this setting (and restarts VeraCrypt), the app makes sure that the encryption key is stored in the computer’s RAM in an encrypted (or, rather, obfuscated) form. In addition, VeraCrypt makes sure that the key is never saved onto the disk. Since there is no easy way to achieve that goal in Windows, VeraCrypt makes a brutal move by disabling both Hibernation and Fast Startup just to ensure that the encryption key does not land on a disk. A howtogeek article has an explanation:

“Fast Startup can interfere slightly with encrypted disk images. Users of encryption programs like TrueCrypt have reported that encrypted drives they had mounted before shutting down their system were automatically remounted when starting back up. The solution for this is just to manually dismount your encrypted drives before shutting down, but it is something to be aware of. (This doesn’t affect the full disk encryption feature of TrueCrypt, just disk images. And BitLocker users shouldn’t be affected.)”

For this reason, VeraCrypt disables Fast Startup when users enable the encryption of keys and passwords in RAM. If they don’t, the small hibernation file produced by Fast Startup may be scanned with Elcomsoft Forensic Disk Decryptor for TrueCrypt/VeraCrypt OTFE keys (if the computer was shut down graciously, and the user did not disable Fast Startup).

Analyzing the hibernation file

As we figured, the hibernation file is created in the following scenarios:

1. Gracious shutdown, if Fast Startup was enabled in Windows settings.
2. Sleep, if Hybrid sleep was enabled.
3. Hibernation.

The first small hibernation file produced during the shutdown operation if Fast Startup is enabled can be scanned for TrueCrypt/VeraCrypt keys. Hibernation files produced with the second and third option can be scanned for all kinds of encryption keys including BitLocker + TPM.

To scan a hibernation file for encryption keys, do the following.

Launch Elcomsoft Forensic Disk Decryptor. Select Decrypt or mount the disk from the main menu.

In the Key mining options, select “Hibernation file“. If you know which specific crypto container was used, select that one app and deselect the others to speed up the search. If you don’t know what kind of full-disk encryption was used, select all available options. In this case, the search will take longer.

Click Next to begin the scan. Once the keys are discovered, they will be displayed. You can now save them into a file. You can save multiple keys of different types into a single file.

Having the decryption keys, you can proceed to decrypting the disk.

Specify the type of the crypto container, select the file with decryption keys, and click Next.

If the encryption keys have been located, the tool will prompt you to either do full decryption (creating a raw image that can be mounted or analyzed with a third-party tool) or mount the volume into the current system. Mounting is implemented via ImDisk virtual disk driver (installed with Elcomsoft Forensic Disk Decryptor). Normally, you won’t need to change any settings and simply press the Mount button:

As you can see, this method is convenient and efficient. Whether or not you can use it depends entirely on the possibility of acquiring the decryption key from the computer’s hibernation file.

The “Bad Dream” attack on TPM modules

In 2018, researchers Seunghun Han, Wook Shin, Jun-Hyeok Park, and HyoungChun Kim from National Security Research Institute published a paper named A Bad Dream: Subverting Trusted Platform
Module While You Are Sleeping (PDF).  When the computer enters the energy-saving sleep state, the TPM saves its PCR registers in NVRAM, and restores them when the computer wakes up. The researchers discovered that, at this brief moment, the PCR registers can be manipulated, thus reading the chain of trust or modifying its content. The researchers notified major motherboard manufacturers such as Intel, Lenovo, Gigabyte, Dell, and hp, who in turn patched the vulnerability in BIOS updates. However, since few users install BIOS updates, there are many computers still vulnerable to this exploit.

Seunghun Han released two tools: Napper for TPM and Bitleaker. The first tool can be used to test the computer’s TPM chip for the “Bad Dream” vulnerability, while the second tool is the actual exploit one can run if the TPM module has the unpatched vulnerability.

The second tool requires manually creating a Live CD with Ubuntu, compiling and installing Bitleaker according to the manual. You will need to disable Secure Boot to run the tool. The alternative way would be signing the modified bootloader and kernel with your signature and adding the public key to BIOS; this, however, defies the purpose as it alters the content of PCR registers.