Sometimes during an examination, it can be important to determine what programs have been executed on a
system, and more specifically, when and by which user. Some of the artifacts on a system will provide us with indications of programs that have been executed, while others will provide information about which user launched the program, and when.  As such, some of this information can be included in a timeline.

Hopefully, something that will become evident throughout this post, as well as other HowTo posts, is that rather than focusing on individual artifacts, we're going to start putting various artifacts into "buckets" or categories.  The purpose for doing this is so that analysts don't get lost in a sea of artifacts, and are instead able to tailor their initial approach to an examination, possibly using an analysis matrix.

Okay, let's get started...

AutoStart Locations
Before we begin to look at the different artifacts that can be directly tied to a user (or not), I wanted to briefly discuss autostart locations.  These are locations within the system...file system, Registry...where references to programs can reside that allow  programs to be executed automatically, without any interaction from the user beyond booting the system or logging in.  There are a number of such locations and techniques that can be used...Registry autostart locations, including the ubiquitous Run key, Windows services, the StartUp folder on the user's Program Menu, and even the use of the DLL Search Order functionality/vulnerability.  Each of these can be (and have been) discussed in multiple blog posts, so for now, I'm simply going to present them here, under this "umbrella" heading, for completeness.

Scheduled Tasks can be, and are, used as an autostart location.  Many of us may have QuickTime or iTunes installed on our system; during installation, a Scheduled Task to check for software updates is created, and we see the results of this task now and again.  Further, on Windows 7 systems, a Scheduled Task creates backups of the Software, System, Security, and SAM hive files into the C:\Windows\system32\config\RegBack folder every 10 days.  When considering autostart locations, be sure to check the Scheduled Tasks folder.


Tools: RegRipper plugins, MS/SysInternals AutoRuns; for XP/2003 Scheduled Task *.job files, jobparse.pl; on Vista+ systems, the files are XML

User
There are a number of artifacts within the user context that can indicate program execution.  This can be very useful, as it allows analysts to correlate program execution to the user context in which the program was executed.

UserAssist
The contents of value data within a user's UserAssist subkeys can provide an excellent view into what programs the user has launched via the Explorer shell...by double-clicking icons or shortcuts, as well as by navigating via the Program Menu.  Most analysts are aware that the value names are Rot-13 encoded (and hence, easily decoded), and folks like Didier Stevens have gone to great lengths to document the changes in what information is maintained within the value data, as versions of the operating systems have progressed from Windows 2000 to Windows 8.

Tools: RegRipper userassist.pl and userassist_tln.pl plugins

RunMRU
When  a user clicks on the Start button on their Windows XP desktop, and then types a command into the Run box that appears, that command is added to the RunMRU key.

Interestingly, I have not found this key to be populated on Windows 7 systems, even though the key does exist.  For example, I continually use the Run box to launch tools such as RegEdit and the calculator, but when I dump the hive file and run the runmru.pl RegRipper plugin against it, I don't see any entries.  I have found the same to be true for other hives retrieved from Windows 7 systems.

Tools: RegRipper runmru.pl plugin

ComDlg32\CIDSizeMRU Values
The binary values located beneath this key appear to contain names of applications that the user recently launched.  From my experience, the majority of the content of these values, following the name of the executable file, is largely zeros, with some remnant data (possibly window position/size settings?) at the end of the file.  As one of the values is named MRUListEx, we can not only see (via a timeline) when the most recent application was launched, but we can also see when other applications were launched by examining available VSCs.

AppCompatFlags
According to MS, the Program Compatibility Assistant is used to determine if a program needs to be run in XP Compatibility Mode.  Further, "PCA stores a list of programs for which it came up...even if no compatibility modes were applied", under the Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted key in the user's NTUSER.DAT hive.  As such, we can query these values and retrieve a list of programs run by the user.

Tools: RegRipper appcompatflags.pl plugin (I updated the plugin, originally written by Brendan Cole, to include retrieving the values beneath the Persisted key, on 6 July 2013; as such, the plugin will be included in the next rollout)

MUICache
The contents of this key within the user hives (NTUSER.DAT for XP/2003, USRCLASS.DAT for Win7) often contains references to applications that were launched within the user context.  Often times, these application will include command line interface (CLI) utilities.

