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.

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

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

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.

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