Timeline Analysis Process

Having discussed timeline analysis in a couple of blog posts so far (such as here...), I thought I'd take an opportunity to dig a bit deeper into the process I've been using for some time to actually conduct analysis of timelines that I create during engagements.

Before we get into the guts of the post, I'd like to start by saying that this is what I've found that works for me, and it does not mean that this is all there is.  This is what I've done, and been doing, tweaking the process a bit here and there over the years.  I've looked at things like visualization to try to assist in the analysis of time lines, but I have yet to find something that works for me.  I've seen how others "do" timeline analysis, and for whatever reason, I keep coming back to this process.  However, that does not mean that I'm not open to other thoughts, or discussion of other processes.  It's quite the opposite, in fact...I'm always open to discussing ways to improve any analysis process.

Usually when I create a timeline, it's because I have something specific that I'm looking for that can be shown through a timeline; in short, I won't create a timeline (even a micro-timeline) without a reason to do so.  It may be a bit of malware, a specific Registry entry or Windows Event Log record, a time frame, etc.  As is very often the case, I'll have an indicator, such as web shell file on a system, and find that in some cases, the time frames don't line up between systems, even though the artifact is the same across those systems.  It's this information than I can then use, in part, to go beyond the "information" of a particular case, and develop intelligence regarding an adversary's hours of operations, action on objectives, etc.

When creating a timeline, I'll use different tools, depending upon what data I have access to.  As I mentioned before, there are times when all I'll have is a Registry hive file, or a couple of Windows Event Logs, usually provided by another analyst, but even with limited data sources, I can still often find data of interest, or of value, to a case.  When adding Registry data to a timeline, I'll start with regtime to add key Last Write times from a hive to the timeline.  This tool doesn't let me see Registry values, only key Last Write times, but it's value is that it lets me see keys that have been created or modified during a specific time frame, telling me where I need to take a closer look.  For example, when I'm looking at a timeline and I see where malware was installed as a Windows service, I'll usually see the creation of the Registry key for the service beneath the Services key (most often beneath both, or all, ControlSets).

When I want to add time stamped information from Registry value data to a timeline, I'll turn to RegRipper and use the plugins that end in *_tln.pl.  These plugins (generally speaking) will parse the data from Registry values for the time stamped information, and place it into the necessary format to include it in a timeline.  The key aspect to doing this is that the analyst must be aware of the context of the data that they're adding.  For example, many analysts seem to believe that the time stamp found in the AppCompatCache (or ShimCache) data is when the program was executed, and in several cases (one announced publicly by the analyst), this misconception has been passed along to the customer.

I also use several tools that let me add just a few events...or even just one event...to the time line.  For example, the RegRipper secrets_tln.pl plugin lets me add the Last Write time of the Policy/Secrets key from the Security hive to the timeline.  I can check the time stamp first with the secrets.pl plugin to see if it's relevant to the time frame I'm investigating, and if it is, add it to the timeline.  After all, why add something to the timeline that's not relevant to what I'm investigating?

If I want to add an event or two to the timeline, and I don't have a specific parser for the data source, I can use tln.exe (image to the left) to let me add that event.  I've found this GUI tool to be very useful, in that I can use it to quickly add just a few events to a timeline, particularly when looking at the data source and only finding one or two entries that are truly relevant to my analysis.  I can fire up tln.exe, add the time stamp information to the date and time fields, add a description with a suitable tag, and add it to the timeline.  For example, I've used this to add an event to a timeline, indicating when the available web logs on a system indicated the first time that a web shell that had been added to the system was accessed.  I added the source IP address of the access in the description field in order to provide context to my timeline, and at the same time, adding the event itself provided an additional (and significant) level of relative confidence in the data I was looking at, because the event I added corresponded exactly to file system artifacts that indicated that the web shell had been accessed for the first time.  I chose this route, because adding all of the web log data would've added significant volume to my timeline without adding any additional context or even utility.

When creating a timeline, I start with the events file (usually, events.txt), and use parse.exe to create a full timeline, or a partial timeline based on a specific date range.  So, after running parse.exe, I have the events.txt file that contains all of the events that I've extracted from different data sources using different tools (whichever applies at the time), and I have either full timeline (tln.txt) or a shortened version based on a specific date range...or both.  To begin analysis, I'll usually open the timeline file in Notepad++, which I prefer to use because it allows me to search for various things, going up or down in the file, or it can give me a total count of how many times a specific search term appears in the file.


Once I begin my analysis, I'll open another tab in Notepad++, and call it "notes.txt".  This is where all of my analysis notes go while I'm doing timeline analysis.  As I start finding indicators within the timeline, I'll copy-and-paste them out of the timeline file (tln.txt) and into the notes file, keeping everything in the proper sequence.

Timeline analysis has been described as being an iterative process, often performed in "layers".  The first time going through the timeline, I'll usually find a bunch of stuff that requires my attention.  Some stuff will clearly be what I'm looking for, other stuff will be, "...hey, what is this..."...but most of what's in the timeline will have little to do with the goals of my exam.  I'm usually not interested in things like software and application updates, etc., so having the notes file available lets me see what I need to see.  Also, I can easily revisit something in the timeline by copying the date from the notes file, and doing a search in the timeline...this will take me right to that date in the timeline.

Recently while doing some timeline analysis, I pulled a series of indicators out of the timeline, and pasted them into the notes file.  Once I'd followed that thread, I determined that what I was seeing as adware being installed.  The user actively used the browser, and the events were far enough back in time that I wasn't able to correlate the adware installation with the site(s) that the user had visited, but I was able to complete that line of analysis, note what I'd found, remove the entries from the notes file, and move on.

As timeline analysis continues, I very often keep the data source(s) open and available, along with the timeline, as I may want to see something specific, such as the contents of a file, or the values beneath a Registry key.  Let's say that the timeline shows that during a specific time frame that I'm interested in, the Last Write time of the HKLM/../Run key was modified; I can take a look at the contents, and add any notes I may have ("...there is only a single value named 'blah'...") to the notes file.

Many times, I will have to do research online regarding some of the entries in the timeline.  Most often, this will have to do with Windows Event Log entries; I need to develop an understanding of what the source/ID pair refers to, so that I can fill in the strings extracted from the record and develop context around the event itself.  Sometimes I will find Microsoft-Windows-Security-Auditing/5156 events that contain specific process names or IP addresses of interest.  Many times, Windows Event Log record source/ID pairs that are of interest will get added to my eventmap.txt file with an appropriate tag, so that I have additional indicators that automatically get identified on future cases.

Not everything extracted from the timeline is going to be applicable to the goals of my analysis.  I've pulled data from a timeline and my research has determined that the events in question were adware being installed.  At that point, I can remove the data from my notes file.

By the time I've completed my timeline analysis, I have the events file (all of the original events), the timeline file, and the notes file.  The notes file is where I'll have the real guts of my analysis, and from where I'll pull things such as indicator clusters (several events that, when they appear together, provide context and a greater level of confidence in the data...) that I've validated from previous engagements, and will use in future engagements, as well as intel I can use in conjunction with other analysis (other systems, etc.) to develop a detailed picture of activity within the enterprise.

Again, this is just the process I use and have found effective...this is not to say that this is what will work for everyone.  And I have tried other processes.  I've had analysts send me automatically-created colorized spreadsheets and to be honest, I've never been very clear as to what they've found or thought to be the issue.  That is not to say that this method of analysis isn't effective for some, as I'm sure it is...I simply don't find it effective.  The process I described has been effective for me at a number of levels...from having a single data source from a system (i.e., a single Registry hive...), to having an entire image, to analyzing a number of systems from the same infrastructure.  And again, I'm not completely stuck to this process...I'm very open to discussion of other processes, and if I do find something that proves to be effective, I have no problem adding it to what I do, or even changing my process all together.

