There Are Four Lights: Shell Items

There's a good bit of information available on artifacts referred to as "shellbags", but not much information, nor discussion, on the underlying data structures within shellbags...shell items.

Shell items are data structures used to identify various elements within the Windows folder hierarchy.  Where a simple ASCII listing the path to a folder or file would suffice, we instead have shell items, and paths reconstructed by parsing shell item ID lists.  Some of these shell items are 22 bytes in length, and contain just a GUID, which needs to be translated into something that the analyst can recognize, such as "My Computer" or "Control Panel".  Other shell items refer to other resources, including folders, and need to be parsed differently.  More on that later.

LNK files
Shell items have been part of Windows systems well before talk of shellbags first came up.  Shell items are included in Windows shortcut/LNK files, which have been available on Windows systems for quite some time.  However, it's only been within the passed 12 to 18 months that there's been much real recognition of the fact that LNK files contain shell items, and this recognition has been due, in part, to some of the popular tools used to parse LNK files actually parsing this information.  Even today, there are a number of tools available and in common use for parsing LNK files that do not parse the shell items.  In just the passed year along, I've examined a number of Windows systems on which LNK files were created for devices (in most cases, digital cameras) that consisted solely of a header and a shell item ID list, and did not contain a LinkInfo block.  What this means is that many of the commonly used tools simply show nothing in the output.  Why does this matter at all?  Well, take a look at this blog post regarding what we're doing wrong with respect to LNK parsing, and when you're done, read the follow-up blog post, found here.

Do I expect to see intruders manipulating LNK files in a manner similar to what is described here?  No, I don't...that doesn't mean that it won't happen, however.  What I have seen when it comes to LNK files is the use of LNK files that are comprised solely of a header and a shell item ID list, but no LinkInfo block, which means that most of the tools in common use within the community will not show data.

A while back, Sophos released a tool to help protect users from the exploitation of the CVE-2010-2568 vulnerability.  Given that this vulnerability is almost three years old, it makes me wonder who often the analysis of shell item ID lists within LNK files is missed.

Time stamps
Many of the shell item structures include DOSDate format time stamps, which correlate to the modified, accessed, and created dates of the object resource (usually, a file or a folder).  A couple of things to keep in mind with respect to these times, particularly when the platform you're analyzing is formatted NTFS:

• The DOSDate time stamps within the shell items, particularly for resources located on the system itself, were originally stored within the MFT as FILETIME objects.  What this means is that we have a significant loss in granularity, going from 64-bits based on 100-nanosecond intervals, to 32-bits with the seconds multiplied times 2.  If the seconds value for the original FILETIME time stamp is 5, then what's stored in the DOSDate format is 10...and a difference of 5 seconds can be significant, particularly in timeline analysis, and if you don't know enough about the data structures to explain it.
• Systems from Vista on up do not, by default, update last accessed times through normal user activity, such as opening files.
• Target resources listed in shellbags can be modified by activity and processes outside the purview of the shellbags artifacts.

While digging a bit deeper into parsing XP shellbags, I saw a number of structures that included either FILETIME objects, or strings that specified a date and time, embedded within the shell items; however, without additional documentation and resources, I really have no way of determining to what these time stamps refer or correlate.  However, suffice to say, those time stamps are there and likely pertain to something.

Many types of shell items also include a good deal of embedded information within the structure itself.  Some include file sizes, and can be used to demonstrate changes in file size over time (on Vista and Windows 7 systems, you may be able to demonstrate the changes in contents via analysis of the files in VSCs).  I've also seen some shell items that contain a lot of information, which each section marked by an individual GUID that I needed to look up on the MS site to determine what it meant...in one case, one of the embedded GUIDs marked the last modification time of the resource, while another marked the creation date.

Where are shell items used?
Artifacts that include shell items include:

• LNK files
• Jump Lists (both auto* and custom*, on both Win7 and 8)
• Shellbags
• MeunOrder subkeys 
• ComDlg32 subkey values (Vista+)
• Windows 8 USRCLASS.DAT (Photos artifacts)

What's clear to me is that shell items appear to be increasing in use within Windows systems as the versions increase.  Shell items are used to refer to resources other than files and folders.  Some shell items refer to network resources, building out a path to other systems that the user accessed.  In a corporate environment, it's not unusual to see paths to file servers, but many times it may be an HR issue when there are number of paths that lead to the C$ share on other employee systems.  Some shell items refer to devices, such as digital cameras, smart phones and iPods, while others refer to web-based resources.  I examined a compromised system a while back and found that the intruder had used FTP through Windows Explorer; I found this very interesting because the shellbags were the only artifacts of this activity, and would have been missed if I had not examined these artifacts.

Usefulness
Overall, what is the usefulness of understanding these artifacts?  One of the things that I've seen throughout my time as an analyst is that if we don't know about something, we're not likely to incorporate it into our analysis process.  The purpose of this blog post is to raise awareness of these artifacts, and get folks looking at them in more than just training courses.

With respect to shellbags artifacts, things changed drastically between XP and Win7.  With XP, the shellbags artifacts are located in the NTUSER.DAT, and the NodeSlot value within each BagMRU subkey points to a Bag\Shell subkey, which may have an ItemPos* value (i.e., a value whose name starts with "ItemPos", followed by what looks like it might be a screen resolution setting).  If so, very often this value contains a number of concatenated shell items that provide a directory listing...yes, that's exactly right, the contents of the folder.  I know of one analyst who has used this information to demonstrate the contents of encrypted volumes.

With Vista (and subsequently, Win7), these artifacts were moved to the USRCLASS.DAT hive, and no longer make use of the NodeSlot value to correlate additional information from the hive.  However, there are an ItemPos* values in the NTUSER.DAT hive that can provide you with an indication of the files on a user's Desktop at a specific point in time.

And now for the Ugly...
While Microsoft provides documentation of a number of formats, shell items is not one of them.  It has taken the work of a small number of dedicated folks within the community, sometimes with support from a small number of other folks who have provided sample data, to put together initial documentation and subsequent tools for parsing these artifacts.

As of now, there are very few tools for parsing LNK files that will parse the shell item ID list (SHITEMIDLIST).  And at this point, we're only talking about parsing the information, not including it into other analysis methodologies.

There are a few tools available that parse shellbags, and of those, most do not parse all of the available shell items.  In particular, many of the available tools do not parse shell item structures that point to devices.  For some of those tools, this can be verified through the source code, while for others, you would need to run those tools and compare the output with other resources.  IMHO, I'd think that something like this would be a significant issue, not just in cases involving illicit images (may show production over possession or distribution), but also in cases of IP theft, harassment, etc.  But this illustrates why it's so important for analysts to understand the underlying data structures that are being parsed.

