Hibernation and NTFS

One basic rule when dealing with “hibernated” volumes is to never write anything to them from another operating system. Otherwise, when a hibernated operating system is resumed, there will be a difference between what is on a drive and what the operating system considers to be on that drive.

In Linux, the NTFS-3G driver is issuing the following error message when trying to mount a “hibernated” volume in the read-write mode:

Windows is hibernated, refused to mount.
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)

But this rule isn’t enforced in the Windows world. An NTFS volume is automatically mounted in the read-write mode even if it belongs to a hibernated operating system.

Since the fast startup mode, which uses the hibernation feature to restore the state of the kernel and the loaded drivers, is enabled by default in Windows 8.1 & 10 installations running on most modern computers, such behavior can lead to data corruption in a dual-boot configuration or when a system drive is attached to another computer.

From a forensics perspective, this means that hibernation files may contain some important data.

First of all, let’s see what happens when one writes to a “hibernated” system volume (with an NTFS file system).

In my tests, the following behavior was observed (the hibernated operating system is Windows 10 in all tests, another operating system is a different installation of Windows 10 in the first and the third tests, Windows Server 2008 R2 in the second test):

  1. An existing file was renamed in a “hibernated” system volume (using another operating system with the drive in question attached as a secondary one); after the resume, the operating system didn’t see a new file name, but the file with an old name was visible; during the full shutdown, the old file name was written to the $MFT file (along with old, prior to the rename operation, timestamps for that file).
  2. A new file was created in a “hibernated” system volume (in a similar way as described above, but another operating system executed the chkdsk operation during the boot); after the resume, the operating system didn’t see a new file; after the reboot, a blue screen appeared (the stop code was: “NTFS FILE SYSTEM”).
  3. A new file was created in a “hibernated” system volume, an existing file was renamed in the same volume, and data was written to another existing file in the same volume (thus, three files were affected by the test); after the resume, the operating system was able to see a new file name of the renamed file and new data in the written file, a created file was visible too, but it couldn’t be opened.

After a manual examination, it was found that the file created in the third test was corrupted by the operating system: in particular, an MFT record describing that file was assigned to another new file (as shown below).

An MFT record for the new file, before the resume process:

MFT Entry Header Values:
Entry: 32069 Sequence: 7
$LogFile Sequence Number: 2132449428
Allocated File
Links: 1

[…]

$FILE_NAME Attribute Values:
Flags: Archive
Name: new_file.txt
Parent MFT Entry: 134018 Sequence: 2
Allocated Size: 0 Actual Size: 0
Created: 2019-01-03 03:21:12.515432700 (MSK)
File Modified: 2019-01-03 03:21:12.515432700 (MSK)
MFT Modified: 2019-01-03 03:21:12.515432700 (MSK)
Accessed: 2019-01-03 03:21:12.515432700 (MSK)

The same record, after the resume process:

MFT Entry Header Values:
Entry: 32069 Sequence: 8
$LogFile Sequence Number: 2132789834
Allocated File
Links: 2

[…]

$FILE_NAME Attribute Values:
Flags: Archive
Name: WINDOW~1.PNG
Parent MFT Entry: 86445 Sequence: 8
Allocated Size: 8192 Actual Size: 0
Created: 2019-01-03 01:57:48.944540100 (MSK)
File Modified: 2019-01-03 03:06:23.034497700 (MSK)
MFT Modified: 2019-01-03 03:06:23.034497700 (MSK)
Accessed: 2019-01-03 03:06:23.034497700 (MSK)

$FILE_NAME Attribute Values:
Flags: Archive
Name: windows-systemtoast-securityandmaintenance_305_0.png
Parent MFT Entry: 86445 Sequence: 8
Allocated Size: 8192 Actual Size: 0
Created: 2019-01-03 01:57:48.944540100 (MSK)
File Modified: 2019-01-03 03:06:23.034497700 (MSK)
MFT Modified: 2019-01-03 03:06:23.034497700 (MSK)
Accessed: 2019-01-03 03:06:23.034497700 (MSK)

It looks like the operating system assigned the file record to another file as if this record was unallocated!

So, based on the tests described above, I can conclude that there is a metadata cache in the NTFS driver, which affects, at least, some file attributes (like a file name and timestamps) and a list of unallocated file records. And this cache isn’t invalidated when the operating system is starting up from the hibernation file.

After a manual examination, I found that a hibernation file (hiberfil.sys), which was extracted (in the third test) before the resume process (but after the volume was modified), contains an “old” bitmap of allocated file records (with the corresponding file record marked as free). The write operation from another operating system didn’t alter this bitmap (obviously).

So, what does this mean?

Obviously, an attempt to plant incriminating files to a “hibernated” volume without booting a suspect operating system could be noticed by comparing data from a hibernation file to metadata in a volume.

However, I’m not aware of any tools to extract such cached NTFS metadata from a memory image (including a hibernation file). Given that Microsoft doesn’t expose (in the debug symbols) the layout of in-memory structures used by the NTFS driver, implementing such functionality in memory forensics tools is going to be extremely tricky.

If a hibernation file contains data from a previous session (such data can survive the boot even on solid-state drives, if they continue to return “old” data for blocks discarded using the TRIM command), a forensic examiner can use a cached bitmap of allocated file records to locate files created “after the resume” (typically, the same could be achieved by using timelines, but another source is always welcome).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s