Monday, March 18, 2013

There are Four Lights: Program Execution

I'd seen a tweet recently where someone was asking about information regarding the last time a user launched an application on a system. The system had an SSD drive, and as such, application Prefetching was disabled, by default.  Therefore, one of the more well-known artifacts that indicate program execution was not available to the analyst.  The fact is that there are a number of locations available on Windows systems that will maintain indications of program execution.  Although not all of them allow the program execution or application launch to be tied directly to a user, or to be correlated to a specific time, they may be useful, nonetheless.

A valuable aspect of these locations is that they will very often persist beyond the deletion or removal of the application.

This category of artifacts can assist you in implementing an analysis matrix for your examination.

This post will be directed at providing information about artifacts that provide indications of program execution; many of the artifacts listed will not be able to allow the analyst to state explicitly that a user last launched an application at a specific date and time; rather, analysts should be aware of the artifacts, and be able to apply them (and others) as needed.  These artifacts can be used in a number of cases, in order to demonstrate a window of compromise, malware detection (just because you detected malware, does that mean that it actually ran??), etc.

Application Prefetch Files
Application prefetch files are a great source of information about applications run on the system, as well as when they were last run (although they are not specific to a user).  However, Windows server systems do not have application prefetching enabled by default, and application prefetching is disabled by default when Windows sees that it's being run from an SSD drive.

Shortcut/LNK files and Jump Lists
I include shortcut/LNK files and Jump Lists together because Jump Lists are comprised of LNK streams (this goes back to my post on understanding data structures).  And they can both provide indications of program execution (as well as access to remote storage).  In order to determine which application was launched, you may need to do some file extension analysis, or in the case of Jump Lists, start with an AppID lookup.

Browser History
With the exception of what was described in this blog post, the existence of a browser history will demonstrate the browser had been launched, within the context of a specific user.  In most cases, the specific records requested will include time stamps.  Also, don't forget to check things like bookmarks/favorites, etc., which will provide other indications of the use of the browser, even after the browser history has been cleared or trimmed (most browsers have an automatic process for clearing out older history and cache entries, independent of the user specifically performing the action).  Also, for IE, check out the RegRipper plugin.

