Windows Shell Item ...
 
Notifications
Clear all

Windows Shell Item Artifacts

18 Posts
4 Users
0 Likes
1,059 Views
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

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.

 
Posted : 18/11/2012 7:27 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

<sigh>

 
Posted : 20/11/2012 4:55 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

…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.

 
Posted : 08/12/2012 6:46 pm
(@yogeshkhatri)
Posts: 26
Eminent Member
 

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.

 
Posted : 12/12/2012 12:11 pm
(@randomaccess)
Posts: 385
Reputable Member
 

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.

 
Posted : 12/12/2012 2:05 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

@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.

 
Posted : 12/12/2012 5:34 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

@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
http//windowsir.blogspot.com/2012/08/shellbag-analysis.html

 
Posted : 12/12/2012 5:52 pm
(@bithead)
Posts: 1206
Noble Member
 

H,
I think you answered your own question.

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.

The only reason to use an item of limited value is to either reinforce other weak findings or when there are no other items of evidentiary value.

For example in an IP case say the examiner found incriminating e-mails, AutoCad files, and a copy of a wire transfer receipt; how helpful is a 21-byte artifact that just shows a drive letter? Conversely if the same examiner just has a file name in a jump list for a removable drive and is looking for other corroborating evidence that same 21-byte artifact may make a difference.

 
Posted : 12/12/2012 7:03 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
Topic starter
 

The only reason to use an item of limited value is to either reinforce other weak findings or when there are no other items of evidentiary value.

Thanks, but what I was referring to was the use of the shell items as part of the operating system. Shell items seem to be most often used to maintain information regarding paths…a "blob" of data several hundred bytes in size will be used to maintain information about a directory, where "system32" would suffice.

However, to your point regarding "evidentiary value"…I agree with your point about using other items to support weak findings. In fact, I generally tend to try to support my findings, without identifying them as "weak"…if I have 6 facts to support a finding, I'll use all 6.

For example in an IP case say the examiner found incriminating e-mails, AutoCad files, and a copy of a wire transfer receipt; how helpful is a 21-byte artifact that just shows a drive letter? Conversely if the same examiner just has a file name in a jump list for a removable drive and is looking for other corroborating evidence that same 21-byte artifact may make a difference.

Again, my reference to the size of, or amount of space used to contain an artifact was more to the point of, "I don't know why the developers would choose to do this…".

However, I do see and agree with your point regarding the relative value of the artifact…in part because I've seen the same thing.

Here's an example…Jacky Fox recently posted her dissertation, which had to do with the pitfalls of interpreting Registry data. One of the things she found out…by looking at the traditional means of identifying USB devices connected to Windows systems…is that the MountPoints2 artifacts are created for all logged on users, not just the user who connected the device to the system. Okay, good to know…but how do we find out which user actually accessed the device?

One way to approach this issue is to look to shellbag artifacts. For example, one of the shell item types is for a "device", which identifies devices that may not show up in the Enum\USBStor key. So, not only would you be able to identify the particular user who accessed the USB device (via drive letter mapping) but you could also use shellbags (shell items) as a means of identifying devices that do not show up via the traditional identification methodologies.

So….back to my original point. Without a discussion of these artifacts, there's little chance for understanding and developing means for understanding the artifacts, as well as developing analysis techniques that fully employ these artifacts.

 
Posted : 12/12/2012 7:24 pm
(@bithead)
Posts: 1206
Noble Member
 

Again, my reference to the size of, or amount of space used to contain an artifact was more to the point of, "I don't know why the developers would choose to do this…".

Although it is a rather trite answer, it is probably because one group of developers at MS needed it for something and never consulted with the Registry developers or any other group to see if the data was already stored somewhere else. Of course we mere mortals will likely never know.

So….back to my original point. Without a discussion of these artifacts, there's little chance for understanding and developing means for understanding the artifacts, as well as developing analysis techniques that fully employ these artifacts.

I agree, unfortunately the limited value and the limited number of times these artifacts are needed in a case will also limit the amount of time researcher/examiners such as yourself and examiners in the trenches (who typically cannot take the time to look past the next case and will await your next tome) can devote to looking at these items. And as you have posted before (on several occasions) if no one is clamoring for information about an item what motivation do you have to invest time and effort into the research.

 
Posted : 12/12/2012 8:19 pm
Page 1 / 2
Share: