LNK Builders

I've blogged a bit...okay, a LOT...over the years on the topic of parsing LNK files, but a subject I really haven't touched on is LNK builders or generators. This is actually an interesting topic because it ties into the cybercrime economy quite nicely. What that means is that there are "initial access brokers", or "IABs", who gain and sell access to systems, and there are "RaaS" or "ransomware-as-a-service" operators who will provide ransomware EXEs and infrastructure, for a price. There are a number of other for-pay services, one of which is LNK builders.

In March, 2020, the Checkpoint Research team published an article regarding the mLNK builder, which at the time was version 2.2. Reading through the article, you can see that the building includes a great deal of functionality, there's even a pricing table. Late in July, 2022, Acronis shared a YouTube video describing how version 4.2 of the mLNK builder available.

In March, 2022, the Google TAG published an article regarding the "Exotic Lily" IAB, describing (among other things) their use of LNK files, and including some toolmarks (drive serial number, machine ID) extracted from LNK metadata. Searching Twitter for "#exoticlily" returns a number of references that may lead to LNK samples embedded in archives or ISO files. 

In June, 2022, Cyble published an article regarding the Quantum LNK builder, which also includes features and pricing scheme for the builder. The article indicates a possible connection between the Lazarus group and the Quantum LNK builder; similarities in Powershell scripts may indicate this connection.

In August, 2022, SentinelLabs published an article that mentioned both the mLNK and Quantum builders. This is not to suggest that these are the only LNK builders or generators available, but it does speak to the prevalence of this "*-as-a-service" offering, particularly as some threat actors move away from the use of "weaponized" (via macros) Office documents, and toward the use of archives, ISO/IMG files, and embedded LNK files.

Freeware Options
In addition to creating shortcuts through the traditional means (i.e., right-clicking in a folder, etc.), there are a number of freely available tools that allow you to create malicious LNK files. However, from looking at them, there's little available to indicate that they provide the same breadth of capabilities as the for-pay options listed earlier in this article. Here's some of the options I found:

lnk-generator (circa 2017)
Booby-trapped shortcut (circa 2017) - includes script
LNKUp (circa 2017) - LNK data exfil payload generator
lnk-kisser (circa 2019) - payload generator
pylnk3 (circa 2020) - read/write LNK files in Python
SharpLNKGen-UI (circa 2021) - expert mode includes use of ADSs (Github)
Haxx generator (circa 2022) - free download
lnkbomb - Python source, EXE provided
lnk2pwn (circa 2018) - EXE provided
embed_exe_lnk - embed EXE in LNK, sample provided 

Next Steps
So, what's missing in all this is toolmarks; with all these options, what does the metadata from malicious LNK files created using the builders/generators look like? Is it possible that given a sample or enough samples, we can find toolmarks that allow us to understand which builder was used?

Consider this file, for example, which shows the parsed metadata from several samples (most recent sample begins on line 119). The first two samples, from Mandiant's Cozy Bear article, are very similar; in fact, they have the same volume serial number and machine ID. The third sample, beginning on line 91, has a lot of the information we'd look to use for comparison removed from the LNK file metadata; perhaps the description field could be used instead, along with specific offsets and values from the header (given that the time stamps are zero'd out). In fact, besides zero'd out time stamps, there's the SID embedded in the LNK file, which can be used to narrow down a search.

The final sample is interesting, in that the PropertyStoreDataBlock appears to be well-populated (unlike the previous samples in the file), and contains information that sheds light on the threat actor's development environment.

Perhaps, as time permits, I'll be able to use a common executable (the calculator, Solitaire, etc.), and create LNK files with some of the freeware tools, noting the similarities and differences in metadata/toolmarks. The idea behind this would be to demonstrate the value in exploring file metadata, regardless of the actual file, as a means of understanding the breadth of such things in threat actor campaigns.

Toolmarks: LNK Files in the news again

 As most regular readers of this blog can tell you, I'm a bit of a fan of LNK files...a LNK-o-phile, if you will. I'm not only fascinated by the richness of the structure, but as I began writing a parser for LNK files, I began too see some interesting aspects of intelligence that can be gleaned from LNK files, in particular, those created within a threat actors development environment, and deployed to targets/infrastructures. First, there are different ways to create LNK files using the Windows API, and what's really cool is that each method has it's own unique #toolmarks associated with it!  

Second, most often there is a pretty good amount of metadata embedded in the LNK file structure. There are file system time stamps, and often we'll see a NetBIOS system name, a volume S/N, a SID, or other pieces of information that we can use in a VirusTotal retro-hunt in order to build out a significant history of other similar LNK files.

In the course of my research, I was able to create the smallest possible functioning LNK file, albeit with NO (yes, you read that right...) metadata. Well, that's not 100% true...there is metadata within the LNK file. Specifically, the Windows version identifier is still there, and this is something I purposely left. Instead of zero'ing it out, I altered it to an as-yet-unseen value (in this case, 0x0a). You can also alter each version identifier to their own value, rather than keeping them all the same.

Microsoft recently shared some information about NOBELIUM sending LNK files embedded within ISO files, as did the Volexity team. Both discuss aspects of the NOBELIUM campaign; in fact, they do so in a similar manner, but each with different details. For example, the Volexity team specifically states the following (with respect to the LNK file):

It should be noted that nearly all of the metadata from the LNK file has been removed. Typically, LNK files contain timestamps for creation, modification, and access, as well as information about the device on which they were created.

Now, that's pretty cool! As someone who's put considerable effort into understanding the structure of LNK files, and done research into creating the smallest, minimal, functioning LNK file, this was a pretty interesting statement to read, and I wanted to learn more.

Taking a look at the metadata for the reports.lnk file (from fig 4 in the Microsoft blog post, and fig 3 of the Volexity blog post) we see

guid               {00021401-0000-0000-c000-000000000046}
shitemidlist    My Computer/C:\/Windows/system32/rundll32.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows  (9)
  C:0                   M:0                   A:0                  system32  (9)
  C:0                   M:0                   A:0                  rundll32.exe  (9)

commandline  Documents.dll,Open
iconfilename   %windir%/system32/shell32.dll
hotkey             0x0
showcmd        0x1

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasArguments|HasExpString|HasIconLocation

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4      SID: S-1-5-21-8417294525-741976727-420522995-1001

***EnvironmentVariableDataBlock***
EnvironmentVariableDataBlock: %windir%/system32/explorer.exe

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

While the file system time stamps embedded within the LNK file structure appear to have been zero'd out, a good deal of metadata still exists within the structure itself. For example, the Windows version information (i.e., "9") is still available, as are the contents of several ExtraData blocks. The SID listed in the PropertyStoreDataBlock can be used to search across repositories, looking for other LNK files that contain the same SID. Further, the fact that these blocks still exist in the structure gives us clues as to the process used to create the original LNK file, before the internal structure elements were manipulated.

I'm not sure that this is the first time this sort of thing has happened; after all, the MS blog post makes no mention of metadata being removed from the LNK file, so it's entirely possible that it's happened before but no one's thought that it was important enough to mention. However, items such as ExtraDataBlocks and which elements exist within the structure not only give us clues (toolmarks) as to how the file was created, but the fact that metadata elements were intentionally removed serve as additional toolmarks, and provide insight into the intentions of the actors.

But why use an ISO file? Well, interesting you should ask.  Matt Graeber said:

Adversaries choose ISO/IMG as a delivery vector b/c SmartScreen doesn't apply to non-NTFS volumes

In the ensuring thread, @arekfurt said:

Adversaries can also use the iso trick to put evade MOTW-based macro blocking with Office docs.

Ah, interesting points! The ISO file is downloaded from the Internet, and as such, would likely have a zone identifier ADS associated with it (I say, "likely" because I haven't seen it mentioned as a toolmark), whereas once the ISO file is mounted, the embedded files would not have zone ID ADSs associated with them. So, the decision to use an ISO file was intentional, and not just cool...in fact, it appears to have been intentionally used for defense evasion.

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)

Links: Plugin Updates and Other Things

Plugin Updates
Mari has done some fascinating research into MS Office Trust Records and posted her findings here. Based on her sharing her findings and sample data, I was able to update the trustrecords.pl plugin.  Further, Mari's description of what she had done was so clear and concise that I was able to replicate what she did and generate some of my own sample data.

The last update to the trustrecords.pl plugin was from 16 July 2012; since then, no one's used it or apparently had any issues with it or questions about what it does.  For this update, I added a check for the VBAWarnings value, and added parsing of the last 4 bytes of the TrustRecords value data, printing "Enable Content button clicked" if the data is is in accordance with Mari's findings.  I also changed how the plugin determines which version of Office is installed. I also made sure to update the trustrecords_tln.pl plugin accordingly, as well.

So, from the sample data that Mari provided, the output of the trustrecords.pl plugin looks like this:

**Word**
----------
Security key LastWrite: Wed Feb 24 15:58:02 2016 Z
VBAWarnings = Enable all macros

Wed Feb 24 15:08:55 2016 Z : %USERPROFILE%/Downloads/test-document-domingo.doc
**Enable Content button clicked.

...and the output of the trustrecords_tln.pl plugin looks like this:

1456326535|REG|||TrustRecords - %USERPROFILE%/Downloads/test-document-domingo.doc [Enable Content button clicked]

Addendum, 25 Feb

Default Macro Settings (MSWord 2010)

After publishing this blog post yesterday, there was something that I ran across in my own testing that I felt was important to point out.  Specifically, when I first opened MSWord 2010 and went to the Trust Center, I saw the default Macro Settings, illustrated in the image to the right; this is with no VBAWarnings value in the Registry.  Once I started selecting other options, the VBAWarnings value was created.

What this seems to indicate is that if the VBAWarnings value exists in the Registry, even if the Macro Settings appear as seen in the image above (the data for the value would be "2"), that someone specifically changed the value.  So, if the VBAWarnings value doesn't exist in the Registry, it appears (based on limited testing) that the default behavior is to disable macros with a notification.  If the setting is changed, the VBAWarnings value is created.  If the VBAWarnings value is set to "2", then it may be that the Macro Settings were set to something else, and then changed back.

For example, take a look at the plugin output I shared earlier in this post.  You'll notice that the LastWrite time of the Security key is 50 min later than the TrustRecords time stamp for the document.   In this case, this is due to the fact that Mari produced the sample data (hive) for the document, and then later modified the Macro Settings because I'd reached back to her and said that the hive didn't contain a VBAWarnings value.

Something else to think about...has anyone actually used the reading_locations.pl plugin?  If you read Jason's blog post on the topic, it seems like it could be pretty interesting in the right instance or case.  For example, if an employee was thought to have modified a document and claimed that they hadn't, this data might show otherwise.
**end addendum**

Also, I ran across a report of malware using a persistence mechanism I hadn't seen before, so I updated termserv.pl to address the "new" key.

Process Creation Monitoring
My recent look into and description of PECapture got me thinking about process creation monitoring again.

Speaking of process creation monitoring, Dell SecureWorks recently made information publicly available regarding the AdWind RAT.  If you read through the post, you'll see that the RAT infection process spawns a number of external commands, rather than using APIs to do the work.  As such, if you're recording process creation events on your endpoints, filters can be created to watch for these commands in order to detect this (and other) activity.

Malicious LNK
Wait, what?  Since when did those two words go together?  Well, as of the morning of 24 Feb, the ISC handlers have made it "a thing" with this blog post.  Pretty fascinating, and thanks to the handlers for walking through how they pulled things out of the LNK file; it looks as if their primary tool was a hex editor.

A couple of things...

First, process creation monitoring of what this "looks like" when executing would be very interesting to see.  If there's one thing that I've found interesting of late is how DFIR folks can nod their heads knowingly at something like that, but when it comes to actual detection, that's another matter entirely.  Yes, the blog post lists the command line used  but the question is, how would you detect this if you had process creation monitoring in place?

Second, in this case, the handlers report that "the ACE file contains a .lnk file"; so, the ACE file doesn't contain code that creates the .lnk file, but instead contains the actual .lnk file itself.  Great...so, let's grab Eric Zimmerman's LECmd tool, or my own code, and see what the NetBIOS name is of the system on which the LNK file was created.  Or, just go here to get that (I see the machine name listed, but not the volume serial number...).  But I'd like to parse it myself, just to see what the shell items "look like" in the LNK file.

As a side note, it's always kind of fascinating to me how some within the "community" will have data in front of them, and for whatever reason, just keep it.  Just as an example (and I'm not disparaging the work the handlers did, but commenting on an observation...), the handlers have the LNK file, but they're not sharing the vol SN, NetBIOS name, or shell items included in the LNK file, just the command line and the embedded payload.  I'm sure that this is a case of "this is what we feel is important, and the other stuff isn't...", but what happens when others find something similar?  How do we start correlating, mapping and linking similar incidents if some data that might reveal something useful about the author is deemed unnecessary by some?

Like I said, not disparaging the work that the handlers did, just thinking out loud a bit.

8Kb One-Liner
There was a fascinating post over at Decalage recently regarding a single command line that was 8Kb long.  They did a really good walk-through for determining what a macro was up to, even after the author took some pretty significant steps to make getting to a human-readable format tough.

I think it would be fascinating to get a copy of this sample and run it on a system with SysMon running, to see what the process tree looks like for something like this.  That way, anyone using process creation monitoring could write a filter rule or watchlist to monitor for this in their environment.

From the Trenches
The "From the Trenches" stuff I've been posting doesn't seem to have generated much interest, so I'm going to discontinue those posts and move on to other things.

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

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.

Jump List Analysis

I've recently spoke with a couple of analysts I know, and during the course of these conversations, I was somewhat taken aback by how little seems to be known or available with respect to Jump Lists.  Jump Lists are artifacts that are new to Windows 7 (...not new as of Vista...), and are also available in Windows 8.  This apparent lack of attention to Jump Lists is most likely due to the fact that many analysts simply haven't encountered Windows 7 systems, or that Jump Lists haven't played a significant role in their examinations.  I would suggest, however, that any examination that includes analysis of user activity on a system will likely see some significant benefit from understanding and analyzing Jump Lists.

I thought what I'd try do is consolidate some information on Jump Lists and analysis techniques in one location, rather than having it spread out all over.  I should also note that I have a section on Jump Lists in the upcoming book, Windows Forensic Analysis 3/e, but keep in mind that one of the things about writing books is that once you're done, you have more time to conduct research...which means that the information in the book may not be nearly as comprehensive as what has been developed since I wrote that section.

In order to develop a better understanding of these artifacts, I wrote some code to parse these files.  This code consists of two Perl modules, one for parsing the basic structure of the *.automaticDestinations-ms Jump List files, and the other to parse LNK streams.  These modules not only provide a great deal of flexibility with respect to what data is parsed and how it can be displayed (TLN format, CSV, table, dumped into a SQLite database, etc.), but also the depth to which the data parsing can be performed.

Jump List Analysis

Jump Lists are located within the user profile, and come in two flavors; automatic and custom Jump Lists.  The automatic Jump Lists (*.automaticDestinations-ms files located in %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations) are created automatically by the shell as the user engages with the system (launching applications, accessing files, etc.).  These files follow the MS-CFB compound file binary format, and each of the numbered streams within the file follows the MS-SHLLINK (i.e., LNK) binary format.

The custom Jump Lists (*.customDestinations-ms files located in %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations) are created when a user "pins" an item (see this video for an example of how to pin an item).  The *.customDestinations-ms files are apparently just a series of LNK format streams appended to each other.

Each of the Jump List file names starts with a long string of characters that is the application ID, or "AppID", that identifies the specific application (and in some cases, version) used to access specific files or resources.  There is a list of AppIDs on the ForensicsWiki, as well as one on the ForensicArtifacts site.

