I mentioned previously that I've been preparing for an upcoming Timeline Analysis course offered through my employer.  As part of that preparation, I've been using the tools to walk through the course materials, and in particular one of the hands-on exercises that we will be doing in the course.

One of the things I'd mentioned in my previous post is that Rob Lee has done a great deal of work for SANS, particularly in providing an Excel macro to add color-coding of different events to log2timeline output files.  I've had a number of conversations and exchanges with Corey Harrell and others (but mostly Corey) regarding event categorization, and the value of adding these categories to a timeline in order to facilitate analysis.  This can be particularly useful when working with Windows Event Log data, as there a good number of events recorded by default, and all of that information can be confusing if you don't have a quick visual reference. 

As I was running through the exercises, I noticed something very interesting in the timeline with respect to the use of the Autoruns tool from SysInternals; specifically, that there were a good number of artifacts associated with both the download and use of the tool.  I wanted to extract just those artifacts directly associated with Autoruns from the timeline events file, in order to demonstrate how a timeline can illustrate indications of program execution.  To do so, I ran the following command:

...and then to get my timeline...


...and got the following:


What I find most interesting about this timeline excerpt is that it illustrates a good deal of interaction with respect to the download and launch of the tool within it's eco-system, clearly demonstrating Locard's Exchange Principle.  Now, there are also a number of things that you don't see...for example, this timeline is comprised solely of those lines that included the word "autoruns" (irrespective of case) somewhere in the line; as such, we won't see things such as the query to the "Image File Execution Options" key, to determine if there's been a debugger assigned to the tool, nor do you see ancillary events or those that might be encoded.  However, what we do see will clearly allow us to "zoom in" on a specific time window within the overall timeline, and see what other events may be listed there.

The timeline is clearly very illustrative.  We can see the download of the tool (in this case, via Chrome to a Windows 7 platform), and the assignment of the ":Zone.Identifier" ADSs, something that with XP SP2 was done only via IE and Outlook.  Beyond the file system metadata, we start to see even more context, simply by adding additional data sources such as the Registry AppCompatCache value data, UserAssist value data, information derived from the SysInternals key in the user's Registry hive, Jump Lists, etc.  In this case, the Jump List info in the timeline was extracted from the DestList stream found in the Jump List for the Windows Explorer shell, as zipped archives will often be treated as if they were folders.

Another valuable aspect of this sort of timeline data is that it is very useful in the face of the use of counter-forensics techniques, even those that may be unintentional (i.e., performed by an administrator, not to hide data, but to "clean up" the system).  Let's say that this tool had been run, and then deleted; remove all of the "FILE" entries that point to C:/tools from the above timeline, and what do you have left?  You have those artifacts that persist beyond the deletion of files and programs, and provide clear indicators that the tools had been used.  We can apply this same sort of analysis to other situations where tools had been run (programs executed) on a system, and then some steps taken to obviate or hide the data.

M... [Program Execution] AppCompatCache - C:\tools\autorunsc.exe

The "M..." refers to the fact that, as pointed out by Mandiant, when the tool is run, the file modification time for the tool is recorded in the data structure within the AppCompatCache value.  The "[Program Execution]" category identifier, in this case, indicates that the CSRSS flag was set (you'll need to read Mandiant's white paper).  The existence of the application prefetch file for the tool, as well as the UserAssist entry, help illustrate that the program had been executed.

One of the unique things about the SysInternals tools is that after they were taken over by Microsoft, they began to have EULA acceptance dialogs added to them.  Now, there is a command line switch that you can use to run the CLI versions of the tools and accept the EULA, but the tools will create their own subkey beneath the SysInternals key in the Software hive, and set the "EulaAccepted" value.  Even if the tool is renamed, these same artifacts will be left on a system.

File system metadata was extracted from the acquired image using TSK fls.exe.  As such, we know that the MACB times are from the $STANDARD_INFORMATION attribute within the MFT, which are highly mutable; that is to say, easily modified to arbitrary values.  We can see from the timeline that Autoruns.zip was downloaded on 15 May, and according to the SysInternals web site, an updated version of the tool was posted on 14 May.  The files were extracted from the zipped archive, carrying with them some of their original file times, which is why we see ".A.B" times prior to the date that the archive was downloaded.  Had the file times been modified to arbitrary values (i.e., "stomped"), rather than the files being deleted, we would still see the other artifacts listed in the timeline, in that order.  In essence, we'd have a "signature" for program execution.

