HowTo: Tie LNK Files to a Device

Based on commentary I've seen in a couple of online forums, I thought I'd resurrect the "HowTo" label from some previous blog posts, and share (for commentary, feedback and improvement) some of the analysis processes that I've used while examining images of Windows systems.  There is a good deal of information available regarding various Windows artifacts, and one of perhaps the most difficult aspects of analysis is to tie various disparate bits of information together, correlating the artifacts, and building a complete picture so that your analysis can be used to answer questions and provide solutions.

This particular topic was previously discussed in this blog (and here's another, much older post), but sometimes processes like this need to be revisited.  Before we start, however, it's important to point out that this process will work only on Windows Vista systems and above, due to the information that is required for the process to work properly.

LNK Files
A Windows shortcut/LNK file can contain volume serial number, or VSNs.  This is intended to be a unique 4-byte (DWORD) value that identifies the volume, and is changed when the volume is reformatted.  Many tools that parse LNK files will display the VSN in their output, if one exists.

Note: Prefetch files include a volume information block which also contains a VSN.  If this information is different from the local system...that is, if a user launched an application from an external storage device...you can also use this process to correlate the VSN to the particular device.  You can view the VSN for a volume on a live system by navigating to the volume via the command prompt and typing the 'vol' command.

Registry
The EMDMgmt key (within the Software hive) contains information about USB external devices connected to the system.  This information is generated and used by the ReadyBoost service, at least in part to determine the suitability of the device for use as external RAM.

The path to the key in question is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key will contain subkeys that pertain to and describe external storage media.  The subkeys that we're interested in are those that begin with "_??_USBSTOR#".  These subkey names are very similar to artifacts found in the System hive, particularly in the USBStor subkeys.  These subkey names include device serial number, as well a volume name (if one exists) and a VSN in decimal format.

An example of such a subkey name, with the VSN in bold, appears as follows:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}TEST_1677970716

For those subkeys that pertain to USB thumb drives, the emdmgmt.pl RegRipper plugin will parse the subkey name, and display the VSN formatted in a usable, understandable manner.  That is to say that the plugin will translate the decimal value for the VSN into a hexidecimal format, and display it in the same manner as the VSN seen in LNK and Prefetch files, as well as what is displayed by the vol command on live systems.

Again, it is important to note the EMDMgmt key exists on Vista systems and above, but not on XP systems. As such, this technique will not work for XP/2003 systems.

