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.
But waits, 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.
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".
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.
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.
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.
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.
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.
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(TM) 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!
Chad Tilbury, GCFA, serves as a Technical Director for CrowdStrike and has spent over fifteen years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He is a Senior Instructor and co-author of FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response at the SANS Institute. Find him on Twitter @chadtilbury.