Windows shortcuts/LNK files and Jump Lists
You're probably thinking..."huh?"  Most analysts are familiar with how shortcuts/LNK files (and Jump Lists) can be used to demonstrate access to files or external storage devices, but they can also be used to demonstrate program execution within the context of a user.

Most of us are familiar with the LNK files found in the ..\Windows\Recent and ..\Office\Recent folders within the user profile...so, think about how those shortcuts are created.  What usually happens is that the user double-clicks a file, the OS will read the file extension from the file, and then query the Registry to determine which application to launch in order to open the file.  Windows will then launch the application...and this is where we have program execution.

Many times when a user installs an application on their system, a desktop shortcut may be created so that the user can easily launch the application.  The presence of an icon on the desktop may indicate that the user launched an installer application.

Tools: custom Perl script, tools to parse LNK files

Java Deployment Cache Index (*.idx) Files
The beginning of 2013 saw a lot of discussion about vulnerabilities to Java, as well as reports of 0-days, and as a result, there was a small number of folks within the community looking into the use of Java deployment cache index (*.idx) files during analysis.  The use of these files as artifacts during an investigation goes back to well before then, thanks to Corey Harrell.  These files provide indications of downloads to the system via Java, and in some cases, those downloads might be malicious in nature.  These artifacts are related specifically to Java being executed, and may lead to indications of additional programs being executed.  Further, given that the path to the files is within the user profile folder, we can associate the launch of Java with a specific user context.

Tools: idxparse.pl parser

Browser History
A user's browser history not only indicates that they were browsing the web (i.e., executing the browser program), but the history can also be correlated to the *.idx files discussed above in order to determine which site they were visiting that caused Java to be launched.

System
There are a number of artifacts on the system that can provide indications of program execution

Prefetch File Analysis
Most analysts are aware of some of the metadata found within Prefetch files.  Application prefetch files include metadata indicating when the application was last launched, as well as how many times it has been launched.  This can provide some excellent information

Tools: pref.pl, or any other tools/scripts that parse the embedded module strings.  Recent versions of scripts I've written and use incorporate an alerting mechanism to identify items within the strings and string paths found to be "suspicious" or "unusual".

AppCompatCache
This value within the System hive in the Registry was first discussed publicly by Mandiant, and has proven to be a treasure trove of information, particularly when it comes to malware detection and determining program execution, in general.

Tools: Mandiant's shim cache parser, RegRipper appcompatcache.pl plugin (appcompatcache_tln.pl plugin outputs in TLN format, for inclusion in timelines).

Legacy_* Keys
Within the System hive, most of use are familiar with the Windows services keys.  What you may not realize is that there is another set of keys that can be very valuable when it comes to understanding when Windows services were run...the Enum\Root\Legacy_* keys.  Beneath the ControlSet00n\Enum\Root key in the System hive, there are a number of subkeys whose names being with LEGACY_, and include the names of services.

There are a number of variants of malware (Win32/Alman.NAD, for example) that install as a service, or driver, and when launched, the operating system will create the Enum\Root\Legacy_* key for the service/driver.  Also, these keys persist after the service or driver is no longer used, or even removed from the system.  Malware writeups by AV vendors will indicate that the keys are created when the malware is run (in a sandbox), but it is more correct to say that the OS creates the key(s) automatically as a result of the execution of the malware.  This can be an important distinction, which is better addressed in another blog post.

Tools: RegRipper legacy.pl plugin

Direct* and Tracing Keys
These keys within the Software hive can provide information regarding program execution.

The "Direct*" keys are found beneath the Microsoft key, and are keys whose names start with "Direct", such as Direct3D, DirectDraw, etc.  Beneath each of these keys, you may find a MostRecentApplication key, which contains a value named Name, the data of which indicates an application that used the particular graphics functionality.  Many times during an exam, I'll see "iexplore.exe" listed in the data, but during one particular exam, I found "DVDMaker.exe" listed beneath the DirectDraw key.  In another case, I found "mmc.exe" listed beneath the same key.

I've found during exams that the Microsoft\Tracing key contains references to some applications that appear to have networking capabilities.  I do not have any references to provide information as to which applications are subject to tracing and appear beneath this key, but I have found references to interesting applications that were installed on systems, such as Juniper and Kiwi Syslog tools (during incident response engagements, this can be very helpful and allow you collect Event Logs from the system that have since been overwritten, and included in a timeline...).  Unfortunately, these artifacts have nothing more than the EXE name (no path or other information is included or available), but adding the information to a timeline can provide a bit of context and granularity for analysis.