Timeline Analysis, pt VI - Taking Another Step

In my last post on timeline analysis, I illustrated how you could use some freely available tools to get started in developing a detailed timeline of activity from a system. Using TSK tools, we can extract file system timeline information from an acquired image, creating what Brian refers to as a bodyfile. This gives us the beginning of a more complete timeline...in order to take our timeline to the next level, we need to look at other sources of timestamped data...for right now, from the system being examined; for this example, we'll look to the Event Log as a source of timeline information.

As a reminder, we're using the 5 field timeline format that I described earlier. I'm referring to this as a "TLN" format, or timeline format, and includes the time (normalized to Unix epoch time), the source of the event (ie, where we got it, such as from an EVT file, INFO2 file, or some other log or source), the host or system on which the event occurred, the user associated with the event (if available), and a description of the event.

So, we have the file system bodyfile (courtesy of the TSK tools), but we need to translate that into the 5 field format; this is really simple to do using a script I call bodyfile.pl. Now, we have to stop for a second, because two of the fields we'd normally include...the server or host name, and the username...are not available in a TSK bodyfile. I opted to use RegRipper on the hive files extracted from the image to get the server name, and bodyfile.pl has a switch that lets me enter the server or host name so that the script can populate that field. This can be very important if you're correlating events across multiple systems.

Note: If you're dealing with live systems, you may opt to use another means, such as Perl or Python, to collect a file system bodyfile that is similar to the output of fls.exe.

Then I used a Perl script for parsing EVT files to parse through the Application, System, and Security Event Logs extracted from the image and add those events to the overall events file that we started with bodyfile.pl. This can add some very interesting correlating information to your timeline file, and the EVT parsing script can be (has been) adapted to parse event records out of a memory dump (which is all kinds of way cool!).

Now, if you've looked at the image that we're using (ie, the NIST hacking case image), you'll know that there's at least one Recycle Bin on the system with "deleted files" in it, as well as a nice INFO2 file. So I extracted the INFO2 file from the image, and used recbin.pl to parse the contents into our TLN format, adding those events to the timeline data.

Okay, at this point, we have a total of three sources for our timeline data: the file system itself, via fls.exe; the Event Logs; a Recycle Bin INFO2 file. Now what we have is a file full of events, and we need some way to make it useful. I wrote a simple script called parse.pl to read in all of the events, then sort them by the most recent time first, and print all of the events associated with each timestamp. Below is an excerpt from the resulting timeline file, illustrating what appears to be a shutdown of the system (some color-coding done for clarity):

Fri Aug 27 15:46:28 2004 Z
FILE N-1A9ODN6ZXK4LQ - MA.E c:/WINDOWS/Tasks/SA.DAT
EVT N-1A9ODN6ZXK4LQ N/A - EventLog/6006;Info;

Fri Aug 27 15:46:27 2004 Z
FILE N-1A9ODN6ZXK4LQ - MA.E c:/WINDOWS/Prefetch/LOGONUI.EXE-0AF22957.pf

Fri Aug 27 15:46:23 2004 Z
FILE N-1A9ODN6ZXK4LQ - MA.. c:/Documents and Settings/Mr. Evil/Local
Settings/Application Data/Microsoft/Windows/UsrClass.dat
FILE N-1A9ODN6ZXK4LQ - MA.. c:/Documents and Settings/Mr. Evil/NTUSER.DAT
FILE N-1A9ODN6ZXK4LQ - MA.E c:/Documents and Settings/Mr. Evil/ntuser.dat.LOG
FILE N-1A9ODN6ZXK4LQ - MA.E c:/Documents and Settings/Mr. Evil/ntuser.ini

Fri Aug 27 15:46:19 2004 Z
FILE N-1A9ODN6ZXK4LQ - .A.. c:/WINDOWS/Media/Windows XP Shutdown.wav
EVT N-1A9ODN6ZXK4LQ N/A - BROWSER/8033;Info;\Device
\NetBT_Tcpip_{86FC0C96-3FF2-4D59-9ABA-C602F213B5D2}

Pretty cool stuff, eh? Well, here's something else that's very cool...from the output of RegRipper, I collected the last shutdown time from the System hive:

ControlSet001\Control\Windows key, ShutdownTime value
ControlSet001\Control\Windows
LastWrite Time Fri Aug 27 15:46:33 2004 (UTC)
ShutdownTime = Fri Aug 27 15:46:33 2004 (UTC)

As you can see, we did indeed observe a shutdown in the timeline data illustrated above!

Now, this timeline information may not necessarily allow you to answer all of the questions in the challenge, but it can be very useful information, particularly when investigating an intrusion.

Don't forget...others have seen the importance of timeline development, as well. Next steps for this process are to include timeline data extraction in RegRipper, so that this data can be added to the timeline, as well. So stay tuned!

Addendum: I uploaded the complete output of parse.pl to the Files section of the Win4n6 group, under the Timeline Data folder. That way, you can look at ALL of the data...let me know if you have any questions.

Timeline Analysis...do we need a standard?

Perhaps more appropriately, does anyone want a standard, specifically when it comes to the output format?

Almost a year ago, I came up with a 5-field output format for timeline data. I was looking for something to 'define' events, given the number of data sources on a system. I also needed to include the possibility of using data sources from other systems, outside of the system being examined, such as firewalls, IDS, routers, etc.

Events within a timeline can be concisely described using the following five fields:

Time - A timeline is based on times, so I put this field first, as the timeline is sorted on this field. Now, Windows systems have a number of time formats...32-bit Unix t_time format, 64-bit FILETIME objects, and the 128-bit SYSTEMTIME format. The FILETIME object has granularity to 100 nanoseconds, and the SYSTEMTIME structure has granularity to the millisecond...but is either really necessary? I opted to settle on the Unix t_time format, as the other times could be easily reduced to that format, without loosing significant granularity.

Source - This is the source from which the timeline data originates. For example, using TSK's fls.exe allows the analyst to compile file system metadata. If the analyst parses the MFT using MFTRipper or analyzeMFT, she still has file system metadata. The source remains the same, even though the method of obtaining the data may vary...and as such, should be documented in the analyst's case notes.

Sources can include Event Logs (EVT or EVTX), the Registry (REG), etc. I had thought about restricting this to 8-12 characters...again, the source of the data is independent of the extraction method.

Host - This is the host or name of the system from which the data originated. I included this field, as I considered being able to compile a single timeline using data from multiple systems, and even including network devices, such as firewalls, IDS, etc. This can be extremely helpful in pulling together a timeline for something like SQL injection, including logs from the web server, artifacts from the database server, and data from other systems that had been connected to.

Now, when including other systems, differences in clocks (offsets, skew, etc.) need to be taken into account and dealt with prior to entering the data into the timeline; again, this should be thoroughly documented in the analyst's case notes.

Host ID information can come in a variety of forms...MAC address, IP address, system/NETBios name, DNS name, etc. In a timeline, it's possible to create a legend with a key value or identifier, and have the timeline generation tools automatically translate all of the various identifiers to the key value.

This field can be set to a suitable length (25 characters?) to contain the longest identifier.

User - This is the user associated with the event. In many cases, this may be empty; for example, consider file system or Prefetch file metadata - neither is associated with a specific user. However, for Registry data extracted from the NTUSER.DAT or USRCLASS.DAT hives, the analyst will need to ensure that the user is identified, whereas this field is auto-populated by my tools that parse the Event Logs (.evt files).

Much like the Host field, users can be identified in a variety of means...SID, username, domain\username, email address, chat ID, etc. This field can also have a legend, allowing the analyst to convert all of the various values to a single key identifier.

