Artifacts: Jump Lists

In order to fully understand digital analysis, we need to have an understanding of the foundational methodology, as well as the various constituent artifacts on which a case may be built. The foundational methodology starts with your goals...what are you attempting to prove or disprove...and once you understand the goals of your analysis, you can assemble the necessary artifacts to leverage in pursuit of those goals.

Like many of the artifacts we might examine on a Windows system, Jump Lists can provide useful information, but they are most useful when viewed in conjunction with other artifacts. Viewing artifacts in isolation deprives the analyst of valuable context.

Dr. Brian Carrier recently published an article on Jump List Forensics over on the CyberTriage blog. In that article, he goes into a good bit of depth regarding both the Automatic and Custom Jump Lists, and for the sake of this article, I'm going to cover just the Automatic Jump Lists. 

As Brian stated in his article, Jump Lists have been around since Windows 7; I'd published several articles on Jump Lists going back almost 14 years at this point. Jump Lists are valuable to analysts because they're (a) created as a result of user interaction via the Windows Explorer shell, (b) evidence of program execution, and (c) evidence of data or file access. 

Automatic Jump Lists follow the old Windows OLE "structured storage" format. Microsoft refers to this as the "compound file binary" format and has thoroughly documented the format structures. Some folks who've been around the industry for a while will remember that the OLE format is what Office documents used to use, and that there was a good bit of metadata associated with these documents. In fact, a good way to find the old school "OG" analysts still hanging around the industry is to mention the Blair document. And the format didn't disappear when Office was updated to the newer style format; rather, the format is used an other areas, such as Jump Lists, and at one point was used for Sticky Notes.

Here's my code for parsing the "structured storage" format; this was specifically developed for Windows 7 Automatic Jump Lists, but the basic code can be repurposed for OLE files, in general, or specifically updated for specific field (i.e., the DestList stream) in newer versions of Windows.

As you saw in Brian's article, Automatic Jump Lists are specific to each user, and are found within the user's profile path. Each Automatic Jump List is named using an "application identifier" or "AppID". This is a value that identifies the application used to open the target files (Notepad, Notepad++, MSWord, etc.), and is consistent across platforms. This means that an AppID that refers to a particular application on a Windows system will remain the same on other Windows systems. 

Microsoft has referred to the "structured storage" format as a "file system within a file"; if you do a study of the format, you'll see why. This structure results in various 'streams' being within the file, and for Automatic Jump Lists, there two types of streams. Most of the streams in a Automatic Jump List file contain a stream structure that follows the Windows shortcut/LNK file format.

The other type of stream is referred to as the "DestList" stream, and the structure of this stream on Windows 7 systems was first documented about 14 yrs ago. The following figure illustrates an Automatic Jump List opened in the Structured Storage Viewer, with the DestList stream highlighted.

The structure of the DestList stream changed slightly between Windows 7 and 10 (and maybe again with Windows 11, I haven't looked yet...), but the overall structure of the Automatic Jump List files remains essentially the same.

Summary
Automatic Jump Lists help analysts validate that a user was active on the system via the Windows shell (as well as when), that they launched applications (program execution), and that they used those applications to open files (file/data access), and when they did so. As such, parsing Jump Lists and including the data in a timeline can add a good deal of granularity and context to the timeline, particularly as it pertains to user activity.

As always, Automatic Jump Lists should be used in conjunction with other artifacts, such as Prefetch, UserAssist, RecentDocs, etc., and should not be viewed in isolation, pursuant to the analyst's investigative goals.

Something else to remember is this...Automatic Jump Lists are generated by the operating system as the user interacts with the environment. As such, if an application is added, the user uses that application and Automatic Jump Lists are generated, and then the user removes the application, the Automatic Jump Lists remain. The same thing happens with other artifacts, such as Recents shortcuts/LNK files, Registry values, etc. So, as with other artifacts, Automatic Jump Lists can provide indications of applications previously installed or files that previously existed on (or were accessed from) the endpoint.

Jump List Analysis

Every now and again, I see questions about Windows forensic analysis such as "what's new/different in Windows 7?"  There are a number of things that are different about Windows 7, some of which may significantly impact how analysts approach an examination involving Windows systems.  While there are some aspects of Windows systems that are just different (Windows Event Logs, Registry, etc.), there are some things that are new technologies.

One of those new technologies is Jump Lists. Windows 7 Jump Lists (see the "Jump Lists" section of this post) are a new and interesting artifact of system usage that may have some significant value during forensic analysis where user activities are of interest.  Jump Lists consist primarily of two file types...the *.automaticDestinations-ms (autodest) files, which are created by the operating system when the user performs certain actions, such as opening files, using the Remote Desktop Connection tool, etc.  The specific Jump Lists produced appear to be associated through file extension analysis...if one use double-clicks a text file on one system, it may open in Notepad, whereas on another system it may open in another editor (I like UltraEdit).  The contents of these Jump Lists appear in application context menus on the TaskBar, as well as the Start Menu.  According to Troy Larson, senior forensic dude for MS, these files follow the OLE/compound document format, with individual numbered streams following the LNK file format.  The autodest files also contain a DestList stream, which according to research performed by Jimmy Weg, appears to be an MRU list, of sorts.

There are tools available to view the contents of the autodest files.  For example, you can use MiTeC's SSViewer to open the files and see the various streams.  From here, you would then need to save the numbered streams and use an LNK file viewer to see the contents of the streams.  There's also Mark Woan's JumpLister, which allows you to view the contents of the numbered streams right there in the tool, automatically parsing the LNK formats.  Chris Brown also added this capability to ProDiscover, including a Jump List Viewer in the tool that parses the contents of the numbered streams.

There are also custom Jump Lists, *.customDestinations-ms (customdest) files, which are created when a user "pins" a file to an application, such as via the TaskBar.  Per Troy, these files appear to consist of stacked segments (not in an OLE container) that are LNK file formats.

Both types of files start with a series of hex characters that are the application identifier, or AppID.  This is an identifier that refers to the specific application that the user was using.  While I've found some short lists of references to AppIDs, I haven't yet found a comprehensive list.  Most of what I have found refers to "fixing" Jump Lists by deleting the appropriate files and starting over.

Addendum: Mark McKinnon recently updated the ForensicsWiki page for Jump List IDs.

In an effort to develop a better understanding of the autodest files, I began digging into the Jump List file structure, and wrote some Perl code that parses the *.automaticDestinations-ms (autodest) Jump List files on a binary level.  This parsing capability consists of two Perl modules; the first parses the autodest Jump List files (maintained in MS OLE/Compound File format) and the DestList stream within those files.  The second module parses the numbered streams, which are maintained in the Windows shortcut/LNK file format.  By combining these two modules, I'm able to parse the autodest Jump List files, correlate the DestList stream entries to the numbered streams, and present the available information in any format (TLN, CSV, XML, etc.) I choose.

So far, this is the only tool that I'm aware of that parses the DestList streams.  I had done some research into the format, and it appears that I was able to figure out at least part of the structure of these streams.  I've also found that various applications maintain different information within the contents of the streams...some maintain file names, other maintain string identifiers that appear to be used similar to a GUID.  One thing of interest, and perhaps significant value to an analyst, is that there's a FILETIME object embedded within each structure, and based on Jimmy Weg's research and input, this appears to be an MRU time.  Each individual structure within the DestList stream has a number that is associated with a numbered stream, so the information can easily be correlated to develop a complete picture of what the Jump List contains.

Here's an interesting example of how the information in Jump Lists can be useful; when a user uses the Remote Desktop Connection tool, the "1bc392b8e104a00e.automaticDestinations-ms" Jump List file is created.  The DestList stream of the Jump List file contains the "MRU Time" for each connection, as well as an identifier string.  However, we can correlate each DestList entry to the corresponding numbered stream within the Jump List file, which is itself maintained in the Windows shortcut/LNK file format; as such, we can extract information such as the basename and command line (if it exists) of the shortcut.  If we combine the two, this would appears as:

C:\Windows\System32\mstsc.exe /v:"10.1.1.23"

The information that is available depends upon how the connection was made; for example, rather than an IP address, the command line element of the LNK stream may contain a system name.  However, what we do have is an action associated with a specific user, that occurred at a specific time.  As this is a Windows 7 system, we may also be able to find additional, historic MRU data in Jump Lists accessed via Volume Shadow Copies.

The code is Perl-based and doesn't use any proprietary or platform-specific modules; while it does make heavy use of seek(), read(), substr(), and unpack(), all of these functions are available in all versions of Perl.  Ideally, this code should run on Windows, Linux, and Mac systems equally well (I don't have a Mac to use for testing).

