My last post addressed parsing Java *.idx files, and since I released that post, a couple of resources related to the post have been updated.  In particular, Joachim Metz has updated the ForensicsWiki page he started to include more information about the format of the *.idx files, with some information specific to what is thought to be the header of the files.

Also, Corey Harrell was kind enough to share the *.idx file from this blog post with me (click here to see the graphic of what the file "looks like" in Corey's post), and I ran it through the parser to see what I could find:

File: d:\test\781da39f-6b6c0267.idx

Times from header:
------------------------------
time_0: Sun Sep 12 15:15:32 2010 UTC
time_2: Sun Sep 12 22:38:40 2010 UTC

URL: http://xhaito.com/work/builds/exp_files/rox.jar
IP: 91.213.217.31

Server Response:
------------------------------
HTTP/1.1 200 OK
content-length: 14226
last-modified: Sun, 12 Sep 2010 15:15:32 GMT
content-type: text/plain
date: Sun, 12 Sep 2010 22:38:35 GMT
server: Apache/2
deploy-request-content-type: application/x-java-archive

Ah, pretty interesting stuff.  Again, the "Times from header" section is comprised of, at this moment, data from those offsets within the header that Joachim has identified as possibly being time stamps.  In the code, I have it display only those times that are not zero.  What we don't have at the moment is information about the structure of the header so that we can identify to what the time stamps refer.

However, this code can be used to parse *.idx files and help determine to what the times refer.  For example, in the output above we see that "time_0" is equivalent to the "last modified" field in the server response, and that the "time_2" field is a few seconds after the "date" field in the server response.  Perhaps incorporating this information into a timeline might be useful, while research continues in order to identify what the time stamps represent.  What is very useful is that the *.idx files are associated with a specific user profile, so for testing purposes, an analyst should be able to incorporate browser history and *.idx info into a timeline, and perhaps be able to "see" what the time stamps may refer to...if the analyst were to control the entire test environment, to include the web server, even more information may be developed.

Speaking of timelines, Sploited commented to my previous post regarding developing timelines analysis pivot points from other resources; in the comment, a script for parsing IE history files (urlcache.pl) was mentioned; I would suggest that incorporating a user's web history, as well as incorporating searches against the Malware Domain List might be extremely helpful in identifying initial infect vectors and entry points.

---

Interested in Windows DF training?  Check it out: Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar.  Be sure to check the WindowsIR Training Page for updates.

I've talked a lot in this blog about employing event categories when developing, and in particular, when analyzing timelines, and the fact is that we can use these categories for much more that just adding analysis functionality to our timelines.  In fact, using artifact and event categories can greatly enhance our overall analysis capabilities.  This is something that Corey Harrell and I have spent a great deal of time discussing.

For one, if we categorize events, we can raise our level of awareness of the context of the data that we're analyzing.  Having categories for various artifacts can help us increase our relative level of confidence in the data that we're analyzing, because instead of looking at just one artifact, we're going to be looking at various similar, related artifacts together.

Another benefit of artifact categories is that they help us remember what various artifacts relate to...for example, I developed an event mapping file for Windows Event Log records, so as a tool parses through the information available, it can assign a category to various event records.  This way, you no longer have to search Google or look up on a separate sheet of paper what that event refers to...you have "Login" or "Failed Login Attempt" right there next to the event description.  This is particularly useful, as of Vista, Microsoft began employing a new Windows Event Log model, which means that there are a LOT more Event Logs than just the three main ones we're used to seeing.  Sometimes, you'll see one event in the System or Security Event Log that will have corresponding events in other event logs, or there will be one event all by itself...knowing what these events refer to, and having a category listed for each, is extremely valuable, and I've found it to really help me a great deal with my analysis.

One way to make use of event categories is to employ an analysis matrix.  What is an "analysis matrix"?  Well, what happens many times is that analysts will get some general (re: "vague") analysis goals, and perhaps not really know where to start. By categorizing the various artifacts on a Windows system, we can create an analysis matrix that provides us with a means for at least begin our analysis.

An analysis matrix might appear as follows:

	Malware Detection	Data Exfil	Illicit Images	IP Theft
Malware	X		X
Program Execution	X	X		X
File Access		X	X	X
Storage Access		X	X	X
Network Access				X

Again, this is simply a notional matrix, and is meant solely as an example.  However, it's also a valid matrix, and something that I've used.  Consider "data exfiltration"...the various categories we use to describe a "data exfiltration" case may often depend upon what you learn from a "customer" or other source.  For example, I did not put an "X" in the row for "Network Access", as I have had cases where access to USB devices was specified by the customer...they felt confident that with how their infrastructure was designed that this was not an option that they wanted me to pursue.  However, you may want to add this one...I have also conducted examinations in which part of what I was asked to determine was network access, such as a user taking their work laptop home and connecting to other wireless networks.

The analysis matrix is not intended to be the "be-all-end-all" of analysis, nor is it intended to be written in stone.  Rather, it's intended to be something of a living document, something that provides analysts with a means for identifying what they (intend to) do, as well as serve as a foundation on which further analysis can be built.  By using an analysis matrix, we have case documentation available to us immediately.  An analysis matrix can also provide us with pivot points for our timeline analysis; rather than combing through thousands of records in a timeline, we now not only have a means of going after that information which may be most important to our examination, but it also helps us avoid those annoying rabbit holes that we find ourselves going down sometimes.

Finally, consider this...trying to keep track of all of the possible artifacts on a Windows system can be a daunting task.  However, it can be much easier if we were to compartmentalize various artifacts into categories, making it an easier task to manage by breaking it down into smaller, easier-to-manage pieces.  Rather than getting swept up in the issues surrounding a new artifact (Jump Lists are new as of Windows 7, for example...) we can simply place that artifact in the appropriate category, and incorporate it directly into our analysis.

I've talked before in the blog about how to categorize various artifacts...in fact, in this post, I talked about the different ways that Windows shortcut files can be categorized.  We can look at access to USB devices as storage access, and include sub-categories for various other artifacts.

---

Interested in Windows DFIR training?  Check it out...Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar.

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.

I finished up leading a Timeline Analysis Course on Tuesday afternoon, ending two days of some pretty intensive training.  One of the things I find when I'm putting presentations or courses together, and then actually giving the presentation, is that I very often end up learning a good deal along the way, and this time around was no different.  As has happened in the past, what I learn leads me to revisit and possibly even modify tools or analysis techniques, and again, this time was no different.

One of my biggest takeaways from the training is that I need to reconsider how at least some of the available time stamped data is presented in a timeline.  One of those items is how Prefetch file metadata is represented and displayed; I've since updated the parsing tool to address this particular item.  Another, and the one I'm going to discuss in this blog post, is how Windows shortcut (LNK file) information might be displayed in a timeline, or more specifically, what information about LNK files might possibly need to be presented in a timeline.

Category IDs
So, as a bit of background, I've been thinking quite a lot lately about how to better take advantage of timeline data.  As I was putting the timeline course together, it occurred to me that I was going to be spending a good deal of time describing to attendees how to create a timeline, and even walking them through this process with demonstrations and hands-on exercises, but spending very little time discussing how to actually analyze the timeline data.  The simplest answer is, it depends.  It depends on your exam goals, why you're performing the exam, and why you created a timeline in the first place.  It occurred to me that I was making an assumption that most analysts would have a good solid justification for creating a timeline as part of their analysis process.  If that were the case every time, I wouldn't have folks signing up for a timeline analysis course, would I?  I'm not saying that analysts don't have a justification for creating a timeline, but sometimes that justification be, "...that's what we always do...", or "...that's what I did last time."

Timeline analysis is something of a data reduction technique...we go from a 500GB hard drive or image, to somewhere around a GB or so of data, and we then arrange it based on a time value in the hopes of obtaining some context and increasing our relative confidence in the data that we're looking at; that's the goal, anyway.  But by grabbing just the data directly associated with a time value, we end up performing a great deal of data reduction.  Even so, we still need a means for directing our analysis, or getting the cream to rise to the top of the container.

Something I'd discussed in a previous blog post was the concept of categories for events.  Rob Lee has done some considerable work in this area already, providing a color-coded Excel macro that implements the category ID scheme he's identified via resources such as the SANS DFIR poster.  Regardless of the method used to identify event types or categories, the idea is to develop some method to assist the examiner in her analysis of the timeline.  After all, if you have something of an idea of what you're looking for, then finding it might be a bit easier if you classify various events by type or category, and then have some means to identify the events accordingly (via color, a tag or identifier, etc.).

Shortcut/LNK Files
Speaking of categories, perhaps one of the most difficult artifacts to classify into a single category is Windows shortcut/LNK files.  Without getting into a long discussion about this, let's take a look at an example of what's available in an LNK file found in a user's Recent folder:

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                 2C645C57...13C2834AAD2                 
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                 2C645C57...13C2834AAD2                 
relativepath                ..\..\..\..\..\Downloads\Autoruns.zip            
vol_sn                        F405-DAC1                                        
vol_type                     Fixed Disk          

As you can see, we have a number of data elements available to us once we've decoded the binary contents of the LNK file, any of which (or any combination of which) may be relevant or significant to our analysis.  For example, as the LNK file was found in the user's Recent folder, we can assume that the existence of the file indicates some form of user activity; that is, the user must have done something, must have performed a specific action (such as double-clicking the file) that caused that LNK file to be created.

Next, we have the path to where the target file was located within the file system, as well as the MA.B times of the target file at the time that the shortcut was created. That might be significant to your analysis, as it demonstrates both knowledge of and access to a file, and will persist even after the target file is no longer available.

Had the LNK file been located on the user's Desktop and pointed to an EXE target file, this might illustrate specific actions taken by the user, such as installing an application.  This might also indicate program execution, rather than file access.

If the target file in the shortcut is a document or image, this might also illustrate program execution.  Launching the shortcut would cause the Windows system to reach into the Registry in order to determine which application with which files with the target file's extension are associated.  For example, let's say a shortcut "points to" a .avi video file.  On some systems, launching a shortcut that points to a video file might cause Windows Media Player to be launched automatically; on other systems, it might be another application all together.  Either way, the existence of an LNK file might also illustrate program execution or application launch.

Finally, we see that the last item visible in our example is called "vol_type", which refers to the type of volume where the target file was at the time of the activity.  In this case, the C:\ volume is a "Fixed Disk"; if it wasn't, would that be significant?  For example, if the volume type were "removable media" or a "network share", would that be significant to your exam?  In some cases, it could very well be, and we might look to that information for indications of access to or use of removable storage devices, or of network shares.

Perhaps the idea here isn't to classify LNK files into a single category, but instead filter the various data items found within LNK files based on a set of rules, and produce timeline events based on the output of each of the rules, where appropriate.  This might mean that for a single LNK file, we might end up with multiple events in our timeline.

Resources
ForensicsWiki LNK page

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.

Timelines
The Sploited blog has part 3 of the Forensic Timeline for Beginners series of posts up, and there are a couple of interesting and useful things mentioned in the post that I wanted to point out.

First, the posts make use of Lance's first practical to illustrate developing a timeline.  Why is this interesting?  Well, even though Lance has closed his blog, he has left the content up.  So, while it's sad to see Lance go, I'm grateful that he's left the information and images up on the 'net.  This first practical has some very interesting artifacts

The post includes the statement:
"For some reason RegRipper said this registry entry was not found. I'm not sure why this was at this point and decided to move on and try the application ProDiscover."

Okay, we can see from the graphic that follows that statement that the key in question does not appear to exist in the System hive within the image.  Creating a ProDiscover project is a great way to troubleshoot the issue; "hey, this tool says that this artifact isn't available, I'd better check it out."  I've heard from a couple of folks who use RegRipper and have told me that it has reduced the Registry analysis portion of their exams from days or hours to just minutes; if that's the case, and it's only taking you a few minutes to do something that normally takes hours,  why not take a minute to troubleshoot or verify your findings?  It's pretty quick and easy to do...

Overall, this has been a very interesting set of blog posts for me to follow along and read, as this mirrors much of what I see when I conduct training courses on Timeline Analysis, as well as other Windows Forensic Analysis topics. 

SQLite
Here is an excellent article that addresses information regarding the SQLite Write Ahead Log (-wal file).  While SQLite databases are found in a number of locations on Windows systems (Firefox places.sqlite and Chrome History file, as well as in iTunes iPhone backups, etc.), they aren't only found on Windows systems.  As such this information can be very important to analysts who encounter a number of different target platforms.

Cyber Espionage
This post to the ShadowServer blog provides some excellent insight into the world of cyber espionage, and specifically strategic web compromises.  Some of what's discussed in the post takes me back to what I mentioned previously in this blog regarding defense driven by intelligence, not FUD.


LFO
According to Grady Summers over at the Mandiant blog:
"...the very systems that hold the data targeted by an attacker are probably the least likely to have malware installed on them."

I think that's a very interesting distinction to make, and one that goes right along with Peter Silberman's comment a while back about LFO, or "least frequency of occurrence".

e-Evidence
The e-Evidence "what's new" page was updated just a bit ago...this site is always an excellent resource for information that you may not have known was out there and available.

Windows 8 Forensics Guide
You can now find a free Windows 8 forensics guide over on the Propeller Head Forensics blog.  Amanda's guide is a great way to get started learning about some of the new things that you're likely to see in Windows 8 (if you aren't already running the Consumer Review edition)

I had an opportunity to meet and listen to Christopher Ard of MS talk about some of the neat new features of Windows 8 recently at the Massachusetts Attorney General's Cyber Crime Conference.  I also sat in on Chris Brown's presentation on ProDiscover, and he stated that he's working on adding support for the new ReFS file system to ProDiscover.  Looks like there are lots of cool things on the horizon with Windows 8 forensic analysis.

Timelines
The Sploited blog has posted part 2 (part 1 is here) of the Forensic Timelines for Beginners series, in which they discuss creating timelines using the tools and techniques illustrated in chapter 7 of Windows Forensic Analysis Toolkit 3/e. 

File System Behavior
There's an interesting thread over on the Win4n6 Yahoo Group regarding file system behavior when files are deleted, including removed from the Recycle Bin.  During the thread, one of members made the statement that during some vendor training, they'd been told that when files are deleted, Windows will automatically securely wipe the files.  This is, in fact, not the case, as Troy Larson clearly states during the thread.

What this does being up, as Troy says later in the thread, is that Windows systems are extremely active under the hood.  During the thread, several members say that they did their own testing and found that files were not securely deleted...what this comes back to is that some files may be very quickly overwritten by normal system activity.  This is something that I've pointed out in my books and presentations for some time, particularly when talking about the need for immediate response.  Troy even mentions in a follow-up post that "just opening and editing a Word file creates several temporary and scratch files--more than you would image."  Even with no specific user interaction, Windows systems have a great deal of activity that go on behind the scenes...look at some of the performance enhancements for XP described here, and in particular in the "Prefetch" section.  Windows 7 is very similar, in that it ships with a Scheduled Task that performs a defrag once a week, and another that backups up the main Registry hives every 10 days.  Add to that all of the other activity that occurs on Windows systems, and it's not surprising that some folks are seeing, on an inconsistent basis, that Windows appears to be securely wiping files upon deletion.  This is very important for DF analysts to keep in mind while performing analysis and file or record carving, but also for incident responders to keep in mind, particularly when developing IR procedures...the more immediate the response, the fresher and more pristine data you will be able to preserve.

Resources
MS File System Behavior Overview

SQLite WAL Files
The DigitalInvestigation blog has an excellent post on SQLite Write Ahead Log files, and their potential as a forensic resource.  I've seen these, as well, in the course of forensic impact analysis, and this is a very good read for folks who want to get a little bit familiar with what these files are all about, and how they can be useful during an examination.

Scripting
Melissa's got a very good post up that demonstrates how useful scripting skills (or "skillz") can be.  Over the years that I've done infosec work, I've found that an ability to write scripts has been invaluable, and I've found that to be even more true in the DFIR realm.  I once held an FTE position where I wrote a Perl script that would reach out across the enterprise, locate all systems that were turned on, query certain Registry keys and return the results to me.  As I began investigating my findings, I was able to develop a white list, and within relatively short order got to the point where I could launch the script before lunch, and return to find a report that was about half a page in length. 
I was able to provide a viable solution that worked extremely well in my environment (rather than fitting the problem to a commercial tool), for free.

If you're interested in trying out some of the things she demonstrates on your Windows box, check out the Resources section below.

Resources
Unix Command Line Tools for Windows
Utilities and SDK from MS
Unix Utilities

Encryption
Encryption has long been a thorn in the side for examiners.   I've had a number of engagements where I was asked to acquire images of systems known to be encrypted, and more than a few where we found out after we got on-site that some of the systems employed whole disk encryption.  In those cases, we opted for a live acquisition via FTK Imager (fully documented, of course).  It appears that Jesse has found found a free program that can reportedly decrypt BitLocker-protected volumes.

PE Files
If you do PE analysis, check out the CorkAmi Google Code site.  There's a good deal of very good information there, as well as detailed information regarding the PE file format.

I recently conducted some research into a specific event/activity on a system, and found that timeline analysis proved to be an extremely valuable technique to use in this case.  I see a good number of questions online in the various forums asking about what could lead to a particular event, and in most cases, I ask the poster if they'd considered generating a timeline.  After all, any time you're interested in an event that occurred, particularly one that occurred at a specific time, generating and analyzing a timeline is a great way to answer that question.  It's also a great way to conduct analysis as part of research.

As indicated in my previous post, I had read online that the volume GUIDs found in the value names within the MountedDevices key, as well as within a user's MountPoints2 subkey names follow the UUID v1 format discussed in RFC 4122.  As such, this GUID contains a node identifier, which is most often a MAC address from the system.  Okay, that's easy enough.  There is also a 60-bit time stamp embedded in the GUID, which tracks 100 nano-second intervals since 15 Oct 1582...and I got interested in determining to what event that time stamp referred or was associated, specifically on my Windows 7 Ultimate test system.

I purchased a SanDisk Blade thumb drive (it was on sale), as I knew that such a device had never been connected to my system.  I then recorded the time and date that I booted system, as well as when I first connected the device to the system.  After connecting the device and noting the drive letter to which it was mapped, I disconnected it, waited a couple of hours and reconnected the device.  After disconnecting it, I shut the system down.  Again, I recorded the significant times in my notes.

Several days later, I copied the setupapi.dev.log file, extracted the System, Software, and NTUSER.DAT hives via FTK Imager, and dumped the System Event Log via LogParser, using the following command:

logparser -i:evt -o:csv "Select RecordNumber,TO_UTCTIME(TimeGenerated),EventID,SourceName,Strings from System" > d:\cases\local\system.csv

Using the appropriate tools, I generated my events file in preparation for creating a timeline.  I wrote a specific script to parse the System Event Log entries into the necessary five-field format, and crafted a specific variant of the RegRipper mp2.pl plugin to parse the volume GUIDs based on the UUID v1 time stamps.  I used regtime.pl (part of my timeline tools) to parse the Registry hives into the necessary format.

Now, what I didn't do was create a supertimeline from all data sources, as it wasn't necessary to do so.  No new Prefetch files had been created during the testing process, and I hadn't created or edited files on the thumb drive, so there really was no need to collect file system metadata.  I focused solely on the System Event Log as I understand that a number of event records are created in that log file with respect to drivers and USB devices, as well as a number of system-specific records.

What I was able to determine is that the time stamp within the volume GUID refers to the boot time of the boot session during which the device was connected to the system.  For example, I booted my test system at approximately 4:29pm EDT on 4 April 2012 (as indicated by a Microsoft-Windows-Kernel-General record with event ID 12); however, I didn't plug the device into the system until 4:55pm EDT (remember, I disconnected it and then plugged it again later at 9:02pm EDT).  When I parsed the volume GUID for the time stamp and normalized it to 32-bit time format, the time was within a second of the boot time of the system.  Throughout the rest of the timeline, I saw the creation of keys beneath the Enum\USB and Enum\USBStor keys within the System hive, as well as several other keys that need to be researched further and possibly included in the USB device analysis process.  I was also able to see that there were a number of event records that pertain to the use of USB devices.

Another example where this sort of analysis can be applied is in determining artifacts corresponding to a CD or DVD being burned on a Windows 7 system.  The System Event Log will have an event record with a source name of "cdrom" and an event ID of 133, indicating that the CDROM was locked for exclusive use.  If the user burned an ISO image, you'll see an indication of the access to the ISO image beneath the user's RecentDocs key, just prior to the ID 133 event.  If the user chose to send a selection of files to the CD/DVD drive and to "burn a disk", you'll likely see an isoburn.exe Prefetch file.

Again, it's very clear that timelines are an extremely valuable technique, not only for analysis of acquired images, but also when conducting research with respect to developing context and an increased relative confidence in the data and events in which you may be interested.

The DoD Cybercrime Conference is approaching, and I've been doing some thinking about my topic, Timeline Analysis.  I'll be presenting on Wed morning, starting at 8:30am...I remember Cory Altheide saying at one point that all tech conferences should start no sooner than 1pm and run no later than 3:30pm, or something like that.  Cool idea.

So, anyway...I've been thinking about some of the things that I put into pretty much all of my timeline analysis presentations.  When it comes to creating timelines, IMHO there are essentially two "camps", or approaches.  One is what I call the "kitchen sink" approach, which is basically, "Give me everything and let me do the analysis."  The other is what I call the "layered" or "overlay" approach, in which the analyst is familiar with the system being analyzed and adds successive "layers" to the timeline.  When I had a chance to chat with Chad Tilbury at PFIC 2011, he recommended a hybrid of the two approaches...get everything, and then view the data a layer at a time, using something he referred to as a "zoom" capability.  This is something I think is completely within reach...but I digress.

One of the things I've heard folks say about using the "everything" or "kitchen sink" approach is that they'd rather have everything so that they can look at it all when they're conducting analysis, because that's how we find new things.  I completely agree with that (the "finding new things" part), and I think it's a great idea.  After all, one of the core, foundational ideas behind creating timelines is that they can provide a great deal of context to the events we're seeing, and generally speaking, the more data we have, the more context there is likely to be available.  After all, a file modification can be pretty meaningless, in and of itself...but if you are able to see other events going on "nearby", you'll begin to see what events led up to and occurred immediately following the file modification.  For example, you may see that the user launched IE, began browsing the web, requested a specific page, Java was launched, a file was created, and the file in question was modified...all of which provides a great deal of context.

That leads me to this question...if you're running a tool that someone else designed and put together, and you're just pushing a button or launching a command, how do you know that the tool got everything?  How do you know that what you're looking at in the output of the tool is, in fact, everything?

The reason I prefer the layered approach is that it's predicated on (a) fully understanding the goals of your examination, and (b) understanding the system that you're analyzing.  Because you understand your goals, you know what it is you're trying to achieve.  And because you understand that system you're analyzing...Windows XP, Windows 7, etc...you also understand how various aspects of the operating system interact and are interconnected.  As such, you're able to identify where there may be additional data, and either request or create your own tools for extracting the data that you need.  Yes, this approach is more manually-intensive than a more automated approach, but it does have it's positive points.  For one, you'll know exactly what should be in the timeline, because you added it.

Alternatively, most often when talking to analysts about collecting data, the sense I get is that the general feeling is to "GET ALL THE THINGS!!" and then begin digging through the volumes of data to perform "analysis".  I had a case a while back that involved SQL injection, and I created a timeline using only the file system metadata and the SQL injection statements from the web server logs; adding everything else available (including user profile data) would have simply made the timeline too cumbersome and too confusing to effectively analyze.  I understood the goals of my exam (i.e., determine what the bad guy did and/or was able to access), and I understood the system (in this case, how SQL injection works, particularly when the database and web server are on the same system).

Now, some folks are going to say, "hey, but what if you missed something?"  To that I say...well, how would you know?  Or, what if you had the data available because you grabbed everything, and because you had no real knowledge of how the system acted, you had no idea that the event(s) you were looking at were important?

Something else to consider is this...what does it tell us when artifacts that we expect to see are not present?  Or...


The absence of an artifact where you would expect to find one is itself an artifact.

Sound familiar?  An example of this would be creating a timeline from an image acquired from a Windows system, and not seeing any indication of Prefetch file metadata in the timeline.  A closer look might reveal that there are no files ending in .pf in the timeline.  So...what does that tell you?  I'll leave that one to the reader...

My point is that while there are (as I see it) two approaches to creating timelines, I'm not saying that one is better than the other...I'm not advocating one approach over another.  I know from experience that there a lot of analysts who are not comfortable operating in the command line (the "dark place"), and as such, might not create a timeline to begin with, and in particular not one that is pretty command-line-intensive.  I also know that there are a good number of folks who use log2timeline pretty regularly, but don't necessarily understand the complete set of data that it collects, or how it goes about doing so.

What I am saying is that, from my perspective, each has it's own strengths and weaknesses, and it's up to the analyst how they want to approach creating timelines.  You may not want to use a manually-intensive approach (which you can easily automate using batch files, a la Corey Harrell's approach), but if you end up using a substantive framework, how do you know you're getting everything?

More APT Confusion
I ran across an interesting article on TechTarget recently, which states that due to confusion over the APT threat, which "...leads companies to often misappropriate resources, making unnecessary or uninformed investments."

Really?  I remember going on-site to perform IR back in 2006 when I was with the ISS ERS Team, and understanding how the customer knew to contact us.  They had three copies of ISS RealSecure.  All still in their shrink-wrap.  One was used to prop a door open.  So what I'm saying is that, with respect to the TechTarget article, it isn't necessarily confusion over what "APT" means that leads to "uninformed investments", although I do think that what most organizations find themselves inundated with, with respect to marketing, does lead to significant confusion.  I think it's not understanding threats in general, as well as the panic that follows an incident, particularly one that, when investigated, is found to have been going on for some time (weeks, months) prior to detection.

Context...no, WFP.  Wait...what?
When presenting on timeline analysis, or most recently at PFIC 2011, Windows forensic analysis, one of the concepts I cover is context within your examination.  Recently, Chris posted on the same topic, and gives a great example.

Something about the post, and in particular the following words, caught my eye:

"...manually went through the list of running services using the same methodology...right name, wrong directory, or slightly misspelled name, right directory (for the answer to why I do this, check this out... http://support.microsoft.com/kb/222193)."

Looking at this, I was a little confused...what does Windows File Protection (WFP) have to do with looking for the conditions that Chris mentioned in the above quote?  I mean, if a malware author were to drop "svch0st.exe" into the system32 directory, or "svchost.exe" into the Windows directory, then WFP wouldn't come into play, would it?

What's not mentioned in the post is that, while both of the conditions are useful techniques for hiding malware (because they work), WFP is also easily "subverted".  The reason I put "subverted" in quotes is that it's not so much a hack as it is using an undocumented MS API call.  That's right!  To break stuff, you don't have to break other stuff first...you just use the exit ramp that the vendor didn't post signs for.  ;-)

Okay, to start, open WFA 2/e and turn to pg. 328.  Just below the middle of the page, there's a link to a BitSum page (the page doesn't seem to be available any longer...you'll need to look here) that discusses various methods for disabling WFP...one that I've seen used is method #3; that is, disable WFP for one minute for a particular file.  This is something that is likely used by Windows Updates.  This CodeProject page has some additional useful information regarding the use of the undocumented SfcFileException API call.

To show you what I mean by "undocumented", take a look at the image to the right...this is the Export Address Table from sfc_os.dll from a Windows XP system, via PEView.  If you look at the Export Ordinal Table, you'll see only the last 4 functions listed, by name.  However, in the Export Address Table, you don't see names associated with several of the functions.

Note that at the top of the BitSum page (archived version), several tools are listed to demonstrate some of the mentioned techniques.  As the page appears to be no longer available, I'm sure that the tools are not available either...not from this site, anyway.

Mandiant has a good example of how WFP "subversion" has been used for malware persistence; see slide 25 from this Mandiant The Malies presentation.  W32/Crimea is another example of how disabling WFP may be required (I've seen the target DLL as a "protected" file on some XP systems, but not on others...).  This article describes the WFP subversion technique and points to this McAfee blog post.

Yes, Virginia...it is UTC
I recently posted a link to some of my timeline analysis materials that I've used in previous presentations.  I've mentioned before that I write all of my tools to normalize the time stamps to 32-bit Unix time format, based on the system's interpretation of UTC (which, for the most part, is analogous to GMT).  In fact, if you open the timeline presentation from this archive, slide 18 includes a bullet that states "Time (normalized to Unix epoch time, UTC)".

I hope this makes things a bit clearer to folks.  Thanks!


Intel Sharing
Not long ago, I posted about OpenIOC.org, and recently ran across this DarkReading article that discusses intel sharing. Sharing within the community, of any kind, is something that's been discussed time and time again...very recently, I chatted with some great folks at PFIC (actually, at the PFIC AfterDark event held at The Spur in Park City) about this subject.

In the DarkReading article, Dave Merkel, Mandiant CTO, is quoted as saying, "There's no single, standardized way for how people to share attack intelligence."  I do agree with this...with all of the various disparate technologies available, it's very difficult to express an indicator of compromise (IoC) in a manner that someone else can immediately employ it within their infrastructure.  I mean, how does someone running Snort communicate attack intel to someone else who monitors logs?

I'd suggest that it goes a bit further beyond that, however...there's simply no requirement (nor apparently any desire) for organizations to collect attack intelligence, or even simply share artifacts.  Most "victim" organizations are concerned with resuming business operations, and consulting firms are likely more interested in competitive advantage.  At WACCI 2010, Ovie talked about the lack of sharing amongst analysts during his keynote presentation, and like others, I've experienced that myself on the teams I've worked with...I wouldn't have any contact with another analyst on my team for, say, 3 months, and after all that time, they had nothing to share from their engagements.  We took steps to overcome that...Chris Pogue and I wrote a white paper on SQL injection, we developed some malware characteristics, and I even wrote plugins for RegRipper.  I've seen the same sharing issue when I've talked to groups, not just about intel sharing, but also about the forensic scanner. 

I think that something like OpenIOC does provide a means for describing IoCs in a manner that can be used by others...but only others with the same toolset.  Also, it is dependent upon what folks find, and from that, what they choose to share.  As an example, take a look at the example Zeus IOC provided at the OpenIOC.org site.  It contains some great information...file names/paths, process handles, etc...but no persistence mechanism for the malware itself, and no Registry indicators.  So, this IoC may be great if I have a copy of IOCFinder and a live system to run it against.  But what happens if I have a memory dump and an acquired image, or just a Windows machine that's been shut off?  Other IoCs, like this one, are more comprehensive...maybe with a bit more descriptive information and an open parser, an analyst could download the XML content and parse out just the information they need/can use.

Now, just to be clear...I'm not saying that no one shares DFIR info or intel.  I know that some folks do...some folks have written RegRipper plugins, but I've also been in a room full of people who do forensic analysis, and while everyone admits to having a full schedule, not one person has a single artifact to share.  I do think that the IoC definition is a good start, and I hope others pick it up and start using it; it may not be perfect, but the best way to improve things is to use them.

DoD CyberCrime Conference
Thanks to Jamie Levy for posting the DC3 track agenda for Wed, 25 Jan 2012.  It looks like there're a number of interesting presentations, many of which all go on at the same time.  Wow.  What's a girl to do?

NoVA Forensics Meetup
Just a quick reminder about the next NoVA Forensics Meetup, scheduled for Wed, 7 Dec 2011, at the ReverseSpace location.  Sam Brothers will be presenting on mobile forensics.

iTunes Forensic Analysis
I ran across a very interesting read regarding the forensic analysis of an iTunes installation via DFINews.  One of the things I see consistently within the community is that folks really want to see how someone else has done something, how they've gone about conducting an exam or investigation, and this is a good example of that.

Volatility Updates
Keep your eye on the Volatility site for updates that include support for Windows 8, thanks to the efforts of @iMHLv2, @gleeda, @moyix, and @attrc.

Speaking of Volatility, the folks at p4r4ni0d take a look at Morto.  Great work, using a great tool set.  If you want to see how others using Volatility, take a look at the blog post.

NetworkMiner
A new version of NetworkMiner has been released.  If your work involves pcap capture and analysis, this is one tool that I'd definitely recommend that you have in your kit.

Registry
Andrew Case (@attrc) put together a very good paper (blog post here) on how he went about recovering and analyzing deleted Registry hives.  Now, this is not recovering deleted keys from within hive files...Andrew recovered entire hive files from unallocated space after (per his paper) the system had been formatted and the operating system reinstalled.  Take a look at the process he went through to this...this may be something that you'd want to incorporate into your tool kit.

If you're read Windows Registry Forensics, you'll understand Andrew's approach; Registry hive files (including those from Windows 8) start with 'regf' at the first 4 bytes of the file.  The hive files are broken into 4k (4096 bytes) pages, with the first one beginning with 'regf'; the subsequent pages start with 'hbin'.  

I've done something similar with respect to Windows XP Event Logs, carving specifically for individual records rather than entire Event Log (.evt) files.  In much the same way, Andrew looked that goals of his examination, and then used the tools he had available to accomplish those goals.  Notice that in the paper, he didn't discuss re-assembling every possible hive file, but instead only those that might contain the data/information of interest to his examination.  Nor did he attempt to carve every possible file type using scalpel; he only went after the types of files that he thought were necessary.

When I wrote my event record carving tool, I had the benefit of knowing that each record contains the record size as part of its metadata; Andrew opted to grab 25MB of contiguous data from the identified offset, and from his paper, he appears to have been successful. 

Also, page 4 includes a statement that is extremely important; "This is necessary as USBSTOR keys timestamps are not always reliable."  As you're reading through the paper, you'll notice that Andrew focused on the USBStor keys in order to identify the devices he was looking for, but as you'll note from other sources (WRF, as well as Rob Lee's documentation), the time stamps on the USBStor keys are NOT a reliable indicator of when a USB device was last connected to (or inserted into) a system.  This is extremely important, and I believe very often confused.

More importantly, I think that Andrew deserves a great big "thanks" for posting his process so clearly and concisely.  This isn't something that we see in the DFIR community very often...I can only think of a few folks who do this work who've stepped up to share this sort of information.  Clearly, this is a huge benefit to the community, as I would think that there will be folks reading his paper who will think to themselves, "wow, I could've used that on that examination!", just as others will likely be using it before 2011 closes out.  Notice that there's nothing in the write-up that specifically identifies a customer or really gives away any case-specific data.

Andrew's paper is an excellent contribution to the community, and provides an excellent look at a thorough process for approaching and solving a problem using what you, as an examiner, have available to you.  Something else to consider would be to look for remnants of the (for Windows XP) setupapi.log file, which would provide an indication of devices that had been connected (plugged in, attached, inserted into) to the system.  I've done something similar with both the pagefile and unallocated space...knowing what I was looking for, I used Perl to locate indications of the specific artifacts, and then grab X number of bytes on either side of that artifact.  As an example, you could use the following entry from a setupapi.log file:


Now, search for all instances of the above string, and then grab 200 or more bytes on either side of that offset and write it to a file.  This could provide some very useful information, as well.

Timelines
Corey has an excellent post up regarding the thought processes behind putting a timeline together.  I'd posted recently on how to go about creating mini-timelines from a subset of data; in his post, Corey discusses the thought process that he goes through when creating timelines, in general...he also provides an example.  If you look at the "Things to consider" section of his post, you'll notice some similarity to stuff I've written, as well as to Chris Pogue's Sniper Forensics presentations; in particular, the focus on the goals of the examination.

In his post, Corey mentions two approaches to timelines; the "kitchen sink" (including everything you can, and then performing analysis) and the "minimalist" approach.  From my perspective, the minimalist approach is very similar to what Corey describes in his post; you can add data sources to a timeline via a "layering" approach, in that you can start with specific data sets (file system metadata, Event Logs, Prefetch file metadata, Registry metadata, Jump Lists, etc.), and then as you begin to develop a more solid picture, add successive layers, or even just specific items, to your timeline.  The modular approach to the tools I use and have made available makes this approach (as well as creating mini-timelines) extremely easy.  For example, during an examination involving a SQL injection attack, I put together a timeline using just file system metadata and pertinent web server log entries.  For an incident involving user activity on a system, I would create a timeline using file system metadata, Registry key LastWrite times (as well as specific entries, such as UserAssist data), Event Log entries, Prefetch file metadata, and if the involved system were Windows 7, Jump List metadata (including parsing the DestList stream and sorting the entries in MFU/MRU order).  In a malware detection case, I may not initially be interested in the contents of any user's web surfing activity, with the exception of the LocalService or "Default User" user accounts.

This is not to say that one way is better or more correct than another; rather, the approach used really depends upon the needs of the examination, skill set of the analyst, etc.  I've simply found, through my own experience, that adding everything available to a timeline and then sorting things out doesn't provide me with the level of data reduction I'm looking for, whereas a more targeted approach allows me to keep focused on the goals of the examination.

There are times when you don't want (or need) a super timeline, but instead just want to focus on one piece of available data, such as Event Log entries or Registry key LastWrite times.  I've had occasion to focus on just specific entries in the Security Event Logs; specifically, event ID 528, type 10, indicating RDP logins to a system.  I used one of the timeline tools I wrote, evtparse.pl, to parse the appropriate records from the Security Event Log and then create a timeline from just those records.

So, let's say that you have something specific that you want to look for, such as all Registry keys that were created or modified between two specific dates.  You'd want to start by either extracting the appropriate hives from the acquired image via FTK Imager, or using FTK Imager to mount the acquired image as a volume on your analysis system. 

For the next steps, go here and download the tln_tools.zip archive...do NOT download regtime.zip for this exercise.  From the tln_tools.zip archive, we will be working specifically with the regtime.pl and parse.pl tools (note that regtime also ships with a standalone EXE...you must have the p2x588.dll file in the same directory along with the EXE).

The first thing you'll need to do is create your events file of the Registry key LastWrite times.  One thing you'll need is the name of the system you're analyzing.  This can be something that's already in your case documentation; however, if you don't have that information, you can either enter a designator, or leave it blank...for what we're doing, it isn't critical.  If you have RegRipper installed, this is very easy to get, using the following command:


We can then use the returned information in your mini-timeline instead of the "SERVER" value in the below commands.

Next, we'll parse the Software and System hives (assume that the image is mounted as H:\):



Now that we have the events file, we can use parse.pl to generate our timeline.  If you type just "parse.pl" at the command prompt (or "parse.pl -h"), you'll see that the script has a couple of options, one of which is to specify a date range.  Let's say that you want all events from your events file, between 3 March and 4 April 2011, inclusive.  You would use the following command:


This command provides an ASCII output format that I've always found very easy to view and understand. If you would like .csv output, which Excel is much happier with, type the following command (note the "-c" switch):


There you go...that's it.  You can also add other hives to your events file, even NTUSER.DAT hives (adding the username after the "-u" switch can help you tell different user's apart).

This blog post has been brought to you by the open source tool, "regtime.pl", and the redirection operator ">".

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.