For example, here is the output of a script for parsing LNK files, including the shell item ID list, run against a Google Chrome LNK file on my desktop:

C:\Perl\jl>lnk.pl "c:\users\harlan\desktop\Google Chrome.lnk"
File: c:\users\harlan\desktop\Google Chrome.lnk
mtime              Fri May 17 21:35:44 2013 UTC
atime              Wed May 22 11:33:48 2013 UTC
ctime              Wed Apr 13 19:37:47 2011 UTC
workingdir         C:\Users\harlan\AppData\Local\Google\Chrome\Application
basepath           C:\Users\harlan\AppData\Local\Google\Chrome\Application\chrome.exe
description        Access the Internet
machineID          enzo
birth_obj_id_node  00:50:56:c0:00:08
shitemidlist       Users/AppData/Local/Google/Chrome/Application/chrome.exe
vol_sn             22D3-06AE
vol_type           Fixed Disk

Here's the output of the same script, run against a completely legit LNK file taken from another system (extension changed):

File: c:\users\harlan\desktop\camera.txt
shitemidlist       My Computer/DROID2/Removable Storage/dcim/Camera

That's it...there's nothing else to display, no LinkInfo block, no string data, nothing beyond the header and the shell item ID list.  In fact, the flags in the header specifically state that there is no LinkInfo block.  Again, it is critical to understand here that the LNK file was not specifically crafted as an exercise; rather, it was created through the normal, legitimate use of the operating system.  However, there are few tools available that will parse the shell item ID lists, and those tools will provide no output for this file.

Resources
ForensicsWiki: LNK
ForensicsWiki: Shell Item

Special thanks to Joachim Metz for correlating and providing a great deal of format information when it comes to a variety of data structures on Windows systems.  I have to say that I fully agree with his philosophy on analysis, as listed in his ForensicsWiki bio.  I also want to thank Kevin Moore for his work in supporting Andrew Case, et al, by writing the shellbag parsing code for Registry Decoder.  Finally, I would like to thank all of those who have provided sample data for me to use in developing some parsing tools.

Shell Item Artifacts

I was watching the 9/20 Forensic Lunch with David Cowen and crew recently, and when Jonathan Tomczak TZWorks was initially speaking, there was a discussion of MFT file reference numbers found in shellbags artifacts.  Jonathan pointed out that these artifacts are also found in Windows shortcut/LNK files and Jump Lists.  From there, Dave posed a question (which I think was based off of the mention of Jump Lists), asking if this was an artifact specifically related to Windows 7.  As it turns out, this isn't so much a function of Windows 7, as how shell items are crafted on different versions of Windows; if you remember this post, shell items are becoming more and more prominent on Windows platforms.  They've existed in shellbags and LNK files since XP, and as of Windows 7, they can be found in Jump Lists (streams in Jump Lists are, with the exception of the DestList stream, LNK format).  Windows 8 has Jump Lists, as well, and thanks to Jason's research, we know that LNK-formatted data can also be found in the Registry.

Shell Items in the Registry
There are a number of RegRipper plugins that parse shell items; menuorder.pl, comdlg32.pl (for Vista+ systems), itempos.pl, shellbags.pl, photos.pl (for Windows 8 systems). This simply illustrates how pervasive shell items are on the different versions of Windows.

Willi mentions the existence of these artifacts here, in his description of the ItemPos* section of the post; look for the section of code that reads:

