In preparation for some upcoming training courses that I'll be delivering, I've been updating some of the tools that I use (in my own work, as well as in the training I provide). I've also been compiling them (via Perl2Exe) so that folks don't have to have Perl installed in order to run them.
One of the tools I've updated is pref, used for parsing Prefetch file metadata. Some of the updates allow for a modicum of Prefetch analysis to occur automatically; for example, when running the tool across a number of Prefetch files, you can look for outliers (with respect to the module paths). Another capability I've added to the tool is to automatically look for '.dat' and '.exe' files, as well as look for paths that include "temp".
I ran pref against a Prefetch file known to be associated with malware, and this is what I saw at the end of the output:
EXEs found:
\DEVICE\HARDDISKVOLUME1\SYSTEM VOLUME INFORMATION\_RESTORE{00D8A395-89D5-46B8-A8
50-E02B0F637CE5}\RP2\SNAPSHOT\REPOSITORY\FS\SMS.EXE
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\INETSRV\RPCALL.EXE
DAT files found:
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\VMWARE\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\VMWARE\COOKIES\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\VMWARE\LOCAL SETTINGS\HISTORY\HISTORY.IE5\INDEX.DAT
Temp paths found:
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\VMWARE\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUME~1\VMWARE\LOCALS~1\TEMP\DEL10.BAT
None of this was surprising, as one of the modules loaded by the malware was WinInet.dll. So what does this tell us?
Well, first off, the malware file was sms.exe...and look where it was launched from. And why is there a second .exe file listed as one of the modules?
Next, check out the .dat files...kind of interesting. We should expect this, as the WinInet API is used...but this also tells us where to go to get additional data. And because we were also able to get the last time that the program ran, we know where (what time) we should look in the index.dat files for artifacts.
Finally, we see two files with "temp" in their paths...one of them a .bat file. Now, we may be able to recover this file, if it was deleted. Hey, wouldn't it be cool if this was really a .bat file and the contents were resident within the MFT entry?
I've also updated the Jump List parsing script, jl, and compiled it.
Another tool that I've updated and compiled is jobparse, for collecting metadata from Windows XP/2003 .job files.
I still have evtparse, for parsing Windows XP/2003 Event Logs, and I've added evtxparse, for parsing the output of LogParser, run against Vista+ Windows Event Logs.
I've updated recbin to parse both Windows XP/2003 INFO2 files as well as the $Ixxxxxx files from Vista+ Recycle Bins. There are a few other odds and ends that I have (and have updated) as part of my toolkit, as well.
Oh, and yes, all of the tools are capable of formatting output to TLN format, for inclusion in the events file.
These tools will be available as part of the training courses.
2 comments:
do you have a method for parsing the IE/Firefox/Chrome history to TLN format Harlan?
Yes.
Post a Comment