Other sources of data that would not appear in a timeline can include, for example, the user's MUICache key.  This key simply holds a list of values, and in a number of exams, I've found references to malware that was run on the system, even after the actual files had been removed.  Also, if the AutoRuns files had been deleted, I could parse the AutoRuns.lnk Windows shortcut file to get the path to, as well as the MA.B times for, the target file.  In order to illustrate that, what follows is the raw output of an LNK file/stream parser:

atime                         Tue May 15 21:11:59 2012                         
basepath                    C:\Users\                                        
birth_obj_id_node       08:00:27:dd:64:d1                                
birth_obj_id_seq         9270                                             
birth_obj_id_time        Tue May 15 21:09:27 2012                         
birth_vol_id                 2C645C57D81C5047B7DDE13C2834AAD2                 
commonpathsuffix       john\Downloads\Autoruns.zip                      
ctime                           Tue May 15 21:11:59 2012                         
filesize                        535772                                           
machineID                  john-pc                                          
mtime                         Tue May 15 21:11:59 2012                         
netname                     \\JOHN-PC\Users                                  
new_obj_id_node        08:00:27:dd:64:d1                                
new_obj_id_seq          9270                                             
new_obj_id_time        Tue May 15 21:09:27 2012                         
new_vol_id                 2C645C57D81C5047B7DDE13C2834AAD2                 
relativepath                ..\..\..\..\..\Downloads\Autoruns.zip            
vol_sn                        F405-DAC1                                        
vol_type                     Fixed Disk                            

The "mtime","atime", and "ctime" values correspond to the MA.B times, respectively, of the target file, which in this case is the Autoruns.zip archive.  As such, I could either go back and add the LNK info to my timeline, or automatically have that information added during the initial process of collecting data for the timeline.  In this case, what I would expect to see would be MA.B times from both the file system and the LNK file metadata at exactly the same time.  Remember, the absence of an artifact where we expect to find one is itself an artifact, and as such, if the Autoruns.zip file system metadata was not available, that would tell me something and perhaps take my analysis in another direction.

