Vista Recycle Bin
Yet another aspect of the Windows operating system that changed with the advent of Vista is the underlying architecture of how the Recycle Bin is implemented. Although this is transparent to the user, the change provides a very useful resource to the forensic analyst, as Mitchell Machor addressed in his paper, "The Forensic Analysis of the Microsoft Windows Vista Recycle Bin" (www.forensicfocus.com/downloads/forensic-analysis-vista-recycle-bin.pdf). As with previous versions of Windows, files deleted by a user are still associated with the user’s SID but are now found in the C:\$Recycle.Bin directory. Where Vista continues to handle deleted files differently is that a deleted file is renamed to "$R", followed by a series of six random characters, and then the original file extension. Then, a second file of the same name, with "$I" instead of "$R", is created that contains information similar to what is found in the INFO2 file. However, this "index" file within the Vista Recycle Bin contains only the original filename, the file’s original size, and the date and time the file was deleted.
XP System Restore Points
We discussed the Registry files maintained in Windows XP System Restore Points in next topic. In this topic, we will address the other log files maintained within those restore points.
Rp.log Files
Rp.log is the restore point log file located within the restore point (RPxx) directory. This restore point log contains a value indicating the type of the restore point, a descriptive name for the restore point creation event (i.e., application or device driver installation, application uninstall, or the like), and the 64-bit FILETIME object indicating when the restore point was created. The restore point type is a 4-byte (DWORD) value starting at the fourth byte of the file. The description of the restore point is a null-terminated Unicode string that starts at offset 16 (0×10) within the file, and the creation date/time is the 8-byte (QWORD) value located at offset 528 (0×210) within the file.
You can run the Perl script sr.pl on a live system to collect information about restore points. The script implements the SystemRestore Windows Management Instrumentation (WMI) class to access the RestorePointType, Description, and CreationTime values for each restore point and display them to the user.
The sysrestore.pl Perl script (located on the accompanying DVD) is a ProScript that you can use with ProDiscover to retrieve information from the rp.log files located in the restore point directories of an image of a Windows XP system (that is open in ProDiscover). The script opens the rp.log file within each directory and retrieves the description of the restore point and the date that the restore point was created.
The description for the restore point can be useful to the investigator, particularly if he’s looking for information regarding the installation or removal of an application. System restore points will be created when applications and unsigned drivers are installed, when a Windows AutoUpdate installation is performed, and when a restore operation is performed. Restore points can also be created manually.
When a restore point is created, a description of the event that caused the restore point creation is written to the rp.log file. Many times, you’ll see the description System Checkpoint, which is the restore point that is created by Windows XP every 24 hours (default setting). The description Software Distribution Service refers to Windows Updates being installed. I’ve also seen descriptions such as Installed QuickTime, Removed ProDiscover 4.8a, and Installed Windows Media Player 11 on systems. The description might tell the investigator the date that a particular application was installed or removed.
The creation date of the restore point could also be useful to the investigator in other ways. Not only does it add information to the timeline of activity on the system, but the investigator can also use the creation date to determine whether changes were made to the system time. If successive restore points (successive based on the number of the restore point, such as RP80, RP81, RP82, etc.) have non-sequential creation dates, it could indicate that someone modified the system time.
Change.log.x Files
Once the restore point has been created, key system and application files continue to be monitored so that the system can be restored to a particular state. File changes are recorded, and if necessary, the entire file is preserved so that the system can be restored. These changes are recorded in the change.log files, which are located in the restore point directories. As changes to the monitored files are detected by the restore point file system driver, the original filename is entered into the change.log file along with a sequence number and other necessary information, such as the type of change that occurred (file deletion, change of file attributes, or change of content). If the monitored file needs to be preserved (as with a file deletion operation), the file is copied to the restore point directory and renamed to the format Axxxxxxx.ext, where x represents a sequence number and .ext is the file’s original extension.
When the system is restarted, the first change.log file is appended with a sequence number (the name of the change.log file is changed to change.log.1) and a new change.log file is created. However, you won’t find a file named change.log in the restore point directories; rather, you’ll find several files named change.log.x, where x is the number of the change.log file.
Each change.log.x file consists of a number of change log records. I was able to locate a Web site that contained detailed information regarding the binary format of these records (to include the 0xABCDEF12 "magic number" for identifying change log records in unallocated space). Using the information on this site, I was able to create a Perl script that parses and interprets the contents of the change.log.x files. The lscl.pl (for LiSt Change Log) Perl script is located on the accompanying DVD.
Tip::
Fifo.log is another file maintained by (and located in the root of) the System Restore. As the System Restore reaches 90 percent of its capacity, it will delete restore points on a first-in, first-out (FIFO) basis, reducing the capacity to 75 percent of the maximum size (either the default or a user-defined value). The fifo.log file maintains a list of restore points that were "fifoed" or deleted from a monitored drive, as well as the date and time they were deleted. Restore points will also be "fifoed" when they are 90 days old.
Vista Volume Shadow Copy Service
Windows Vista uses a function similar to XP’s System Restore Points to maintain copies of important files; the function is called Volume Shadow Copy (http://technet.microsoft.com/en-us/library/cc785914.aspx). Like XP restore points, the volume shadow copies are maintained in the System Volume Information directory and are enabled by default on Vista. Typically, volume shadow copies are created at system boot, but they can also be created at other times. As with the XP restore points, Vista volume shadow copies can contain a wealth of information valuable to forensic analysts. Unlike XP restore points, however, volume shadow copies are apparently accessible only on a live Vista system, via vssadmin. exe. For information on booting an acquired image from a Windows system, please see the "Alternative Methods of Analysis" section of this topic.
Tip::
Christopher Hargreaves and Howard Chivers authored a paper titled "Potential Impacts of Windows Vista on Digital Investigations" (www.forensicfocus.com/downloads/potential-impact-windows-vista.pdf), an expanded version of which is available in the Journal of Digital Investigation. In the article, they describe a similar method of obtaining access to the information stored in volume shadow copies as described in this section. In addition to the method described in this section, ShadowExplorer (www.shadowexplorer.com/) can also be used to access information as well as files and folders within volume shadow copies on live Vista systems (and on Windows 2003, if the capability is enabled).
Using vssadmin.exe on a live Vista system, you can use the following command to list the available volume shadow copies:
Once the available volume shadow copies have been listed, you can create a link to any of them using mklink.exe as follows (where n is a number of an identified volume shadow copy) to create a symbolic link to the volume shadow copy:
At this point, the volume shadow copy files are accessible via C:\Voln (e.g., C:\Vol3 would be a symbolic link to HarddiskVolumeShadowCopy3). In addition to this process, Rob Lee mentioned in the SANS Forensic blog (http://sansforensics.wordpress.com/2008/10/10/shadow-forensics/) that dd.exe can be used to acquire an image of a specific shadow. Rob states in his blog post that the following command, run from a USB thumb drive, can be used to acquire an image of a volume shadow copy:
You can find dd.exe at http://gmgsystemsinc.com/fau/.
Given the fact that you apparently can access volume shadow copies only on a live Vista system, you must be careful to ensure that responders are aware of this fact so that the appropriate steps can be taken to preserve data. This may include acquiring images of volume shadow copies from live systems, or it may include obtaining a username and password to access an acquired image that has been booted to access the volume shadow copies.
Prefetch Files
Beginning with Windows XP, Microsoft operating systems began using something called "prefetching" to improve system performance. XP, Windows 2003, and Vista perform boot prefetching by default, and XP and Vista also perform application prefetching by default.
For boot prefetching, the Cache Manager monitors hard page faults (require that data be read from disk) and soft page faults (require that data in memory be added to a process’s working set) during whichever occurs first—the first two minutes of the boot process, the first minute after all Windows services have started, or the first 30 seconds following the start of the user’s shell. The fault data is processed along with references to files and directories that are accessed, which ultimately allows all of this data to be accessed from a single file rather than requiring that the data be retrieved from different files and directories scattered across the hard drive. This, in turn, decreases the amount of time required to boot the system.
During application prefetching, the Cache Manager monitors the first 10 seconds after a process is started. Once this data is processed, it is written to a .pf file in the Windows\ Prefetch directory. This file’s name is created using the application’s name followed by a dash and then by a hexadecimal representation of the hash of the path to the application. Therefore, the same program run from different locations will create different .pf files. For example, on a Windows XP system, two different .pf files will be created when Notepad is run from the C:\Windows directory and from the C:\Windows\system32 directory. (For some reason, Windows XP has a copy of Notepad in each directory.)
Prefetching is controlled by the following Registry key:
Within this key is a value named EnablePrefetcher. The data associated with this value will tell you which form of prefetching the system uses:
■ 0: Prefetching is disabled.
■ 1: Application prefetching is enabled.
■ 2: Boot prefetching is enabled.
■ 3: Both application and boot prefetching are enabled.
On Windows XP and Vista, the default value for EnablePrefetcher is 3; it is 2 on Windows 2003. One of the interesting things about application prefetching is that Windows XP has a limit of 128 .pf files.
Some information in the .pf files in the Prefetch directory can be extremely useful to an investigator. At offset 144 within the file is a DWORD (4-byte) value that corresponds to the number of times the application has been launched. At offset 120 within the file is a 64-bit value that is a FILETIME object that corresponds to the last time the application was run. This value is stored in UTC format, which is analogous to GMT time. The prefetch.pl Perl script on the accompanying DVD is a ProScript that will parse the Prefetch directory for .pf files and then extract the run count and last run times from the .pf files. The pref.pl Perl script (a "compiled" executable version of the script is also available on the accompanying DVD) will run through the Prefetch directory on a live system and retrieve the MAC times (more on MAC times in the next section) and the last run time from .pf files, sending its output to the console in a comma-delimited format (suitable for opening in an Excel spreadsheet).
The path to the application that was run is saved in a Unicode string within the .pf file (along with a range of other strings), as Figure 5.8 illustrates.
Figure 5.8 Example of a File Path in a .pf File
You can correlate the various information from within a .pf file with information from the Registry or the Event Log to determine who was logged on to the system, who was running which applications, and so on. One of the benefits of this correlation is that if the user installs an application, runs it, and then deletes the application, traces of that application could be left in the Prefetch directory. When I’ve spoken to law enforcement officers about issues such as steganography applications used in online crime, all of them have said they don’t usually look for steganography unless something indicates that such an application was used. The existence of a .pf file with the name of a particular application can be that indication.
Vista SuperFetch
Windows Vista incorporates a version of prefetching called SuperFetch, and creates files similar in nature to Windows XP application prefetching. However, offsets within the file are slightly different for various metadata than those for XP application prefetch files. The vista_ pref.pl Perl script (and associated "compiled" executables, both available on the media accompanying this topic) will extract the last run date from a Vista prefetch file.
Shortcut Files
Shortcut files can prove useful during an investigation. Think of the way shortcuts (files with .lnk extensions) are created and accessed in normal day-to-day use. A user accesses a document on her hard drive, a removable storage device, or a network share, and a shortcut is created on the system in the Recent folder (the Recent folder is a hidden folder within the user’s profile directory). Shortcuts can provide information about files (or network shares) that the user has accessed as well as devices that the user might have had attached to her system at one point. Several commercial forensic analysis tools, such as AccessData’s Forensic Toolkit (FTK) and EnCase from Guidance Software, provide the ability to parse the contents of the .lnk files to reveal information embedded within the file. Also, the Windows File Analyzer (WFA) from MiTeC is a freeware tool that will parse information from within an .lnk file. Not long ago, Jesse Hager published a white paper, "The Windows Shortcut File Format," in which he documented the offsets and sizes of the various components of a shortcut file. Nathan Weilbacher wrote an article (www.forensicfocus.com/link-file-evidentiary-value) for the ForensicFocus.com site that referenced Jesse’s paper and detailed the evidentiary value of Windows shortcut files.
The Perl script lslnk.pl (found on the accompanying DVD) implements much of Jesse’s white paper and allows an investigator to view the internals of Windows shortcut files, displaying information such as the MAC times of the target file, various flag and attribute settings, and local volume information, an example of which is shown here:
If the target file is on a network share, lslnk.pl will extract the path to the share, as illustrated here:
The lslnk.pl script opens the shortcut file in binary mode, parsing the contents without using the Windows API. You can use the Perl script on any system that supports Perl. Jake Cunningham wrote a similar Perl script that is named lnk-parse.pl and is available on his JAFAT Web site (http://jafat.sourceforge.net/files.html).
File Metadata
The term metadata refers to data about data. The most commonly known metadata about files on Windows systems are the file MAC times; in this case, MAC stands for modified, accessed, and created. The MAC times are time stamps that refer to the time at which the file was last modified in some way (data was either added to the file or removed from it), last accessed (when the file was last opened), and originally created. How the operating system manages these times depends on the file system used. For example, on the FAT file system, times are stored based on the local time of the computer system, whereas the NTFS file system stores MAC times in UTC format, which is analogous to GMT. When applications such as Windows Explorer display the MAC times, time zone and daylight saving time settings need to be taken into account. Further, MAC time resolution for the FAT file system is 10 milliseconds for the creation time, two seconds for the modification time, and one day for the last access time (the date, really, which isn’t terribly granular). For the NTFS file system, the last access time has a resolution of one hour.
Warning::
On Windows systems, the NtfsDisableLastAccessUpdate Registry value (located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem key) will allow you to disable the updating of last access times within the operating system (a DWORD value of 1 disables the functionality). Although this is a recommended setting for high-volume file servers (to optimize performance and increase overall response time), it can make things difficult for a forensic analyst, particularly when determining file access times is an important part of the case. You can set this value via the fsutil command on Windows XP and 2003, and it comes set (i.e., updating of last access times is disabled) by default on Vista. This means forensic analysts will need to develop additional analysis techniques and methodologies and rely on other sources of evidence.
Another aspect of file and directory MAC times that an investigator might be interested in is the way the time stamps are displayed (http://support.microsoft.com/?kbid=299648) based on various move and copy actions. For the FAT16 file system:
■ Copy myfile.txt from C:\ to C:\subdir Myfile.txt keeps the same modification date, but the creation date is updated to the current date and time.
■ Move myfile.txt from C:\ to C:\subdir Myfile.txt keeps the same modification and creation dates.
■ Copy myfile.txt from a FAT16 partition to an NTFS partition Myfile.txt keeps the same modification date, but the creation date is updated to the current date and time.
■ Move myfile.txt from a FAT16 partition to an NTFS partition Myfile.txt keeps the same modification and creation dates.
For the NTFS file system:
■ Copy myfile.txt from C:\ to C:\subdir Myfile.txt keeps the same modification date, but the creation date is updated to the current date and time.
■ Move myfile.txt from C:\ to C:\subdir Myfile.txt keeps the same modification and creation dates.
In a nutshell, regardless of the file system in use, if the file is copied, the creation date for the file is updated to the current date and time; if the file is moved, the creation date stays the same. The modification date is updated when a change is made to the file.
Notes from the Underground…
Modifying MAC Times
As useful as file MAC times can be to an investigation, you need to keep in mind that there are people out there who might be actively attempting to hide data on a system by modifying the MAC times of the files. I have demonstrated the use of tools that allow the user to modify the MAC times on a file at conferences, using Perl scripts to access the necessary (and thoroughly documented) Windows APIs to first create a file, then change the creation date to six years in the future and make the modification date two years in the past. That sort of thing can throw off an investigation, and when you see something like that, how are you to trust any MAC times?
But that’s not all. The Metasploit Project has an Anti-Forensics Project (www. metasploit.org/research/projects/antiforensics/) that includes a tool called timestomp. exe that allows an attacker to modify not only the MAC times of a file but also the "entry modified" date/time stamp, which indicates when file attributes were modified. Hopefully by the time you’ve reached this point in the topic, however, you have come to realize that antiforensic tools are intended to subvert the analyst, rather than a specific forensic analysis application.
The rest of this section addresses metadata embedded within various file formats.
