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 menuorder.pl 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.
Registry
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.
MSIs
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.
RecentDocs
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.
AppCompatCache
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.
MUICache
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
*Tracing
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).
SysInternals
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.
UserAssist
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.
RunMRU
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.
LANDesk
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 malware...in 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.
Resources
Network artifacts found in the Registry
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 menuorder.pl 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.
Registry
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.
MSIs
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.
RecentDocs
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.
AppCompatCache
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.
MUICache
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
*Tracing
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).
SysInternals
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.
UserAssist
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.
RunMRU
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.
LANDesk
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 malware...in 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.
Resources
Network artifacts found in the Registry