It wasn’t that long ago that every report I read containing Windows prefetch artifacts included only the basics: executable name, first and last time executed (now eight timestamps in Win8), and number of executions. There is much more information stored in prefetch files, but until recently there were few tools to easily parse and provide it to the examiner. Mark McKinnon wrote one of the first prefetch parsers to include full path names for additional files accessed within the first ten seconds of application launch. TZWorks’ pf tool now also provides this information. Depending on case type, this information could be overkill, but imagine a prefetch file tracking execution of a malicious binary while also identifying a related malicious DLL loaded, or the location of keylog output. A lot of files are accessed within the first ten seconds of execution, so you may find evidence of specific documents opened in the prefetch file for the Microsoft WinWord application or in the case of Figure 1, files accessed within zip archives via a 7zip prefetch file.
Figure 1: Excerpt showing file access recorded inside a prefetch file (output from TZWorks pf)
But wait, there’s more! In fact, if you take a quick look at the prefetch documentation in Joachim Metz’s libyal project, you will find data structures storing a wealth of information. If you are a visual learner, see Jared Atkinon’s superb Windows 8 Prefetch Walkthrough poster. I intend to demonstrate one of the lesser used structures, the Volume Information Entry, in this post. Windows operating systems have expanded the data structure over the years, but even the simplest version (Figure 2) includes extremely useful volume information like device path, creation time, and serial number.
Figure 2: Prefetch Volume Information Entry from the libyal documentation project
Windows Volume Device Paths
If you have been doing Windows forensics long enough, you have inevitably run into artifacts referencing “\Device\HarddiskVolume” in the path. I see this most often during event log review. As an example, Figure 3 shows a Windows Filtering Platform event in the security log referencing a device “harddiskvolume3”.
Figure 3: Security event log entry referencing a MS-DOS device name
What does “HarddiskVolume3” mean? The nomenclature belongs to the MS-DOS device naming scheme, and can be referenced via the Windows API QueryDosDevice function. Correlating a volume device path to a specific device can be a great exercise in frustration. Even on a live system, there is no built-in command to tie everything together. Diskpart perhaps is the most useful, but does not provide volume serial number or GUID information. Mountvol and the WMI Win32_Volume class can map drive letters to GUIDs, but do not include device path information (try: Get-Wmiobject win32_volume). The built-in Filter Manager Control Program (try: fltmc volumes) maps drive letters to device path. To get all the pieces together, you will have to write some code. Matt Graeber created the PowerShell script Get-DevicePath that maps device path to drive letter, and it could be modified to also include volume GUIDs for a reasonably complete solution. NirSoft’s DriveLetterView does the most complete job of any tool I have tested, but it must be run on a live system and does not scale for remote use. As we will see in the next section, finding a way to record some or all of this data during live response is a worthy effort as it can save significant time during subsequent analysis.
Figure 4: Diskpart output from a live system
Figure 5: Example output from Nirsoft DriveLetterView
Mapping Volume Device Paths from Disk Artifacts
If you are stuck investigating a volume device path from only artifacts on disk (i.e. deadbox analysis), you are at a disadvantage. Luckily event logs can offer a little more information. If the mounted volume was formatted as NTFS, you may find an event ID 98 entry in the System log providing the mapping between device name and mountpoint.
Figure 6: System event log ID 98 entry (NTFS volume added)
If you are incredibly lucky and chkdsk was run on the volume, the chkdsk event recorded in the Application log correlates the volume device name and volume label.
Figure 7: Application event log ID 26228 (Chkdsk executed on a volume)
Interestingly, the Volume Information Entry present in prefetch files holds a key piece of the puzzle. If any application was executed from the volume of interest (\Device\HarddiskVolume3 in the previous example), the resulting prefetch file will record the device path, serial number and creation time for that volume. Device information will also be recorded for any volumes where files were accessed by an application within ten seconds of application execution. This is a big win since most applications are executed only from the system drive, but arbitrary files can be opened from many different volumes. Figure 8 illustrates relevant data present in a Microsoft Word prefetch file. Note that data on four different volumes was stored within this prefetch file. Taking things a step further, collecting this data from all 1024 prefetch files on a Windows 8 system would provide an excellent historical reference of volumes attached to a system. However, one caveat is that prefetch post-Windows XP does not appear to be reliably recording volume device path information for objects accessed on devices with the removable media bit set, such as many thumbdrives. However, the good news is that USB hard drives, eSATA connections, mounted VHDs, and many other devices do not fall into this category.
Figure 8: Mapped devices present in a Winword.exe prefetch file (output from TZWorks pf)
Putting it All Together
Our work is not finished once information is collected from prefetch. At this point we have mapped a volume device name to a volume serial number (via prefetch) and may have an associated drive letter (via event logs). To gather more information about the volume of interest, a search for LNK files and jumplist entries should be conducted. These two artifacts record myriad data about files and folders opened by a user, including the volume serial number from where an object was opened. By matching this serial number to what was found during prefetch (and event log analysis), we can resolve additional information like the volume label, file timestamps, and full path information of files and folders present on that device.
Figure 9: LNK data mapping volume serial number to label and mount point (output from TZWorks lp)
While certainly not a painless process, with some good investigative work we can detemine the following:
Volume Device Name: event logs, prefetch
Volume Serial Number: prefetch, LNK/jumplist
Volume Creation Time: prefetch
Volume Name: event logs, LNK/jumplist
Volume Mount Point: event logs, LNK/jumplist
Times of Use: prefetch, LNK/jumplist
Files and Folders Present: LNK/jumplist
I hope this post will inspire examiners to look beyond what their tools are currently showing them. In classes I teach, students are always surprised at the need for so many different tools to complete a forensic investigation. Someday Forensicator Pro
will parse every piece of data from every artifact perfectly, but until then it is imperative that examiners understand underlying data structures to know what they are missing. Have fun!