Usually, a SID will be the longest method of referring to a user, and as such would likely be the maximum length for this field.

Description - This is something of a free-form, variable length field, including enough information to concisely describe the event in question. For Event Log records, I tend to include the event source and ID (so that it can be easily researched on EventID.net) , as well as the event message strings.

Now, for expansion, there may need to be a number of additional, perhaps optional fields. One is a means for grouping individual events into a super-event or a duration event, such as in the case of a search or AV scan. How this identifier is structured still needs to be defined; it can consist of an identifier in an additional column, or it may consist of some other structure.

Another possible optional field can be a notes field of some kind. For example, event records from EVT or EVTX files can be confusing; adding additional information from EventID.net or other credible sources may add context to the timeline, particularly if multiple examiners will be reviewing the final timeline data.

This format allows for flexibility in storing and processing timeline data. For example, I currently use flat ASCII text files for my timelines, as do others. Don has mentioned using Highlighter as a means for analyzing an ASCII text timeline. However, this does not obviate using a database rather than flat text files; in fact, as the amount of data grows and as visualization methods are developed for timelines, using a database may become the standard for storing timeline data.

It is my hope that keeping the structure of the timeline data simple and well-defined will assist in expanding the use of timeline creation and analysis. The structure defined in this post is independent of the raw data itself, as well as the means by which the data is extracted. Further, structure is independent of the storage means, be it a flat ASCII text file, a spreadsheet or a database. I hope that those of us performing timeline analysis can settle/agree upon a common structure for the data; from there, we can move on to visualization methods.

What are your thoughts?

How do you "do" analysis?

Everybody remembers "The Matrix", right?  So, you're probably wondering what the image to the right has to do with this article, particularly given the title.  Well, that's easy...this post is about employing various data sources and analysis techniques, and pivoting in order to add context and achieve a greater level of detail in your analysis.  Sticking with just one analysis technique or process, much like simply trying to walk straight through the building lobby to rescue Morpheus, would not have worked.  In order to succeed, Neo and Trinity had to pivot and mutually support each other in order to achieve their collective goal.  So...quite the metaphor for a blog post that involves pivoting, eh?

Timeline Analysis
Timeline analysis is a great technique for answering a wide range of questions.  For malware infections and compromises, timeline analysis can provide the necessary context to illustrate things like the initial infection (or compromise) vector, the window of compromise (i.e., based on when the system was really infected or compromised, if anti-forensics techniques were used), what actions may have been taken following the infection/compromise, the hours during which the intruder tends to operate, and other systems an intruder may have reached to (in the case of a compromise).

Let's say that I have an image of a system thought to be infected with malware.  All I know at this point is that a NIDS alert identified the system as being infected with a particular malware variant based on C2 communications that were detected on the wire, so I can assume that the system must have been infected on or before the date and time that the alert was generated.  Let's also say that based on the NIDS alert, we know that the malware (at least, some variants of it) persists via a Windows service.  Given this little bit of information, here's an analysis process that I might follow, including pivot points:

1. Load the timeline into Notepad++, scroll all the way to the bottom, and do a search (going up from the bottom) to look for "Service Control Manager/7045" records.
2. Locate the file referenced by the event record by searching for it in the timeline.  PIVOT to the MFT: parse the MFT, extract the parsed record contents for the file in question in order to determine if there was any time stomping involved.
3. PIVOT within the timeline; start by looking "near" when the malware file was first created on the system to determine what other activity occurred prior to that event (i.e., what user was logged in, were there indications of web browsing activity, was the user checking their email, etc.)
4. PIVOT to the file itself: parse the PE headers to get things like compile time, section names, section sizes, strings embedded in the file, etc.  These can all provide greater insight into the file itself.  Extract the malware file and any supporting files (DLLs, etc.) for analysis.
5. If the malware makes use of DLL side loading, note the persistent application name, in relation to applications used on the system, as well as within the rest of the infrastructure.  
6. If your timeline doesn't include AV log entries, and there are AV logs on the system, PIVOT to those in order to potentially get some additional detail or context.  Were there any previous attempts to install malware with the same or a similar name or location?  McAfee AV will flag on behaviors...was the malware installed from a Temp directory, or some other location?  
7. If the system has a hibernation file that was created or modified after the system became infected, PIVOT to that file to conduct analysis regarding the malicious process.
8. If the malware is known to utilize the WinInet API for off-system/C2 communications, see if the Local Service or Network Service profiles have a populated IE web history (location depends upon the version of Windows being examined). 
9. If the system you're analyzing has Prefetch files available, were there any specific to the malware?  If so, PIVOT to those, parsing the modules and looking for anything unusual.  

Again, this is simply a notional analysis, meant to illustrate some steps that you could take during analysis.  Of course, it will all depend on the data that you have available, and the goals of your analysis.

Web Shell Analysis
Web shells are a lot of fun.  Most of us are familiar with web shells, at least to some extent, and recognize that there are a lot of different ways that a web shell can be crafted, based on the web server that's running (Apache, IIS, etc.), other applications and content management systems that are installed, etc.  Rather than going into detail regarding different types of web shells, I'll focus just on what an analyst might be looking for (or find) on a Windows server running the IIS web server.  CrowdStrike has a very good blog post that illustrates some web shell artifacts that you might find if an .aspx web shell is created on such a system.

In this example, let's say that you have received an image of a Windows system, running the IIS web server.  You've created a timeline and found artifacts similar to what's described in the CrowdStrike blog post, and now you're read to start pivoting in your analysis.