From an analysis perspective, the existence of automatic Jump Lists is an indication of user activity on the system, and in particular interaction via the shell (Windows Explorer being the default shell).  This interaction can be via the keyboard/console, or via RDP.  Jump Lists have been found to persist after an application has been deleted, and can therefore provide an indication of the use of a particular application (and version of that application), well after the user has removed it from the system.  Jump Lists can also provide indications of access to specific files and resources (removable devices, network shares). 

Further, the binary structure of the automatic Jump Lists provides access to additional time stamp information.  For example, the structures for the compound binary file directory entries contain fields for creation and modification times for the storage object; while writing and testing code for parsing Jump Lists, I have only seen the creation dates populated.

Digging Deeper: LNK Analysis
Within the automatic Jump List files, all but one of the streams (i.e., the DestList stream) are comprised of LNK streams.  That's right...the various numbered streams are comprised of binary streams following the MS-SHLLINK binary format.  As such, you can either use something like MiTeC's SSV to view and extract the individual streams, and then use an LNK viewer to view the contents of each stream, or you can use Mark Woan's JumpLister to view and extract the contents of each stream (including the DestList stream).  The numbered streams do not have specific MAC times associated with them (beyond time stamps embedded in MS-CFB format structures), but they do contain MAC time stamps associated with the target file. 