I opted to create Perl modules for this capability because it is a much more flexible method that allows me to incorporate it into other tools.  For example, I can incorporate the modules into a Perl script (which I have done) that will parse through either individual autodest Jump List files or all such files found in a directory, and list the information they contain in any manner that I choose.  Or, I can write a ProDiscover ProScript.  Or, I can (will) include this in my forensic scanner.  Or, to paraphrase Beyonce, "If you like then you better put a GUI on it!"

Output formats are also a matter of personal choice now.  I'm focusing on TLN and CSV formats for the time being, but there's nothing that restricts me to these formats; XML is a possibility (I simply don't have a style sheet format in mind, so I may not pursue this output format).

Issues
Jump Lists are fairly new...although Windows 7 has been out for a while now, I haven't seen a great deal of discussion or questions in public forums or lists looking for more information about these artifacts.  However, some issues have already come up.  For example, I was contacted recently by someone who indicated that one of available tools for parsing Jump Lists "didn't work".  Initial correspondence indicated that at least one Jump List may have been recovered from unallocated space, but it turned out that the three "problem" Jump Lists were from a live acquisition image, and the applications in question could have been open on the desktop during the acquisition.

This presents an interesting and valid issue...how do you deal with Jump Lists from live acquisition images, where the apps were open during the acquisition (live acquisition may be required for a number of reasons, such as whole disk encryption, etc.)?  Or, what about Jump Lists carved from unallocated space?

The answer is that you need to understand the binary format of the Jump Lists (or know someone who is), because that's really the only way to resolve these issues.  When a tool "doesn't work", you need to either have the understanding of the formats to troubleshoot the issue yourself, or go to the tool author for assistance, or go to another resource for that assistance.  If you're squeamish about sharing information about the issue, or the "problem" Jump List file, even with confidentiality agreements in place, then you're really limiting yourself, and by extension, your analysis.  However, this applies to every facet of an examination (Registry, Event Log, USB device analysis, etc.), not just Jump Lists.  So, the answer is to develop the capability internally, or develop trusted resources that you can reach to for assistance.

Summary
From an analyst's perspective, Jump Lists are a new technology and artifact that need to be better understood.  However, at this point, we have considerable information that clearly indicates that these artifacts have value and should be parsed, and the embedded information included in timelines for analysis.  In many ways, Jump Lists contain analytic attributes similar to the Registry and also to Prefetch files, and are tied to specific user actions.  Further research is required, but it appears at this point that Jump Lists also represent a persistent artifact that remains after files and applications are deleted.  In one test, I installed iTunes 10 on my system, and listened to two CyberSpeak podcasts via iTunes.  The Jump Lists persisted even after I removed the application from my system.

Resources
Code Project: Jump Lists
AppID list 1
ForensicsWiki Jump Lists page

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

Jump List Analysis, pt II

I recently posted regarding Jump List Analysis, and also updated the ForensicsWiki page that Jesse K created.  Mark McKinnon has added a great list of AppIDs to the ForensicsWiki, as well.  So why am I talking about Jump Lists again?  Over two and a half years ago, I said the following in this blog:

...from a forensic perspective, this "Jump List" thing is just going to be a gold mine for an analyst...

The more I look into Jump Lists, the more convinced I am of that statement.  However, there's still a great deal that needs to be addressed regarding Jump Lists; for example, none of the tools available at this point parse the DestList streams in the automaticDestinations files (I wrote a Perl script that does this).  Also, the available tools that do parse Jump Lists, including ProDiscover, do so in a format decided upon by the developer, not by analysts.  I've heard from several folks who have stated that the process that they have to go through to find relevant information in the Jump List files is very manual and very cumbersome, and we all know how repetitive processes like this can be prone to errors.  Even though I've developed code that quickly parses either a single Jump List file (or a whole directory full of them), I haven't yet settled on an output format (beyond TLN and CSV) and how to display or present relevant information derived from the Jump List files.  That brings to this to mind...there's the issue of what is relevant to the analyst...what I want to see as part of my analysis isn't necessarily the same thing someone else would want to see.

AppIDs
Another issue is the application identifiers for the Jump List files.  Thanks to Mark McKinnon, a nice list of AppIDs is publicly available, but I'm sure that anyone looking at it will recognize that it's far from complete.  This is going to be a community effort to keep building the list.

This page at the WindowsTeamBlog site discusses how AppIDs are created, and strongly suggests that they're very similar to the manner in which Prefetch file hashes are created.  For example, the hash that is part of a Prefetch file name is created using the path and command line for the application; it appears from this page that a similar approach is used for AppIDs, indicating that the AppIDs can vary based on the file location and the command line used.

This page at MS talks about AppUserModelIDs; this page doesn't explicitly discuss Jump Lists, but does reference exclusion lists for Taskbar pinning and recent/frequent lists.  The page also discusses Registry keys to use for exclusion lists, as well as provides a list of applications (including rundll32.exe and mmc.exe) that are excluded from the MFU list.  What this indicates is that the automaticDestination Jump Lists are, in fact, MRU/MFU lists.

With respect to the exclusion lists discussed at the MS site, the page mentions a "Registry entry" as one means of preventing inclusion in the Start Menu MFU list, but not what kind of entry; i.e., key or value.  Reading on, there is mention that the type of the entry can be "Reg_None" and that the data is ignored, indicating that the "entry" is a value.

These pages do provide some insight as to how Jump List analysis needs to incorporate more than just looking at the files themselves; we have to include the Registry, as well.  For example, let's say that there are indications of an application on a Windows 7 system, but no Jump List files; do we just assume that the application was never used by the user in question if there are no Jump List files in their profile?  I would suggest that, based on the pages linked to above, conclusions regarding usage and attribution could not be drawn without including Registry analysis.


Now, I'm a bit skeptical about all of this, as when parsing Jump Lists created by the Remote Desktop Client, the numbered streams include a command line entry within the LNK stream (i.e., /v:"192.168.1.2").  However, all of the streams are contained in the same file rather than separate files.

What this means is that there's more we need to know about Jump Lists...

Analysis
So, how would you use Jump Lists and the information they contain during an examination?  Well, whenever there is some question of the user's activities on the system, would be my number one thought.  I would think that attempting to determine if a user had used an application (or had not...remember, forensic analysis can be used to exonerate someone, as well) would be the primary use of Jump List analysis.  There are secondary uses, for example, such as determining when the user was active on the system, or when the system itself was active (i.e., booted and running).

I would also include parsing Jump Lists and sorting the LNK streams based on the DestList stream time stamps in a timeline; again, this might be of particular value when there was some question regarding the user's activities.

Also, limited testing has demonstrated Jump Lists persist on a system even after the application with which they are associated have been deleted and removed from the system.  I found this to be the case with iTunes 10, and others have observed similar behavior.  This behavior can prove to be invaluable during investigations, providing a significant amount of valuable information that persists long after a user has made attempts to hide their activity.

Something else to consider is this...what if the user connects a USB drive to the system, or inserts a DVD into the system, and the attached media includes files with a unique viewer application?  That viewer would not have to be installed on the system, but the user's use of the application to view the files (images, movies, etc.) would likely create a Jump List file that would persist long after the user removed the media.  This is definitely something that needs to be looked into and tested, and it also demonstrates how valuable Jump Lists could possibly be during an examination.

Carving
One of the things that many of us do during an examination is file carving.  For the most part, this is done through one of the commercial tools, or using a tool (foremost, scalpel) that looks for file headers and footers, or just the headers (and it grabs X bytes following the header).

I've taken a more targeted approach to carving.  For example, on Windows XP and 2003 systems, using blkls to extract the unallocated space from an image, I then searched for the event record magic number, and instead of grabbing X bytes from there, I followed the event record format specification and retrieved over 330 "deleted" albeit valid Event Log event records from unallocated space.  I was able to do this because I know that there's more to the record format than finding a header and grabbing X bytes following that.

I've started to take a similar look at carving Jump Lists from unallocated space, and getting anything that can be parsed is going to be a challenge.  Remember that the compound file format is referred to as a 'file system within a file', and that's exactly what it is.  The header of the file specifies the location of the directory table within the file, and for the most part, each of the streams is comprised of 64 byte sectors.  However, at a certain point, the file contains enough numbered stream entries that the DestList stream gets over 4Kb (4096 bytes) in size, and it's content is moved to 512 byte sectors.  Also, as numbered streams are added to the Jump List, the DestList stream becomes intermingled amongst the rest of the sectors in the file...one of the things I had to do in writing my code was build lookup arrays/lists, and as the file becomes larger, the DestList stream becomes more dispersed throughout the file.

Now, consider the numbered streams.  A numbered stream that is 203 bytes in length, per the directory table, will consume four 64 byte sectors, with 53 bytes left over.  A numbered stream that is 456 bytes long will consume eight 64 byte sectors...and in neither case is there any requirement for these sectors to be contiguous.  This means that they could be dispersed within the Jump List file.  Reassembling those streams is enough of an issue without having to deal with hoping that you retrieved the correct sectors from unallocated space within the image.

Based on this, something does come to mind that would make an interesting honors or university project...carving within the Jump List file itself.  Locating deleted keys and values (as well as pulling out unallocated space) within Registry hive files has proved to be a very useful analysis technique, so maybe something of value could also be retrieved by locating and extracting unallocated space within Jump List files.  This would simply be a matter of reading the directory table and determining all of the 64- and 512-byte sectors used, and then extracting those that are currently not being used.

Resources
Alex Barnett's paper on Jump List Forensics
Mark Woan's JumpLister
Troy Larson's Forensic Examination of Windows 7 Jump Lists presentation
Mike Ahrendt's blog post on Jump Lists (3 Apr 2011)

Updates

DLL Search Order Issue
Nick Harbour recently put together another great, very informative post over on the Mandiant that has to do with the DLL search order issue that he'd discussed last year ("Malware Persistence without the Windows Registry").  His recent post has to do with fxsst.dll, which appears to pertain to the Fax Service.  The difference in fxsst.dll with respect to the earlier issue that Nick mentioned (re: ntshrui.dll) is that whilst ntshrui.dll was loaded directly by Windows Explorer (as an approved shell extension), fxsst.dll is actually loaded by stobject.dll (System Tray component for Windows Explorer).

The DLL search order issue is something that's been around for a while (11 years), and as Nick mentioned, allows for malware persistence without the use of the Registry.  The analysis technique that I've used to track down issues like this is timeline analysis...putting a timeline together and looking at various aspects of the incident (timeframe, files involved, etc.) has been a very revealing process, and really turned up some good information.  Nick used an interesting approach to track down how fxsst.dll was loaded...I'd suggest taking a look at what he did, and seeing where you could use a technique similar to his in your examinations.

In short, if you find a copy of fxsst.dll in the Windows or Windows\system32 directory, take a very careful look at it.  However, be sure that when you do look at it, you understand what's going on...because just because you find a file with this name on the system, it doesn't necessarily follow that the file has anything to do with the incident.

NoVA Forensics Meetup Slides
Chris has been kind enough to post his presentation slides from this month's meetup presentation.  Chris provided a lot of great information in his presentation...take a look and see what you think, and feel free to send him questions.

Jump Lists
Jump lists are something new to Windows 7, a nice little feature that appears to be similar to the Windows shortcuts in the user's Recent folder.  Here's more information about Jump Lists, and how they're used, from MS.

A while back, I was at a Microsoft cybercrime conference in Redmond, and Troy Larson mentioned during his presentation that the "old" OLE "structured storage" file structure that was used in MS Office documents prior to Office 2007 was again used in Windows 7, and one of the locations was the Jump Lists.  I made a note of it then, but really hadn't pursued it.  As I've been using Windows 7 more and  more, and looking into forensic artifacts, I thought I'd take a look at them.  Troy had also mentioned that not only did the Jump Lists make use of the OLE "structured storage" mechanism, but the streams within the "file system within a file" were based on the shortcut/LNK file format, so that was something to go on...

ProDiscover v6.11 (I use the IR edition) has a Jump List viewer, and over on the Win4n6 list, Rob Lee said that he uses MiTeC's Structured Storage Viewer and a Windows shortcut/LNK file viewer (MiTeC WFA) to parse the Jump List information.

I used code from wmd.pl and lslnk2.pl to develop a Perl script to parse Jump Lists.  Wmd.pl uses the OLE::Storage module, and lslnk2.pl is completely Perl-based, using no Win32-specific modules, but instead parses the LNK file information on a binary level based on the shortcut file format. I've just got the code working, so it's not ready for prime time, and I still have to figure out how I want to display the information.  I'm considering the TLN format as one means of displaying the information, using something similar to how I recently updated/modified regtime.pl and rip.pl...maybe .csv will be an option, as well.

Addendum:  Using this resource from MS, I was able to identify and parse the ExtraData blocks, and extract the NetBIOS name of the system from the TrackerDataBlock. 


Tools

I ran across this one by accident recently...I'm not really a *nix person (and I don't claim to be), and haven't made wide use of awk, but I thought that this post on using awk to address clock skew in the regtime bodyfile output was worth sharing.  Clock skew on a system, as well as between systems, are definitely an issue when performing analysis, particularly if you're putting things into timelines.  At the OSDFC conference last year, I talked about timelines, and was informed (not asked, but told...) that my technique for developing timelines did not allow for clock skew...and that simply isn't/wasn't the case (dude, it's open source...).  My point is that things like time zones and clock skew are very important when it comes to performing analysis on multiple systems, particularly when they're geographically dispersed.


News
I had posited a bit ago when something like this would happen...the Unveillance CEO faced extortion (JadedSecurity has a different take on the matter).  I added this to this post, as this is something I discussed with others recently via email, and the results were pretty much what they'd suggested would happen...

Even More Stuff

DFIROnline
Last Thu, we had (at one point) 32 attendees to the #DFIROnline online meetup, and my impression is that overall, it went pretty well.  Mike took the time to post his impressions, as well.

I think it would be very helpful to hear from others who attended and find out what they liked or didn't like about this format.  What works, what doesn't, what would folks like to see?  I know that with the NoVA Forensics Meetups, most (albeit not all) of the comments about content that I received were from out of town folks, and included, "...set up a meetup in my town...".  Well, Mike's brought that to you...in fact, you can battend from anywhere.  Mike's survey results indicated that case studies and malware analysis are things that folks are interested in, and that's a great start.

Also, I've been thinking...what do folks think about moving the NoVA Forensics Meetups to DFIROnline?

For those interested, I posted my slides (in PDF format) to the Win4n6 Yahoo Group Files section.

A a great big, huge, Foster's thanks to Mike for setting this up. 

Cool Stuff
If you do timeline analysis, David Nides has posted a great little log2timeline cheat sheet over on the SANS Forensics blog.  David made this cheat sheet available at the recent SANS360 event as a single laminated sheet...if you weren't able to make it and didn't get one, download the PDF and print out your own.  The content of the cheat sheet goes right along with Rob's SANS360 presentation, which you can watch here (actually, it's the entire set of presentations).