Tools: RegRipper direct.pl and tracing.pl plugins

Event Logs
Service Control Manager events within the System Event Log, particularly those with event IDs 7035 and 7036, provide indications of services that were successfully sent controls, for either starting or stopping the service.  Most often within the System Event Log, you'll see these types of events clustered around a system start or shutdown.  During DFIR analysis, you're likely going to be interested in either oddly named services, services that only appear recently, or services that are started well after a boot or system startup.  Also, you may want to pay close attention to services such as "PSExeSvc", "XCmdSvc", "RCmdSvc", and "AtSvc", as they may indicate lateral movement within the infrastructure.

On Windows 2008 R2 systems, I've found indications of program execution in the Application Experience Event Logs; specifically, I was examining a system that had been compromised via an easily-guessed Terminal Services password, and one of the intruders had installed Havij (and other tools) on the system.  The Application-Experience/Program-Inventory Event Log contained a number of events associated with program installation (event IDs 903 and 904), application updates (event ID 905), and application removal (event IDs 907 and 908).  While this doesn't provide a direct indication of a program executing, it does illustrate that the program was installed, and that an installer of some kind was run.

On my own Windows 7 system, I can open the Event Viewer, navigate to the Event Log, and view the records that illustrate when I have installed various programs knowingly (FTK Imager) and unknowningly (Google+ Chat).  There are even a number of application updates to things like my ActiveState Perl and Python installations.

Tools: LogParser, evtxparse.pl

Other Indirect Artifacts
Many times, we may be able to determine program execution through the use of indirect artifacts, particularly those that persist well after the application has finished executing, or even been deleted.  Many of the artifacts that we've discussed are, in fact, indirect artifacts, but there may still be others available, depending upon the program that was executed.

A number of years ago, I was...and I don't like to admit this...certified to perform PCI forensic audits.  On one case, I ran into my first instance of a RAM scraper...this was a bit of malware that was installed on a point-of-sale (POS) back office server (running Windows) as a Windows service.  After the system was booted, this instance of the malware would read the contents of a register, do some math, and use that value as a seed to wait a random amount of time before waking up and dumping the virtual memory from one of eight named (the names were listed in the executable file) processes.  The next step was to parse the memory dump for track data, and this was accomplished via the use of Perl script that was "compiled" via Perl2Exe.  I'm somewhat familiar with such executables, and one of the artifacts we found to validate our findings with respect to the actual execution of the malicious code was temporary directories created by "compiled" script.  When executables "compiled" with Perl2Exe are run, any of the Perl modules (including the runtime) packed into the executable are extracted as DLLs into a temporary directory, at which time they are "available" to the running code.  As the code was launched by a Windows service, the "temp" directories were found in the C:\Windows\Temp folder.  The interesting thing that we found was that the temp directories used to hold the modules/DLLs are not deleted after the code completes, and they persist even if the program itself is removed from the system.  In short, we had a pretty good timeline for each time the parsing code was launched.

On my own Windows 7 system, because I run a number of Perl scripts that were "compiled" with Perl2Exe within the context of my user account, the temp directories are found in the path, C:\Users\harlan\AppData\Local\Temp...the subdirectories themselves are named "p2xtmp-", and are followed by an integer, and themselves contain subdirectories that represent the Perl runtime namespace.  The time stamps (creation dates) for these subdirectories provide indications of when I executed scripts  that had been compiled via Perl2Exe.

Memory Dumps
During dead box analysis, memory dumps can be an excellent source of information.  When an application crashes, a memory dump is created, and a log file containing information including a process list also created.  When another application crash occurs, the memory dump is overwritten, but the log file is appended to, meaning that you can have a number of crash events available for analysis.  I have found this historical information to be very useful during examinations because, while the information is somewhat limited, it can illustrate whether or not a program was running at some point in the past.

We're not going to discuss hibernation files here, as once you access a hibernation file and begin analysis, there really is very little difference between analyzing the hibernation file and analyzing a memory dump for a live system.  Many of the techniques that you'd use, and the artifacts that you would look for, are pretty much the same.

