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