The purpose of this article is to explore the many different forensic artifacts that can be discovered from Windows prefetch files. The first section will briefly cover the prefetch file and the prefetching process. The second section, will discuss the forensic values of the prefetch file, specifically the forensic artifacts the prefetch file contains, and the story that can be revealed by the mere existence or absence of prefetch files. The article will conclude with some examples of how you can use prefetch files to aid in forensic analysis and what to watch out for when using prefetch files to prove or disprove a case.The main purpose of this article is to explain the use of prefetching in forensic analysis, but it is important to have a baseline understanding of the technology to provide a good foundation for how and why prefetch files contain certain artifacts. The prefetching process utilized by Microsoft was created to speed up the Windows operating system and application startup. The prefetching process occurs when the operating system, specifically the Windows Cache Manager, monitors certain elements of data that are extracted from the disk into memory. This monitoring occurs each time the system is started for the first two minutes of the boot process, then sixty seconds after all the Win32 services have completed their startup, and the first ten seconds after an application is executed. The Cache Manager then records these “faults” and works with the Task Scheduler, which after some pre-processing will write the data to files called prefetch files.1 The purpose is for these files and their locations to be readily available and consolidated prior to being demanded. Windows prefetching is the process of the operating system moving data from the hard drive into memory before it is needed. For example, when a user executes notepad.exe, the Cache Manager will look in the prefetch directory to see if a prefetch file exists for that application. If a prefetch file does exist the Cache Manger will notify the NTFS operating system to read the notepad.exe prefetch file, extract the Master File Table (MFT) metadata, and open any directory or file referenced in that prefetch file.
Windows Prefetching Background
Windows prefetching started with Windows 2003 Server and Windows XP. Windows Vista took the prefetch file one step further with the creation of the superfetch file. Superfetch was an enhancement to XP’s prefetching by creating a profile of the applications that show how, when, and how often you use the particular application.
There are three types of prefetch files: boot trace, application, and hosting application. Each prefetch file type has a specific independent purpose. The boot trace prefetch file’s main purpose is to help speed up the operating system when it’s being started or rebooted. The application prefetch file was created with the intent of speeding up the time it took for Windows to load certain applications. These applications include all native Windows applications, such as notepad, cmd.exe, and any third party applications that run on Windows, such as Adobe Reader, Firefox, and Microsoft Word. The last type of prefetch file is the hosting application prefetch file, which records the trace activity of certain programs that are used to spawn system processes. These programs that start other processes include DLLHOST.exe, RUNDLL32.exe, and MMC.exe. Windows needs a way to keep track of the different programs that can start multiple different processes, which is why they are categorized separately as hosting applications.2
Prefetch files are located in the prefetch folder found under C:\Windows\. This location is the same for all current systems that use prefetching technology. The contents of the prefetch directory are different for each of the Windows operating systems. Windows 2003 Server only contains one prefetch file called a Boot Trace prefetch file. Windows XP contains not only prefetch files, but also a file called layout.ini. The layout.ini file is a list of the contents of the prefetch files, specifically the NTFS/MFT log sections that contain a list of files and their logical locations or paths. The entries in the layout.ini file are organized in the order in which they are loaded. The entries in the layout.ini file will then be moved or “reallocated” to a contiguous section of the hard drive, which will result in a faster recall time by the operating system. The process of moving the physical location of the files located in the layout.ini file occurs about every seventy-two hours when the Task Scheduler executes the defragmenter. The focus of the defragmenter is only on the contents of the layout.ini file and not the whole disk drive. Since these files are now physically located contiguously on the drive they will be read much faster.
The naming convention is unique for each of the three types of prefetch files mentioned above: boot trace, application, and hosting application. Since there is only one boot trace prefetch file its name will be static, NTOSBOOT-B00DFAAD. NTOSBOOT is short for NT Operating System Boot, which is used by the Windows operating system when the system is booting up. This prefetch file is always named the same with the trailing hash BAADF00D, which is used to represent uninitialized data. This is the largest of the prefetch files.
The application prefetch file is the most common and most familiar prefetch file that also produces the most forensic value. The naming convention for this prefetch file uses the name of the application that was executed and its extension (i.e. cmd.exe), followed by a thirty-two bit hash or number represented in hexadecimal, with a “.pf” extension. An example is cmd.exe-06264562.pf. The trailing hash values are the results of a calculation that includes the algorithm PI (3.14159) as a seed for randomizing, plus the number 37, in addition to the file’s path where it was executed.3 This is what allows the same file to create two separate prefetch files when executed from two separate locations. It is possible to have two files executed from the same location on two different computer systems with the same full prefetch file name.
The application hosting prefetch file calculates the trailing hash value a little differently than the application prefetch file. As previously referenced, the executed file’s name and extension are used in the first part of the prefetch file. The trailing hash value is calculated using the application’s path of execution and the command line used to start the application. This method was utilized to allow multiple application hosting files, such as DLLHOST.EXE, which are used to spawn many different processes that can coexist in the same prefetch folders under different names.
The prefetch files are considered data files. The construct of the prefetch file consists of two main sections, the file’s metadata, (the top part), and the NTFS/MFT file log, the bottom section of the file. The file’s metadata contains the application or program’s name, timestamps, and the number of times the file was executed. The timestamps that are recorded are the file’s creation time, modification, and last accessed time. These timestamps are recorded in GMT. The number of times the application was executed is incremented by one each time the file is started. If the prefetch file is deleted the run count will start over with the creation of a new prefetch file. This top portion of the file is not legible without a parsing tool. The second section, NTFS/MFT file log is written in ASCII and is legible, but still easier to read if parsed out. These files and directories are trace files that are used by the application when it is loading. This mapping of files will include system files, application specific files, and events that are interpreted by the application that is started. For example, the name of a document that is interpreted by Microsoft Word. The size of this section will vary for each prefetch file. Figure 1 shows the contents of a prefetch file. This is the view of the file when viewing it with Guidance Software’s EnCase4 forensic tool. There are several tools that can be used to parse prefetch files and some of these tools will be discussed in the sections below.
Click for larger image.
Figure 1: Contents of a Prefetch File
In addition to the cleanup or file re-allocation that the Task Scheduler performs on the files located in the layout.ini file, the operating system also performs a cleanup process on the prefetch directory itself. The Windows XP operating system will only retain 127 prefetch files, while Windows 7 will retain 129. After the maximum number is met, no new prefetch files will be created. Sometime after thirty minutes of reaching the maximum number of files in the prefetch folder, the system will purge all but thirty-two of these prefetch files. Testing did not show favoritism over the type of files that were retained versus being purged, but Windows 7 seemed to retain application hosting files, while Windows XP only retained application prefetch files. Repetitive testing also showed that on some occasions, Windows XP retained only 126 files and then other times it retained 129. Both Windows XP and 7 retained the NTOSBOOT prefetch file.
The Forensic Value of Prefetch Files
So what is the forensic value of the prefetch file? If you use Google to search for prefetch files, approximately the first fifty hits are websites telling users that they should delete the prefetch files to help speed up their computer. This information is obviously incorrect since the main purpose of the prefetch file is to speed up the loading of user applications. Without even intending to do so, prefetch files can sometimes answer the vital questions of computer forensic analysis: who, what, when, where, why, and sometimes even how.
The forensic value of the prefetch files will be examined from two different perspectives:
- The contents of the prefetch file
- The creation of the existence of the prefetch file in the prefetch directory
The content of each prefetch file provides rich information about the applications that were executed. There are two main sections of the prefetch file. The top, or first section, of the prefetch file contains the metadata of the file. The metadata includes the file name, file location, associated timestamps (file created, last accessed, and file modified), and the number of times the file was executed. This information will be expanded on in the section below. The second, or bottom, section of the prefetch file includes a ten second snapshot of files that are associated with the executed file when it was first opened. This information will also be expanded on below.
Click for larger image.
Figure 2: Parsed Prefetch file using Prefetch_info.exe
Figure 2 shows a prefetch file after being parsed by the tool Prefetch_info.exe.5 With the use of a parser the data can be easily interpreted. In this example the name of the file that was executed was cmd.exe, which created the prefetch file cmd.exe-087B4001.pf. The associated timestamps shown below are all listed in UTC. Figure 2 also shows the program cmd.exe was executed fifteen times and the location in which the file cmd.exe was executed, \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\CMD.EXE, which equates to the \Windows\System32\ directory.
The forensic value of the contents of this file is immediately obvious. From the file metadata an examiner can identify that cmd.exe was executed, the location, and frequency. These artifacts might answer the “what” and the “where” of an incident. The number of times executed will increment each time the application is run. The timestamp information indicates when the first time the application was executed and when it was last accessed, or executed. This might answer the “when” some activity of interest occurred. Any file that is configured to automatically “autostart” will not register a prefetch file when it is created. If the prefetch file is deleted from the prefetch folder, both the timestamps and the number of times executed will be reset.
The second half of the prefetch file is written in plain text, but it can be challenging to read. Tools such as, BinText6 or Prefetch_info.exe, can organize the content making it easier to read and to identify artifacts of interest.
The value of browsing all the locations for the source of where an application was executed can reveal hidden or obfuscated directory locations. As highlighted below in Figure 3, the prefetch file for excel.exe shows the file one.xls located in a TrueCrypt volume. Since TrueCrypt has the ability to hide directories from view, finding the path listed in a prefetch file can provide a data source that might not otherwise be identified. By just browsing the contents of prefetch files it is possible to identify an obfuscated directory, such as C:\WINDOWS\System32\WiQZC\hidden\hacking\tools\nc.exe. Often, hackers will hide tools in plain sight in unusual directories in the System32 folder. The System32 directory is a folder that contains many programs used by the operating system. Most users do not browse this directory.
Click for larger image.
Figure 3: Identifying Hidden or Obfuscated locations
The full directory path in the prefetch file can also provide any user accounts listed under the Documents and Settings (Windows XP) or Users folder (Vista/Windows 7). This could reveal a temporary account used for malicious activity by showing programs that were executed sometime in the past by a potential unauthorized user. This may answer the “who” question for a forensic exam, or at least narrow the scope. Figure 4 shows file activity from the user account “adnin”. This account may be malicious and try to disguise itself as the legitimate account “admin”. Analyzing the full paths in the prefetch files can show that an application or file was accessed from an external storage device. The external storage device entries will differentiate from those of a hard drive with an entry such as \DEVICE\HARDDISK\DP(1)0-0+D\ instead of just having \DEVICE\HARDDISKVOLUME1\. As long as the external device in question was not subsequently inserted into the computer re-writing the last access time, the last access time in the prefetch file can be used to coordinate with the timestamps in the USBStor registry key. Once identified via matching timestamps, the USBStor registry key entry will contain the serial number of the device in question. This can broaden the scope of forensic analysis to other devices that need to be seized and analyzed. Identifying unaccounted USB storage devices and applications or files accessed on those USB devices might help in answering the “what” and “why” questions.
Click for larger image.
Figure 4: Identifying abnormal accounts
Prefetch files can also reveal whether file “time stomping” might have occurred. When hackers compromise a system and alter the timestamps of an application or tool, they might not be aware of what information is captured in a prefetch file. For instance if the Standard Information Attribute (SIA) and File Name Attribute (FNA) timestamps are modified in the Master File Table (MFT) to impede analysis, the entries in the prefetch files for those applications that were executed will reveal the actual timestamp when the application was first and last executed, completely circumventing the “time stomping” efforts. Just the existence of a prefetch file for the tool used to perform the time stamp manipulation would reveal nefarious activity.
Click here for part 2 of this article.
References
- http://msdn.microsoft.com/en-us/magazine/cc302206.aspx
- Help file from PFDump V2.2 – Enpack created by Dominik Weber
- http://42llc.net/index.php?option=com_myblog&Itemid=39&limitstart=10 - by Yogesh Khatri
- www.guidancesoftware.com
- http://cfed-ttf.blogspot.com/2008/02/prefetch-information.html by Mark McKinnon
- www.foundstone.com
Part 2 of this article will demonstrate what the existence of the prefetch file itself can tell you. Examining the contents of the prefetch directory can provide a storyline of activity on a computer system because the prefetch file captures the activity of applications that were first or subsequently executed. By using a tool, such as Guidance Software’s EnCase12 you can extract the prefetch files and just view the file’s creation or last access time stamp. First and foremost, the existence of the prefetch file shows that a certain application not only existed on the computer, but has at one time been executed. By sorting the entries by file creation or last access time it is possible to see what applications were executed on the system and to see what activity might have occurred on the system. or WinPrefetch View,
For instance, the entries in Figure 1 show that on April 9, 2010, two separate cmd.exe programs were executed. After the second cmd.exe (cmd.exe-5D0264ff.pf) was executed the application CONSENT.exe was executed (as shown by consent.exe-65f6206D.pf), which indicates the computer system is a Vista or Windows 7 system. The consent.exe program is the popup window that is presented to the user when requesting a program that requires administrator access, such as the MMC.exe application, which was executed ten seconds after CONSENT.exe. The presence of the prefetch files indicates that on April 9, 2010, at 1:16 PM two instances of CMD.exe were executed from different locations, followed by the execution of the program MMC.exe. This event spawned the execution of CONSENT.exe (this file will be executed first before MMC.exe even though chronologically MMC.exe was executed first). The MMC program is the Microsoft Management Console program and used to manage user accounts, Windows Events logs, disk management, and other management programs. Figure 1 also shows that the application PSEXEC.exe was executed, which is a command-line tool that allows a user to execute commands remotely on a computer system.
Click for larger image.
Figure 1: Analyzing the Prefetch Folder
So what can prefetch files tell you? The existence of two prefetch files with the same application prefix and different trailing hashes would be indicative of two files (i.e. I) that were executed from two different locations. The eight-character hash that exists in the prefetch file’s name is based on the location from which the application was executed. In this example, a rogue CMD.exe was executed from a different location than Windows\System32. This scenario can also detect a possible malware infection in which the malware was executed in one location, say the desktop or temp directory, then removed itself from the original location and placed a copy in Windows\System32, then re-executed itself once it changed locations. This would cause the creation of two instances of the same prefetch file prefix with two different eight-character trailing hashes. If during a forensic exam there are two prefetch files located with different trailing hashes, and the examiner needs to determine the location the file was executed from, the examiner can reverse engineer the location through trial and error. There is no magic algorithm that will allow you to plug in a formula and reproduce the path from which the application was executed. However, since the eight-character hash was created from an algorithm using the executed file’s location you can take any file, rename it to the prefix of the prefetch file (i.e. calc.exe), and place it in different suspected directories. Then execute the file and monitor the prefetch directory until the trailing hash file matches. This process is very time consuming so it is wise to focus on suspect directories.
The number and type of prefetch files in the prefetch directory can also reveal information about the individual who is using the computer system. The operating system will reduce the number of prefetch files once a certain number is met. The number of prefetch files can reveal a few different items.
- The system is relatively new and only a few different applications have been executed on the system. This situation is typical of a normal home user. They may only use about ten to fifteen programs over time.
- The system has been used extensively, and either over a short or long period of time the user(s) have executed many different programs. The timestamps and number of times the application was executed will provide background information on the duration and frequency these applications have been used.
- The type of applications that have been executed can also help in profiling the user’s technical capabilities. For instance, by identifying the type of programs the individual executes, the analyst can determine if the user is highly technical (for example if there are prefetch files for programming tools such as Python and Perl or technical programs such as IdaPro and VMWare.) The presence of hacker tools, such as nmap, Metasploit, or netcat could easily reveal the nature and intent of a computer user. On the other hand if the user is only using Internet web browsers, mail clients, and social networking software (i.e. Yahoo, Microsoft’s Instant Messenger) then you get a better profile of the type of computer user.
Here are some more practical forensic examples of how the prefetch file can be used to aid a forensic exam:
- A simple scenario is where network logs show that system PC-A was scanning system PC-B with a tool such as Nessus. When the local administrators asked the user of PC-A about the activity he denied the allegations and even said that they could search his system for the tool Nessus if they wanted to. The seemingly savvy user had not only removed the Nessus tool after its use but also used a tool such as BCWipe to overwrite all unallocated space. What the user of system PC-A didn’t realize is that when he executed Nessus a prefetch file was created capturing the first time and last time the file was executed, the number of times it was run, and the location from which it was executed. These timestamps should correlate with the network logs and any activity recorded on system PC-B. The other valuable artifact is the prefetch file for the wiping tool BCWipe. The same type of incriminating information is contained in the BCWipe prefetch file.
- From a forensic standpoint a prefetch file can be used to show that an employee who denied obtaining a salary spreadsheet actually did open a Microsoft Excel file named ABCorp_2010_Salaries.xls on their computer, which was located on an external thumb drive. For this to occur the employee would have to have opened the file by double clicking on the spreadsheet to open the file.
Prefetch_info.exe is a Windows command line tool that neatly parses out both the file’s metadata (time stamps), and the NTFS/MFT file log. Prefetch_info.exe can only be run on one prefetch file at a time. This tool can quickly return results on a prefetch file of interest.
The second tool by Mark McKinnon, Prefetch_parse_gui.exe is a graphical based tool that analyzes a whole directory of prefetch files. NirSoft’s WinPrefetch View is modularized with the top section listing each prefetch file along with all its associated metadata. The bottom section displays the NTFS/MFT log data for the prefetch entry that is selected in the top section. Figure 2 shows the interface for WinPrefetch View. By default this tool will read the prefetch files of the local computer system. The Advanced Options entry under the Options tab allows you to select another location where prefetch files might have been extracted out of an image.
The metadata shown below can be sorted by columns and any results of interest can be exported to HTML reports.
Click for larger image.
Figure 2: WinPrefetch View
The most extensive analytical prefetch tool seen so far is Dominik Weber’s PFDump EnScript. The EnScript will identify all the prefetch files on the loaded hard drive and identify if the prefetch file is a hosting application prefetch file or a regular application prefetch file. If no entries are selected all of the files with the “.pf” extension will be processed. There are two options on the main page, Toggle MFT processing for selected files, and Toggle hash verification for selected files. The Toggle MFT processing for selected files allows the option to extract and process any Master File Table record information that is located within the prefetch file.
EnCase’s Console will provide a status of the EnScript’s operation, while the prefetch artifacts for the selected files are placed in EnCase’s Bookmark section. Figure 3 shows the options available when analyzing identified application hosting prefetch files, and the output of an identified command line used to start compmgmt.msc. When working with application hosting files, by default PFDump will try many different standard command line options that the hosting application might have used to execute the process. Identifying how a process of interest was started and the options used might prove useful during forensic analysis. There is also an entry to insert a suspected command line option that might have been used to start a process. This can be used to verify a command line option that might have been discovered in unallocated space.
Figure 3: PFDump EnScript Hosting Application Entries and output
If the prefetch files have been purposefully or systematically deleted through routine maintenance, there is still a chance to recover prefetch files of interest. Common sense in computer forensics states that any file that has been deleted can be recovered as long as the file has not been overwritten. The same rule holds true for prefetch files. A common method to search for and extract files is to search for a file’s header. Since every file has a distinguished file header, we can search through unallocated space looking for the specified prefetch file header. That header in ASCII is “….SCCA”. In hexadecimal, the prefetch file is represented as “11 00 00 00 53 43 43 41”. Once the file has been identified it can be carved out and analyzed with one of the aforementioned tools. Since prefetch files do not have file footers it is okay if extra data is carved out when extracting a potential prefetch file. Any excess data will be easily recognized and discarded.
When analyzing prefetch files there are a few items to note: When certain applications are executed and are in an “open state” the prefetch file will not be created until the application is closed. For instance, if the application netcat was executed for the first time on June 14th, at 13:00:00, but the file was not shut down until June 15th, at 15:00:00, the prefetch file will not be created until the netcat application is closed, twenty-six hours later than when it was first executed. This delay in file creation will throw off timeline analysis. Programs that are located in a user’s Startup directory will not create a prefetch file.
When performing an Internet search for prefetch files, many of the initial findings are telling users to remove the prefetch files to speed up their computers. This may not be a sign of anti-forensics. The lack of prefetch files may be due to the system’s registry key settings, “Enable Prefetcher,” which might have been modified to disable prefetching. Below is the registry key that controls what actions the operating system will take with regard to prefetching. By default Windows XP, Vista, and Windows 7 have a value of “3,” which has both application and boot prefetching enabled. On Windows 2003 systems the default value is “2,” which is why there is no application prefetching.
- HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\Prefetch paramters
- Value: 0 “zero” = Prefetching is disabled
- Value: 1 = Application Prefetching is enabled
- Value: 2 = Boot Prefetching is enabled
- Value: 3 = Both application & boot prefetching is enabled5
This article reveals the many different forensic artifacts that can be recovered from prefetch file analysis while conducting forensic analysis. Whether prefetch file analysis can help in an investigation depends on the type of forensic investigation that is being conducted.
References
1. www.guidancesoftware.com
2. www.nirsoft.net/utils/win_pretech_view.html
3. http://cfed-ttf.blogspot.com/2008/02/prefetch-information.html
4. www.support.guidancesoftware.com/forum/downloads.php?do=file&id=427
5. http://en.wikipedia.org/wiki/Prefetcher
Mark Wade is a Digital Forensic Analyst with Harris Corporation (Crucial Security Programs), performing digital forensics for a Federal Law Enforcement agency as a government contractor. Mark has been engaged in computer/network security for the past twelve years with specific focus in penetration testing, IDS and firewall management, incident response, malware analysis, and most recently spent the last three years conducting computer forensics. E-mail: mwade05@harris.com
轉自 http://www.dfinews.com/print/5572
發表文章