if (ext_version >= 0x0007) {
        FILEREFERENCE file_ref;
        ....

What this says, essentially, is that for certain types of shell items, when a specific ext_version value is found (in this case, greater than 7, which indicates Vista...), there may be file reference available within the shell item.  I say "may be" to reiterate Jonathan's comments; I have only looked at a very limited set of artifacts, and Jonathan made no specific reference to the types of shell items that did or did not contain file reference numbers.

This is also mentioned in Joachim Metz's Windows Shell Item format specification, specifically on pg 25, within the discussion of the extension block.  Joachim has put a lot of effort into documenting a great deal of information regarding the actual structure of a good number of shell items; in his documentation, if the ext_version is 7 or greater, certain types of shell items appear to contain the MFT file reference.

So, again...this is not something that you should expect to see in all types of shell items...many types of shell items simply will not contain this information.  However, those shell items that point to files and folders...type 0x31, 0x32, 0xB1, etc...and those on Vista systems and beyond...may contain MFT file reference numbers.

I had a quick chat with David, and he pointed out that making use of the MFT file reference number from within the shellbags artifacts can show you what existed on the system at some point in the past, as the file reference number is essentially the MFT record number concatenated with the sequence number for the record.  This works in very well with David's TriForce analysis methodology, and can be extremely valuable to an examiner.

The only shortcoming I can see here is that the time stamps embedded within these shell items are not of the same granularity as the time stamps found within the MFT; see this MS API for translating FILETIME time stamps to DOSDate format, which is how the time stamps are stored in the shell items.  As such, the time values will be different from what's found in the MFT.

DOSDate Time Stamps in Shell Items

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? 

Shellbags

Dan recently posted what has to be one of the most thorough/comprehensive blog articles regarding the
Windows shellbags artifacts.  His post specifically focuses on shellbag artifacts from Windows 7, but the value of what he wrote goes far beyond just those artifacts.

Dan states at the very beginning of his post that his intention is to not focus on the structures themselves, but instead address the practical interpretation of the data itself.  He does so, in part through thorough testing, as well as illustrating the output of two tools (one of which is commonly used and endorsed in various training courses) side-by-side.

Okay, so Dan has this blog post...so why I am I blogging about his blog post?  First, I think that Dan's post...in both the general and specific sense...is extremely important.  I'm writing this blog post because I honestly believe that Dan's post needs attention.

Second, I think that Dan's post is just the start.  I opened a print preview of his post, and with the comments, it's 67 pages long.  Yes, there's a lot of information in the post, and admittedly, the post is as long as it is in part due to the graphic images Dan includes in his post.  But this post needs much more attention than "+1", "Like", and "Good job!" comments.  Yes, a number of folks, including myself, have retweeted his announcement of the post, but like many others, we do this in order to get the word out.  What has to happen now is that this needs to be reviewed, understood, and most importantly, discussed.  Why?  Because Dan's absolutely correct...there are some pretty significant misconceptions about these (and admittedly, other) artifacts.  Writing about these artifacts online and in books, and discussing them in courses will only get an analyst so far.  What happens very often after this is that the analyst goes back to their office and doesn't pursue the artifacts again for several weeks or months, and by the time that they do pursue them, there are still misconceptions about these artifacts.

Shell Items
This discussion goes far beyond simply shellbags, in part because the constituent data structures, the shell items, are much more pervasive on Windows systems that I think most analysts realize, and they're becoming more so with each new version.  We've known for some time that Windows shortcut/LNK files can contain shell item ID lists, and with Windows 7, Jump Lists were found to include LNK structures.  Shell items can also be found in a number of Registry values, as well, and the number of locations has increased between Vista to Windows 7, and again with Windows 8/8.1

Consider a recent innovation to the Bebloh malware...according to the linked article, the malware deletes itself when it's loaded in memory, and then waits for a shutdown signal, at which point it writes a Windows shortcut/LNK file for persistence.  There's nothing in the article that discusses the content of the LNK file, but if it contains only a shell item ID list and no LinkInfo block (or if the two are not homogeneous), then analysts will need to understand shell items in order to retrieve data from the file.

These artifacts specifically need to be discussed and understood to the point where an analyst sees them and stops in their tracks, knowing in the back of their mind that there's something very important about them, and that the modification date and time don't necessarily mean what they think.  It would behoove analysts greatly to take the materials that they have available on these (and other) artifacts, put them into a format that is most easily referenced, keep it next to their workstation and share it with others.

Publishing Your Work
A very important aspect of Dan's post is that he did not simply sit back and assume that others, specifically tool authors and those who have provided background on data structures, have already done all the work.  He started clean, by clearing out his own artifacts, and walking through a series of tests without assuming...well...anything.  For example, he clearly pointed out in his post that the RegRipper shellbags.pl plugin does not parse type 0x52 shell items; the reason for this is that I have never seen one of these shell items, and if anyone else has, they haven't said anything.  Dan then made his testing data available so that tools and analysis processes can be improved.  The most important aspect of Dan's post is not the volume of testing he did...it's the fact that he pushed aside his own preconceptions, started clean, and provided not just the data he used, but a thorough (repeatable) write-up of what he did.  This follows right in the footsteps of what others, such as David Cowen, Corey Harrell and Mari DeGrazia, have done to benefit the community at large.

Post such as Dan's are very important, because very often artifacts don't mean what we may think they mean, and our (incorrect) interpretation of those artifacts can lead our examination in the wrong direction, resulting is the wrong answers being provided as a result of the analysis.

HowTo: Correlate an Attached Device to a User

Not long after my previous post on correlating LNK files to an external device, I received a question regarding correlating a device to a particular user.  Some may look at this and think, well, that's easy...the LNK files in question are located in the user profile, so correlating the user to the device is actually pretty easy.

Okay, but what happens if there are no LNK files that point to the device?  After all, for a LNK file to be available, the user must either create it manually, or perform some action where the operating system will create it automatically, right?  Usually, this means that the user has opened a folder on the external device and double-clicked a non-executable file of some kind, such as a .txt file or a Word or PowerPoint document.  The resulting action is that the appropriate application is launched based on the file extension, and the file is opened in that application, and an LNK file is created.

So, if you're examining a system and you suspect (or can show) that a USB device had been connected to the system, then how would you go about associating the device with a particular user, in the absence of LNK files?

MountPoints2 Key
As part of your USB device discovery process, one of the places that you're going to look is in the MountedDevices key within the System hive, in order to map the devices you've found in the USBStor subkeys to the volume globablly-unique identifier (GUID).  Beneath the MountedDevices key, some of the value names will be the volume GUIDs, and their binary data will contain the device information, in Unicode format.  Parsing the data and mapping back to the value name will provide you with the volume GUID.  You can then use this information to search the subkeys beneath the MountPoints2 key in the NTUSER.DAT hive files for the volume GUID

The path to the MountPoints2 key is:
\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Volume GUID key LastWrite time
It's commonly accepted that the LastWrite time for the volume GUID subkey beneath the MountPoints2 key indicates when that device was last connected to the system.

Shellbags Artifacts
Another artifact that allows us to correlate an attached device to a user is the shellbags artifacts, which on Windows 7 systems are found in the USRCLASS.DAT hive file within the user profile.  This is how we can tie a device to a particular user.

The shellbags artifacts are simply paths to resources composed of shell items, the same types of data structures that can be found in LNK file shell item ID lists, Jump Lists, as well as other locations within the Registry.  On Vista and Windows 7 systems, the first time that the user opens an Explorer window to a folder on an attached USB device (external hard drive or thumb drive), one of the shell items in the path will represent the drive letter to which the device was mapped, followed by the folder paths.  The drive letter can be correlated to a particular USB device by mapping to the contents of the MountedDevices key values (or, for a device previously connected to the system, you may want to dig a bit into the MountedDevices key contents available in VSCs), or to the "Windows Portable Devices\Devices" subkeys in the Software hive (again, be sure to check VSCs, as well).

Historical Registry Information
If you're looking for historical information from within the Registry, be sure to check the contents of the C:\Windows\system32\config\RegBack folder for backed-up copies of the System and Software hives.

However...and this is very important...the shellbags artifacts may contain information about attached devices that are not immediately obvious via other means of analysis.  For example, USB external drives and thumb drives are usually represented on the system as a volume (i.e., F:\, G:\) or drive letter, whereas smartphones, digital cameras, and MP3 players, while storage devices, usually appear beneath in the shellbags artifacts as a different type (type == 0x2e) of shell item.  Not all of the tools available for parsing shellbags will parse these types of shell items; in fact, those that don't seem to simply skip parsing the entire path, so shellbags with type 0x2e shell items at their root are not displayed.

Further, depending upon the version of Windows and the type of device, the shell items the comprise the path the resource might be type 0x00, or a variable type.  As the name implies, the routine for parsing these types of shell items varies, and in many instances, a great deal of information can be retrieved via knowledgeable manual analysis.

Devices connected via Bluetooth
Devices can be connected to a Windows system in other ways, including via Bluetooth. What's interesting about this type of connection is that smartphones are pretty ubiquitous at this point, and once the initial connection has been made, reconnecting to the device is trivial, and the device doesn't even have to be in view. The device can be reconnected as long as it is in range, and can be on a belt, or in a backpack or purse.

In my research, I found that a lot of users will connect to their smartphone via Bluetooth and use that connection to play music via their computer.  I also found out that MS provides a file called fsquirt.exe, which is loaded on a system during installation if the system is found to have a Bluetooth radio.

Use the bthport.pl RegRipper plugin to get some information about devices connected to a Windows system via Bluetooth.

LNK Files

Update, 28 Feb: Just a quick note...this post is not about tools.  I do not mention any tools in the post, and the content isn't about one tool being better than another. I do mention using a hex editor, but that is simply to verify finds from whichever tool is used.  In the first example below, every parsing tool available would've returned the exact same time stamps, and I would have (and recommended) used a hex editor to confirm the finding. At the time I'm writing this update, this post has been viewed 1258 times, and not one question about tools has been posted as a comment. This post is about LNK file metadata, what it means, and how it can be used in analysis. Thanks.

I know, I know...yet another blog post on LNK files...yeah.  I get it.  But some new things popped up recently that I wanted to take advantage of, and they ended up here.

I had an opportunity to look at several LNK files recently, and I wanted to dig a bit deeper into their metadata.  Most available write-ups make mention of the LNK file, but tend to gloss over the file and move right to the embedded command and the next stage download.  I wanted to take a closer look at what's in the LNK file, because after all, this is something created within the adversary's environment that they're sending out.  In a lot of ways, it's like free money, so why not make the best use of what you have available, and squeeze every little bit out of the data that you have?  Maybe it's just me, but when the adversary gives you something, it's hardly a "little bit".

Consider this: several years ago, the folks at JPCERT/CC said that LNK files give us a view into the attacker's development environment; this was, and still is, a great idea, so let's see if we can not only replicate what they did (with respect to metadata extraction) but also see if we can't squeeze just a bit more out of the files, and see  what we can learn about the adversary's development environment, and maybe even see what we can learn about the tools they use to create the LNK files.

Steroids
I ran across two write-ups on LNK files recently; perhaps it would be more correct to say two write-ups on the same (or very similar) LNK file.  I found this write-up at D3xt3r's Malware Lab (blog includes a hash), and this write-up on Max's blog (blog includes a link to download the sample).  While D3xt3r's write-up is dated 16 Feb 2019, Max's doesn't have a date as part of the published material, but it does appear to have been published in Feb 2019, as well.  This is to say that they're both fairly recent posts, and as such, the LNK file itself may be fairly recent, as well.

Anyway, I wanted to take a look at a few things associated with the LNK file metadata that weren't discussed in either blog post, specifically what we could learn by going really deep in parsing the files.  One of the first things that I looked at was the shell item ID list, shown below:

shitemidlist       My Computer/C:\/Windows/system32/cmd.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows (8)
  C:0                   M:0                   A:0                  system32 (8)
  C:0                   M:0                   A:0                  cmd.exe (8)

As we can see from the above output, I parsed the shell item ID list, but the time stamps embedded within the individual shell items (the creation, modification, and last accessed times of the resources) appear to all be zeros.  Using a hex editor, I verified this quite easily, and in fact, the bytes at the locations for the time stamps within each of the shell items are all zeros.  Interestingly enough, the LNK file mentioned here also has the shell item time stamps zero'd out, so this is likely not a unique finding.  However, it's unclear whether this is the result of the tool used to create the LNK file, or of anti-forensic/obfuscation efforts taken after the LNK file was created.

We also see that the version information for the shell items is "8", indicating that the platform is Windows 2008, 7, or 8 (per section 6.5 here).  This gives us some additional (beyond what the JPCERT/CC folks discussed) insight into the development environment used by the adversary.

Now, let's take a look at the contents of the PropertyStoreDataBlock, shown below:

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
         SID: S-1-5-21-1243223150-2135741377-3118647425-500
{f29f85e0-4ff9-1068-ab91-08002b27b3d9}/6

As we can see,there are two GUID/ID pairs, the first of which points to a Unicode string that is a SID.  This is fairly common, in that we not only see the GUID/ID pair populated with a SID in a good number of LNK files, but we can use native tools (PowerShell, etc.) on Windows systems to create LNK files that contain this property set.  In this instance, the RID points to the default Administrator account for the system.  For the second property, the GUID indicates that it's a Summary Information Property Set, and the ID indicates that it's a comment.  Looking at the contents of the property set itself (via a hex editor), there don't appear to be any visible strings.

Interestingly, the LNK file does not appear to have a TrackerDataBlock, and as such, there is no machine ID (system NetBIOS name) embedded in the LNK file.  Again, this is pretty easy to verify via a hex editor.

What we have so far is a pretty interesting view into the manufacture of this LNK file.  There are some 'normal' elements of the file structure that exist, and there are other elements that we expect to see, but have been removed.  This is only one file, so without more insight, anything regarding the "why" is simply speculation and assumption.  What we do know at the moment is that steps were taken, either during the manufacturing process or afterward, to remove elements of the file structure, and the removal of those elements did not impact the function of the LNK file itself.

Finally, the D3xt3r post also includes a link (no pun intended) to this TrendMicro post from 2017.  The TM post indicates that, at the time, the use of LNK files to download malware was a "rising trend".

Cb
I also ran across this write-up from Carbon Black, dated 11 Feb 2019. The LNK file discussed in the Cb blog post contains some interesting metadata.  For example, this file happens to contain a description field, as shown below:

description        AVI

I can't say that I've often seen a description field within an LNK file that's been populated.  However, I should note that the LNK file from the 2018 campaign described here did have a description field of "ds7002.pdf"; the LNK file from the 2016 campaign did not.

In addition, we can see from the shell item ID list (below) that the shell items contain time stamps, and that the version numbers embedded within the shell items indicate that the system is a Windows 8.1 or 10 system.

shitemidlist       My Computer/C:\/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
**Shell Items Details (times in UTC)**
  C:2018-04-11 21:04:34  M:2018-11-16 21:29:56  A:2018-11-16 21:29:56 Windows (9)
  C:2018-04-11 21:04:34  M:2018-11-21 17:32:02  A:2018-11-21 17:32:02 System32 (9)
  C:2018-04-11 23:38:22  M:2018-04-11 23:38:22  A:2018-06-28 23:05:46 WindowsPowerShell (9)
  C:2018-04-11 23:38:22  M:2018-06-28 23:04:20  A:2018-06-28 23:04:20 v1.0 (9)
  C:2018-04-11 23:35:28  M:2018-04-11 23:35:28  A:2018-04-11 23:35:28 powershell.exe (9)

Looking at the PropertyStoreDataBlock (below), we see a SID, as well as another property.

***PropertyStoreDataBlock***
GUID/ID pairs:
{446d16b1-8dad-4870-a748-402ea43d788c}/104
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
    SID: S-1-5-21-1607665944-3235443811-1991609163-1001

Looking at the SID, we see that in this case, the RID is "1001", indicating a user account was used to create the LNK file (as opposed to the built-in administrator account, with a RID of 500).  In fact, we know from the RID that this was the second user account created on the system.

Looking up the other GUID, it appears to be a System.VolumeID property; I'm still looking for information on how to parse this property field.

Finally, we have the TrackerDataBlock (below):

***TrackerDataBlock***
Machine ID                     : x10-slim
New Droid ID Time         : Sun Jul 29 22:57:38 2018 UTC
New Droid ID Seq Num  : 5969
New Droid    Node ID     : e8:9e:b4:3a:a3:ea
Birth Droid ID Time         : Sun Jul 29 22:57:38 2018 UTC
Birth Droid ID Seq Num  : 5969
Birth Droid Node ID        : e8:9e:b4:3a:a3:ea

As we can see from the TrackerDataBlock, the NetBIOS name of the system on which the LNK file was created is "x10-slim". Looking up the MAC address OUI (i.e., e8:9e:b4) indicates that it belongs to "Hon Hai Precision Ind. Co.,Ltd.", which was also mentioned in the JPCERT/CC article. Through the course of discussions of "toolmarks", one of the topics that came up was that a common virtual machine may be used by actors; the fact that a VM is used is supported by the OUI lookup, but something that hasn't been addressed is how common this may be.

RAT
I also ran across a Proofpoint blog post from August 2017 that was very interesting, and not just because of the use of Game of Thrones as the lure.  In this particular case, the LNK file was embedded within the .docx lure file

First, let's take a look at the shell item ID list (below):

shitemidlist       My Computer/C:\/WINDOWS/system32/WindowsPowerShell/v1.0/powershell.exe
**Shell Items Details (times in UTC)**
  C:2006-05-22 17:08:04  M:2007-12-06 05:29:12  A:2007-12-06 05:29:12 WINDOWS (3)
  C:2006-05-22 17:08:04  M:2007-12-04 00:44:06  A:2007-12-04 00:44:06 system32 (3)
  C:2007-09-21 00:56:32  M:2007-09-21 00:56:32  A:2007-09-21 00:56:32 WindowsPowerShell (3)
  C:2007-09-21 00:56:32  M:2007-12-03 06:20:46  A:2007-12-03 06:20:46 v1.0 (3)
  C:2009-07-13 23:49:08  M:2009-07-14 01:39:22  A:2009-07-13 23:49:08 powershell.exe (8)

In this case, the version of "3" from the shell items indicates a Windows XP or 2003 system.  And yes, I did catch (and verify) that the version info for the final shell item ("powershell.exe") is indeed "8".  This seems to indicate that the LNK file was created on an older platform.

Skipping past the encoded Powershell command, we see a couple of times of interest.  First, the PropertyStoreDataBlock (below):

***PropertyStoreDataBlock***
GUID/ID pairs:
{0c570607-0396-43de-9d61-e321d7df5026}/3
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
   SID: S-1-5-21-3345294922-2424827061-887656146-1000
{dabd30ed-0043-4789-a7f8-d013a4736622}/100
{b725f130-47ef-101a-a5f1-02608c9eebac}/10
{28636aa6-953d-11d2-b5d6-00c04fd918d0}/30

Okay, this LNK file has 5 items in this data block, which is unusual in itself.  We see the SID, which as with the LNK file from the Carbon Black post, is for a user account.  We also see a number of other GUID/ID pairs, as well, and I think that this may be the result of the EnableTargetMetadata flag having been set in the LNK file.  I say this because if you read the description of the flag (here), it says:

The shell link attempts to collect target properties and store them in the PropertyStoreDataBlock (section 2.5.7) when the link target is set.

I'm not 100% clear on what this means, but it seems to say that target properties are stored when the target of the LNK file is "set".  I guess maybe another question to consider is, was the flag specifically set, and if so, what tool or application was used to create the LNK file?

Moving on, we see that this particular LNK file has a code page value identified in the metadata, as shown below:

***ConsoleFEDataBlock***
Code page: 936

The code page is identified as "simplified Chinese", which makes sense because the campaign was thought to have a Chinese nexus.  However, what I have to wonder is how many times a code page is seen within LNK files.  For example, neither of the LNK files discussed here appeared to contain code pages.  I rarely see write-ups that mention LNK files that also mention a code page entry.

Is it possible that this field was modified as a "false flag" or "red herring"?  Sure.  When looking at any single metadata field with a file structure in isolation, the possibility exists that it was modified.  We've seen evidence, just in this blog post, of either a manufacturing process that creates the files in the state that we see them, or an "after market" process that removes the missing elements from the file structure.  But what we're not seeing is the exploration of these findings in the context of the larger campaign.  Are the actors creating other "false flags"?  If so, how pervasive are they?  Are the LNK file elements linked to other campaigns, possibly even ones associated with different actors?

Finally, the TrackerDataBlock contains a machine ID of "john-win764".  Used in conjunction with the SID and volume serial number (in this case, "CC9C-E694"), a VirusTotal retro-hunt might turn up other examples of similar LNK files.

Final Thoughts
Some thoughts come to mind as a result of looking at these files.  First off, there's a good bit of metadata that can be used to do research on campaigns, particularly through individual archives, as well as VirusTotal (re: retro-hunt).

I know some folks have said, "...yeah, but it's easy to change those fields...".  Sure, I agree to an extent, but there would be a 'cost' associated with that.  The Proofpoint team addressed this in their post.  However, what I'm referring to is parsing files already collected, ones that have been archived by teams following the campaigns and collecting data, or are available from other archival sources (VirusTotal, etc.).  If those files are tied to specific campaigns, or attributed to specific actors, then you may have something there.  Not only can you see if and how the files have changed over time (like the FireEye folks did), but what if LNK files with similar metadata appear across different campaigns, and are used by different actors?  What does that tell us?

Further, what this sort of analysis shows is that there's a lot going on underneath the MITRE ATT&CK technique, specifically, "Initial Access, Spearphishing Attachment".  In fact, quite a few sub-techniques and even specific technical details seem to pop right out.  Just look at what we've seen so far; some LNK files are sent as attachments themselves, but in other cases, the LNK files are embedded in a lure document.  Embedded commands differ (WMIC, Powershell, etc.), as does the level of obfuscation and encoding. Some LNK files contain embedded commands with some serious obfuscation, while some contain no obfuscation whatsoever.  We could create an entire matrix just for weaponized attachments.

The JPCERT/CC article described some work done in clustering LNK files based on some of the available metadata around different attacks, which was very interesting.

Additional Resources
FireEye blog post, re: FIN7 - mentions LNK "toolmarks"
PodCast with Nick Carr, discussing "toolmarks"
2018 NCSC Advisory - discusses not only the use of iconfilename fields in LNK files to maintain persistence across password changes, but also includes a very basic Yara rule for detecting the 'weaponized' LNK file (I should note that none of the metadata was shared)

There Are Four Lights: LNK Parsing tools

Based on the content of my last post regarding shell items, I wanted to take a look at some of the available tools for parsing Windows shortcuts/LNK files.  I started by asking folks what tools they used to parse LNK files, and then went looking for those, and other, tools.

The purpose of this blog post is to take a look at how effective some of the various tools used by analysts are at parsing shell item ID lists within Windows shortcut/LNK files.

This blog post contains an excellent description of what we're looking for and trying to achieve with the testing.

My previous post includes sample output from the tool I use to parse LNK files; one of the files I used for testing is an LNK file for a device that does not contain a LinkInfo block, but instead contains ONLY a shell item ID list.  I did not specifically craft this LNK file...it was taking from a Windows 2008 R2 system.  I copied this file to my desktop, and changed the extension from ".lnk" to ".txt".

For comparison purposes, the script I wrote parses the device test file as follows:

File: c:\users\harlan\desktop\camera.txt
shitemidlist       My Computer/DROID2/Removable Storage/dcim/Camera

The other file I used in this testing is an LNK file created by the installation of Google Chrome.  All of the tools tested handled parsing this LNK file just fine, although not all of them parsed the shell item ID list.

Now, on to the tools themselves.  Some of the things I'm most interested in when looking at tools for parsing LNK files include completeness/correctness of output, ease of use, the ease with which I can incorporate the output into my analysis processes, etc.  I know that some of these aspects may mean different things to different people...for example, if you're not familiar with parsing shell item ID lists, how do you determine completeness/correctness?  Also, "ease of use" may mean "GUI" to some, but it may mean "CSV output" to others.  As such, I opted to not give any recommendations or ratings, but to instead just provide what I saw in the output from each tool.

TZWorks lp64 v0.55 - lp64 (the 64-bit version of the tool) handled the Google Chrome LNK file easily, as did the other tools included in this test.  Unlike some of the other tools, lp64 parsed the shell item ID list from the LNK file:

ID List:  {CLSID_UsersFiles}\Local\Google\Chrome\Application\chrome.exe

For the device test file described above, lp64 provided the following output:

ID List:  {CLSID_MyComputer}\{2006014e-0831-0003-0000-000000000000}

I'm not sure what the GUID refers to...I did a look up via Google and didn't find anything that would really give me an indication of what that meant.  Looking at the file itself in a hex editor (i.e., UltraEdit), I can see from where that data originated, and I can tell that the shell item was not parsed correctly; that is to say, the 16 bytes extracted from the file are NOT a GUID, yet lp64 parses them as such.

WoanWare LnkAnalyser v1.01 - This tool is a CLI utility that took me a couple of attempts to run, first because I had typed "lnkanalyzer" instead of "lnkanalyser".  ;-)  I then pointed it at the camera.txt file from the previous post (renamed from camera.lnk) and it did not display any shell item contents.  In fact, the tool listed several sections (i.e., Target Metadata, Volume ID, TrackerDataBlock, etc.), all of which were empty, with the exception of the time stamps, which were listed as "1/1/0001 12:00:00 AM".