Tools: text viewer


Resources
This idea of determining program execution has been discussed before:
Timeline Analysis, and Program Execution
There Are Four Lights: Program Execution

I recently blogged on Prefetch Analysis, Revisited, and was poking around one of Corey's blog posts regarding exploit artifacts, this one associated with Java.  Corey was kind enough to send me the  Prefetch file that was created as part of his testing, and I ran it against the Perl script that I'd written.  It pulled out some pretty interesting things, and with Corey's permission, I've pulled out some of the more interesting strings to share.  Where the paths are really long and they have to wrap, I've added a space between the lines to cut down on confusion and make them a bit more readable.

First, we know from where Java was run:

\DEVICE\HARDDISKVOLUME1\PROGRAM FILES\JAVA\JRE6\BIN\JAVA.EXE

There's also another EXE listed in the output:

\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\CMD.EXE

That's interesting.  Maybe an interesting analysis technique to add via the tools is to parse the module paths, and find not just the path to the EXE that was created, but also any other EXE paths listed, and flag on those with more than one.  Flagging on those Prefetch files that include more than one EXE path may not find anything in most cases, but hey, it's automated and documented, only takes a quick second to run, and the time that it does find something will be a real winner.

Okay, now back to our regularly scheduled program, already in progress...

Then I found these paths:


\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D9.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D8THK.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\VMX_FB.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D9CAPS.DAT
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D9CAPS.TMP

I wasn't too interested in those (I had no idea what they are) until I found this one later on:

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\TEST\LOCAL SETTINGS\APPLICATION DATA\D3D9CAPS.TMP

I still have no idea what any of this is...remember, I only have the single Prefetch file...but this might be something worth investigating.

Here's a path to one of the logs that Corey mentioned in his post:


\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\APPLICATION DATA\SUN\JAVA\DEPLOYMENT\DEPLOYMENT.PROPERTIES

We see something similar later in the output, for the Test user:

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\TEST\APPLICATION DATA\SUN\JAVA\DEPLOYMENT\DEPLOYMENT.PROPERTIES

Here's the path to another log file that Corey mentioned in his blog:

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\JAVA_INSTALL_REG.LOG


And here's the same thing, but for the Test user account (again):


\DEVICE\HARDDISKVOLUME1\DOCUME~1\TEST\LOCALS~1\TEMP\JAVA_INSTALL_REG.LOG

Remember that Corey was using MetaSploit, per his blog post:


\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\~SPAWN7448022680969506475.TMP.DIR\METASPLOIT.DAT

A while I go, I posted on Prefetch file analysis, and based on some recent events, I thought that I'd revisit this topic.

By now, most analysts are familiar with Prefetch files and how they can be useful to an examination.  I think most of us tend to take a quick look over the names of the Prefetch files during analysis, just to see if anything jumps out at us (I've seen Prefetch files for "0.exe", and I'd call that odd and worth digging into).  As described on the ForensicsWiki, Prefetch files also have a good bit of embedded metadata, and can be very useful during analysis.  For example, you may look at the listing of files and something unusual may immediately jump out at you.

Also, if you include Prefetch file metadata in a timeline of an XP system, you should see a file access time for the executable "near" to when a Prefetch file for that executable is created or updated.  If that's not the case, you may have an issue of time manipulation, or the original executable may have been deleted.

Thankfully, Prefetch files are an artifact of an EXE file engaging with its eco-system and not a direct artifact of the EXE.  As such, if the EXE is deleted, the Prefetch file persists.  Very cool.

Prefetch files also contain a number of strings, which are file names and full paths that point to modules used or accessed by the executable, and even some other files accessed by the executable.  This stuff can be very interesting.  For example, if you see two Prefetch files for Notepad, remember that the hash in the .pf file name is generated using the path to the file, as well as command line options.  As most Windows systems have two copies of Notepad (one in the Windows dir, the other in the Windows\system32 dir), you're very likely to see two Prefetch files for that executable...and you will likely also find the full path to the executable right there within the embedded strings.

So, I got to thinking...how can we use this information?  How about we do a little data reduction?  Rather than running through all 128 or so .pf files manually, one at a time, we can let some code do that for us, and then display the paths to all of the executables.  We might even want to add some checking, say grep() the file path for something like "temp", so we can see executables that were launched from a path that included "Temp" or even "Temporary Internet Files".

