Thursday, March 15, 2012

Prefetch Analysis, Revisited...Again...

I recently blogged on Prefetch Analysis, Revisited, and was poking around one of Corey's blog posts regarding exploit artifacts, this one associated with Java.  Corey was kind enough to send me the  Prefetch file that was created as part of his testing, and I ran it against the Perl script that I'd written.  It pulled out some pretty interesting things, and with Corey's permission, I've pulled out some of the more interesting strings to share.  Where the paths are really long and they have to wrap, I've added a space between the lines to cut down on confusion and make them a bit more readable.

First, we know from where Java was run:


There's also another EXE listed in the output:


That's interesting.  Maybe an interesting analysis technique to add via the tools is to parse the module paths, and find not just the path to the EXE that was created, but also any other EXE paths listed, and flag on those with more than one.  Flagging on those Prefetch files that include more than one EXE path may not find anything in most cases, but hey, it's automated and documented, only takes a quick second to run, and the time that it does find something will be a real winner.

Okay, now back to our regularly scheduled program, already in progress...

Then I found these paths:


I wasn't too interested in those (I had no idea what they are) until I found this one later on:


I still have no idea what any of this is...remember, I only have the single Prefetch file...but this might be something worth investigating.

Here's a path to one of the logs that Corey mentioned in his post:


We see something similar later in the output, for the Test user:


Here's the path to another log file that Corey mentioned in his blog:


And here's the same thing, but for the Test user account (again):


Remember that Corey was using MetaSploit, per his blog post:




All in all, some pretty interesting data.  Some of the new additions to the tools will make some of the automated collection and correlation of this information automated, but the analysis will still be up to...well, the analyst.

I'd like to thank Corey for not only doing the "heavy lifting" of compromising a system with MetaSploit, but also providing the Prefetch file, from which the script I wrote was able to extract the above module paths.  


Corey Harrell said...

Awesome information and thank you for revisiting Prefetch files. Between your last two posts I learned alot about data inside a Prefetch file that I wasn't looking at.

I still have all my images from exploit artifacts so I plan on updating my exploit posts to reflect this new information. I even have a few images from purposely infected systems and am curious about the prefetch files for malware. Again, thanks for the info and asking for the Prefetch file. Without you asking for it I may not have went back and looked at them.

Anonymous said...

You need to check out pfdump enscript for Encase. it decodes entire contents of prefetch to include all open file handles within the first 10 seconds. Very useful -Diocyde

H. Carvey said...


WHY do I need to check out the EnScript? I don't use EnCase, and as you can clearly see, the script that used does the same thing...and more. For example, consider my previous post on the subject...with this script, I can do all sorts of analysis, including LFO analysis of the loaded modules.

Given this, why would I need to check out the EnScript?


H. Carvey said...


It's all about teamwork and sharing, my friend!

Anonymous said...

All of the D3Dxxx.dll files are part of the Direct 3D components of DirectX, which you'll probably recognize. They are likely to be related to gaming, but I'm sure they are used for more than that. The next digit(s) refer to the version, so D3D9 is Direct 3D v9