LnkAnalyser did handle the Google Chrome LNK file just fine, but without parsing the shell item ID list.

Lnk_parser - The Google Code page states that this tool is "in beta" and should not be rehosted...I opted to include it in testing.  It turns out that this tool is very interactive (which I could have avoided, had I read the command line usage instructions), posting a list of questions to the console for the analyst to answer, with respect to where the target file is located, the type of output that you want, and where you want the output to go.  I chose CSV output, going to the current working directory, as well as to the console.  The output of the tool did include:

[Link Target ID List]
CLSID:    20d04fe0-3aea-1069-a2d8-08002b30309d = My Computer

This was followed by a number of "[Property Store]" entries that made little sense; that is to say, I am familiar with what these entries might represent from my research, but the data that they contain doesn't look as it would be meaningful or usable to an analyst.   I did find a reference to one of the PROPERTYSTORAGE values from the lnk_parser output listed in the Cloud Storage Forensic Analysis PDF, reportedly as part of the output from XWays 16.5, but I'm not clear as to what it refers to.

Lnk_parser did not handle the Google Chrome LNK file at all.  I used the same settings/choices as I did for the previous file, and got no output the console.  The resulting CSV file in the working directory had only one entry, and it was just some garbled data.

MiTeC Windows File Analyzer (WFA) - LNK files are just one of the file formats that WFA is capable of parsing.  WFA is GUI-based and works on directories (rather than individual files), so I had to rename the camera.txt file to camera.lnk.  WFA did not parse any data from the camera.lnk file, although it handled the Google Chrome LNK file just fine.  WFA did not, however, parse the shell item ID list from the Google Chrome LNK file.

