Windows 8 Forensics: Reset and Refresh Artifacts

(Note:  The following information is primarily from a paper that I wrote detailing the Windows 8 Reset and Refresh functions.  A few pieces have been changed for formatting, but the structure has stayed the same.  The sections are broken down in the same manner as the paper. – Ethan Fleisher)

1. Introduction

1.1 Research Problem

Windows 8 ships with a new feature that will be extremely handy for the average consumer; the Reset and Refresh function.  This allows a user to choose whether or not to reinstall the OS, quickly reset their entire computer, or thoroughly reset their entire computer.  A function that has the potential to wipe out data is of extreme importance to the world of digital forensics, as it could easily make or break a case.  This paper will delve into what can be found on a machine that has had the refresh, quick reset, or thorough reset function performed on it.

2. Refreshed and Reset Machines

Before diving into the differences between a refreshed machine and a reset machine, the first important thing to look at is whether or not the machine even had one of the two functions performed on it.

2.1 Recovery Directory

Within the system recovery volume on a Windows 8 computer, a folder named recovery can be found.  Within the recovery folder, a folder labeled with the GUID will exist.  Three files are located in this folder: Winre.wim, boot.sdi, and ReAgent.xml.  Winre.wim is the windows image format file, boot.sdi is the windows deployment system image, and ReAgent.xml, which is associated with recovery.  All of this is typical behavior and can be found on any installation of a Windows 8 machine.

Windows 8 – System Recovery Volume\Recovery\GUID\ReAgent.xml

When a Refresh or Reset is done to a system, a new file/folder can be found in the Recovery folder on the system volume.  The folder, named logs, contains a file named Reload.xml.  The information contained within this file remains the same, whether or not the system was refreshed or reset.

Windows 8 – System Recovery Volume\Recovery\Logs\Reload.xml

3. Refresh vs. Data Generation

Upon first glance, there are three folders that pop out when comparing a refreshed image to one that has never been refreshed.  The windows partition contains: $SysReset, Windows.old, and Lost Files:

 4. Lost Files

To start, we’ll take a look at the Lost Files folder.  This folder will appear on more than just a system that has been refreshed, but it is still worth mentioning what it is.  The Lost Files folder contains files that still have a MFT entry on the system, but their parent folder has been deleted.  The files and folder that contained them were deleted, and the only the parent folder was overwritten.  However, the files within were not overwritten, and the MFT entries are still present.  Due to the entries still being present, forensic software is still able to know that the file exists.

With that being said, the Lost Files folder could potentially hold data of forensic value, but, in regards to this Windows 8 paper, is nothing new.

5. $SysReset

The SysReset folder contains a vast amount of information, ranging from log files to migration xml documents, all of which provide useful information to a forensic investigator.

5.1 Bin Directory

The bin directory is a great asset of information.  Within the bin directory, a directory named rollback can be found.  There are three text files that provide information relevant to the refresh that happened.  These files are:

1.       QuarantineLog.txt
2.       LogRestore.txt
3.       FolderMoveLog.txt

5.1.1 QuarantineLog.txt

QuarantineLog.txt displays which folders were saved, and where they were saved.  The contents of QuarantineLog.txt are as follows:

5.1.2 LogRestore.txt

LogRestore.txt contains the location of the migration log from the reset. This will be explained in further detail  later.

example:  D:\$SysReset\Logs\Mig

5.1.3 FolderMoveLog.txt

FolderMoveLog.txt contains a list of all folders that were moved, with listing their new location followed by their previous location.  It is notated in the format:

New file location | Previous file location

Within this text file, files ranging from typical user document files to internet favorites and also metro settings are found.

5.2 Framework Directory

The framework directory contains information that does not immediately appear to be very helpful.

Within Framework\Migration\Preserve is a file named Immersive Apps MigrationMigration.xml.  This file contains information that appears to relate to metro apps.  It contains registry key information, as well as multiple lines stating “rejuvenation”.   These rejuvenation lines relate to:

  •     AppX Payload
  •     AppX Licensing
  •     Modern Tiles
  •     Modern App Data
  •     AppX Enterprise Apps Authorization
  •     AppX Lock Screen Notifications
  •     AppX Application Tamper State Cache

5.3 Logs Directory

$SysReset contains a directory named Logs as well.  Within this directory are multiple log files and xml files defining the migration process during the refresh, stating where files previously were and also where the files currently reside.