1. You find indications of a web shell via timeline analysis; you now have a file name.
2. PIVOT to the web server logs (if they're available), searching for requests for that page.  As a result of your search, you will know have (a) IP address(es) from where the requests originated, and (b) request contents illustrating the commands that the intruder ran via the web shell.
3. Using the IP address(es) you found in step 2, PIVOT within the web server logs, this time using the class C or class B range for the IP address(es), to cast the net a bit wider.  This can give you additional information regarding the intruder's early attempts to fingerprint and compromise the web server, as you may find indications of web server vulnerability scans originating from the IP address range.  You may also find indications of additional activity originating from the IP address range(s).
4. PIVOT back into your timeline, using the date/time stamps of the requests that you're seeing in the web server logs as pivot points, in order to see what events occurred on the systems as a result of requests that were sent via the web shell.  Of course, where the artifacts can be found may depend a great deal upon the type of web shell and the contents of the request.
5. If tools were uploaded to the system and run, PIVOT to any available Prefetch files, and parse out the embedded strings that point to module loaded by the application, in order to see if there are any additional files that you should be looking to.

Once again, this is simply a notional example of how you might create and use pivot points in your analysis.  This sort of process works not just for web shells, but it's also very similar to the process I used on the IBM ISS ERS team when Chris and I were analyzing SQL injection attacks via IIS web servers; conceptually, there is a lot of overlap between the two types of attacks.

Additional Resources (Web Shells)
Security Disclosures blog post
Shell-Detector
Yara rules - 1aN0rmus, Loki

Memory Analysis
This blog post from Contextis provides a very good example of pivoting during analysis; in this case, the primary data source for analysis was system memory in the form of a hibernation file.  The case stated with disk forensics, and a hit for a particular item was found in a crash dump file, and then the analyst pivoted to the hibernation file.

Adam did a great job with the analysis, and in writing up the post.  Given that this post started with disk forensics, some additional pivot points for the analysis are available:

1. Pivoting within the memory dump, the analyst could have identified any mutex utilized by the malware.  
2. Pivoting into a timeline, the analyst may have been able to identify when the service itself was first installed (i.e., "Service Control Manager" record with event ID 7045).
3. Determining when the malicious service was installed can lead the analyst to the initial infection vector (IIV), and will be extremely valuable if the bad guys used anti-forensic techniques such as time stomping the malware files to try to obfuscate the creation date.
4. Pivot to the MFT and extract records for the malicious DLL files, as well as the keystroke log file.  Many of us have seen malware that includes a keylogger component that will continually time stomp the keystroke log file as new key strokes are added to it.  

"Doing" Analysis
I received an interesting question a while back, asking for tips on how I "do analysis".  I got to thinking about it, and it made sense to add my thoughts to this blog post.

Most times, when I receive an image, I have some sort of artifact or indicator to work with..a file name or path, a date/time, perhaps a notice from AV that something was detected.  That is the reason why I'm looking at the image in the first place.  And as a result, producing a timeline is obviated by the questions I need to answer; that is to say, I do not create a timeline simply because I received an image.  Instead, I create a timeline because that's often the best way to address the goals of my exam.

When I do create a timeline, I most often have something to look for, to use as an initial starting or pivot point for my analysis.  Let's say that I have a file that I'm interested in; the client received a notification or alert, and that led them to determine that the system was infected.  As such, they want to know what the malware is, how it got on the system, and what may have occurred after the malware infected the system.  After creating the timeline, I can start by searching the timeline for the file listing.  I will usually look for other events "around" the times where I find the file listed...Windows Event Log records, Registry keys being created/modified, etc.

Knowing that most tools (TSK fls.exe, FTK Imager "Export Directory Listing..." functionality) used to populate a timeline will only retrieve the $STANDARD_INFORMATION attributes for the file, I will often extract and parse the $MFT, and then check to see if there are indications of the file being time stomped.  If it does appear that the file was time stomped, I will go into the timeline and look "near" the $FILE_NAME attribute time stamps for further indications of activity.

One of the things I use to help me with my analysis is that I will apply things I learned from previous engagements to my current analysis.  One of the ways I do this is to use the wevtx.bat tool to parse the Windows Event Logs that I've extracted from the image.  This batch file will first run MS's LogParser tool against the *.evtx files I'm interested in, and then parse the output into the appropriate timeline format, while incorporating header tags from the eventmap.txt event mapping file.  If you open the eventmap.txt file in Notepad (or any other editor) you'll see that it includes not only the mappings, but also URLs that are references for the tags.  So, if I have a timeline from a case where malware is suspected, I'll search for the "[MalDetect]" tag.  I do this even though most of the malware I see on a regular basis isn't detected by AV, because often times, AV will have detected previous malware infection attempts, or it will detect malicious software downloaded after the initial infection (credential dumping tools, etc.).

Note: This approach of extracting Windows Event Logs from an acquired image is necessitated by two factors.  First, I most often do not want all of the records from all of the logs.  On my Windows 7 Ultimate system, there are 141 *.evtx files.  Now, not all of them are populated, but most of them do not contain records that would do much more than fill up my timeline.  To avoid that, there are a list of less than a dozen *.evtx files that I will extract from an image and incorporate into a timeline.

Second, I often work without the benefit of a full image.  When assisting other analysts or clients, it's often too cumbersome to have a copy of the image produced and shipped, when it will take just a few minutes for them to send me an archive containing the *.evtx files of interest, and for me to return my findings.  This is not a "speed over accuracy" issue; instead, it's a Sniper Forensics approach that lets me get to the answers I need much quicker.

Another thing I do during timeline analysis is that I keep the image (if available) open in FTK Imager for easy pivoting, so that I can refer to file contents quickly.  Sometimes it's not so much that a file was modified, as much as it is what content was added to the file.  Other times, contents of batch files can lead to additional pivot points that need to be explored.

Several folks have asked me about doing timeline analysis when asked to "find bad stuff".  Like many of you reading this blog post, I do get those types of requests.  I have to remember that sometimes, "bad stuff" leaves a wake.  For example, there is malware that will create Registry keys (or values) that are not associated with persistence; while they do not lead directly to the malware itself (the persistence mechanism will usually point directly to the malware files), they do help in other ways.  One way is that the presence of the key (or value, as the case may be) lets us know that the malware is (or was) installed on the system.  This can be helpful with timeline analysis in general, but also during instances when the bad guy uses the malware to gain access to the system, dump credentials, and then comes back and removes the malware files and persistence mechanism (yeah, I've seen that happen more than a few times).

Another is that the LastWrite time of the key will tell us when the malware was installed.  Files can be time stomped, copied and moved around the file system, etc., all of which will have an effect on the time stamps recorded in the $MFT.  Depending on the $MFT record metadata alone can be misleading, but having additional artifacts (spurious Registry keys created/modified, Windows services installed and started, etc.) can do a great deal to increase our level of confidence in the file system metadata.

So, I like to collect all of those little telltale IOCs, so that when I do get a case of "find the bad stuff", I can check for those indicators quickly.  Do you know where I get the vast majority of the IOCs I use for my current analysis?  From all of my prior analysis.  Like I said earlier in this post, I take what I've learned from previous analysis and apply it to my current analysis, as appropriate.

Sometimes I get indicators from others.  For example, Jamie/@gleeda from Volatility shared with me (it's also in the book) that when the gsecdump credential theft tool is run to extract LSA secrets, the HKLM/Security/Policy/Secrets key LastWrite time is updated.  So I wrote a RegRipper plugin to extract the information and include it in a timeline (without including all of the LastWrite times from all of the keys in the Security hive, which just adds unnecessary volume to my timeline), and since then, I've used it often enough that I'm comfortable with the fidelity of the data.  This indicator serves as a great pivot point in a timeline.

A couple of things I generally don't do during analysis:
I don't include EVERYTHING into the timeline.  Some times, I don't have everything...I don't have access to the entire image.  Someone may send me a few files ($MFT, Registry hives, Windows Event Logs, etc.) because it's faster to do that than ship the image.  However, when I do have an image, I very often don't want everything, as getting everything can lead to a great deal of information being put into the timeline that simply adds noise.  For example, if I'm interested in remote access to a system, I generally do not include Windows Event Logs that focus on hardware monitoring events in my timeline.

I have a script that will parse the $MFT and display the $STANDARD_INFORMATION and $FILE_TIME metadata in a timeline...but I don't use it very often.  In fact, I can honestly say that after creating it, I haven't once used it during my own analysis.  If I'm concerned with time stomping, it's most often only for a handful of files, and I don't see that as a reason for doubling the size of my timeline and making it harder to analyze.  Instead, I will run a script that will display various metadata from each record, and then search the output for just the files that I'm interested in.

I don't color code my timeline.  I have been specifically asked about this...for me, with the analysis process I use, color coding doesn't add any value.  That doesn't mean that if it works for you, you shouldn't do it...not at all.  All I'm saying is that it doesn't add any significant value for me, nor does it facilitate my analysis.  What I do instead is start off with my text-based timeline (see ch. 7 of Windows Forensic Analysis) and I'll create an additional file for that system called "notes"; I'll copy-and-paste relevant extracts from the full timeline into the notes file, annotating various things along the way, such as adding links to relevant web sites, making notes of specific findings, etc.  All of this makes it much easier for me to write my final report, share findings with other team members, and consolidate my findings.

Even More Thoughts on Timelines

I realize that I've talked a bit about timeline creation and analysis, and I know that others (Chris, as well as Rob) have covered this subject, as well.

I also realize that I may have something of a different way of going about creating timelines and conducting analysis. I don't think that, out of the ways I've seen so far that there's a wrong way, I just think that we approach things a bit differently.

For example, I am not a fan of adding everything to a timeline, at least not as an initial step. I've found that IMHO, there's a lot of noise in just the file system metadata...many times, by the time I get notified of an incident, an admin has already logged into the system, installed and run some tools (including anti-virus), maybe even deleted files and accounts, etc. When interviewed about the incident and the specific question of "what actions have you performed on the system?" is asked, that admin most often says, "nothing"...only because they tend to do these things every day and they are therefore trivial. To add to that, there's all the other stuff...automatic updates to Windows or any of the applications, etc., that also adds a great deal of stuff that needs to be culled through in order to find what you're looking for. Adding a lot of raw data to the timeline right up front may mean that you're adding a lot of noise into that timeline, and not a lot of signal.

Goals
Generally, the first step I take is to look at the goals of my exam, and try to figure out which data sources may provide me the best source of data. Sometimes it's not a matter of just automatically parsing file system metadata out of an image; in a recent exam involving "recurring software failures", my initial approach was to parse just the Application Event Log to see if I could determine the date range and relative frequency of such events, in order to get an idea of when those recurring failures would have occurred. In another exam, I needed to determine the first occurrence within the Application Event Log of a particular event ID generated by the installed AV software; to do so, I created a "nano-timeline" by parsing just the Application Event Log, and running the output through the find command to get the event records I was interested in. This provided me with a frame of reference for most of the rest of my follow-on analysis.

Selecting Data Sources
Again, I often select data sources to include in a timeline by closely examining the goals of my analysis. However, I am also aware that in many instances, the initial indicator of an incident often is only the latest indicator, albeit the first to be recognized as such. That being the case, when I start to create a timeline for analysis, I generally start off by creating a file of events from the file system metadata, as well as available Event Log records, as well as running the .evt files through evtrpt.pl to get an idea of what I should expect to see from the Event Logs. I also run the auditpol.pl RegRipper plugin against the Security hive in order to see (a) what events are being logged, and (b) when the contents of that key were last modified. If this date is pertinent to the exam, I'll be sure to include an appropriate event in my events file.

Once my initial timeline has been established and analysis begins, I can go back to my image and select the appropriate data sources to add to the timeline. For example, during investigations involving SQL injection, the most useful data source is very likely going to be the web server logs...in many cases, these may provide an almost "doskey /history"-like timeline of commands. However, adding all of the web server logs to the timeline means that I'm going to end up inundating my timeline with a lot of normal and expected activity...if any of the requested pages contains images, then there will be a lot of additional, albeit uninteresting, information in the timeline. As such, I would narrow down the web log entries to those of interest, beginning with an interative analysis of the web logs, and add the resulting events to my timeline.

That's what I ended up doing, and like I said, the results were almost like running "doskey /history" on a command prompt, except I also had the time at which the commands were entered as well as the IP address from which they originated. Having them in the timeline let me line up the incoming commands with their resulting artifacts quite nicely.

Registry Data
The same holds true with Registry data. Yes, the Registry can be a veritable gold mine of information (and intelligence) that is relevant to your examination, but like a gold mine, that data must be dug out and refined. While there is a great deal of interesting and relevant data in the system hives (SAM, Security, Software, and System), the real wealth of data will often come from the user hives, particularly for examinations that involve some sort of user activity.

Chris and Rob advocate using regtime.pl to add Registry data to the timeline, and that's fine. However, it's not something I do. IMHO, adding Registry data to a timeline by listing each key by its LastWrite time is way too much noise and not nearly enough signal. Again, that's just my opinion, and doesn't mean that either one of us is doing anything wrong. Using tools like RegRipper, MiTec's Registry File Viewer, and regslack, I'm able to go into to a hive file and get the data I'm interested in. For examinations involving user activity, I may be most interested in the contents of the UserAssist\Count keys (log2timeline extracts this data, as well), but the really valuable information from these keys isn't the key LastWrite times; rather, it's the time stamps embedded in the binary value data within the subkey values.

If you're parsing any of the MRU keys, these too can vary with respect to where the really valuable data resides. In the RecentDocs key, for example, the values (as well as those within the RecentDocs subkeys) are maintained in an MRU list; therefore, the LastWrite time of the RecentDocs key is of limited value in and of itself. The LastWrite time of the RecentDocs key has context when you determine what action caused the key to be modified; was a new subkey created, or was another file opened, or was a previously-opened file opened again, modifying the MRUListEx value?

Files opened via Adobe Reader are maintained in an MRU list, as well, but with a vastly different format from what's used by Microsoft; the most recently opened document is in the AVGeneral\cRecentFiles\c1 subkey, but the name of the actual file is embedded in a binary value named tDIText. On top of that, when a new file is opened, it becomes the value in the c1 subkey, so all of the other subkeys that refer to opened documents also get modified (what was c1 becomes c2, c2 becomes c3, etc.), and the key LastWrite times are updated accordingly, all to the time that the most recent file was opened.

Browser Stuff
Speaking of user activity, let's not forget browser cache and history files, as well as Favorites and Bookmarks lists. It's very telling to see a timeline based on file system metadata with a considerable number of files being created in browser cache directories, and then to add data from the browser history files and get that contextual information regarding where those new files came from. If a system was compromised by a browser drive-by, you may be able to discover the web site that served as the initial infection vector.

Identifying Other Data Sources
There may be times when you would want to determine other data sources that may be of use to your examination. I do tend to check the contents of the Task Scheduler service log file (schedLgU.txt) for indications of scheduled tasks being run, particularly during intrusion exams; however, this log file can also be of use if you're trying to determine if the system were up and running during a specific timeframe. This may much more pertinent to laptops and desktop systems than to servers, which may not be rebooted often, but if you look in the file, you'll see messages such as:

"Task Scheduler Service"
Started at 3/21/2010 6:18:19 AM
"Task Scheduler Service"
Exited at 3/21/2010 9:10:32 PM

In this case, the system was booted around 6:16am EST on 21 March, and shut down around 9:11pm that same day. These times are listed relative to the local system time, and may need to be adjusted based on the timezone, but it does provide information regarding when the system was operating, particularly when combined with Registry data regarding the start type of the service, and can be valuable in the absence of, or when combined with, Event Log data.

There may be other data sources available, but not all of them may be of use, depending upon the goals of your examination. For example, some AV applications record scan and detection information in the Event Log as well as in their own log files. If the log file provides no indication that any malware had been identified, is it of value to include all scans (with "no threats found") in the timeline, or would it suffice to note that fact in your case notes and the report?

Summary
Adding all available data sources to a timeline can quickly make that timeline very unwieldy and difficult to manage and analyze. Through education, training, and practice, analysts can begin to understand what data and data sources would be of primary interest to an examination. Again, this all goes back to your examination goals...understand those, and the rest comes together quite nicely.

Finally, I'm not saying that it's wrong to incorporate all available data sources into a timeline...not at all. Personally, I like having the flexibility to create mini-, micro- or nano-timelines that show specific details, and then being able to go back to the overall timeline to be able to see what I learned viewed in the context of the overall timeline.

Thoughts on Timeline Analysis

I was chatting with Chris Pogue (a fellow Syngress book author attending the SANS Forensic Summit) a bit over the past couple of days on the subject of Timeline Analysis, and had some thoughts that I wanted to throw out there and see what others thought about them...

Personally, I've been doing some pretty cool things with timeline analysis, incorporating not only file system metadata, but Event Log entries, data from the Registry, as well as the user's web browser history, etc. What this does is allow me to view events from several sources all in one place, giving me some context, but not all of the possible context. And this can be a LOT of data! I go through the process of creating a bodyfile, then a 5-field TLN format events file, and then a full timeline in ASCII, saving it in a text file. I've updated some of my code recently to allow me to re-run the events-file-to-timeline conversion tool and focus solely on a specific date range, down to a single day.

This is where we usually start talking about visualization...what's a good way to present this information in a graphic format so that the analyst can determine the answer to the question they're trying to answer? Perhaps better yet...IS there a good way?

When it comes down to presenting the data to the customer, I've never been a supporter of giving the customer all of the raw data (there are folks out there who think a 3300+ page report is a good thing!), and giving the customer a timeline graphic of ALL of the data really doesn't do a whole lot, either for them to understand what's going on, or for your professional credibility. That's where the knowledge and ability of the analyst come in, and you create a timeline that summarizes the important and relevant events for the customer.

So, how do you do this? Do you sift through the data, extracting all of the irrelevant stuff (ie, removing thousands of file last accessed events and replacing them with a single AV scan event, etc.) and dump it into some kind of program that will generate the timeline automatically, or is it something more of a manual process? (See the Resources section at the end of this post for some examples of how to create a graphic representation of a timeline that can be added to reports.)

At this point, I'm of the opinion that this is still largely a manual process. While timeline creation and analysis has been automated to some degree through the use of tools, the fact is that there's currently no automated "sausage grinder" that you can drop an acquired image into and have it chug away and give you a full timeline. Just the file system metadata alone from one system can be cumbersome and overwhelming, particularly if you don't know what you're looking for. Lets say that you automatically add the Event Log entries to the timeline...but what if the Security Registry hive shows that the type of auditing you're looking for (successful login attempts) wasn't enabled, and a scan of the Event Logs shows that the events do not cover the dates in question anyway? If this is an automatic process, you've now got a lot of extra, albeit irrelevant, data.

What about context? Not all context of the events is visible in a timeline...in some cases, a recent modification date on a file isn't as important as what was added (or removed) from the file. Or you may have two events...a USB removable storage device plugged into the system and shortly thereafter, a Windows shortcut/LNK file created...and the valuable context of the correlation between the two events is in the path information and volume ID embedded in the LNK file.

In a way, this discussion brings us back around to the basic idea of the skill and knowledge of the examiner/analyst. Lets say an analyst responds to an incident, and goes on-site to find four desktop systems that had been powered down and taken off of the network. One analyst might look at this, remove the drives, and image them with the pair of Vooms he has in his jump kit. Another might hook each drive up to a write-blocker and acquire logical images of each partition. Yet another responder might boot each system, log in as Administrator, acquire volatile data, and then perform live acquisitions. Given this kind of disparity across a single response, how does an analyst then "correctly" decide which information needs to be included in a timeline for analysis, and then determine the context of the data?

IMHO, this all comes down to training and experience. Training specifically in this topic needs to be available, followed by guidance and mentoring. Cheatsheets need to be available to remind folks about what's available, why and how the data is important, and then within organizations and labs, there needs to be some kind of peer review.

Thoughts?

Resources
How to create a timeline in Excel (free templates)
Free SmartDraw Timeline Software

Timeline Analysis

As I've been preparing for our upcoming timeline analysis course, I've been putting some work into updating some of the tools that I use for creating timelines, which are also provided to attendees for their use, along with the other course materials.  Some of the updates I've been doing are intended to bring a new level of capabilities to the analyst, and really illustrate the power that timelines bring to an analyst.

One of the things Rob Lee has talked about in his timeline analysis courses is the idea of "pivot points", events within a timeline that would likely serve as anchor points for our analysis, or for what you're interested in determining.  I've had some conversations with folks at work and some extensive email exchanges with Corey Harrell lately, both of which have involved determining what some of these pivot or anchor points might be.  One place from which I've obtained pivot points is the initial triage phone call with the customer; maybe the customer had logged into a system and found that, at some point, WinRAR had been installed.  Or maybe they saw a pop-up from the AV application.  Or maybe banking or credit card fraud was reported by the bank to have occurred on a certain date, so you know that access to a system had to have occurred prior to that date.  The point is that we usually have some piece of information that leads us to the decision to create a timeline; after all, we wouldn't simply create a timeline "...because that's what we've always done."  I say, nay, nay...we're not likely to index an entire image unless we're planning to perform a keyword search, and we're equally unlikely to create a timeline unless we have a good reason for doing so.

My point is this...when we sit down to analyze an acquired image, how many times have we opened the image in our commercial analysis framework and just started poking around aimlessly?  The answer is probably...far too often.  What if I had a timeframe ("prior to April 5th"), or better yet, a specific event ("WinRAR was installed") that led me to creating a timeline?   I would then have a specific point within the timeline that I could go to in order to begin my analysis.

A Brief Word About Goals...
During the recent Intro to Windows Forensic Analysis course, one of the attendees asked me, "How do you determine the goals of your analysis if your customer doesn't even know them?"  Well, the fact of the matter is that they will know their goals, even if they don't know it...as an analyst, it's your job to work with them and draw that out.  Start with something simple, such as why the customer called you in the first place, or what led them to identify a system that they want you to acquire and analyze; now you just need to determine, analyze for what?  Sometimes, this can involve something (AV alert, pop-up, etc.) having occurred on a specific date, and that's a start...you'll at least know that you're looking for an event that occurred on a certain date, and that would be your initial anchor point.

And Now, Back To Timelines...
When I'm building at timeline, I like to use LogParser to extract data from the Windows Event Log (*.etvx) files.  I then use a Perl script, evtxparse.pl (provided as a standalone Windows executable), to transition the resulting .csv format logs into TLN format for inclusion into the timeline.  One of the tool updates I've completed recently is to add an event ID mapping capability to evtxparse.pl: as it parses through the output of LogParser, for each event, it checks a lookup table, based on event source and event ID pairs, for an identifier of what type or category the event is, and adds an identifier or tag to the event description.  For example, there are event records that tell you when a program has been installed, removed, or launched.  There are event records that tell you when the system has been connected to a wireless access point.  And there are a LOT of event records that indicate login attempts, either locally or remotely.  As I was working my way through an analysis, I thought that it might be useful to be able to quickly see at a glance what I was looking for...login events, program execution, etc.

Note: While I refer to the tools as Perl scripts, I also provide course attendees with copies of the scripts compiled into Windows executables via Perl2Exe.

The event ID mapping file is a flat text file, and in my modifications to the evtxparse.pl script, I included the ability to add comments to the file.  As part of my research, I've included links to Microsoft resources (as comments) that identify what certain events mean; so, it's not me saying that a particular event means that a program was installed, it's Microsoft stating that that's what the event identifies, and I provide a link a vendor resource that analysts can use to validate that information.  This provides a great facility for an analyst to not only easily research the event, but also add their own event identifiers.  I've also taken this a step further by adding similar identifiers to the TLN output of other tools, including the RegRipper plugins and other data parsers that are provided along with the course materials.

Another potential means for identifying pivot or anchor points for your analysis is to add an additional layer of filtering to the tools.  For example, I wrote a RegRipper plugin that replicates Mandiant's shimcache.py Python script, and we know from the published research that the entries identify programs that had been executed on the system.  Now, what if we were to not only tag these entries in our timeline as identifying program execution, but also scan each entry and identify those in particular that were run from a directory that includes the word "temp" in the path (such as "Local Settings\Temp" or "Temporary Internet Files")?  With all of the available data in a timeline, adding tags to identify pivot or anchor points in this way would likely be extremely useful.

This isn't anything new, and I'm not the only one to look at things this way.  At the SANS360 event last year, Rob Lee spent his 6 minutes talking about an Excel macro he had created to color code events in a similar manner, so that they could be easily identified in the output of log2timeline.  Rob's also created a poster of these event categories.

Tools
Some analysts have asked me about the timeline analysis course that we're offering, and why I don't use other, perhaps more popular tools when I perform my analysis.  I'm not against the use of other tools; in fact, if you have the time and interest, I strongly encourage you to use multiple tools to look at data.  Creating my own tools serves two purposes; it forces me to better understand the actual data so that I can better understand it and see how it can be useful, and it allows me a finer, more granular level of access to the data.  Sometimes, I don't want a full timeline...in fact, I may not even want a timeline created from just one source.  Other times, I may not have a complete image to work with; rather, I will have a selected set of files from a system.  I conduct various levels of analysis using a selected set of files in cases where it takes far too long to obtain and ship a full image file, when working with compromised systems that may contain sensitive data or illicit images, or when working to assist another analyst, to name but a few instances.  Or, based on the questions that the customer has, I may want a timeline created solely from a subset of one data source, such as a timeline of remote logins and from where they originated.  If that were the case, I might use a command line such as the following:

Logparser -i:evt -o:csv "Select RecordNumber,TO_UTCTIME(TimeGenerated),EventID,SourceName,ComputerName,SID,Strings from Log.evtx" | find "TerminalServices-LocalSessionManager/XX" > remote_logins.csv

Now that I have just the remote login messages, I can (a) parse these into a timeline, and (b) quickly write up a Perl script that will run through the information in the .csv file and provide me with a list of unique IP addresses.

Again, I'm not averse to using other tools, and definitely would not advocate against the use of other tools.  This is simply how I prefer to go about creating timelines, and I think that it serves as an excellent foundation from which to teach timeline creation and analysis.

ActivitesCache.db vs NTUSER.DAT

I recently had an opportunity to work with the data available in the Windows 10 Activity Timeline, or ActivitiesCache.db file.  I'd seen a number of descriptions of the file contents, as well as descriptions of tools, but few of these are from the perspective of a DFIR analyst/responder, and none that I could find provided a view of how the data from the database stands up alongside other data sources an analyst might examine.

First, I grabbed a copy of my own ActivitiesCache.db file:

esentutil /y /vss \ActivitiesCache.db /d ActivitiesCache.db

Then I grabbed a copy of my NTUSER.DAT hive:

reg save HKCU NTUSER.DAT

I used Eric Zimmerman's WxTCmd tool to parse the database; from the output, I got two CSV files (as described in Eric's blog post for the tool), one for the Activity table.  I then wrote a Perl script to translate elements of the Activity table into the 5-field TLN timeline format that I use for analysis.  This way, I was able to do something of a side-by-side comparison of data from the NTUSER.DAT hive with the contents of the ActivitiesCache.db database. Specifically, I created a timeline using the TLN variants of the UserAssist, RecentDocs, Applets, MSOffice and RecentApps RegRipper plugins, and then added the Activity table data to the events file before parsing it into a timeline.

What I found was pretty interesting.

For one, the data from the Activities table illustrated some interesting activity.  For example, here's what the data looks like for when I opened a PDF document from my desktop:

Wed Nov 20 23:04:15 2019 Z
  TIMELINE                   - End Time:Program Files x86\Adobe\Reader 11.0\Reader\AcroRd32.exe 

Wed Nov 20 23:04:14 2019 Z
  TIMELINE                   - End Time:C:\Users\harlan\Desktop\WRR.exe 

Wed Nov 20 23:00:51 2019 Z
  TIMELINE                   - Start Time:C:\Users\harlan\Desktop\WRR.exe 

Wed Nov 20 22:58:07 2019 Z
  TIMELINE                   - Start Time:Program Files x86\Adobe\Reader 11.0\Reader\AcroRd32.exe C:\Users\harlan\Desktop\A_Forensic_Audit_of_the_Tor_Browser_Bundle4.pdf
  TIMELINE                   - Start Time:Program Files x86\Adobe\Reader 11.0\Reader\AcroRd32.exe

I was doing some research into a particular Registry value, and a search had revealed a hit within the PDF.  I opened the PDF, and while it was open, also opened the MiTeC Windows Registry Recovery (WRR.exe) tool.

Another interesting finding is illustrated below:

Wed Nov 20 22:50:02 2019 Z
  REG                        - RegEdit LastKey value -> Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\TaskFlow
  TIMELINE                   - End Time:Windows\regedit.exe 

Wed Nov 20 22:49:11 2019 Z
  TIMELINE                   - Start Time:Windows\regedit.exe 

Wed Nov 20 22:49:07 2019 Z
  REG                        - [Program Execution] UserAssist - {F38BF404-1D43-42F2-9305-67DE0B28FC23}\regedit.exe (1)
  REG                        - [Program Execution] UserAssist - {0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\Administrative Tools\Registry Editor.lnk (1)

I opened RegEdit, navigated to a specific key, and that key was in focus when I closed RegEdit.  With respect to the LastKey value, we're aware that's the context of the data...the key that was in focus with RegEdit was closed.  What this clearly illustrates is "humanness"...human-based actions occurring and being recorded in these data sources.  We can see from the UserAssist data how RegEdit was opened, we can see how long it was open (in this case, ~50 sec or so), and which key was in focus when it was closed.  Looked at together, these artifacts provide a clear illustration of human activity.

Here's another example of what correlating the two data sources can look like:

Wed Nov 20 21:11:29 2019 Z
  TIMELINE                   - End Time:C:\Users\harlan\Desktop\WRR.exe 

Wed Nov 20 21:10:01 2019 Z
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs - local
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.dat - NTUSER.DAT
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\Folder - local

Wed Nov 20 21:09:45 2019 Z
  TIMELINE                   - Start Time:C:\Users\harlan\Desktop\WRR.exe 
  REG                        - [Program Execution] UserAssist - C:\Users\harlan\Desktop\WRR.exe (1)

In this particular case, I'd opened WRR and loaded an NTUSER.DAT file from a folder called "local".

Here's an example of how correlating the two data sources can provide additional insight and context into accessing files:

Wed Nov 20 20:20:56 2019 Z
  REG                        - RecentDocs - Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.doc - Armor of God.doc
  TIMELINE                   - End Time:Program Files x86\Microsoft Office\Office14\WINWORD.EXE 

Wed Nov 20 20:09:29 2019 Z
  REG                        - Word File MRU - C:\Users\harlan\Desktop\Armor of God.doc
  REG                        - Word Place MRU - C:\Users\harlan\Desktop\

Wed Nov 20 20:09:28 2019 Z
  TIMELINE                   - Start Time:Program Files x86\Microsoft Office\Office14\WINWORD.EXE 
  REG                        - [Program Execution] UserAssist - {7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Office\Office14\WINWORD.EXE (5)

In this particular case, I was preparing for Bible study and had a Word document open.  The data from the Activity Timeline database showed that MSWord had been opened, but it took data from the NTUSER.DAT hive (RecentDocs and MSOffice plugins) to provide information about which file had been opened.  In this case, the data illustrates that I'd had the file open approximately 11 minutes.

I could go on with the examples but suffice to say that the ActivitiesCache.db data provides context and validation to data from other sources; in this case, from data from the NTUSER.DAT hive associated with user activity.  Adding additional data from other sources, such as Automatic JumpLists would not only provide additional context, but would be extremely valuable in the face of anti-forensics efforts.  Getting a good view of what constitutes artifact clusters will also help us seen when elements from those clusters are missing, potentially through deletion efforts.

Further, the correlation of multiple data sources gives us a better view not only of artifact clusters, but also of past activities.  As I went through the timeline data, I was references to files and applications that no longer existed on my system. I also saw references to files on external data sources (F:\, G:\, etc.), as well.

Something else I found as a result of this exercise was that the first entry in the database table appears to be dated 20 Jun 2019.  Based solely on the data available, it would appear that an update was applied, as I'm also seeing all of the LastWrite times for RecentDocs subkeys set to the same time shortly before the first entry in the database.  A quick query via WMIC reveals that a security update was installed on that day, for KB4498523.  The finding is reminiscent of what Jason Hale discussed in his blog post regarding shellbags and a Win10 feature update.

Going Deeper
A while back, Mari had written a tool to parse deleted entries from a SQLite database, so I thought I'd give it a shot.  I downloaded the CLI version of the tool, and after running it, got a TSV file that I opened up in Excel.  There were a total of 630 rows, not all of which seemed to have much data, let alone much data of value.  However, many of the rows contained what looked like extensive JSON-formatted data.  A number of these contained references to files I'd opened in Notepad++, including the full path to the file, as well as the following:

{"gdprType":"ProductAndServiceUsage","clipboardDataId":"

So, much like other data sources, it appears that deleted items from this database file can provide additional insight and context, as well.

Additional Resources:
GroupIB writeup
Salt4n6 writeup
CCLGroup LTD writeup
Journal of Forensic Science paper
Medium.com article - lists descriptive resources, and tools, including Mark McKinnon's Autopsy plugin
PureInfoTech article - disabling the Timeline Activity feature (be sure to look for this being used for anti-forensics, or check the value if you're not finding the ActivitiesCache.db file)

Tools:
kacos2000 - WindowsTimeline
forensicMatt - ActivitiesCacheParser
Eric Z's Tools site
TZWorks - Timeline ActivitiesCache parser
Mari's SQLParser tools

Micro- & Mini-Timelines

I don't always create a timeline of system activity...but sometimes when I do, I don't have all of the data from within the system image available.  Many times, I will create a mini-timeline because all I have available is either limited data sources, or even just a single data source.  I've been sent Event Logs (.evt files) or a couple of Windows Event Logs (.evtx files), and asked to answer specific questions, given some piece of information, such as an indicator or a time frame.  I've had other analysts send me Registry hive files and ask me to determine activity within a specific time frame, or associated with a specific event.

Mini, micro, and even nano-timelines can assist an analyst in answering questions and addressing analysis goals in an extremely timely and accurate manner.

There are times where I will have a full image of a system, and only create a mini- or nano-timeline, just to see if there are specific indicators or artifacts available within the image.  This helps me triage systems and prioritize my analysis based upon the goals that I've been given or developed.  For example, if the question before me is to determine if someone accessed a system via RDP, I really only need a very limited number of data sources to answer that question, or even just to determine if it can be answered.  I was once asked to determine the answer to that question for a Windows XP system, and all I needed was the System Registry hive file...I was able to show that Terminal Services was not enabled on the system, and it hadn't been.  Again, the question I was asked  (my analysis goal) was, "...did someone use RDP to access this system remotely?", and I was able to provide the answer to that question (or perhaps more specifically, if that question could be answered).

Sometimes, I will create a micro-timeline from from specific data sources simply to see if there are indicators that pertain to the time frame that I've been asked to investigate.  One example that comes to mind is the USN change journal...I'll extract the file from an image and parse it, first to see if it covers the time frame I'm interested in.  From there, I will either extract specific events from that output to add to my overall timeline, or I'll just add all of the data to the events file so that it's included in the timeline.  There are times when I won't want all of the data, as having too much of it can add a significant amount of noise to the timeline, drowning out the signal.

There are times when I simply don't need all of the available data.  For example, consider a repurposed laptop (provided to an employee, later provided to another employee), or a system with a number (15, 25, or more)  of user profiles; there are times that I don't need information from every user profile on the system, and including it in the timeline will simply make the file larger and more cumbersome to open and analyze.

I've also created what I refer to as nano-timelines.  That is, I'll parse a single Windows Event Log (.evtx) file, filter it for a specific event source/ID pair, and then create a timeline from just those events so that I can determine if there's something there I can use.

For example, let's say I'm interested in "Microsoft-Windows-Security-Auditing/5156" events; I'd start by running the Security.evtx file through wevtx.bat:

C:\tools>wevtx.bat F:\data\evtx\security.evtx F:\data\sec_events.txt

Now that I have the events from the Security Event Log in a text file, I can parse out just the events I'm interested in:

C:\tools>type F:\data\sec_events.txt | find "Microsoft-Windows-Security-Auditing/5156" > F:\data\sec_5156_events.txt

Okay, now I have an events file that contains just the event records I'm interested in; time to create the timeline:

C:\tools>parse -f F:\data\sec_5156_events.txt > F:\data\sec_5156_tln.txt

Now, I can open the timeline file, see the date range that those specific events cover, as well as determine which events occurred at a specific time. This particular event can help me find indications of malware (RAT, Trojan, etc.), and I can search the timeline for a specific time frame, correlating outbound connections from the system with firewall or IDS logs.  Because I still have the events file, I can write a quick script that will parse the contents of the events file, and provide me statistics based on specific fields, such as the destination IP addresses of the connections.

What's great about the above process is that an analyst working on an engagement can archive the Windows Event Log file in question, send it to me, and I can turn around an answer in a matter of minutes.  Working in parallel, I can assist an analyst who is neck-deep in an IR engagement by providing solid answers to concrete questions, and do so in a timely manner.  My point is that we don't always need a full system image to answer some very important questions during an engagement; sometimes, a well-stated or well-thought-out question can be used as an analysis goal, which leads to a very specific set of data sources within a system being examined, and the answer to whether that system is in scope or not being determined very quickly.

Analysis Process
Regardless of the size of the timeline (full-, mini-, micro-), the process I follow during timeline analysis is best described as iterative.  I'll use initial indicators...time stamps, file names/paths, specific Registry keys...to determine where to start.  From there, I'll search "nearby" within the timeline, and look for other indicators.

I mentioned the tool wevtx.bat earlier in this post; something I really like about that tool is that it helps provide me with indicators to search for during analysis.  It does this by mapping various event records to tags that are easy to understand, remember, and search for.  It does this through the use of the eventmap.txt file, which is nothing more than a simple text file that provides mappings of events to tags.  I won't go into detail in this blog post, as the file can be opened in viewed in Notepad.  What I like to do is provide references as to how the tag was "developed"; that is, how did I decide upon the particular tag.  For example, how did I decide that a Microsoft-Windows-TerminalServices-LocalSessionManager record with event ID 22 should get the tag "Shell Start"?  I found it here.

This is very useful, because my timeline now has tags for various events, and I know what to look for, rather than having to memorize a bunch of event sources and IDs...which, with the advent of Vista and moving into the Window 7 system and beyond, has become even more arduous due to the shear number of Event Logs now incorporated into the systems.

So, essentially, eventmap.txt serves as a list of indicators, which I can use to search a timeline, based upon the goals of my exam.  For example, if I'm interested in locating indications of a remote access Trojan (RAT), I might search for the "[MalDetect]" tag to see if an anti-virus application on the system picked up early attempts to install malware of some kind (I should note that this has been pretty helpful for me).

Once I find something related to the goals of my exam, I can then search "nearby" in the timeline, and possibly develop additional indicators.  I might be looking for indications of a RAT, and while tracking that down, find that the infection vector was via lateral movement (Scheduled Task).  From there, I'd look for at least one Security-Auditing/4624 type 3 event, indicating a network-based logon to access resources on the system, as this would help me determine the source system of the lateral movement.  The great thing about this is that this sort of activity can be determined from just three Windows Event Log files, two Registry hives, and you can even throw in the MFT for good measure, although it's not absolutely required.  Depending on the time frame of response...that is, was the malicious event detected and the system responded to in a relatively short time (an hour or two), or is this the result of a victim notification of something that happened months ago...I may include the USN change journal contents, as well.

My efforts are most often dedicated toward finding clusters of multiple indicators of specific activity, as this provides not only more context, but also a greater level of confidence in the information I'm presenting.  Understanding the content of these indicator clusters is extremely helpful, particularly when anti-forensics actions have been employed, however unknowingly.  Windows Event Logs may have "rolled over", or a malware installer package may include the functionality to "time stomp" the malware files.