Hibernation Files
While hibernation files will not explicitly put the suspect at the keyboard, much like crash dump files, they can be used to demonstrate that an application was (or wasn't) running at one time.  If you're going to analyze hibernation files, I strongly recommend that you consider using Volatility, or take the course taught by these folks.

Windows Event Log
I was analyzing a Windows 2008 R2 server not long ago, and found that an intruder had installed and run Havij and some other, similar tools.  Interesting enough, the Application Experience Event Log included entries indicating that the application had been installed on, as well as removed from the system.  Remember, Process Tracking isn't always enabled within audit configuration, but there may be other ways to determine indications of applications or programs being executed via serivces starting (event ID 7035/7036), etc.

The Windows Registry can contain a number of interesting keys and values that can provide indications of applicaitons being launched, or programs being executed.  In many cases, much like the file system, these locations can contain information about program execution long after the deletion/removal of the application or program.

Windows maintains a list of applications that were installed via Microsoft Installer (*.msi) files.  While this does not tie directly the execution of the program, it can indicate that it was installed.

The user's RecentDocs key can provide indications of program execution, even if indirectly.  For example, an .exe file may have been opened, but rather than launched, the user had opened it in a hex editor...which itself is an indication of "program execution" (of the hex editor).  You may have to perform file extension analysis or timeline analysis in order to determine specifically which application was used to open the file.

Also, be sure to check the OpenSaveMRU and OpenSavePidlMRU subkeys beneath the ComDlg32 key.

An old favorite, Corey Harrell has talked about this Registry value on his blog.  Also, if you really want to get  the available information about this value, check out what Mandiant has to say about it.  They discovered and publicized it, and even wrote up an excellent white paper on parsing the value data.  It's important to keep in mind that the last modification time for each application that is retrieved by the various tools is from the file system.

I've found over the years that some applications run within the user context have had entries created as values beneath this Registry key.  Now, the values do not have a time stamp associated with them

MS states that the Routing and Remote Access protocol has some pretty extensive tracing capabilities used for troubleshooting.  During exams, I've seen applications with networking capabilities included in subkeys beneath this key.

*DirectDraw, etc.
There are a number of subkeys beneath the Microsoft key (in the Software and NTUSER.DAT hives) that have names like DirectDraw, Direct3D, etc., and some of these may have a subkey named MostRecentApplication, which provides the name of the last application to make use of the capability.  I have seen this most often used by legitimate applications, such as iexplorer.exe, but it may also lead to malware (see this Sophos ZBot writeup). 

While this key is particular to a specific set of applications, the fact is that in order to run the SysInternals utilities, you need to accept the EULA, which creates a Registry subkey beneath the SysInternals key.  This can be very useful during an exam.

AppCompatFlags (NTUSER.DAT)
This key contains artifacts of applications executed by a user under the Program Compatibility Assistant, even if no compatibility modes are applied.

These artifacts provide indications of applications that the user launched by clicking on them through the shell, either double-clicking an icon on their Desktop or through Windows Explorer, or by selecting the Start button and clicking on the application through the program menu.

This Registry key provides indications of commands that the user has typed in at the Start->Run box.

AutoStart locations - *Run keys, Windows Services, etc.
You would need to correlate these entries to when the system was started, or when the user logged in.  This can be extremely significant.  If something (malware or another application) is set to autostart based on when a user logs in (usually found within the HKCU hive), then the last time that the application executed could be well after the system was started.  This may not be significant to the examination, but it does go to overall clarity and correctness of your findings.

I've seen a couple of instances where a system I was examining had LANDesk installed; part of the functionality of LANDesk includes the application writing Registry keys for each application launched on the system, including values for when the application was first and last launched, the user account used to launch the application the last time it was run, etc.  This proved very useful, particularly when included in a timeline.

Windows Services/AutoStart Locations
Windows Services can provide some excellent information regarding the start of an application; however, do not assume that because a service is listed that it automatically started with the system booted.  This is not always the case.  An analyst needs to check the start type of the service, as well as check the Windows Event Log for events with ID 7035/7036 (indicate a service start).  Another artifact that can be extremely useful when examining services is the Enum\Root\LEGACY_* keys within the System hive; the subkeys beneath these keys for each service are created the first and last time, respectively, that the service was run, and like other artifacts, will persist after the service was either disabled or removed from the system.

The same is true with other autostart locations; you need to be clear on the location and the effect that it has on the application start...even MS has gotten this one wrong.  If the application is listed in a user hive (HKCU), then it will start when the user logs in, NOT when the system starts.

'*' indicates Registry keys that may also have a counterpart found in the Wow6432Node path.

The artifacts described in this blog post are intended to assist analysts in understanding where to look for indications that applications has been run on a system.  In some cases, the artifacts may tie the program execution to a specific user, and other times, to a specific time.  These artifacts are not specific to fact, I tend to attribute other, specific artifacts to the "malware" artifact category.  Other artifacts may be specific to applications...for example, the Terminal Services Client will maintain a list of systems to which a user has connected in both Jump Lists, as well as beneath a Registry key in the NTUSER.DAT hive, indicating that the user launched the application.  IE (versions 5-9) has Registry artifacts, as well.  Applications that include MRU lists will allow the analyst to demonstrate the use of that application, by a user, at a specific time.

Network artifacts found in the Registry


Ken Pryor said...

Great information and very timely for me. I'm working a case with a Windows 2008 Terminal Server. I appreciate this post, as I believe it will help me answer some questions I still need to answer.

Thierry_Fr said...

Great summary. Thank you.
I would add AV logs that can be useful too.

H. Carvey said...


Can you elaborate on how this information was useful to you?

Ken Pryor said...

Certainly! First, it was just helpful as I don't work a lot of cases that require determining program execution and so on. Most of my cases are CP related and are basically a case of find the porn and if possible try to figure out how it got there if possible. That's often accomplished with a timeline and not much else.

So, it was an exciting thing for me to hear my most recent case had nothing to do with CP, but rather the intrusion to a 2008 server. I discovered WinRAR, some hacking tools, 3 different web browsers and a bulk email program in a couple of the user downloads and desktop folders. I wanted to determine whether or not any of those things had been used by the intruders. That wasn't too difficult for the browsers, as there was significant web history for each browser. I needed to see if the other items had been run or if the intrusion had been discovered in time to interrupt the bad guys. I found evidence of them all being run in the registry (user assist).
I haven't finished looking at everything yet. I plan to check the AppCompatCache when I go back in to the office.


H. Carvey said...


Thanks for the comment.

So, you were able to run the RegRipper UserAssist plugin against the NTUSER.DAT? How about the plugin against the System hive?

Ken Pryor said...

Sorry for the delayed reply. My shifts are a little crazy this week.

I ran the plugin against the System hive and found more evidence of several programs I was interested in being run. I'm still going through all the output, but RR with this plugin definitely provided useful information.

H. Carvey said...


Interesting comment, thanks. I DM'd you on Twitter with a question...sorry, I don't have an email address for you...