Within the $SysReset\Logs directory is a file named MigLog.xml, as well as two subdirectories Mig and Rollback.  These files are the ones that appear to be of most importance.

5.3.1 MigLog.xml

MigLog.xml can be relatively beneficial to determining basic information about the machine itself.  Information such as the system name, user name and SID correlation, last access times/log in times, and windows mapping schemes can all be found here.

For example, by doing a simple ctrl-f search for the username that was used, the first hit provided me with last access, profile path, SID, and the domain that the account was tied to.


5.3.2 Logs\Mig Subdirectory

Within the sub-directory Mig are three files, two log and one xml, that provide more information about the system.  These three files are setupact.log, systemresetplatform.log, and miglog.xml.

5.3.3 Setupact.log

Setupact.log holds some basic information about the system and the setup itself.  All user profiles that are present on the machine at the time of the migration can be located within here.  By searching for the string “Processing Profile”, all of the accounts that are migrated over can be found.  These range from the system profile to localservice and networkservice, and also the created users themselves.  Default locations are mapped for each user as well.

The machine name, SID, and GUID can all also be found in the setupact.log


Finally, all apps that were recursively downloaded on the Windows 8 store and migrated over can be found.  Doing a search for the string “STORERECURSIVE” will bring display this.  A list of all applications downloaded from the Windows store can be found here.

5.3.4 Systemresetplatform.log

This relatively short log file contains a couple pieces of information.   It is convenient, that like the other logs, this one also gives timestamps for when the events happened.  This can very easily put a date and time to the refresh.  Also, much like setupact.log, all of the immersive metro apps that were installed on the system and migrated over can be found here.

Perhaps the more interesting piece of information on this page though is where old registry keys were unloaded to.  These keys include the software hive, system hive, and NTUSER.dat hives.  This is located at the very end of this log.

5.3.5 MigLog.xml

MigLog.xml contains similar information to the previous files, including system names, SSID numbers, domain names, profile names, mapping information, and more.  Any of these logs can be used to gain information about the system and the migration process, giving investigators locations of both old data and new migrated locations.

5.4 MigEngineStore Directory

The MigEngineStore directory contains two subdirectories: MachineSpecific and XMLs.  The MachineSpecific folder has two files containing information, migstate.dat and catalog.mig.  After  very briefly parsing these, however, it appears that the information provided is nothing overly new when compared to the other files that have been found.

The XMLs subdirectory contains two xml files, both of which appear to simply ensure that the system is setup correctly.  Once again, the information in here may be useful, but it would extremely situational.

5.5 MigEngineWork and Temp

The remaining directories in $Sys.Reset are MigEngineWork and Temp.  With the system I worked on, both of these were empty.

6. Windows.Old

The windows.old folder is an amazing resource.  Opening this folder is almost like opening the computer before the refresh was even done.  When initially drilling through the folder structure, it appears to resemble exactly that of the previous computer.

The simple breakdown of a few key points and differences looks like this:

6.1 $Recycle.Bin

Within the $Recycle.Bin folder, deleted files that were never emptied from the recycle bin can still be found.  However, unlike the current version of the system, the $R file is not displayed with its file name.  Instead, it is simply given the $R value.  However, the metadata is still present, and the $I file still contains the data itself.

6.2 System Volume Information

This folder cannot be found in the windows.old directory, only under the new install.

6.3 Users

A majority of the data in each user’s directory can be recovered from a refreshed machine.

Internet history is preserved and can be found within here.  Primarily, with Windows 8, we will be looking in a variety of places, including WebCachev24.dat and the IndexedDB directory within <user>\appdata\local\microsoft\internet explorer.  Other internet related activity, such as TypedURLs and TypedURLsTime results from NTUSER.dat, can be recovered as well.

An interesting key can be found in NTUSER.dat\software\microsoft\windows\currentversion\settingsync.  At this location is a registry value labeled LastLocalTimeChange.  This value is displayed in big endian hex format.

When run through DCode, the value in the above picture yielded Wed, 20 June 2012 16:41:10 UTC.  This could help to place the computer in a specific proximity on a certain date at the very least.

Because I was logged into the system under a Microsoft Live account, however, I would be curious to see if this key exists when only a local account has been used and the Microsoft Sync was not occurring.

Each user’s desktop contains an html file named Removed Apps.  Opening this file shows all removed applications that were installed by a third party vendor on the machine.