Log2Timeline - a user over on the Win4n6 forum mentioned that log2timeline parses shell item ID lists in LNK files, but I verified with Kristinn that at the moment, it does not.  As such, log2timeline was not included in the test.  I am including it in this listing simply due to the fact that someone had mentioned that it does parse shell item ID lists.

Other tools - some others have mentioned using EnCase 6 and/or 7 for parsing LNK files; I do not have access to either one, so I cannot test them.

Results
The overall results of my (admittedly limited) testing indicates that the TZWorks lp64 tool does the best job of the available tools when it comes to parsing shell item ID lists within LNK files.  That being said, however, some shell items do not appear to be parsed correctly.

On a side note, something that I do like about lp64 is that it lists it's output in an easy-to-parse format.  Each element is listed on a single line with an element ID, a colon, and then the data...this makes it easy to parse using Perl or Python.

So What?
So, why is this important?  After all, who cares?  Well, to be honest, every analyst should, for the simple fact that shell items can be found in a number of artifacts besides just Windows LNK files.  They exist in shellbags artifacts, within the MenuOrder subkeys, they're embedded within Windows 7 and 8 Jump Lists, ComDlg32 subkey values (Vista+), and they can even be found in the Windows 8 Photo artifacts.  Being able to understand shell items can be important, and being able to correctly parse device shell items can be even more important; in CP cases, the use of devices may indicate production, and in IP theft cases, a device may have been used as the target of a copy or move operation.  Also, there is malware that is known to use specially-constructed LNK files (ie, target.lnk) as part of their infection/propagation mechanism, so being able to accurately parse these files will be valuable to the malware threat analysis.