Another idea is to do a little Least Frequency of Occurrence analysis, and run through all of the .pf files and list those module paths that only appear once in all of the files.  This is a great bit of work that can be easily automated, leaving us to just look over the output.  You can even expand your analysis to those modules that occur twice, or even three times.

The more I think of this, the more I'm thinking that this is something that would go really well in a forensic scanner.

Addendum, 3/11:  Tonight I completed transitioning the pref.pl Perl script to a module, so that the functionality can be encapsulated in other tools.  

I've seen a couple of posts recently on other blogs (here's one from Mark McKinnon) pertaining to the Windows XP Prefetch capability, and I thought I'd throw out some interesting stuff on analysis that I've done with regards to the Prefetch folder.

First off, XP's Prefetch capability is meant to enhance the user eXPerience by helping frequently used applications load faster. Microsoft has a nice writeup on that, and portions of and references to that writeup are included in my book. XP has application prefetching turned on by default, and while Windows 2003 has the capability, only boot prefetching is turned on by default. So, XP systems are rich in data that can help you assess and resolve an incident investigation.

First off, XP can maintain up to 128 Prefetch files...these are files within the Windows\Prefetch directory that end in ".pf". These files contain a bunch of prefetched code, and the second half of the files generally contain a bunch of Unicode strings that point to various modules that were accessed when the application was launched. Also, each Prefetch file contains that run count (number of times the application has been run) as well as a FILETIME object representing the last time the application was launched, within the file itself (ie, metadata).

Okay, so how can this information be used during forensics analysis? Remember Harlan's Corollary to the First Law of Computer Forensics? If you acquire an image from a system...say, a user's laptop...and you're told that the user had this laptop for a year or so, and you don't find any .pf files...what does that tell you?

Mark talked about U3 Smart Technology, and some of the Prefetch artifacts left behind by the use of tools like this. Excellent observations, but keep in mind that the Prefetch files aren't specific to a user...they're system-wide. On a multi-user system, you may have to look other places to determine which user launched the application in the first place. Ovie does a great job talking about the UserAssist keys and how they can help you narrow down who did what on the system.

I've looked to the Prefetch folder for assistance with an investigation. In one instance, there was a suspicion that a user had deleted some files and removed software from the system, and attempted to cover his tracks. While it was clear that the user had done some of these things (ie, removed software, emptied their Recycle Bin, etc.) it was also clear that they hadn't gone through the trouble of running one of those tools that delete everything; most of the artifacts I would look for were still in place (can you guess from my book what those artifacts might have been?). I found a reference to defrag.exe in the Prefetch folder, but nothing to indicate that the user had run the defrag tool (XP's built-in, automatic anti-forensics capabilities are a subject for another post). It turns out that as part of the Prefetch capability, XP runs a limited defrag every 3 days...the Prefetch capability prefetches XP's own prefetch functionality. ;-)

In another instance, I wanted to see if a user had burned anything to CD from the system. I found the installed software (Roxio Sonic), but found no references in any of the user artifacts to actually launching the software. I did, however, find an IMAPI.EXE-XXXXXX.pf file in the Prefetch directory. Interestingly enough, the Unicode strings within the file included a reference to iTunes, which, it appeared, the user used a lot. It turns out that iTunes likes to know where your CD or DVD burner is...I confirmed this on another system on which I knew the user used iTunes, and had not burned any CDs.

So, as a wrap up, some things to look for when you're digging into the Prefetch directory:

- How many .pf files (between 0 and 128) are in the Prefetch directory?

- For each .pf file, get the last run time and the run count. The last run time is a FILETIME object, meaning that it is maintained in UTC format...you may need to adjust using information from the TimeZoneInformation Registry key (ie, ActiveTimeBias).

- Correlate .pf files and the last run times to UserAssist key entries to tie activity to a specific user, as well as the Event Logs.

- Run strings to get the Unicode strings from the file and see what other modules were accessed when the application was launched.

Finally, there is a ProDiscover ProScript on the DVD that ships with my book (in the ch5 directory) that will locate the Prefetch folder (via the Registry) and automatically parse the .pf files, listing the last run time and run count for each. I have since updated that ProScript to display its output in time-sorted order, showing the most recent time first. I've found that this makes analysis a bit easier.