All of the users downloads, pictures, videos, and music are also left untouched and intact in their native folders.

Taking a glance at where Windows 7 stored jump list information, c:\users\<user>\appdata\roaming\microsoft\windows\recent\automaticdestinations, I was quickly able to find the same information.  Many of the pieces of information listed in here came from recent locations that were touched, including websites, downloaded files, and pictures.

All user assist information is capable of being captured within the windows.old directory as well.

Other items such as open/save MRUs, LNK files, RunMRU, Last Visited MRU, were all found in the same locations as Windows 7.

6.4 Windows

Before diving into registry hives, the first thing I checked was for the existence of event logs.  Much to my avail, all of the computers event logs can be located within system32\winevt\logs.  Simply exporting and viewing them in whatever preferred event log viewer is all that is necessary.

When taking a quick glance at the registry, all plugged in USB devices are able to be determined as well.  Doing a quick search for provided results, and allowed for me to determine the first time USB drives were plugged into the system.

Other files such as prefetch files and system information, i.e. timezone info, and network history information can still be found in the same areas as Windows 7.

7. Reset vs. Data Generation

Upon first glance of a system that has undergone either of the reset functions, it would appear that not much information can be located.  Unlike the Refresh function, which contained two folders full of information (SysReset and Windows.Old), a reset machine appears as a though it is a fresh image.  While looking through the various folders, however, I was able to come across important artifacts.

The recovery volume of the system appears to be relatively untouched by the resets done to the computer.  As shown below, the MFT, $Bitmap, and other important system files were, for the most part, created and last written to prior to the reset of the computer.

Only a few other pieces of evidence were found that put the computer to a previous date.  Internet history within WebCacheV24.dat can still be located from before the machine was reset.

As noted previously, 36 bytes prior to the Visited: Ethan@http/website (highlighted in blue) is the timestamp of the visit in big-endian format.  The decoded value of this (DC 60 82 DF 4C 4A CD 01 – big endian) is equal to Thu, 14 June 2012 16:43:49 UTC.  The computer itself was reset on Wednesday, June 20th, 2012.

Along with this discovery, the history.IE5 folder contains subdirectories from dates prior to the reset, yet they all still contain empty container.dat files.

Exporting WebCacheV24.dat and parsing it with EseDbViewer presented user browsing information as well, dating back to the creation of the virtual machine.

Besides these pieces of evidence, there isn’t much that can pin the machine back to before the reset date; at least, not much that I found.  Running log2timeline, however, did provide some information about the system prior to the reset.

Most of the information that was parsed by log2timeline unfortunately just related to the system recovery partition, and more or less displayed that there was existence of a system before the reset occurred.

With the exception of these few artifacts recovered from the machine, not much else has been found that can be recovered.  Although it is somewhat disappointing, the fact that a chunk of internet history still exists is amazing.  Log2timeline giving us an insight to the fact that the system existed on a certain date is also helpful in the grand scheme of a timeline.

Both the quick and thorough resets left behind the same traces of data.  One function did not outperform the other in terms of data deletion, even when it came to WebCacheV24.dat.

8. Conclusion

It appears that a system that was simply refreshed can still provide a plethora of evidence to an investigator.  Seemingly everything about the machine pre-refresh can be recovered, and is conveniently placed into a nifty folder named windows.old.  Information in regards to the migration process itself, old mappings versus new mappings, and the exact date and time of the refresh can be found by examining the $SysReset folder and checking the specific log and xml files within.

All in all, let’s hope that people will refresh their computer if they perform any of the three features, or that other artifacts are left behind when more user activity is done on the computer.

Keep in mind too that all of this testing is being done on release preview.  Although I doubt it would change drastically when the release itself hits in a couple months, it is possible some artifacts may change.

About the Author:

Ethan Fleisher is a Senior majoring in Computer and Digital Forensics at Champlain College. Originally from Carlisle, Pennsylvania, Ethan currently works as a Forensic Intern and System Administrator at the Senator Patrick Leahy Center for Digital Investigation where he is involved in real life investigation forensic analysis, network and system administration, and forensic research. Ethan has spent close to the last year researching the Microsoft Windows 8 OS with focus on revealing new artifacts and attempting to confirm previous methodologies.

