Since this past spring, the term "shellbags" has been heard more and more often. Searching for "shellbag analysis" via Google reveals a number of very informative links. I'm going to gloss over the specifics of these links, but my doing so in no way minimizes any of the research, analysis and documentation by those who have contributed to the understanding of these Windows artifacts.
What I want to get to directly is the underlying data structures associated with the shellbags artifacts, specifically, the shell items and shell item ID lists, structures that Joachim Metz and others such as Kevin Moore have worked to identify and define. Again, mentioning the contributions made by these two individuals is in no way intended to take away from work performed by others in this area.
Shell items and shell item ID lists are used in a number of artifacts and data structures on Windows systems. Perhaps one of the most well known of those structures is the Windows shortcut/LNK files; you can see from the MS specification regarding the file format where the shell items exist within the structure. A number of Registry keys also use these data structures, including (but not limited to) Shellbags, ComDlg32, and MenuOrder.
Several of the data structures that make up the shell item ID lists include embedded data, to include time stamps. In many cases (albeit not all), these embedded time stamps are DOSDate format, which is a 32-bit time stamp with a granularity of two seconds.
Now, since a lot of the analysis that we do is often based heavily upon not simply that an event or action occurred, but when it occurred, often having additional sources of time stamped data can be extremely valuable to an analyst. However, there is much more to timeline analysis than simply having a time stamp from an artifact...the analyst must understand the context of that artifact with respect to the time stamp in question.
The question I would like to pose to the community is...what is the value of the embedded DOSDate time stamps within the shell items?
Let's first consider shellbags. The keys that store these artifacts are mentioned in MS KB 813711, so we have an idea of how these artifacts are created. In short, it appears that the shellbags artifacts are created (or modified) when a user accesses a folder via the Windows Explorer shell, and then repositions or resizes the window that appears on the desktop. So let's say that I open Windows Explorer, navigate to the "C:\Windows\Temp" directory, and resize the window. I would then expect to find indications of the path in the shellbags artifacts. At this point, we would expect that the time stamps embedded within the shellbags artifacts (and keep in mind, more testing is required in order to verify this...) refer to the MAC times from the "Windows" and "Temp" folders at the time that the artifact was created.
If we can agree on this, even for the moment, can we then also agree that other activities outside of those that create or modify the shellbags artifacts will also act upon the MAC times for those folders? For example, adding or deleting files or subfolders, or any other action that causes those folders to be modified will cause the last modified ("M") date to be...well...modified.
On Vista systems and above, the updating of last access times for file system objects has been disabled by default. Even if it weren't, other actions and events not associated with the shellbags artifacts (AV scans, user activity, normal system activity, etc.) would also cause these times to be modified.
The same thing could be said for the ComDlg32 artifacts. On Vista systems and above, several of the subkeys beneath the ComDlg32 key in the user's NTUSER.DAT hive contain values that are consistent with shell items, and are parsed in a similar manner. The data structures that describe the files and folders in these shell items contain embedded DOSDate time stamps, but as with the shellbags, these artifacts can be affected by other actions and events that occur outside of the scope of the ComDlg32 key.
Given this, I would like to reiterate my question: what is the value of the "M" and "A" DOSDate time stamps embedded within shell item data structures? The "C" time is defined as the creation date, and even with a 2 second granularity, I can see how this time stamp can be of value, particularly if (a) the described resource no longer exists on the system, or (b) the described resource is on remote or removable storage media. However, I would think that adding the "M" and "A" times for a resource to a timeline could potentially add considerable noise and confusion, particularly if the nature and context of the information is not completely understood. In fact, simply having so many artifacts that are not easily understood can have a significant detrimental impact on analysis.
What are your thoughts?
No comments:
Post a Comment