You found a malicious executable! Now you’ve got a crucial question
to answer: did the file execute? We’ll discuss a few sources of
evidence you can use to answer this question. In this post, we will
focus on static or "dead drive" forensics on Windows
systems. We will cover four main sources of evidence: Windows
Prefetch, Registry, Log Files, and File Information.
Prefetch
Windows Prefetch is a good place to begin
looking for evidence of file execution. Microsoft designed Windows
Prefetch to allow commonly used programs to open faster. By default,
it stores information for the last 128 executed files in prefetch
files found in "C:WindowsPrefetch". A prefetch file is
named as "executable file name" + hash
of file path + .pf. The prefetch file stores the first and last run
dates, file path, number of times executed, and files loaded within
the first ten seconds of process execution. So, if your malware
filename / path hash shows up as a prefetch file named
"DABEARS.EXE-12F3B52A.pf", then you know the file
executed. Note: on Windows servers, Prefetch is disabled by
default.
Registry
As one would expect, the Windows Registry
contains vast amounts of information on what goes on behind the
scenes in Windows. Since the Registry is so large, the list below is
not comprehensive, but it shows the main Registry keys we examine to
determine file execution:
1. ShimCache
Microsoft created the ShimCache, or
"AppCompatCache" to identify application compatibility
issues. The cache data tracks file path, size, last modified time,
and last "execution" time (depending on OS). If a file is
executed with Windows "createprocess," it is logged in the
ShimCache. While a file’s presence in the ShimCache does not 100%
prove file execution, it does show Windows interacted with the file.
The following keys contain ShimCache data:
"HKLMSYSTEMCurrentControlSetControlSession
ManagerAppCompatibilityAppCompatCache (XP) and
"HKLMSYSTEMCurrentControlSetControlSession
ManagerAppCompatCacheAppCompatCache" (Non-XP). For more
information on the ShimCache, see Andrew Davis’ blog entry here
– or Mandiant’s SANS DFIR conference presentation here.
2. MUICache
When a file is executed via Windows
Explorer, the program shell creates an entry in the MUICache.
There’s a good write up of the process on the Windows
Incident Response blog. Windows uses the MUICache to store
application names as retrieved from the PE Version Information in
its Resource Section. The information is stored in the following
keys:
- "HKCUSoftwareMicrosoftWindowsShellNoRoamMUICache"
(XP, 2000, 2003) and - "HKCUSoftwareClassesLocal
SettingsSoftwareMicrosoftWindowsShellMuiCache" (Vista, 7,
2008).
3. UserAssist
The UserAssist tracks executables and
links opened in Explorer. The UserAssist key tracks last execution
time and number of times a file was run in the registry key:
"HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist".
Values under the UserAssist key, corresponding to the executable
names and file paths, are encrypted with ROT13; as a result, you may
miss evidence within this key if you conduct keyword searches prior
to decoding. There are a number of tools to decrypt the key,
including the RegRipper userassist.pl plugin, found here.
Log Files
There are a few logs you can analyze to
determine file execution. Start with the Windows System Event Log,
since this log records service starts. The event in Figure 1 shows
an Administrator (SID="-500") executed the PSEXECSVC
remote execution service:
Figure 1: Event ID 7035 –
Service start
When a service starts, it usually executes the file
specified in the ImagePath or a loaded service DLL. For example, the
"Netman" service uses the legitimate file
"netman.dll" when it executes. However, if the ServiceDll
in the registry contains a path to a backdoor named
"tabcteng.dll", the "Netman" service would
execute "tabcteng.dll" instead. Be sure to validate the
files in the ImagePath and ServiceDlls for any suspicious service
starts.
If Audit Process Tracking is enabled in the Windows
Event Log audit settings, the Windows Security Event Log is a wealth
of information about processes and can definitively prove file
execution. Figure 2 and Figure 3 show the malicious file and
associated process ID, as well as the parent process ID and username
to aid in further investigation.
Figure 2: XP EventID 592 –
Process creation
Windows Vista+ records a similar process creation
event, but the EventID is 4688.
Figure 3: Vista+ EventID 4688 –
Process creation
Auditing capabilities are more granular with newer
versions of Windows and are integrated with Group Policy starting in
Windows Server 2008 R2 and Windows 7. Advanced audit policy settings
can be found here.
There are too many
vendors to cover in this post, but host-based IPS or AV product logs
may show when a file is running and/or attempting an action on
another file. Figure 4 contains an example event from a McAfee
Access Protection log.
Figure 4: McAfee Access
Protection log event
The Windows Scheduled Task Log may confirm if
the attacker used a scheduled task to execute malware. Scheduled
Tasks are recorded in a log file named "SchedLgU.txt" as
follows:
Figure 5: Event in Scheduled
Task log
In Windows Vista+, the scheduled task executions are also
recorded in the log
"Microsoft-Windows-TaskScheduler/Operational" event log
under Event ID 200 and 201.
Figure 6: Event ID 200 & 201
– Scheduled Task execution
Finally, if an application crashes, the Dr.
Watson log may record a malicious task running.
Figure 7: Running tasks captured
in Dr. Watson Log
File Functionality
Another way to determine if a file
was executed is to look for any output files. When you analyzed the
malicious file, was it configured to create data? For example, if
the malicious file you found is a keylogger and an associated keylog
file is present on the system, the attacker likely executed the
file. If the malware was configured to connect to a particular
domain name, the browser history may have recorded the associated
domain. Table 1 contains an example of two communication mechanisms
captured in browser history from the same backdoor.
Table 1: Malicious communication
in browser history
To determine if a malicious file executed,
analyze the file’s functionality, and look for evidence of the
resulting activity on disk. Malware functionality can also help you
assess an attacker’s motivation,
end goals, and perhaps reveal additional malicious files.
While this post covered the primary sources of evidence we use to
detect file execution, there are many more Registry keys and other
Windows files which provide evidence of malware execution,
especially in Windows Vista and above. Similarly, information found
in system memory can be even more valuable for proving file
execution and may provide specific attacker commands and accessed
resources. So please, if you find a malicious executable on a
running system,
be sure to capture the memory before doing anything
else. You can capture and analyze memory with Mandiant
Redline™.
We will discuss more forensic artifacts in future
posts, but feel free to direct message me on Twitter @marycheese.