A huge thanks to David for putting this together and making it available.  This is another great example of how someone can contribute to the community, without having to be able to stand up in front of people, or write code. 

Jump Lists
I recently received a question about Windows 7 Jump Lists, and dusted off some of the code I wrote last summer for parsing Jump Lists.  Yes, it's in Perl...but the way I wrote it was to use just core Perl functions (i.e., no esoteric, deprecated, or OS-specific modules) so that it is platform-independent, as well as much easier to install and run.  Also, I wrote it as Perl modules, so I have additional flexibility in output formats...in short, I can have a script spit out text in a table format, CSV, or even TLN format.

If you haven't yet, check out Mark Woan's JumpLister...it's at version 1.0.5, and does a great job of parsing not only the LNK streams, but also the DestList stream (partial structure of which was first publicly documented here).  It also maps the AppId to an application name...a list of which can be found here, and here. 

Another use I've found for this code is Windows 8 forensics.  I've had a VirtualBox VM of Windows 8 Dev Build running, but recently set up a laptop (wiped XP off of it forever) to dual boot Win7 & 8, so that I could look at some of the various artifacts available, such as wireless networks within the Registry, the use of a Windows Live account to log into Win8, and the Jump Lists...yep, Win8 uses Jump Lists and at this point, they appear to be consistent in format with the Win7 Jump Lists.