Resources
ForensicsWiki page - LNK
LinuxSleuthing blog post

What's the value of data, and who decides?

A question that I've been wrestling with lately is, for a DFIR analyst, what is the value of data?  Perhaps more importantly, who decides the value of available data?

Is it the client, when they state what their goals, what they're looking for from the examination?  Or is it the analyst who interprets both the goals and the data, applying the latter to the former?

Okay, let me take a step back...this isn't the only time I've wrestled with this question. In fact, if you look here, you'll see that this is a question that has popped up in this blog before.  There have been instances over the past almost two decades of doing infosec work that I, and others, have tussled with the question, in one form or another.  And I do think that this is an important question to turn to and discuss time and again, not specifically to seek an answer from one person, but for all of us to share our thoughts and hear what others have to say and offer to the discussion.

Now, back to the question...who determines the relative value of data during an examination?  Let's take a simple example; a client has an image of an employee's laptop (running Windows 7 SP1), and they have a question that they would like answered.  That question could be, "Is/was the system infected with malware?", or "...did the employee perform actions in violation of acceptable use policies?", or "...is there evidence that data (PII, PHI, PFI, etc.) had been exfiltrated from the system?"  The analyst receives the image, and runs through their normal in-processing procedures, and at that point, they have a potential wealth of information available to them; Prefetch files, Registry data, autoruns entries, the contents of various files (hosts, OBJECTS.DATA, qmgr0.dat, etc.), Windows Event Log records, the hibernation file, etc.

