Has anyone looked at the various shell item artifacts associated with the Windows shell?

Specifically, shell items and shell item ID lists are included in a number of Registry keys (shellbags, ComDlg32, etc) as well as within Windows shortcut/LNK files and Jump Lists.

Many (albeit not all) of the data structures that make up the folder or file paths (depending upon the artifact and the target) contain DOSDate format time stamps, which in most cases are the object MAC times derived from the file system metadata for that object at the time that the artifact is created. In many cases, other activities beyond the scope of the originating action/event can act upon the file system metadata artifacts without having an effect of the DOSDate time stamps embedded in the shell items.

As such, I'm curious as to what other analysts might feel would be the relative value of these time stamps, in the scope of an overall exam. I can see how the "C" time would be useful, even given the different in granularity between file system metadata (FILETIME object, granularity of 100 nanoseconds) and the DOSDate structure (granularity = 2 seconds), particularly if the path were deleted and was no longer visible within the active file system.

"A" times, even when they are actively updated (by default, they are not on Vista+ systems) have a granularity of 1 hr.

Again, "M" times within the file system can be modified by actions that have nothing to do with the action that created the artifact in question. For example, a user can add a file to a path that creates an artifact in the ComDlg32 key in the Registry, and other actions (adding, deleting files without the use of the Common Dialogs) can modify those times, leaving a number of disparate time stamps on that relate to essentially the same object.

Given all of this, I'm not suggesting that the DOSDate time stamps embedded within the shell item structures are not of value; rather, I'm asking about the relative value that other analysts find in these time stamps, given the conditions that can affect them.

Thanks.  

<sigh>  

...and still nothing.

I have to say, I'm a bit surprised. I have seen where this artifact has provided indications of access to resources (drives, network resources, even devices) that do not show up readily in other locations within the rest of the Registry.  

Harlan, I have asked this question previously too. I see a lot of 'potential' value in them, however I haven't had any time to write up some code to actually meaningfully display these items, a visual representation would work best for something like this. The regular quick & dirty spreadsheet(csv) output will not work. In code I have written earlier, I have intentionally ignored these timestamps as they are too many and its unnecessary duplication in most cases. Most often the existence of a file or folder is what we are looking for (at least in cases I've dealt with, its been enough). Of course that entirely depends on your case.
_________________
Yogesh Khatri
- EnCE, GREM, GPEN, GCIA

Independent Forensic Consultant & Researcher
Mumbai, India
Blog- www.swiftforensics.com 

I think the reason you didnt get any replies is because your description went a bit over some peoples heads.
I know I need to do a lot of research to catch up to where you're at, or at least to make a meaningful contribution to your (much appreciated) effort.  

@Yogesh - I'm not sure I see the value in some sort of visualization routine, but I agree with the second half of your post. I believe that mixing the DOSDate format time stamps with others (i.e., MACB times from file system metadata) would be both redundant and confusing, particularly since the DOSDate time stamps have a granularity of 2 seconds. This means that the creation date from the file system metadata won't line up _to the second_ with the DOSDate format creation date. As such, those unfamiliar with both timeline analysis and the artifacts themselves will be confused by the apparent disparity.

@RA - if that were the case, then I would hope that someone would have said something.

What research do you feel that you need to do? Perhaps Yogesh or I can answer some questions in order to speed that along.  

@RA...

Okay, I went back and stared at my original post for a couple of minutes, and I guess I'm just shocked that there is such a small portion of the community that has any idea what I'm talking about, and most of those people aren't even active on this forum.

Shell items have been part of Windows going back as far as when shortcut files first came out. These artifacts could be found in a number of locations within the Registry (on XP, in shellbags), but really started to be used to a much greater extent beginning in Vista.

To be honest, I have no idea why that's the case. For example, there's a shell item that is 21+ bytes in length, and all that it appears to contain is a volume letter (i.e., F:\). So...all those bytes to store a size value, type ID, and three bytes. It doesn't make sense. Further, some shell items are much larger, and contain much more information...very little of which appears to actually be used.

However the question of "why" is irrelevant...the fact is that the artifacts are there.

Given how long these artifacts have been around, what do you think would be the reason that few analysts are familiar with them?

I've posted to my blog, as well:
windowsir.blogspot.com...lysis.html