Speaking Engagements
My upcoming speaking engagements include the DoD CyberCrime Conference (the conference even has a Facebook page), where I'll be presenting on Timeline Analysis.  I've also submitted to the CfP for the SANS Forensic Summit this next summer (topic: Windows 7 Forensic Analysis), so we'll see how that goes.

When was a file accessed?

One of the aspects of Windows analysis that I discuss in the courses we're offering is that the version of Windows you're analyzing is significant.  For example, as of Windows Vista, updating of file system last accessed times, as a result of normal user behavior, is disabled by default.  However, even though we can't look to file accesses times as an indication of when a user accessed the files, there are a number of artifacts on Windows systems, in particular Windows 7, which will tell us not only that a user accessed a file (based on the context of those artifacts), but also when.  As such, we  can add category IDs or tags (i.e., "[File Access]") to those events (something that I've discussed previously) in order to make them much easier to identify in timelines, as well as in other reporting formats.

I'll take a moment a discuss a few of the artifact sources we can use on Windows 7 systems that provide indications of file access...

LNK Files
One of the ways that LNK files are created on a system is that a user will double-click a file which is located somewhere on that system, on removable media, or even on a network share.  When this happens, a shortcut file that points to the target will be created in the user's Recent folder.  The operating system will select the appropriate application (based on the extension of the target file) with which to open the file.

