- Cold Case Chronicles
- Crime Lab
- Crime Scene
- Digital Forensic Insider
- Digital Forensics
- Evidence Collection
- Forensic Anthropology
- Forensic Pathology: Expert Witness
- Impression Evidence
- Medical Examiner
- Mobile Forensics
- Most Wanted
- The DNA Collection
- Who Says
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.
- 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
- http://cfed-ttf.blogspot.com/2008/02/prefetch-information.html by Mark McKinnon
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: firstname.lastname@example.org