(Guest post provided by Ethan Fleisher. Original article can be found at the author’s blog

Windows 8 Forensics: Internet History Cache

Internet history on Windows 8, particularly with Microsoft Internet Explorer v10, has taken a turn from its traditions that we are all used to.  Gone are the days of index.dat.  That’s somewhat of a scary statement to say, even for someone like myself who has only been around for a couple years now.

Fortunately, I spend much of my time doing research and development, always trying to figure out things that can help the world of forensics.  With the help of Jimmy Weg, I’ve been able to add on to my previous research into WebCacheV24.dat and came across quite a few things.

 Just a few directories down from the old <user>\appdata\local\microsoft\windows\history directory is a directory that may be a new good friend, WebCache.

Within this folder is a file named WebCacheV24.dat.  Before learning of Mark Woan’s EseDbViewer, I parsed these files manually by their hex values.  It was great fun, and I figured out a lot of information.  Most of my initial research on this can be found on the LCDI blog, if at all interested.

However, I wanted to now take it to the next level with EseDbViewer and verify my results against what I had previously found.  First step is obvious, open up WebCacheV24.dat into the program.  On the left side of the window is a Table Name pane:

Important information for navigating throughout the tables is found in the Containers table.  All containers are listed numerically and display the path of the directory that is being extracted for that specific table.  The name of the type of data that is being extracted is shown as well.  For example, in the follow picture, container 10 and 14 both are being extracted from c:\users\forensicator\appdata\local\microsoft\windows\history\history.ie5\mshist[daterange].

With an image that has much more information, there could be upwards to 50 or more containers.  With that in mind, it’s quite obvious why the Containers table is very important to parse through before looking into each and every container.  For my purposes, I will examine containers 2, 6, 10 and 14.

Before going into the parsing, the following is my documentation table that I created while visiting websites:

Time/Date of Visit
Opened IE – default page
16:28  –  7/18/2012
Bing search: Asrock
Z77 Extreme6 Specs
Google search: asrock z77 extreme6 mac compatibility
Google search: best mac compatible motherboards 2012
Google search: best mac compatible motherboards 2012
Opened IE – default page
09:08  –  7/19/2012

As one last note, please keep in mind that the containers I am looking at here (2,6,10,14) may change from case to case.  This is why parsing the Containers table first is extremely important.

But, without further ado, here goes:

Container 2

Container 2 contains information that looks very similar to the information that I parsed manually in the WebCacheV24.dat file, at least in terms of its syntax.  Oddly though, it’s located within users\forensicator\appdata\local\microsoft\windows\history\history.ie5, which is the location of where the all-containing index.dat file used to be located.  Instead, now, there is a container.dat file in this folder that (in EnCase) appears empty.  Apparently not so empty after all.

The first thing that pops out in this container is Bing searches that I performed.  Pretty easy find, just takes a little scrolling.

The next thing to do is to check the time stamps for these and verify them.  Thanks to Jimmy Weg for pointing out that the numbers here are decimal and need converted to hexadecimal, and then run through D-Code or a similar tool.  The time values displayed by EseDbViewer are shown in the following image:

For the following times, I am using the values in the fifth row down, “Visited: Forensicator@”

Time Entry
Actual Time
Accessed Time
Thu, 19 July 2012 09:55:39 -0500
Modified Time
Wed, 18 July 2012 15:29:25 -0500
Sync Time
Thu, 19 July 2012 09:55:39 -0500
Expiry Time
Mon, 13 August 2012 15:29:25 -0500

When parsing through this container and the table, it is very common to find the same value in many places for both Accessed Time and Sync Time.  There are also many instances where the Expiry Time is listed as 0.  Strangely, though, the accessed/sync times are one hour behind what they should actually be, in reference to the logs from earlier.

Another value from these tables that appeared off is Modified Time.  I created this virtual machine for this testing at 16:00 on July 18th, 2012, and logged my first time opening the browser at 16:28.  Despite this, the time for this entry is thirty (30) minutes before the creation of the system even.

Container 6

Despite being listed as a container that should hold history, this container seems to contain mostly cookies when initially looking at it.  Typically on a Windows Vista or Windows 7 machine, when an index.dat file is found in …\windows\history\low\history.ie5, it is because UAC is turned on and the system is in Protected Mode.  Using default settings will cause these folders to be used for all cache, cookies, and history for the internet security zone and restricted security zone.

With that being said, this particular container still contained information mainly relating to cookies, as shown below:


Container 10

Container 10 holds url history that is more common from what we’ve seen before.  It is broken down though by date and week periods, similar to how MSHIST files work.  Container 10, in this instance, held the web browsing history for the date range of 07-18-2012 to 07-19-2012.

The information in the following table pertains to the time values for the top row, 2012071820120719: Forensicator@ Host:

Time Entry
Actual Time
Accessed Time
Wed, 18 Jul 2012 15:28:09 -0500 UTC
Modified Time
Wed, 18 Jul 2012 8:28:09 -0500 UTC
Sync Time
Wed, 18 Jul 2012 15:28:09 -0500 UTC
Expiry Time

Once again, the confusing thing about this is the time that is being tracked.  It references the accessed, modified, and sync time to a time all before the system was ever booted, and accessed/sync time are again one hour behind the time they should be.

Container 14

Container 14 holds the same content as container 10 with the exception that it is just for a different day.  This is the same notion as what a user would get from MSHist index.dat files that are separated by dates.  Once again, all date timestamps are still an hour off with this table.

Test Round 2

So, because my time stamps were consistently one hour off the first time did this, I decided to test again and again.  The following table and screenshots all come from my third round of testing, and yield the same results (timestamps being one hour off) as the first two tests.

Time settings for the Windows 8 virtual machine:


The following table is my documented browsing information for this test.

Time/Date of Visit
Opened IE – default page
10:26  –  7/23/2012
Opened new IE – default page
Google Search: computer and digital forensics research topics

Due to there only being one day of brief internet browsing on this machine, the Containers table only lists one container directly linking to an MSHist directory.

The container directly linked to MSHist, in this instance, was once again container 10.  The following image shows this table, sorted by Access Time in descending order.  As shown, it follows the same order that I documented.

For this time testing, we will use the third timestamp down, in reference to 2012072320120724: ethanf@

Time Entry
Actual Time
Accessed Time
Mon, 23 July 2012 09:29:26 -0500
Modified Time
Mon, 23 July 2012 05:29:26 -0500
Sync Time
Mon, 23 July 2012 09:29:26 -0500
Expiry Time
Sat, 18 August 2012 09:29:26 -0500

Once again, the timestamps from this are one hour behind what I documented.


It’s great to have a lot of progress on the WebCachev24.dat files, personally.  I had been trying to parse them at the hex level for a VERY long time.  What a relief.  The frustrating part, now, is determining why it is giving me time stamps from before the machine was even created, and why the accessed time timestamps are all one hour off.  I made sure that the virtual machine was set to -0500 UTC, my machine was set to -0500 UTC, and DCode set to -0500 UTC.  Even still, all my times are still coming up one hour before the time I actually accessed the websites.

One more kink in my never ending road of turmoil with MSIEv10 history files.  The other item that I haven’t been able to check with this system yet is the NoQuota.edb file within <user>\appdata\local\microsoft\internet explorer\Indexed DB.  MSDN refers to Indexed DB as “… a W3C Working Draft that enables you to store, search, and retrieve data on the user’s device, even when Internet connectivity is disabled.  IndexedDB is a feature of the Web platform shared by IE10 and Metro style apps in the Windows 8 Consumer Preview.”

A user also has the ability to set a quota on the amount of data that is stored on the device itself.  These quotas, however, do not apply to metro apps, nor did I set any quotas on this machine itself.  Therefore, being able to parse this database should give me more information relevant to internet history.  As I stated in my previous blog post though, I have been unable to run esentutl to fix the database and actually parse it.

Windows 8: File Forensics Part 1 – Recycle Bin

Windows 8: File Forensics Part 2 – USB Drive Activity

About the Author:

Ethan Fleisher is a Senior majoring in Computer and Digital Forensics at Champlain College. Originally from Carlisle, Pennsylvania, Ethan currently works as a Forensic Intern and System Administrator at the Senator Patrick Leahy Center for Digital Investigation where he is involved in real life investigation forensic analysis, network and system administration, and forensic research. Ethan has spent close to the last year researching the Microsoft Windows 8 OS with focus on revealing new artifacts and attempting to confirm previous methodologies.

(Guest post provided by Ethan Fleisher. Original article can be found at the author’s blog

Windows 8 Forensics: USB Activity

When I started working on Windows 8 USB drive forensics, I assumed it would be pretty similar to Windows 7. I created a fresh Windows 8 VM and plugged a thumb drive into my local system. Like normal, the VM recognized it as it should. At this point I shut the VM down and opened it in EnCase to examine what happened. All of the findings were similar to Windows 7 USB forensics, and much like the recycle bin, proved nothing exciting.

Here are the results.

(The original post for this can be found on the Patrick Leahy Center for Digital Investigation blog.)

Mounted devices tab:


 Software\microsoft\windows portable devices\devices – friendly name link:


These keys are all the same as Windows 7, therefore it should be smooth sailing to continue producing USB activity results.

About the Author:

Ethan Fleisher is a Senior majoring in Computer and Digital Forensics at Champlain College. Originally from Carlisle, Pennsylvania, Ethan currently works as a Forensic Intern and System Administrator at the Senator Patrick Leahy Center for Digital Investigation where he is involved in real life investigation forensic analysis, network and system administration, and forensic research. Ethan has spent close to the last year researching the Microsoft Windows 8 OS with focus on revealing new artifacts and attempting to confirm previous methodologies.

(Guest post provided by Ethan Fleisher. Original article can be found at Champlain College and the author’s blog

Windows 8 Forensics: Recycle Bin


Today I am starting the preliminary research on the Windows 8 Operating System from a Digital Forensics standpoint. I will be comparing it primarily to known information on the Windows 7 Operating System. There are going to be many items that I am looking at, and any comments with suggestions for further things to look into would be appreciated.

Topics so far include:

  • Recycle Bin Properties
  • USB Drive Activity
  • Internet History
  • Windows 8 Reset and Reload Feature
  • Event Logs
  • Prefetch Files
  • Jump Lists
  • File History Feature

As I dig into these topics, there is likely to be a large amount of information that will be discovered. It is important to remember, though, that some of these topics may yield little to no differences.


The purpose of this project is to determine key differences between the Windows 7 and Windows 8 operating system from a forensic standpoint in order to determine if there are any significant changes that will be either beneficial or detrimental to the forensic investigation process.

Version:1.0 StartHTML:0000000167 EndHTML:0000003071
StartFragment:0000000747 EndFragment:0000003055 Version:1.0
StartHTML:0000000167 EndHTML:0000002862 StartFragment:0000000747

Windows 8 Recycle Bin

No shocking information to be found here, the Windows 8 recycle bin behaves just like the Windows 7 recycle bin.

The original blog post for this can be found at the Patrick Leahy Center for Digital Investigation blog, but this is a slightly edited version.

We still find the $Recycle.Bin, $R, and $I files. Here’s a breakdown of my methodology.

  • Created “I wonder if this will appear“ at 10:14
  • Deleted “I wonder if this will appear“ at 10:14
  • Created “test document.txt“ at 10:22
  • Deleted “test document.txt“ at 10:23
  • Created “lets try this” at 10:40 – filled it with text, 36.5 mb
  • Deleted “lets try this“ at 10:40

Recycle Bin in EnCase still has $Recycle.Bin and $I files. The actual $R notation can be found when looking at simply the user ID under the recycle bin, but since the $R file is the file data itself, it is represented by the file name in the recycle bin.

Located and verified times of “test document”, “lets try this”, and “I wonder if this will appear” to be accurate to what I recorded when creating/deleting originally.

Verified hex values for $I files in comparison to known Windows 7 values.

Bytes 0-7 are still the file header, always 01 followed by seven sets of 00.

Bytes 8-15 are the original file size, stored in hex, in little-endian. This can be converted into big endian format and converted with a hex calculator to a decimal notation to determine the size in bytes. I tested this with the “Lets try this” document that was 36.5mb. The hex value in encase was F0 E2 39 02, read in little endian. Converting this into big endian yields 02 39 E2 F0, which ran through a hex calculator shows that it is 37348080 bytes, which is roughly 36.5mb

Bytes 16-23 reflect the deleted date time stamp, represented per normal standards (number of seconds since Midnight, January 1, 1601).

Bytes 24-543 reflect the original file path/name.

About the Author:

Ethan Fleisher is a Senior majoring in Computer and Digital Forensics at Champlain College. Originally from Carlisle, Pennsylvania, Ethan currently works as a Forensic Intern and System Administrator at the Senator Patrick Leahy Center for Digital Investigation where he is involved in real life investigation forensic analysis, network and system administration, and forensic research. Ethan has spent close to the last year researching the Microsoft Windows 8 OS with focus on revealing new artifacts and attempting to confirm previous methodologies.

(Guest post provided by Ethan Fleisher. Original article can be found at Champlain College and the author’s blog