Now that we have these two pieces of information, we can correlate LNK files (or Prefetch files, if necessary) to a particular device, based on the VSNs.  I've used this technique a number of times, most recently in an attempt to determine a user's access to a particular device (remember, LNK files are most often associated with a user, as they are often located within the user's profile).  If you know what it is that you're attempting to determine or demonstrate...that is, the goals of your analysis...then the tools and artifacts tend to fall right into place.  When I've had to perform this type of correlation of artifacts, because of the tools I have available, this analysis is complete in just a few minutes.

As a final note, do not forget the value of historical information on the system, particularly for the Registry.  The RegBack folder should contain a backed-up copy of the Software hive, and there is additional information available in VSCs.  Corey Harrell has a number of excellent posts on his blog that demonstrate how to use simple tools and processes...batch files...to exploit the information available in VSCs.

Resources
MS-SHLLINK file format specification
Description of EMDMgmt RegRipper plugin

Crossing Streams

Sometimes, crossing the streams can be a good thing.  I was checking out some of the new posts on my RSS feed recently, and saw SQLite on the Case over on the LinuxSleuthing blog.

I'm not an anti-Linux, Windows-only guy.  I'm just a guy who's used Windows, done vulnerability assessments of Windows systems, and been asked to do IR and forensic analysis of Windows systems for a long time.  I also like looking in other places for something I can use to make my job easier, progress more smoothly, and allow me to perform a more comprehensive analysis of Windows systems.  Because you can find SQLite databases on Windows systems (usually associated with a third-party application, such as Firefox or Chrome, or found in iDevice backups), I like to see what's out there in the DFIR community with respect to this database structure, and the LinuxSleuthing blog has been both generous and valuable in that regard.

The blog as a whole, and this post specifically, contains a lot of great info, but this time, it wasn't the technical info within the post that caught my attention...it was something of a crossing of the streams.  What I mean by that is that I saw a couple of statements in the post that reminded me of things I'd said in my own blog, and it was as if two different people, with different backgrounds, interests, etc., were following the same (or very similar) reasoning.  

The first statement:

It is very common in SQLite databases for integers to represent a deeper meaning than their numeric value. 

This sentence took me back to my post on understanding data structures.  Much like many of the data structures on Windows systems, the SQLite table in question has a column that contains integers, which must be translated in order to be meaningful to the analyst.  Either the analyst does this automatically, or a software tool, which provides a layer of abstraction over the raw data, does it for us.  In this case, "4" refers to an "incoming" call...that's important because doing a text-based keyword search for "incoming" won't reveal anything directly pertinent to the table or column in question.  

In the case of Windows systems, a 4 byte DWORD value might be an identifier, providing information regarding the type of something, or it might be a flag value, containing multiple settings AND'd together.  Our tools tend to provide a layer of abstraction over the data, and many will translate the integers to their corresponding human-readable values.  As such, it is important that we understand the data structure and it's constituent elements, rather than simply relying on tools to spit out the data for us, as this helps us better understand the context of the data that we're looking at.  

Consider the DOSDate time stamps found embedded in some shell items...what do they represent, and where do they come from?  Okay, we have something of an understanding of what they represent - the MAC times of the target resource (folder, file usually).  If the file system in which the target resource resides is NTFS, we know that the values start as FILETIME objects with 100 nanosecond granularity, are truncated to the second, and then (per the publicly available MS API), the second value is multiplied by 2.  So, an NTFS time value of "23:15:05.657" becomes "23:15:10", and we have a considerable loss of granularity.  We also know that the embedded time stamps are a snapshot in time, and that the resources can be impacted by actions outside the purview of the shell items.  For example, after a shell item ID list within an LNK file is created, files can be added to or deleted from one of the constituent folders, updating the last modification time.  Finally, of what value is the last accessed time on Vista and above systems?

So, my (rather long winded) point is that when we see a date/time stamp labeled "last access time" in the output of a tool, do we really understand the context of that integer value?

Okay, on to the second statement...

If you thought use another tool and see what it says then go outside and drag your knuckles on the concrete for a bit.

This statement reminded me on my thoughts on what I refer to as the tool validation "myth-odology".  

Consider another recent blog post regarding LNK file parsing tools; in that post, I described the issue I wanted to test for, and then after querying a forum for the tools folks currently used to parse these files, I ran several of them against some test data.  In this case, my goal was to see which of the tools correctly parsed shell item ID lists within the LNK files.  Given this goal, would you download a tool that does NOT parse/display the shell item ID list in an LNK file, and use it to validate the output of other tools?

Here's the issue...many of the tools recommended for parsing LNK files parse only the header and LinkInfo block, and not the shell item ID list.  Some that do parse the shell item ID lists do not appear to do so correctly.  The shell item data structures are not isolated to just LNK files, they're actually pretty pervasive on Windows systems, but I chose to start with LNK files as they've been around for a lot longer than other artifacts, and tools for parsing them might be more mature.  

So, why the interest in shell item ID lists?  Well, in most normal cases, the shell item ID lists might simply provide redundant information, replicating what's seen in the LinkInfo block.  However, there are legitimate cases where Windows will create an LNK file for a device (smart phone, digital camera, etc.) that consists solely of a header and a shell item ID list, and does not contain a LinkInfo block.  Not being able to accurately parse these LNK files can present an issue to IP theft (devices are great at storing files) and illicit images cases (might mean the difference between possession and production).  Also, there is malware out there that uses specially-crafted LNK files (i.e., "target.lnk") as a propagation mechanism.  

Given all this, if someone wants to use the output of a tool that does not parse the shell item ID list of an LNK file to validate the output of another tool, I think the above imagery of "drag your knuckles" is appropriate.  ;-)  Just sayin'.  

Reading

I wanted to share some of the interesting items I've read over the passed couple of weeks, and in doing so, I think that it's important to share not just that it was read, but to also share any insights gleaned from the material.  It's one thing to provide a bunch of links...it's another thing entirely to share the impact that the material had on your thinking, and what insights you might have had.  I see this a good deal, not just in the DFIR community...someone posts links to material that they have read, as if to say, "hey, click on this and read it...", but don't share their insights as to why someone should do that.  If something is of value, I think that a quick synopsis of why it's of value would be useful to folks.

