Prefetch Analysis, Revisited
By now, most analysts are familiar with Prefetch files and how they can be useful to an examination. I think most of us tend to take a quick look over the names of the Prefetch files during analysis, just to see if anything jumps out at us (I've seen Prefetch files for "0.exe", and I'd call that odd and worth digging into). As described on the ForensicsWiki, Prefetch files also have a good bit of embedded metadata, and can be very useful during analysis. For example, you may look at the listing of files and something unusual may immediately jump out at you.
Also, if you include Prefetch file metadata in a timeline of an XP system, you should see a file access time for the executable "near" to when a Prefetch file for that executable is created or updated. If that's not the case, you may have an issue of time manipulation, or the original executable may have been deleted.
Thankfully, Prefetch files are an artifact of an EXE file engaging with its eco-system and not a direct artifact of the EXE. As such, if the EXE is deleted, the Prefetch file persists. Very cool.
Prefetch files also contain a number of strings, which are file names and full paths that point to modules used or accessed by the executable, and even some other files accessed by the executable. This stuff can be very interesting. For example, if you see two Prefetch files for Notepad, remember that the hash in the .pf file name is generated using the path to the file, as well as command line options. As most Windows systems have two copies of Notepad (one in the Windows dir, the other in the Windows\system32 dir), you're very likely to see two Prefetch files for that executable...and you will likely also find the full path to the executable right there within the embedded strings.
So, I got to thinking...how can we use this information? How about we do a little data reduction? Rather than running through all 128 or so .pf files manually, one at a time, we can let some code do that for us, and then display the paths to all of the executables. We might even want to add some checking, say grep() the file path for something like "temp", so we can see executables that were launched from a path that included "Temp" or even "Temporary Internet Files".
Another idea is to do a little Least Frequency of Occurrence analysis, and run through all of the .pf files and list those module paths that only appear once in all of the files. This is a great bit of work that can be easily automated, leaving us to just look over the output. You can even expand your analysis to those modules that occur twice, or even three times.
The more I think of this, the more I'm thinking that this is something that would go really well in a forensic scanner.
Addendum, 3/11: Tonight I completed transitioning the pref.pl Perl script to a module, so that the functionality can be encapsulated in other tools.