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:

\DEVICE\HARDDISKVOLUME1\PROGRAM FILES\JAVA\JRE6\BIN\JAVA.EXE

There's also another EXE listed in the output:

\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\CMD.EXE

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:


\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D9.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D8THK.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\VMX_FB.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D9CAPS.DAT
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\D3D9CAPS.TMP

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

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\TEST\LOCAL SETTINGS\APPLICATION DATA\D3D9CAPS.TMP

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:


\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\APPLICATION DATA\SUN\JAVA\DEPLOYMENT\DEPLOYMENT.PROPERTIES

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

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\TEST\APPLICATION DATA\SUN\JAVA\DEPLOYMENT\DEPLOYMENT.PROPERTIES

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

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\JAVA_INSTALL_REG.LOG


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


\DEVICE\HARDDISKVOLUME1\DOCUME~1\TEST\LOCALS~1\TEMP\JAVA_INSTALL_REG.LOG

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


\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\~SPAWN7448022680969506475.TMP.DIR\METASPLOIT.DAT

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\~SPAWN5710426834330887364.TMP.DIR\METASPLOIT\PAYLOAD.CLASS

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\~SPAWN5710426834330887364.TMP.DIR\METASPLOIT.DAT

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.