I look at it this way...have you ever looked up a restaurant on Yelp to read the reviews, and used what you saw to decide whether you wanted to go or not?  Or have you ever look at reviews of movies in order to decide if you wanted to spend the money to see it in the theater now, or just wait until it hits the cable system, where you can see it for $5?  That's the approach I'm taking with this post...

Anyway, onward...

The Needs of the Many - this is an excellent blog post that presents and discusses the characteristics of servant security leader.

This is an excellent read, not just for those seeking to understand how to be a servant leader, but also for the any Star Trek fan, as Andrew uses not just quotes from the series and movies, but also uses scenes as metaphors for the topic.  It's one thing to write a paragraph and add a Wikipedia link for reference, but it's another thing entirely to use iconic movie characters and scenes to illustrate a point, such as three-dimensional thinking, giving the reader that, "oh, yeah" moment.

Survivorship Bias - this blog post was an excellent read that really opened my eyes to how we tend to view our efforts in tool testing, as well as in analysis.

A quote from the article that really caught my attention is:

Failure to look for what is missing is a common shortcoming, not just within yourself but also within the institutions that surround you.

This is very true in a lot of ways, especially within the DFIR community, which is the "institution" in the quote.  Training courses (vendor-specific and otherwise) tend to talk a lot about tools, and as such, many analysts focus on tools, rather than the analysis process.  Some analysts will use tools endorsed by others, never asking if the tools have been tested or validated, and simply trusting that they have been.  In other cases, analysts will use one tool to validate the output of another tool, without ever understanding the underlying data structures being parsed...this is what I refer to as the tool validation "myth-odology".

This focus on tools is taking analysts away from where they need to be focused...which should be on the analysis process.  I've seen analysts say that the tools allow non-experts to be useful, but how useful are they if there is no understanding of what the tool is parsing, or how the tools does what it does?  A non-expert finding a piece of "evidence" at a physical crime scene will not know to provide the context of that evidence, and the same is true in the digital realm, as well.  Tools should not be viewed as "making non-experts useful".  Again, this is part of the "institution".

What I've seen this lead to is the repeated endorsement and use of tools that do not completely parse data structures, and do not provide any indication that they have not parsed those structures.  As the tools are endorsed by "experts", and analysts find just those things that they are looking for (that "survivorship bias", where failures are not considered) the tools continue to be used, and this is something that appears to be institutional rather than an isolated, individual problem.

If you have the time, I highly recommend reading through other posts at the YouAreNotSoSmart blog.  There are some really good posts there that are definitely worth your time to not just read, but consider and ingest.  I'm a firm believer that anyone who wants to progress in a field needs to regularly seek knowledge outside of that field, and this is a good place to spend some time doing just that.

Paul Melson: GrrCON 2012 Forensic Challenge Write-up - Folks seem to really like stories about how others accomplished something...Paul provides how he answered the GrrCON 2012 Forensic Challenge.  This is actually from the end of last year, but that's fine...everything he did still holds. Paul walks through the entire process used, describing the tools used, providing command lines, and illustrating the output.  If you attempted this challenge, compare what you did to what Paul provided.

Within the DFIR community especially, I've found that analysts really tend to enjoy reading about or hearing how others have gone about solving problems.  However, one of the shortcomings of the community is that not a lot of folks within it like to share how they've gone about solving problems.  I know that last year, a friend of mine tried to set up a web site where folks could share those stories, but it never got off the ground.  It's unfortunate...none of us alone is as smart as all of us together, and there is a lot of great information sitting out there, untapped and unused, because we aren't willing or able to share it.

Digital Forensics Stream: Amazon Cloud Drive Forensics, pt I - Similar to Paul's post, this DFStream blog post wasn't about a challenge, but it did provide an end-to-end walk through of an important aspect of analysis...testing.  With the rise of cloud services, and an increased discussion of their use, one of the aspects that analysts will have to contend with is the use of desktop applications for accessing these services.  Access to these services are being built into platforms, and their use is going to become more transparent (to the user) over time.  As such, analysts are going to need to have an understanding of the effect of these applications on the systems being analyzed, and many analysts are in fact already asking those questions...and this post provides some answers.

GSN: Computer forensics experts discover how to determine how many times a hard drive had been turned on, and for how many hours it had run.  Very interesting find within the SMART info of some drives, this can definitely be useful.

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

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.