As such, under "normal" circumstances, the creation date of the LNK file would correspond to when the target file was first accessed, and the last modification date of the LNK file would correspond to when the target file was most recently accessed. [Ref: Harry Parsonage's excellent "The Meaning of LIFE" white paper.]

Jump Lists
On Windows 7 systems, we now have new Task Bar artifacts called Jump Lists available for analysis.  The AutomaticDestinations Jump Lists are produced by activities very similar to those associated with LNK files, with the added advantage that the Jump Lists are associated with an application (based on the AppID), as well as with a user.

Let's say that the user accesses a Word .docx file by double-clicking it.  When this happens, an LNK file is created, and a Jump List associated with the version of MS Word installed on the system is created, if it doesn't already exist.  These Jump Lists are based on the MS Compound Document format, and an entry that contains an LNK stream is created within the Jump List file, and a structure is added to the DestList stream within the Jump List.  When the file is accessed and the DestList stream structure is added, the time of the activity is included within that structure.  This time can be used to illustrate the most recent time the user accessed that file.

As the LNK streams that point to the target file are not files themselves, they do not have MACB file system times specifically associated with each of them.  They do contain the MA.B times of the target file, embedded within the stream, as they follow the binary format specification described by MS. 

MRU Lists
There are a number of Registry keys (specifically within the user's NTUSER.DAT hive file) that maintain references to files that the user has accessed.  Some, such as the RecentDocs key, maintain simply names of files, while others, such as the Paint subkey beneath the user's Applets key (see the RegRipper applets.pl plugin), provide the full path to the file.  Many of these keys also contain Most Recently Used entries, indicating that the key's LastWrite time may reflect when the appropriately listed file was most recently accessed. 

Document Metadata
There are a number of file formats that allow for metadata to be stored within the file itself.  MS Office has long been known for providing a good deal of (potentially embarrassing) metadata.  While more recent formats of MS Office documents don't contain as much metadata as previous versions, we may still be able to use this information to provide indications of file access.

VSCs
Let's not forget that previous versions of each of the artifacts we've discussed so far may be located within available Volume Shadow Copies; as such, we may want to take a targeted (perhaps even laser-focused) approach to parsing previous versions of each of these artifacts for comparative, historical data.

Summary
As you can see, even though the updating of last access times for files is disabled by default on Windows systems as of Vista, this doesn't mean that we can't determine when a user accessed particular files.

Links and Updates

Working Remotely
Thanks to a tweet from Richard Bejtlich, I ran across this very interesting post titled, "Working Remotely".  The post makes a great deal of sense to me, as I joined ISS (now part of IBM) in Feb, 2006, and that's how we rolled at the time.  My boss lived about 2 miles from me, and there was an office in Herndon (with a REALLY great, albeit unused, classroom facility), but we had team members all over...Atlanta, Kansas City, Norfolk, and then as we expanded, Chicago, Corpus Christi, and Tulsa.  We lived near airports (our job was to fly out to perform emergency incident response), and FedEx (or insert your favorite shipment vendor) rounded out our "offices".

Even when we weren't flying, many of us were constantly in touch...so much so that when one person needed assistance with an engagement, it was easy for us to provide whatever support was needed.  Encryption made it very easy to send data for analysis, or for someone to provide insight to, or to write a script to parse a much wider sample of data.  Imagine being on an engagement and needing support...so you send someone a sample of data, and when you wake up, there's a parsing tool in your inbox. 

Something that the article points out is that it takes a certain kind of person to work remotely and that's very true...but when you find them, you need to do everything you can to not just keep them, but grow them.  The article also points out that if you want the best of the best, don't restrict yourself to your local area, or to those who are willing to relocate.  And in today's age, remote communications is relatively easy...if you don't want to bring everyone together once a year (more or less) due to the cost of gas and air fare, Skype and $20 web cam can do a LOT!

Jump Lists
Jimmy Weg has done some testing of Windows 7 Jump Lists (and shared his findings on the Win4n6 group list), and found (thus far) that the DestList stream structure within the Automatic Destination (autodest) Jump List does appear to be an MRU of sorts.  In his testing using Notepad to open text files, the FILETIME object written to the structure for each file correlated to when he opened the files.

When testing Windows Media Player, Jimmy found that there were no MRU entries for the application in the user's Registry hive, nor were any Windows shortcuts/LNK files created in the user's Recent folder.  Jimmy also found that applications such as OpenOffice (AppID: 1b4dd67f29cb1962) created Jump Lists, as well. 

Jimmy mentions Mark Woan's JumpLister application in his post for viewing numbered stream information found within the autodest Jump Lists; this is a very good tool, as is the MiTeC Structured Storage Viewer, although SSView doesn't parse the contents of each stream.  I like to use SSView at this point, although I have written Perl code that will parse the "autodest" Jump List files (those ending in "*.automaticDestinations-ms"), as it is based on the MS OLE format, and each numbered stream is based on the LNK file format.  I have also written code for parsing the DestList stream structure, as well, and thanks to Jimmy's testing, the validity and usefulness of that code is beginning to come to light.  My hope is that by having shared what I've found with respect to the DestList structure thus far, others will continue the research and identify other structure elements that can be of value to an analyst, and share that information.  I've also found some deprecation issues with Perl 5.12, with respect to some of the current Perl modules that handle parsing OLE documents; as such, I've taken a look at the MS documentation on the compound document binary specification, and I'm working on writing a platform-independent Jump List parser.

Troy Larson, senior forensic analyst at Microsoft, added that the DestList stream entries are either an MRU or MFU (most frequently used) list, depending upon the application, and that the order of activities in the DestList stream is reflected when you right-click on a pinned application (to the TaskBar).  The order of items in the DestList stream is apparently determined by how recently/frequently the activity (document opened, etc.) is performed.  Troy went on to mention that as of Windows 7, other methods of tracking files have been deprecated in favor of the API used to create Jump Lists.

CyberSpeak
Ovie's posted a new CyberSpeak podcast, this one addressing the launch of CDFS, which I mentioned in my last blog post.  If you have any questions about this organization, I'd recommend that you download the podcast, and give it a listen. Ovie interviews Det. Cindy Murphy, who's been a member of LE since 1985, and invited me to WACCI last year.

If you want to learn more about CDFS, give this podcast a listen.

Ovie, it's good to have you back, my friend.

Hostile Forensics
Mark Lachniet has released a whitepaper through the SANS Forensics blog site titled, "Hostile Forensics". This is the name given to "penetration-based forensics", in which the forensic analyst uses penetration techniques in order to gain access to a computer system in order to further exploit that system through forensic analysis techniques.

The PDF whitepaper, currently in version 1.0, is available online here.  The paper is 43 pages long, but if this is something that you're interested in, it's well worth the time it takes to read it.  Mark lays out the structure for his proposal, which he states is the result of a "thought experiment". 

Tools

It looks as if x0ner has released PDF X-RAY, an API for static analysis of PDF documents for malicious code.


On a similar note, Cuckoo is a freely available sandbox for analyzing PDF files and malware that runs in VirtualBox.  Cuckoo has it's own web site, as well.  If you're performing malware analysis, this may be something that you'd like to take a look at, along with Yara.  These are all great examples of the use of open-source and free tools for solving problems. 

Shell Item Artifacts

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

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

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

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

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

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

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

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

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

Meetup, Tools and other stuff

Meetup
Just a reminder about our next NoVA Forensic Meetup, scheduled for 6 July.  Tom Harper will be presenting, and he's posted  his slides on his site.  Take a look at his slides, and download them if you want to bring them along.  Also, taking a look at them ahead of time will make the presentation itself go a bit more smooth, and leave more time for questions and interaction.

Location: ReverseSpace, 13505 Dulles Technology Drive, Herndon, VA.

Time: 7:00 - 8:30pm

Review
Corey Harrell posted his review of DFwOST.  Thanks for the review, Corey, and for taking the time to put your thoughts out there for others to see.

MBR

I've mentioned previously that I include a check for MBR infectors in my malware detection process, and I even have it on my checklist.  I discussed this recently with Chris Pogue ("@cpbeefcake" on Twitter), and he pointed me to the mbrparser.pl Perl script that Gary Kessler makes available via his site (the script can be found in the Boot Record Parsers archive).  Gary's mbrparser.pl script does more than just display the MBR; it also parses the partition table in a very readable manner, providing a bit more information than mmls from the TSK tools.

My own Perl script is used for something other than just displaying the MBR, and it doesn't parse the partition table...instead, it looks for sectors that are not all zeros, and will either list those sectors (in summary mode) or display them.  The thought process behind this approach is that many of the identified MBR infectors will modify the MBR with a jmp instruction, and copy the original MBR to another sector.  Some may even include executable code within sectors.  This is particularly useful when you have an image acquired from a physical disk and the first active partition is located at sector 63; usually, I will see sector 0 and 63 as non-zero, and maybe one or two other sectors.  Running the script in summary mode gives me an idea of how many of the sectors I will need to look at, and then running it in full mode allows me to have something that I can redirect to a file and even include in my report, should the need arise.  Even if nothing is found, that's useful, too...because now my malware detection process includes an additional step beyond simply, "I ran an AV scanner against the mounted image...".

Here are some links to disassembling the MBR:
Links
MBR disassembly
More MBR disassembly

Also be sure to check out Gary's page for other utilities, particularly if you're into SCUBA.

Speaking of MBR infectors, a recent MS Technet blog post mentioned a new MBR infector/bootkit called "Trojan:Win32/Popureb.E", which is apparently an update to previous versions of the identified malware, in that it infects the MBR.  Unfortunately, MS's recommendation is to fix your MBR using your recovery disk - I say "unfortunately" because without a root cause analysis, what is the likelihood that you "fix" the system, and the bad guy is then able to un-fix your fix?  Pretty high.  I've seen other MBR infectors get delivered via Java exploits...so if you don't figure out how the MBR got infected, how are you going to protect your infrastructure?  I'd suggest that the steps should be more along the lines of acquiring memory and an image of the physical disk, and then if you must re-provision the system, clean the MBR as suggested, but tag the system as such, and put a high priority on determining an overall fix.

Tools
Nick Harbour of Mandiant maintains a page with a couple of interesting tools, including nstrings and pestat.  Nick's also posted some FileInsight plugins, as well as interesting presentations, on that same page.

The Malicious Streams site includes a Python-based LNK file parser (as well as some interesting MacOSX-specific tools).

David Kovar has moved his analyzeMFT tool to a new location; take note, and keep an eye out for new tools/libraries...

What is "APT"?
Jason Andress published an article for ISSA about APT, what it is, and what the threat really means.  While I do think that the article gets a little too mired down in the origins and meaning of the term "APT", it does make a very valid point...regardless of what side of the fence you're on, APT is a very real threat.  Jason does point out some very important points with respect to defending against this threat, but he does mention tools without specifically identifying any particular tools to use.  I think that in doing this, he makes a point...that is, there is no security silver bullet, and one tool (or combination of tools) may work very well for one organization, but not at all for another.

I think that the most important point that Jason makes regarding defense is the idea of "defense-in-depth".  Now, I've seen where some have suggested that this doesn't work...but the fact of the matter is that you can't deem something a failure if it was never employed.

Jason mentions "security awareness"...this is important, but it has to begin at the top.  If you spend the time and effort to train your employees and raise security awareness, but your C-level executives aren't in attendance, how effective do you think that training will be?  If it's really that important, wouldn't the boss be there?  I attended two days of manager-and-above training for an employer, which was kicked off with a message from the CEO.  And guess what...every time I looked around throughout the two days, I saw the CEO there.  More than anything else, that told me that this stuff was important.  Security has to be top-down.

Something to point out that wasn't mentioned in Jason's article is that many of the things he mentions are either directly or indirectly covered in most of the legal and regulatory compliance standards.  Testing...training...having the right tools in place...many of these map directly to the PCI DSS.  Even defense-in-depth, when you include the computer security incident response team (CSIRT), maps to chapter 12.9 of the DSS.

Jump List DestList Structure
Jump lists are one of those new things in Windows 7 that many analysts are trying to wrap their heads around.  Jump lists provide similar functionality to the user as shortcuts in the Recents folder, as well as the RecentDocs Registry key, albeit in a different manner.  First, jump lists come in two flavors; Automatic and Custom destinations.  I'm not going to be really prolific about jump lists, but from a binary point of view, custom destinations are apparently SHLLNK structures run to together consecutively, one after another, where as Automatic destinations are streams within an OLE container (that is, each *.automaticdestination-ms file is an OLE container).  Each of the streams within the contain is numbered (with the exception of one called "DestList"), and follows the SHLLNK structure. You can open the automatic destinations jump list using the MiTeC Structured Storage Viewer, extract each numbered stream, and view the contents of the stream in your favorite LNK viewer.

There is very little (i.e., "none") information available regarding the structure of the "DestList" stream, but looking at it in a hex editor seems to indicate that it may serve as a most recently used (MRU) or most frequently used (MFU) list.  We know that the SHLLNK structure in the numbered streams contains time stamps, but from the structure definition we know that those are the MAC times of the target file.  So how does Windows 7 know how to go about ordering the entries in the jump list?

Well, I spent some time with some jump lists, a hex editor and a number of colored pens and highlighters, and  I think I may have figured out a portion of the DestList structure.  First, each DestList structure starts with a 32 byte header, which contains (at offsets 0x03 and 0x18) an 8 byte number that corresponds to the number of numbered streams within the jump list.

Following the header, each element of the structure is 114 bytes, plus a variable length Unicode string.  The table below presents those items within each element that I've been able to extract on a consistent basis, albeit via limited testing.

Offset	Size	Description
0x48	16 bytes	NetBIOS name of the system; padded with zeros to 16 bytes
0x58	8 bytes	Stream number; corresponds to the numbered stream within the jump list
0x64	8 bytes	FILETIME object
0x70	2 bytes	Number of Unicode characters in the string that follows

While the information represented in the above table clearly isn't all that's available, I do think that it's a good start.  Once further testing is able to determine what the FILETIME object represents, this is enough information to allow for inclusion of jump lists into timelines.

HowTo: File Extension Analysis

Subtitle: Determining which application a file "belongs" to

Many times when I am browsing through online lists and forums, I see questions geared along this avenue; an analyst finds a file with a specific extension, and wants to know which application uses it or may have been used to modify that file.  Most times, this is just a small part of a much larger question, and initial attempts to answer the question via Google searches may have led to additional confusion (specified application does not appear to be installed on the system, etc.).  However, there are things that an analyst can do to answer that question using the data currently available, within the collected image.

File Extension Analysis
So you have a file that you're interested in, along with a path, name, and extension, and you want to know which application may have been used to create or modify that document.  One way we can go about this is to use Registry analysis.  Within the acquired image, locate the Software hive (usually in the path "\Windows\system32\config"), and within that hive, look to the Classes key.  Many of the first subkeys that you'll see beneath this key are file extensions, such as ".3g2".  The "(Default)" value of this key is "QuickTime.3g2", which indicates that this system will attempt to open a file with this extension using the QuickTime application.  Additionally, the "OpenWithList" subkey includes a subkey named "QuickTimePlayer.exe". Locating the key "Classes\QuickTime.3g2", I saw that that key had a "shell\open\command" subkey with a "(Default)" value that pointed to QuickTimePlayer.exe (along with the complete path to that file).

As another example, beneath the "Classes\.aa" key, the "OpenWithList" subkey contains a subkey named "iTunes.exe", which indicates that the iTunes application will be used to open a file that ends in the ".aa" extension.  Some extensions may have multiple subkeys beneath the "OpenWithList" key, which serves as an indicator to the type of file with which the extension is associated.

Other keys beneath the "Classes" key may have different information that may indicate how the file had been accessed or used on the system.  On a system I was looking at, I found the ".rnk" extension, and the key only had a "(Default)" value with "rnkfile".  I then located the "Classes\rnkfile" key, which had a "shell" subkey, with additional subkeys that referred to different commands.  When I went to the command line on that system and typed "assoc rnkfile", the response was "rnkfile=Dial-Up Shortcut". 

As this technique is based on Registry analysis, analysts need to keep in mind that it may often be unique to the system being analyzed, and findings on one system may not necessarily map directly to or represent those on another system.  Also, these artifacts are based on file associations, which many times will be set when an application is installed, during the installation process.  As such, when the application is uninstalled, those associations may be removed.

As this technique involves Registry analysis, there are other areas you can check, as well.  For example, each user hive (XP) has a "Software\Classes" key within the NTUSER.DAT hive that may contain file associations specific to the user.  On Vista and above systems, this information will be located in the root of the USRCLASS.DAT hive.  You can also look to the RecentDocs key within the NTUSER.DAT hive to see which files the user has accessed, by extension.  Also, if you suspect that someone may have purposely deleted any of the keys or values of interest, be sure to use regslack to check the unallocated space within the hive files for those artifacts.

If you have a file name (as opposed to just an extension) you might open up the user's hives in something like MiTeC's Windows Registry Recovery tool or the Registry Decoder from DFS, and search for the file name...you may find a reference in the application MRU listing.

Jump Lists
Jump Lists are artifacts that are new to Windows 7, and appear to contain most frequently used or most recently used (MFU/MRU) information with respect to applications and files.  The *.automaticDestinations-ms Jump List files are created by the operating system, with only interact from the user being to open the file.  However, testing indicates so far that Jump Lists created as a result of an application being used will persist after the application itself has been removed or uninstalled from a system.  Therefore, an analyst with a specific file extension of interest should be sure to check the available Jump Lists (assuming that the image is from a Windows 7 system, of course) for indications of the extension or the complete file name.  From there, the analyst can then map the AppID (first part of the Jump List name, before the '.') to the application, using the list on the ForensicsWiki, or on ForensicArtifacts.com.

Timeline Analysis
When presenting on timeline analysis, one of the benefits of this analysis technique that I try to get across is that it can provide context to what we're looking at; for example, creating a timeline from multiple data sources (including data from the user profile) may provide clear indications as to how a file with a specific extension was created or modified.  Timelines very often include (if available) file system metadata, Prefetch file metadata, as well as time stamped data from a user's NTUSER.DAT, including (but not limited to) UserAssist data, RecentDocs data, etc.  Through a timeline, you may find that a user opened an application, and shortly thereafter a Prefetch file was created or modified for that application, and then the file in question was created or modified.  At this point, you'd not only know when the file was created, but using with application, and by which user.

VSCs
Volume Shadow Copies (VSCs) may provide some considerable information that may not be available via other sources.  If an artifact does not persist when an application has been uninstalled from a system (such as may be the case with file extension associations), there may be historic remnants available in the VSCs (Vista, Windows 7).

Resources
Jump List Analysis (part 1, part 2, part 3)

Links and Stuff

Sysmon
I've spent some time discussing MS's Sysmon in this blog, describing how useful it can be, not only in a malware testing environment, but also in a corporate environment.

Mark Russinovich gives a great use case for Sysmon, from RSA in this online PowerPoint presentation.  If you have any questions about Sysmon and how useful it can be, this presentation is definitely worth the time to browse through it.

Ransomware and Computer Speech
Ransomware has been in the "news" quite a bit lately; not just the opportunistic stuff like Locky, but also what appears to be more targeted stuff.  IntelSecurity has an interesting write-up on the Samsam targeted ransomware, although a great deal of the content of that PDF is spent on the code of the ransomware, and not so much the TTPs employed by the threat group.  This sort of thing is a great way to showcase your RE skillz, but may not be as relevant to folks who are trying to find this stuff within their infrastructure.

I ran across a write up regarding a new type of ransomware recently, this one called Cerber.  Apparently, this particular ransomware, as part of the infection, drops a *.vbs script on the system that makes the computer tell the user that its infected.  Wait...what?

Well, I started looking into it and found several sites that discussed this, and provided examples of how to do it.  It turns out that its really pretty simple, and depending upon the version of Windows you're using, you may have a greater range of options available.  For example, per this site, on Windows 10 you can select a different voice (a female "Anna" voice, rather than the default male "David" voice), as well as change the speed or volume of the speech.

...and then, much hilarity ensued...

Document Macros
Okay, back to the topic of ransomware, some of it (Locky, for example) ends up on systems as a result of the user opening a document that contains macros, and choosing to enable the content.

If you do find a system that's been infected (not just with ransomware, but anything else, really...), and you find a suspicious document, this presentation from Decalage provides a really good understanding of what macros can do.  Also, take a look at this blog post, as well as Mari's post, to help you determine if the user chose to enable the content of the MS Office document.

Why bother with this at all?  That's a great question, particularly in the face of ransomware attacks, where some organizations are paying tens or hundreds of thousands of dollars to get their documents back...how can they then justify paying for a DFIR investigation?  Well, my point is this...if you don't know how the stuff gets in, you're not going to stop it the next time it (or something else) gets in.

You need to do a root cause investigation.

Do not...I repeat, do NOT...base any decisions made after an infection, compromise, or breach on assumption or emotion.  Base them on actual data, and facts.  Base them on findings developed from all the data available, not just some of it, with the gaps filled in with speculation.

Jump Lists
One way to determine which files a user had accessed, and with which application, is by analyzing Jump Lists.  Jump Lists are a "new" artifact, as of Windows 7, and they persist through to Windows 10.  Eric Zimmerman recently posted on understanding Jump Lists in depth; as you would expect, his post is written from the perspective of a tool developer.

Eric noted that the format for the DestList stream on Windows 10 systems has changed slightly...that an offset changed.  It's important to know and understand this, as it does affect how tools will work.

Mysterious Records in the Index.dat File
I was conducting analysis on a Windows 2003 server recently, and I found that a user account created in Dec 2015 contained activity within the IE index.dat file dating back to 2013...and like any other analyst, I thought, "okay, that's weird".  I noted it my case notes and continued on with my analysis, knowing that I'd get to the bottom of this issue.

First, parsing the index.dat.  Similar to the Event Logs, I've got a couple of tools that I use, one that parses the file based on the header information, and the other that bypasses the header information all together and parses the file on a binary basis.  These tools provide me with visibility into the records recorded within the files, as well as allowing me to add those records to a timeline as necessary.  I've also developed a modified version of Jon Glass's WebCacheV01.dat parsing script that I use to incorporate the contents of IE10+ web activity database files in timelines.

So, back to why the index.dat file for a user account (and profile) created in Dec 2015 contained activity from 2013.  Essentially, there was malware on the system in 2013 running with System privileges and utilizing the WinInet API, which resulted in web browser activity being recorded in the index.dat file within the "Default User" profile.  As such, when the new user account was created in Dec 2015, and the account was used to access the system, the profile was created by copying content from the "Default User" profile.  As IE wasn't being used/launched via the Windows Explorer shell (another program was using the WinInet API), the index.dat file was not subject to the cache clearance mechanisms we might usually expect to see (by default, using IE on a regular basis causes the cache to be cleared every 20 days).

Getting to the bottom of the analysis didn't take days or weeks of analysis...it just took a few minutes to finish up documenting (yes, I do that...) what I'd already found, and then circling back to confirm some findings, based on a targeted approach to analysis.

Updates

RegRipper Plugin Updates
I made some updates to a couple of plugins recently.  One was to the networklist.pl/networklist_tln.pl plugins; the update was to add collecting subkey names and LastWrite times from beneath the Nla\Cache\Intranet key.  At this point, I'm not 100% clear on what the dates refer to, but I'm hoping that will come as the data is observed and added to timelines.

I also updated the nic2.pl plugin based on input from Yogesh Khatri.  Specifically, he found that in some cases, there's a string (REG_SZ) value named "DhcpNetworkHint" that, if you reverse the individual nibbles of the string, will spell out the SSID.

This is an interesting finding in a couple of ways.  First, Yogesh found that by reading the string in hex and reversing the nibbles, you'd get the SSID.  That in itself is pretty cool.  However, what this also says is that if you'd doing a keyword search for the SSID, that search will not return this value.

jIIr
Corey's most recent blog post, Go Against The Grain, is a pretty interesting read.  It is an interesting thought.  As a consultant, I'm not usually "in" an infrastructure long enough to try to effect change in this manner, but it would be very interesting to hear how others may have utilized this approach.

"New" Tools
Eric Zimmerman recently released a tool for parsing the AmCache.hve file, which is a "new" file on Windows systems that follows the Registry hive file format.  So, the file follows the same format as the more "traditional" Registry hive files, but it's not part of the Registry that we see when we open RegEdit on a live system.

Yogesh Khatri blogged about the AmCache.hve file back in 2013 (here, and then again here).

While Eric's blog post focuses on Windows 10, it's important to point out that the AmCache. hve file was first seen on Windows 8 systems, and I started seeing them in images of Windows 7 systems since about the beginning of 2015.  Volatility has a parser for AmCache.hve files found in memory, and RegRipper has had a plugin to parse the AmCache.hve file since Dec, 2013.

I applaud Eric for adding a winnowing capability to his tool; in an age where threat hunting is a popular topic for discussion, data reduction (or, "how do I find the needle in the haystack with no prior knowledge or experience?") is extremely important.  I've tried doing something similar with my own tools (including, to some extent, some RegRipper plugins) by including an alerting capability based on file paths found in various data sources (i.e., Prefetch file metadata, Registry value data, etc.).  The thought behind adding this capability was that items that would likely be of interest to the analyst would be pulled out.  However, to date, the one comment I've received about this capability has been, "...if it says 'temp was found in the path', what does that mean?"

Again, Eric's addition of the data reduction technique to his tool is really very interesting, and is very likely to be extremely valuable.

Shell Items
I had an interesting chat with David Cowen recently regarding stuff he'd found in LNK files; specifically, Windows shortcut/LNK files can contain shell item ID lists, which can contain extremely valuable information, depending upon the type of examination you're performing.  Specifically, some shell item ID lists (think shellbags) comprise paths to files, such as those found on network shares and USB devices.  In many cases, the individual shell items contain not only the name of a folder in the path, but also timestamp information.  Many of the shell items also contain the MFT reference number (record number and sequence number combined) for the folder.  Using this information, you can build a historical picture of what some portion of the file system looked like, at a point in the past.

Conference Presentations And Questions
Many times when I present at a conference and open up for questions, one question I hear many times is, "What's new in Windows (insert next version number)?"  Many times, I'm sort of mystified by questions like this, as I don't tend to see the "newest hotness" as something that requires immediate attention if analysts aren't familiar with "old hotness", such as ADSs, Registry analysis, etc.

As an example, I saw this tweet not long ago, which led to this SANS ISC Handler's Diary post.  Jump Lists are not necessarily "new hotness", and have been part of Windows systems since Windows 7.  As far as resources go, the ForensicsWiki Jump Lists page was originally created on 23 Aug 2011.  I get that the tweet was likely bringing attention back to something of value, rather than pointing out something that is "new".

As a bit of a side note, I tend to use my own tools for parsing files like Jump Lists, because the allow me to incorporate the data in to the timelines I create, if that's something I need to do.