[Note: I know you're looking at the above output and thinking, "wow, that looks like a MAC address in the output!"  You're right, it is.  In this case, looking up the OUI leads us to Cadmus Systems, and yes, the system was from a VM running in VirtualBox.  Also, there's a good deal of additional information available in the LNK file metadata, to include the fact that the target file was on a fixed disk, as opposed to a removable or network drive.]

The Value of Multiple Data Sources
Regarding the value of data from multiple sources (even additional locations within the same source, in a comment to his post regarding a RegRipper plugin that he'd written, Jason Hale points out, quite correctly:

I didn't think there was a whole lot of value in the information from the TypedURLsTime key itself (other than knowing that computer activity was occurring at that time) without correlating it with the values in TypedURLs.

Jason actually wrote more than one plugin to extract the TypedURLsTime value data (this key is specific to Windows 8 systems). I've looked at the plugin that outputs in TLN format, for inclusion in a timeline...I use a different source identifier in version I wrote (I use "REG", for consistency...Jason uses "NTUSER.DAT").  However, we both reached point B, albeit via different routes.  This will definitely be something I'll be including in my Windows 8 exams.

Key Concepts
1. Employing multiple data sources to develop a timeline of system activity provides context, as well as increases our relative confidence in the data itself.
2. Employing multiple data sources can demonstrate program execution.
3. Employing multiple data sources can illustrate and overcome the use of counter-forensics activities, however unintentional those activities may be.

As a follow-up to my recent Jump List Analysis blog post, I've posted the Jump List parser code that I've been talking about.

Again, this isn't a Windows GUI program.  The code consists of two Perl modules that I wrote (and I'm not an expert in either Perl OO programming or writing Perl modules...), and the available archive contains a couple of of example scripts that demonstrate simple uses of the modules. 

I wrote these modules in order to provide maximum flexibility to the analyst.  For example, I use a five-field timeline (TLN) format for a good bit of my analysis, and that's not something I can get from available tools...not without manually exporting the contents of those tools and writing a separate parser.  Also, I know some folks who really love to use SQLite databases (MarkMcKinnon), so providing the code in this manner allows those analysts to write scripts using the Perl DBI to access those databases.

Also, I know that analysts like Corey Harrell will be itching to rip previous versions of Jump List files from VSCs.  As such, scripts can be written to parse just the DestList streams out of previous versions of the *.automaticDestinations-ms Jump List files and correlate that data.

The archive also contains a user guide that I wrote that explains not only the modules but how to use them and what data they can provide to you.

As a side note, I ran the lnk.pl script provided in the archive through Perl2Exe to create a simple, standalone Windows EXE file, and then ran it against the same target file (a shortcut in my own Recent folder) that I had tested the Perl script on, and it worked like a champ.

Once again, I am not an expert.  These modules should be fairly stable, and I wouldn't expect them to crash your box.  However, they are provided as-is, with no warranties or guarantees as to their function. Also, the code uses only core Perl functions and parses the target structures on a binary level, so it's entirely possible that I may have missed a structure or parsed something improperly.  If you find something amiss, I'd greatly appreciate you letting me know, and providing some sample data so that I can replicate and address the issue.

That being said, I hope that folks find this code to be useful.

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

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.

ADSs
I've been fascinated by NTFS alternate data streams for almost 14 years now, and I caught MHL's recent blog post on detecting stealth ADSs with TSK tools.  The idea behind a "stealth ADS" came from this Exploit Monday post, and both posts were very interesting reads.

ADSs are one of those NTFS artifacts that many folks (DF analysts, admins, etc.) don't really know a whole lot about, and I'm not sure why.  I guess it's a chicken-or-the-egg issue; how do you know that there aren't any ADSs on your systems if you're not looking for them?  If you don't look for them, why do you then need to know about them...right?  I remember about 11 years ago, Benny and Ratter of the group 29A wrote Win32/Stream, mostly as a proof of concept.

F-Response
If you haven't heard of Matthew Shannon's F-Response, I'd really have to question where've you been.  F-Response is one of those tools that have really pushed incident response work ahead by leaps and bounds.  Using F-Response, you can reach out systems on another floor, in another building, or even in another city, and make a read-only connection to the physical disk, and from there, run tools to search for specific items, collect specific files, or even conduct a physical or logical acquisition.  With Windows systems, you can even collect the contents of physical memory.

Matt's added the FlexScript scripting capability to F-Response, and through Powershell, recently demonstrated how to use F-Response to automate large collections.  As always, Matt includes a video so you can see what he did, in addition to providing the scripts along with the F-Response Mission Guides.

This adds a whole new dimension to an already-valuable tool; being able to automate large-scale collections is a powerful capability.  If an incident occurs, an organization can use this capability to automate quickly connecting to systems and either collecting data, or

Live Forensics
Speaking of Matt Shannon, thanks to his Twitter account, I was recently directed to this paper, which is intended to dispel some of the myths of live digital forensics.  The paper is just 5 pages long, so I printed it out so I could read it...and found it very interesting.  The paper essentially addresses (and shoots down) three common myths that are encountered within the digital forensics community regarding live forensics, and does so only with respect to the admissibility of "live" digital evidence in a US court of law.  I can see how this distinction is important for the paper, particularly in driving its point home.  Additional discussion in dispelling the myths would extend the length of the paper unnecessarily, and potentially make the argument a bit murky.  In short, each of the myths is addressed with "...the Court makes no requirement...".

This is similar to conversations I've had with Chris Pogue, during which we've discussed "court certified" tools; this is something we've both heard, and the long and short of the discussion is that there is no such thing, regardless of what folks (including marketing staff) my choose to believe or say.


Volatility
Here's a post on the malwarereversing blog that discusses (and provides) the vscan.py plugin for Volatility 2.0, which allows you to submit malicious stuff you've found in a Windows memory dump to an online AV scanning site (the post uses Jotti).

The blog post also mentions MHL's avsubmit.py plugin, which allows for the submission of stuff you've found to VirusTotal.

Tools
I ran across the CERT Linux Forensics Tools Repository recently; very cool.  Not only are some of my tools posted there (i.e., RegRipper, tln_tools) but many of the ones listed also run on Winderz!

Mark Woan recently updated JumpLister to include parsing of DestList streams, as well as looking up AppIDs. It appears from the JumpLister web page that the DestList parsing capability was added based on the information available in the ForensicsWiki, which really shows how useful and powerful a resource the ForensicsWiki can be.  Mark's application downloads as part of an installer package, and it only runs on Windows.  The installer adds 11 files to your system, and when you run it, you can load one autodest JumpList at a time.  The tool did a great job of parsing the DestList stream on the few files I loaded.  Mark mentioned in the Win4n6 Yahoo group that he changed the functionality of the tool, so that instead of loading the entire compound file, it first parses the DestList stream, and then looks for the numbered streams identified in the DestList stream.  Jimmy Weg reports that XWays now supports parsing autodest JumpLists, including the DestList streams.

I hope that with the information in the ForensicsWiki, and a number of available tools (free and otherwise) supporting parsing of these artifacts, that maybe this will push folks to start looking at these files as a valuable forensics resource.  Since I started posting about Jump List analysis, I've created my own code for parsing these files, including not only the compound files that the autodest Jump Lists are stored in, but also the LNK streams and the DestList stream.  This code allows me a great deal of flexibility, not only to troubleshoot issues with "misbehaving" Jump List files, but also to modify the output into any format I desire (CSV, TLN), either to analyze separately or include in a timeline.  I've seen the value of Jump Lists in forensic analysis, and I hope others begin to parse these files and include them in their analysis.

AutoRuns Update
AutoRuns has been updated to version 11, to include a "jump to folder" capability, as well as several new autostart locations.  I haven't gone through all of them yet, but this looks very promising.


Speaking of autostart mechanisms, Martin Pillion recently posted to the HBGary blog regarding malware's use of Local Group Policy to maintain persistence on a system.  I found the blog post fascinating (it's always interested to see stuff you've seen talked about before), albeit a bit hard to follow in some places; for example, just below figure 4, the second sentence states:


What section?  I see the "following line", but for the casual reader (or perhaps someone not quite as knowledgeable in this area), this can be confusing.  Overall, however, this doesn't really take much away from this persistence mechanism.  I mention it here (rather than in its own section), as according the blog post, the new version of AutoRuns does NOT detect this persistence mechanism.

Several other MS/SysInternals tools have been updated, as well, to including ProcDump and Process Explorer.

DFF
DFF RC 1.2 is available.

Dan recently posted on Jump Lists on his blog, and provided a list of AppIDs, which can be used to augment what Mark posted on the ForensicsWiki.

So what happens if you run across an AppID that's not on one of the lists?  Recently Jamie (Twitter: @gleeda) suggested determining the algorithm used to generate AppIDs, but what if the algorithm is a one-way hash, similar to what is used to compute the hashes in Prefetch file names?  If that's the case, then having the AppID alone doesn't provide a means for determining the application name (i.e., if the hash is one-way).  So, what else can be done?

Well, this would be a great time for timeline analysis.  After all, it's unlikely that the only thing you'll want to determine is the name of the application that corresponds to the AppID; it's much more likely that that will be the first (or one) question of several.

When developing your timeline of system activity from a Windows 7 system, you'll likely have Prefetch files, Windows Event Log (EVTX) files, file system metadata, Registry key LastWrite times, time stamped information from Registry values, etc.  Also, when you parse the DestList stream from the *.automaticDestinations Jump List files (particularly the one you're interested in), you'll have an MRU/MFU listing that you can add to the timeline.  So what you'd normally look for (as with a Windows XP system) is that an entry was added to or modified within the Jump List file around the time that an application .exe was accessed...but wait...by default, Windows 7 (and Vista) doesn't update last access times on files!  Holy MFT, Batman!  What now?

