Shell Item Artifacts, Reloaded
In short, what I'd done is this...based on a previous Forensic Lunch, during which Joachim Metz discussed the existence of MFT file reference numbers within some of the shell item structures. Specifically, starting with Vista, shell items pointing to files and folders appear to contain MFT file reference numbers. This is mentioned not only in Joachim's Windows Shell Item format specification, but it's also described on Willi Ballenthin's Shellbags analysis page.
Accepting this, I wanted to validate the information and see what it looks like in the real world. Using FTK Imager Lite, I extracted the MFT and USRCLASS.DAT hive file from my own Windows 7 system. Parsing the shellbags entries from the USRCLASS.DAT hive (using a customized RegRipper plugin), I was able to get a hex dump of specific shell items as all of the shellbags were being parsed. I redirected the output of the plugin to a file, and selected specific entries for analysis. Figure 1 illustrates one of those examples.
 |
| Fig. 1: Sample Shell Item |
The translated DOSDate times are as follows:
M: 2011-11-29 20:27:44
A: 2011-11-29 20:27:44
B: 2011-11-29 20:27:44
The times listed above are the last modified, last accessed, and creation/born dates for the folder, extracted and translated from the shell item that points to the folder (see fig. 1). Per Joachim's format specification, there doesn't seem to be an entry modified time value available. All of the times are listed in UTC format.
It's important to keep in mind where these times come from...the time stamps are read from the MFT (in FILETIME format) and translated to DOSDate time stamps via the FileTimeToDosDateTime() function.
I had also extracted the MFT from the D:\ volume and parsed it via a custom Perl script. I searched the output for record number 45, and it still had the sequence number of 13.
The times from the $STANDARD_INFORMATION attribute:
M: Mon Sep 23 16:17:36 2013 Z
A: Mon Sep 23 16:17:36 2013 Z
C: Mon Sep 23 16:17:36 2013 Z
B: Tue Nov 29 20:27:43 2011 Z
The times from the $FILE_NAME attribute:
M: Tue Nov 29 20:27:43 2011 Z
A: Tue Nov 29 20:27:43 2011 Z
C: Tue Nov 29 20:27:43 2011 Z
B: Tue Nov 29 20:27:43 2011 Z
Now, the big question is...so what? Well, the fact is that this information can be extremely useful to an analyst.
The time stamps can be extremely telling. In this case, we see that the times from the shell item are relatively close to those within the $FILE_NAME attribute; this tells us that
Sebastien pointed out something important with respect to shellbags on Windows 7 systems a bit ago over on the Win4n6 Yahoo group, specifically:
"Go in your Windows 7 help file and search for "Folders: frequently asked questions". Then select: "Why doesn't Windows remember a folder window's size and location on the desktop?". You will find why you are not able to find something similar on Win7:
"In Windows Vista, a folder window opens at the same size and location on the desktop that it did the last time you closed it, based on the location where the folder is stored. For example, if you resize the Music folder window and then close it, it'll be the same size the next time you open it.
Windows 7 remembers one size and location setting for all your folders and libraries. So each time you open Windows Explorer, it'll open at the same size and location on the desktop that it did the last time you closed it, regardless of which folder or library you open.""
The MFT file reference number tells us something about the MFT record; specifically, MFT records are reused, not deleted, when a file is deleted, and the sequence number is incremented each time the record is reused. In our example, the folder still exists, and the MFT file reference number from the shell item points to an existing record in the MFT. If this wasn't the case...if the sequence number in the MFT was 14 or more, then the information from the shell item would provide us with historical information from the system, showing us what existed on the system at some point in the past. In this case, the LastWrite time for the key in question (which, based on the MRU values, applies to the item of interest), is 2012-05-22 14:34:27 UTC, which tells us when the folder in question actually existed on the system. So, in addition to VSCs and hives in the RegBack folder, we have yet another potential source of historical information on systems, and it's simply a matter of how this information will be applied during an investigation.
Where this becomes really valuable, particularly if it pertains to the goals of your exam, is that you can develop a partial reconstruction of what a system "looked like" in the past...it would be more of a smear than a snapshot, given the various sources. What I mean by that is that shell items exist within many more locations and artifacts on a Windows system than simply the shellbags...as previously mentioned, shell items exist in shortcut/LNK files, Jump Lists (Win7/8), as well as a number of locations within the Registry. In short, there are a lot of locations within a Windows system where these particular artifacts can be found, and they seem to get more numerous as the versions of Windows increase, and they're created behind the scenes by the operating system. As such, they're not only useful for seeing that the system "looked like" in the past, but they can also be valuable if the use of anti-forensics techniques are suspected.
Finally, I'm sure that you noticed the slight discrepancy between the times listed in the shell item, and what's in the MFT. This most likely has to do with the translation that occurs via the API function...a 64-bit value with 100 nanosecond granularity is reduced to a 32-bit value with second granularity. Also, per the API function, the seconds are divided by 2, and there's no sub-second granularity to the value.
