Windows 8 Forensic Overview

**** Update 03/21/2012 ****
This is being revised and updated for SANS DFIR Summit in Austin.
Some Artifacts in the Developer Version are no longer found in the Consumer Version

My Code to save 10% is PrincipalGroup10

Write up of System Refresh can be found here: http://randomthoughtsofforensics.blogspot.com/2012/05/windows-8-refresh-excerpt.html
*************************

I finally submitted my term paper for my Forensics class, While there are some things to be said for waiting until the last minute, my problem was as I delved into the four points I wanted to cover, I found Windows 8 exhibiting some interesting behavior, I also noticed that some of the things I thought would change, did not. 


I will be making my paper available for download soon, but I need to clean up a few things, and will let you know when you can grab it. Meanwhile, here is a few things that I want to pass on. 

When I initially started this paper I took a dive into Windows Registry I was at a loss with what to look for. I posted questions onto Twitter with some guidance of where to look. Eventually I stumbled across the Registry Key called TypedURLsTime, trying to decipher the value contained in the data field I posted to Twitter the information I was looking at.  Harlan Carvey explained that this data is filetime data; I came to rely on the experience of Harlan and others as I asked questions, I am grateful for their experience and willingness to answer my questions and be patient with me. Harlan, went as far to help as sending me a copy of his Windows Registry Forensics book, this is an incredible resource for anyone interested in looking at and understanding the registry.

Building off what I learned from Harlan's book Windows Registry Forensics I was able to confirm that the primary registry hives, SAM, System, Security, Software, NTUser and UsrClass all were retained within Windows 8.  I returned to the Registry Keys for the typedURLs and TypedURLsTime and did some more digging around. Here are the keys below for reference, as you can see URL10 is in both locations, one showing the location visited and the other the filetime that is was accessed.

Through some more analysis of the registry I came across the following keys, which appear to be related to the Immersive Browser that Microsoft is pushing in Windows 8. I attempted to test the typedurls-immersive-browser key, but this feature was not accessible in this build.

While listening to Wade Wegner presentation at the 2011 Build conference, Microsoft touted the ability to allow applications and user to save data to the cloud. With the option of using your Windows Live ID as your user name to facilitate this idea I decided to look a little more regarding this. I found the following while digging into the directory structure of a Live user:

C:\Users\USERID\AppData\Local\Microsoft\Windows\Live\Roaming\2d5b1639895c2556\CloudSync

Within this directory there were numerous files with the SDF file type, some of the files are named the same as the immersive browser keys in the previous images. I decided to look further into the registry to see if I could find any reference to the CloudSync option and I came across the following:

It appears that the Immersive Browser and CloudSync Registry keys will need to be analyzed further. I am planning on looking into them more over the next few weeks, will update blog with the information.

When I was typing out this blog I had I was going to delve deeper into Jump Lists, but they appear to be similar to the Windows 7 area, and felt that my research could be utilized in a different approach. It does not appear that Metro Applications keep a jump list; instead they keep their information in the respective program folder within AppData. I noticed this behavior while utilizing the PicStream Metro App. Digging into the file path I found the following folder structure:

Within each of those sub directories there was a regular file and a file slack for each image I viewed through Picstream application. Further research should define the naming convention of the INetCache sub directories.

Within the Windows 8 Operating system, they have introduced file history backup which changes the way that backups were previously used. In previous versions of windows, backups could only be maintained and restored using the default system. Within windows 8 this solution is more robust and allows backups to be stored both on removable media and remote network shares. By default this will backup folders such as Music, Documents, Videos, Contacts and Favorites.

There are a few artifacts that are established when file history is turned on, this includes File History folder, Registry Value, and Windows Events. The file history folder can be found at C:\Users\USERID\AppData\Local\Microsoft\Windows\FileHistory within this folder there is a configuration folder and a data folder. The data folder is a temporary staging directory for the files that are to be backed up. The Configuration folder contains at least 2 files, they are an EDB file named Catalog#.edb and a XML file names Config#. These files are created both Locally and on the drive being used as backup. As of this writing I have not be able to explore the EDB file. The Config file on the other hand offers the following information: 

If the File History option has been turned on there is also a registry key that is created, this key is only found on users that have turned on this feature. The Registry key can be found at:

HKU\Software\Microsoft\Windows\CurrentVersion\FileHistory 


Within this directory there is a key named ProtectedUpToTime that shows the last time this process backed up the files. This value can be deciphered utilizing a 64 Bit Hex Value - Big Endian values. The DCode application can handle this.

There is also another area in the HKLM registry that may provide more information and keys of importance, this is t. This is the FHSVC which is the File History Service and can be found here: 

HKLM\System\Controlset001\Services\fhsvc. 

Keys in the FHSVC folder













Keys in the Config files

Another area worth looking at in gathering File History information is within the System Events. The following Event Sources provide us with auditing information related to the File History:

• FileHistory-Catalog
• FileHistory-ConfigManager
• FileHistory-Core
• FileHistory-Engine
• FileHistory-EventListener
• FileHistory-Service

The final features of Windows 8 that I am going to cover in this blog are the Refresh and Recovery options. The Recovery feature will bring your windows to a factory state, similar to re-installing the operating system, the refresh feature acts like a restore point, but will clean everything needed for the OS to run, leaving individual files, and applications from the Microsoft store untouched, deleting any other 3rd party application.

When looking at a refreshed image of the windows operating system within AccessData FTK Imager, there are three items that are quickly noticed. These are two partitions and an unpartitioned space.

Partition 1 is a 350MB partition that contains the information needed to boot up the operating system. There are a few interesting files that can be found in this partition that can provide some more clues about what has happened on with the operating system and if the device has been recovered or refreshed. When comparing this partition against machines that have had the refresh/recover option ran against them and those that have not we can see some differences in files.

The screen shot on the left is from a machine that has not been refreshed or restored, while the one on the right has been refreshed. From my analysis of this partition from a refreshed or recovered is there will be more unallocated spaces in a recovered machine. On all images there is a folder called Recovery in the System32 folder, within this directory there is a file called ReAgent.xml, this file is used to recover or refresh. 

On a Refreshed/Recovered machine there is a new folder named Log under the recovery folder. In that folder is a file called Reload.XML. The Reload.xml is an updated ReAgent.xml file; it will also have a different timestamp from the ReAgent. This folder and file will give a good idea if the machine has been refreshed or restored. Out of the 24 lines in these xml files, the only line different is:

                    

For a non-refreshed or recovered system the state and status would both be 0.

Partition 2 is the main system partition that is mapped to the C: Drive. This partition also allows us to know if the machine was refreshed or restored. A restored machine will have a lot of unallocated spaces of various sizes that can still be data carved against. The directories and files shown between a Restored and a Non-Restored machine will be similar, but against a refreshed machine there will be two new Directories that contain data. These folders are the $SysReset and Windows.old, as can be seen below.

Within these folders we can still access the previous data that was on the drive, this data still remains in its file structure under the Windows.Old folder. Within the $SysReset there are two directories that contain what appears to be potential useful information. Within the Logs folder there are three files that will provide some usable data. The SystemResetPlatform.log and the setupact.log provides details of what was changed, the MigLog.xml will contain the Users that were retained and their current mappings. This can be beneficial after a reset a user account is deleted.  There two files located in the Framework/Migration/Preserve that also may provide evidence at a later date, they seem to deal with the Microsoft Store, and since this feature is currently not available I am unable to investigate.

Over the next few months I will research more artifacts that might be left behind in Windows 8, and the behaviors that the new operating system brings with it. As more features are unlocked there is potential for more locations that must be analyzed to find the big picture.