Or, what happens if the user installs an application, does some stuff, and then deletes the application?  Even if the Windows 7 system had been tweaked to update last access times on files, if the application is deleted and the executable file isn't available (MFT entry is overwritten...)...well, you can see where I'm going with this...

There is a solution to determining which application used in both of the above scenarios.  One of the forensically interesting aspects of Jump Lists is that they persist on the system even after the application has been removed.  We can use other, similar artifacts, such as Prefetch file metadata and UserAssist key entries (which also persist on a system after the application that was launched has been removed) to correlate the necessary information.  For example, if a user installed an application (via an MSI package), you'd see that activity in the UserAssist key (as well as the MSI key listing).  If they then launched the installed app, you'd also likely (depending upon how it was launched) see that in the UserAssist key, and then you'd see a Prefetch file being created in close proximity to the launch.  You should also see the Jump List file being created within close proximity to the UserAssist key and Prefetch file data. 

Once the application is removed from the system, you shouldn't see any further modifications to the Prefetch file or Jump List file data.  If you found that the application appeared to have been run multiple times, then you should be sure to look to VSCs for additional available time stamped data.

What I hope this demonstrates is how analysis techniques such as timelines not only provide context to the data that you're looking at, but by incorporating multiple data sources, you increase your relative level of confidence in the data itself.  Understanding the nature and value of those data sources also means that not only do you understand what should be there, but you can also fill the gaps when something (i.e., an application) is intentionally removed or deleted.

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)

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