Just to be clear...I'm not suggesting an answer to the question.  Rather, I'm putting the question out there for discussion, because I firmly believe that it's important for us, as a profession, to return to this question on a regular basis. Whether we're analyzing individual images, or performing enterprise incident response, I tend to think that sometimes we can get caught up in the work itself, and every now and then it's a good idea to take a moment and do a level set.

Data Interpretation
An issue that I see analysts struggling with is the interpretation of the data that they have available.  A specific example is what is referred to as the Shim Cache data.  Here are a couple of resources that describe what this data is, as well as the value of this data:

Mandiant whitepaper, 2012
Mandiant Presentation, 2013
FireEye blog post, 2015

The issue I've seen analysts at all levels (new examiners, experienced analysts, professional DFIR instructors) struggling with is in the interpretation of this data; specifically, updates to clients (as well as reports of analysis provided to a court of law) will very often refer to the time stamp associated with the data as indicating the date of execution of the resource.  I've seen reports and even heard analysts state that the time stamp associated with a particular entry indicates when that file was executed, even though there is considerable documentation readily available, online and through training courses, that states that this is, in fact, NOT the case.

Data interpretation is not simply an issue with this one artifact.  Very often, we'll look at an artifact or indicator in isolation, outside and separate from its context with respect to other data "near" it in some manner.  Doing so can be extremely detrimental, leading an analyst down the wrong road, down a rabbit hole and away from the real issue at hand.

GETALLTHETHINGS
The question then becomes, if we, as a community and a profession, do not have a solid grasp of the value and correct interpretation of the data that we do have available to us now, is it necessarily a good idea to continue adding even more data for which we may not have even a passing understanding?

Lately, there has been considerable discussion of shell items on Windows systems.  Eric's discussed the topic on his BinForay blog, and David Cowen recently conducted a SANS webcast on the topic.  Now, shell items are not a new topic at all...they've been discussed previously within the community, including within this blog (here, and here).  Needless to say, it's been known within the DFIR community for some time that shell items are the building blocks (in part, or in whole) for a number of Windows artifacts, including (but not limited to) Windows shortcut/*.lnk files, Jump Lists, as well as a number of Registry values.

Now, I'm not suggesting that we stop discussing shell items; in fact, I'm suggesting the opposite, that perhaps we don't discuss this stuff nearly enough, as a community or profession.

Circling back to the original premise for this post, how valuable is ALL the data available from shell items?  Yes, we know that when looking at a user's shellbag artifacts, we can potentially see a considerable number of time stamps associated with a particular entry...an MRU time, several DOSDATE time stamps, and maybe even an NTFS MFT sequence number.  All, or most, of this can be available along with a string that provides the path to an accessed resource.  Further, in many cases, this same information can be derived from other data sources that are comprised of shell items, such as Windows shortcut files (and by association, Jump Lists), not to mention a wide range of Registry values.

Many analysts have said that they want to see ALL of the available data, and make a decision as to its relative value.  But at what point is ALL the data TOO MUCH data for an analyst?  There has to be some point where the currently available data is not being interpreted correctly, and adding even more misunderstood/misinterpreted data is detrimental the analyst, to the case, and most importantly, to the client.

Reporting
Let's look at another example; a client comes to you with a Windows server system, says that the system appears to have been infected with ransomware a week prior, and wants to know the source of the infection; how did the ransomware get on the system in the first place?  At this point, you have what the client's looking for, and you also have a time frame on which to focus your examination. During your analysis, you determine the initial infection vector (IIV) for the ransomware, which appeared to have been placed on the system by someone who'd subverted the system's remote access capability.  However, during your examination, you also notice that 9 months prior to the ransomware infection, another bit of malware seemed to have infected the system, possibly due to a user's errant web surfing.  And you also see that about 5 months prior to that, there were possible indications of yet another malware infection of some kind.  However, having occurred over a year ago, the IIV and any impact of the infection is indeterminate.

The question is now, do you provide all of this to the client?  If the client asked a specific question, do you potentially bury that answer in all of your findings?  Perhaps more importantly, when you do share all of your findings with them, do you then bill them for the time it took to get to that point?  What if the client comes back and says, "...we asked you to answer question A, which you did; however, you also answered several other questions that we didn't ask, and we don't feel that we should pay for the time it took to do that analysis, because we didn't ask for it."

If a client asks you a specific question, to determine the access vector of a ransomware infection, do you then proceed to locate and report all of the potential malware infections (generic Trojans, BHOs, ect.) you could find, as well as a list of vulnerable, out-of-date software packages?

Again, I'm not suggesting that any of what I've described is right or wrong; rather, I'm offering this up for discussion.

There are FOUR lights!

Okay, you're probably wondering what Picard and one particular episode of Star Trek TNG has to do with forensicating.  Well, to put it quite simply...everything!

I recently posted the question in a forum regarding Shellbag analysis, and asked who was actually performing it as part of their exams.  One answer I got was, "...I need to start."  When I asked this same question at the PFIC 2012 conference of a roomful of forensicators, two raised their hands...and one admitted that they hadn't done so since SANS training.

I've seen during exams where the shellbags contain artifacts of user activity that are not found anywhere else on the system.  For example, I've seen the use Windows Explorer to perform FTP transfers (my publisher used to have me do this to transfer files), where artifacts of that activity were not found anywhere else on the system.  When this information was added to a timeline, a significant portion of the exam sort of snapped into place, and became crystal clear.