Most any analyst who has done LNK file analysis is aware of the wealth of information contained in these files/streams.  My own testing has shown that various applications populate these streams with different contents.  One thing that's of interest...particularly since it was pointed out in Harry Parsonage's The Meaning of LIFE paper...is that some LNK streams (I say "some" because I haven't seen all possible variations of Jump Lists yet, only a few...) contain ExtraData (defined in the binary specfication), including a TrackerDataBlock.  This structure contains a machineID (name of the system), as well as two "Droids", each of which consists a VolumeID GUID and a version 1 UUID (ObjectID).  These structures are used by the Link Tracking Service; the first applies to the new volume (where the target file resides now), and the second applies to the birth volume (where the target file was when the LNK stream was created).  As demonstrated in Harry's paper, this information can be used to determine if a file was moved or copied; however, this analysis is dependent upon the LNK stream being created prior to the action taking place.  The code that I wrote extracts and parses these values into their components, so that checks can be written to automatically determine if the target file was moved or copied.

There's something specific that I wanted to point out here that has to do with LNK and Jump List analysis.  The format specification for the ObjectID found in the TrackerDataBlock is based on UUID version 1, defined in RFC 4122.  Parsing the second half of the "droid" should provide a node identifier in the last 6 bytes of stream.  Most analysts simply seem to think that this is the MAC address (or a MAC address) for the system on which the target file was found.  However, there is nothing that I've found thus far that states emphatically that it MUST be the MAC address; rather, all of the resources I've found indicate that this value can be a MAC address.  Given that a system's MAC address is not stored in the Registry by default, analysis of an acquired image makes this value difficult to verify.  As such, I think that it's very important to point out that while this value can be a MAC address, there is nothing to specifically and emphatically state that it must be a MAC address.

DestList Stream
The DestList stream is found only in the automatic Jump Lists, and does not follow the MS-SHLLINK binary format (go here to see the publicly documented structure of this stream).  Thanks to testing performed by Jimmy Weg, it appears that not only is the DestList stream a most-recently-used/most-frequently-used (MRU/MFU) list, but some applications (such as Windows Media Player) appear to be moving their MRU lists to Jump Lists, rather than continuing to use the Registry.  As such, the DestList streams can be a very valuable component of timeline analysis.

What this means is that the DestList stream can be parsed to see when a file was most recently accessed.  Unlike Prefetch files, Jump Lists do not appear (at this point) to contain a counter of how many times a particular file (MSWord document, AVI movie file, etc.) was accessed or viewed, but you may be able to determine previous times that a file was accessed by parsing the appropriate Jump List file found in Volume Shadow Copies. 

Summary
Organizations are moving away from Windows XP and performing enterprise-wide rollouts of Windows 7.  More and more, analysts will encounter Windows 7 (and before too long, Windows 8) systems, and need to be aware of the new artifacts available for analysis.  Jump Lists can hold a wealth of information, and understanding these artifacts can provide the analyst with a great deal of clarity and context.

Resources
ForensicsWiki: Jump Lists
Jump List Analysis pt. I, II, III
DestList stream structure documented
Harry Parsonage's The Meaning of LIFE paper - a MUST READ for anyone conducting LNK analysis
RFC 4122 - UUID description; sec 4.1.2 describes the structure format found in Harry's paper; section 4.1.6 describes how the Node field is populated
Perl UUID::Tiny module - Excellent source of information for parsing version 1 UUIDs

Copying Files

I've been party to or heard a good number of discussions lately regarding USB removable storage devices, and one of the topics that invariably comes up is, how can you determine which files were copied from the system to a thumb drive, or vice versa.

In most instances, folks are working only with the image of a system, and do not have access to the thumb drive itself. They can easily find the information that tells them when a thumb drive was first connected, and when it was last connected...and then the next question is, what files were or may have been copied to the thumb drive (or from the thumb drive to the system)?

The fact is that Windows systems do not maintain a record of file copies or moves...there is simply no way for a forensic analyst to look at the image of a system and say which files were copied off of the system onto a thumb drive. In order to determine this, you'd need to have the thumb drive (or other media) itself, and be able to see that you had two files of the same or similar size (you can also compare the files with md5deep or ssdeep), one of which is on each piece of media. From there, you could then check the file MAC times and possibly make some conclusions regarding the direction of transfer.

Many times in a conversation on this topic, someone will bring up Windows shortcuts or LNK files. To be honest, I'm not really sure why this comes up, it just seems to be the case. Shortcuts can be created manually, of course, but with regards to files, they are created when a user double-clicks a file, such as a Word document, to open it. Repeated testing on my part (including testing done by others) has yet to turn a method by which normal (as in "normal user activity") dragging-and-dropping a file or using the "copy" command will result in a Windows shortcut file being created.

Does anyone out there have any thoughts or input on tracking this kind of activity, having nothing more than a single system image to analyze? If so, I'd appreciate hearing from you.

From the Lab: Mapping USB devices via LNK files

My first "From the Lab" post will be to address something I see regularly in forums; how does one tie a specific USB-connected device to a Windows system using shortcut (LNK) files, given nothing more than an acquired image to work with? We know that we can extract information about USB devices that have been connected to a system using nothing more than the raw System Registry file...we can get the devices, any drive letters they were mapped to, as well as the date that they were last connected to the system. However, often times we'll have some shortcut files in an image that will point to specific files...images, documents, etc...that we may be interested in, and the drive letter will be F:\ or G:\, or something else that is not part of the system (either as physical or logical drive) that we acquired the image from. So the question is, how do we map the shortcut file to the specific device?

Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.

Remember: the ParentIdPrefix value is NOT the device serial number!!

But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...

Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.

The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.

Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:

F:\,Removable,,1B360101,FAT,,961.875 MB

Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.

Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.

I verified the volume serial number using "chkdsk f:", and got:

Volume Serial Number is 1B36-0101

It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.

The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.

Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:

Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101

Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.

So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.

If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.

Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95