Something I've seen with respect to USB devices that were connected to Windows systems is that our traditional methodologies for parsing this information out of a system are perhaps...incomplete.  I have seen systems where some devices are not so much identified as USB storage devices by Windows systems (rather, they're identified as portable devices...iPods, digital cameras, etc.), and as such, starting by examining the USBStor subkeys means that we may miss some of these devices that could be used in intellectual property theft, as well as the creation and trafficking of illicit images.  Yet, I have seen clear indications of a user's access to these devices within the shellbags artifacts, in part because of my familiarity with the actual data structures themselves.

The creation and use of these artifacts by the Windows operating system goes well beyond just the shellbags, as these artifacts are comprised of data structures known as "shell items", which can themselves be chained together into "shell item ID lists".  Rather than providing a path that consists of several ASCII strings that identify resources such as files and directories, a shell item ID list builds a path to a resource using these data structures, which some in the community have worked very hard to decipher.  What this work has demonstrated is that there is a great deal more information available than most analysts are aware.

So why is understanding shell items and shell item ID lists important? Most of the available tools for parsing shellbags, for example, simply show the analyst the path to the resource, but never identify the data structure in question...they simply provide the ASCII representation to the analyst.  These structures are used in the ComDlg32 subkey values in the NTUSER.DAT hive on Windows Vista and above systems, as well as in the IE Start Menu and Favorites artifacts within the Registry.  An interesting quote from the post:

Of importance to the forensic investigator is the fact that, in many cases, these subkeys and their respective Order values retain references to Start Menu and Favorites items after the related applications or favorites have been uninstalled or deleted.

I added the emphasis to the second half of the quote, because it's important.  Much like other artifacts that are available, references to files, folders, network resources and even applications are retained long after they've been uninstalled or deleted.  So understanding shell items are foundational to understanding larger artifacts.

But doesn't stop with the Registry...shell item ID lists are part of Windows shortcut (LNK) files, which means that they're also part of the Jump Lists found on Windows 7 and 8.

Okay, but so what, right?  Well, the SpiderLabs folks posted a very interesting use of LNK files to gather credentials during a pen test; have any forensic analysts out there seen the use of this technique before?  Perhaps more importantly, have you looked for it?  Would you know how to look for this during an exam?

Here's a really good post that goes into some detail regarding how LNK files can be manipulated with malicious intent, demonstrating how important it is to parse the shell item ID lists.

So, the point of the graphic, as well as of the post overall, is this...if you're NOT parsing shellbags as part of your exam, and if you're NOT parsing through shortcut files as part of your root cause analysis (RCA), then you're only seeing three lights.

There are, in fact, four lights.

Resources
DOSDate Time Stamps in Shell Items
ShellBag Analysis, Revisited...Some Testing

Shell Item Artifacts, Reloaded

I spoke on David Cowen and crew's Forensic Lunch a bit ago, on the topic of shell item artifacts.  I put together some slides at the last moment to use as visual references for the discussion, to illustrate what I'd done with respect to digging into the talk a bit more.  The slides

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 example that we're using is for a shell item that points to the D:\cases folder, with the key path Shell\BagMRU\1\2\18.  As you can see in figure 1, I've boxed the DOSDate times in yellow; the MFT file reference number is marked in colored text, with the MFT record entry (i.e., 45) in red, and the sequence number (i.e., 13) in green.  I highlighted these values, as we'll be using them in the rest of our examination.

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.

A Minimal LNK

Yeah, so I've written about LNK files before, but I wanted to take it a step further and explore just how much of the specification is required for a functioning LNK file.

Step 1
I used VBS to create a "bare-bones" LNK to run calc.exe.  I like to have something visual when testing this sort of thing.

The resulting LNK file is 890 bytes in size, and here's what the metadata for the file looks like:

guid               {00021401-0000-0000-c000-000000000046}
mtime              Wed Apr 11 23:34:36 2018 Z
atime              Wed Apr 11 23:34:36 2018 Z
ctime              Wed Apr 11 23:34:36 2018 Z
basepath           C:\Windows\System32\calc.exe
shitemidlist       My Computer/C:\/Windows/System32/calc.exe
**Shell Items Details (times in UTC)**
  C:2018-04-11 21:04:34  M:2018-10-11 21:39:08  A:2018-10-11 21:39:08 Windows (9)
  C:2018-04-11 21:04:34  M:2018-12-20 22:46:22  A:2018-12-20 22:46:22 System32 (9)
  C:2018-04-11 23:34:38  M:2018-04-11 23:34:38  A:2018-04-11 23:34:38 calc.exe (9)
vol_sn              22D3-06AE
vol_type           Fixed Disk
hotkey              0x14
showcmd          0x4

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasLinkInfo|HasRelativePath

***PropertyStoreDataBlock***
GUID/ID pairs:
{446d16b1-8dad-4870-a748-402ea43d788c}/104
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       SID: S-1-5-21-3855314428-4085452759-4066589348-1000

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

***TrackerDataBlock***
Machine ID                   : enzo
New Droid ID Time        : Tue Sep 18 10:39:24 2018 UTC
New Droid ID Seq Num  : 7175
New Droid    Node ID     : 5c:26:0a:24:29:6f
Birth Droid ID Time       : Tue Sep 18 10:39:24 2018 UTC
Birth Droid ID Seq Num : 7175
Birth Droid Node ID       : 5c:26:0a:24:29:6f

Okay, that is a LOT of stuff that's created in an LNK file, based on the following .vbs script:

set w = CreateObject("Wscript.shell")
set l = w.CreateShortcut("\foo2.lnk")
l.TargetPath = "c:\windows\system32\calc.exe"
l.Save

Step 2
Write code that creates a bare-bones LNK file header.  By "bare-bones", I mean one with the time stamps and any extraneous metadata zero'd out.

Step 3
Write code that goes to the LNK file created in step 1, and strips out just the linktargetIDlist, or "shell item ID list".  Zero out all of the time stamps in the shell items, and just for giggles, change the version value within the shell items.  Append this linktargetIDlist to the header created in step 2.

The resulting LNK file appears below:

The LNK file is 389 bytes in size, and functions perfectly well, no matter where I put it within the file system.  I double-click it, it launches the Calculator, as expected. 

However, this is what the metadata now looks like:

guid               {00021401-0000-0000-c000-000000000046}
shitemidlist       My Computer/C:\/Windows/System32 /calc.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows (10)
  C:0                   M:0                   A:0                  System32  (10)
  C:0                   M:0                   A:0                  calc.exe  (10)
hotkey             0x0
showcmd         0x1

***LinkFlags***
HasLinkTargetIDList|IsUnicode

The result of this process is a functioning LNK file with minimal metadata.  No disk or volume info, no SID, no MAC address, none of the things we'd look for when analyzing a weaponized LNK file.

I put some of what was used in the creation of these LNK files on GitHub.