Forensic Perspective

We all have different perspectives on events, usually based on our experiences.  When I was a member of the ISS ERS team, I tried to engage the X-Force Vulnerability folks in discussions regarding the exploits they developed.  I figured that they needed to test them, and that they used virtual systems to do so...what I wanted to do was get access to the images of those virtual systems after an exploit had successfully been developed, so that I could examine the image for artifacts directly associated with the exploit.  The perspective of the folks who wrote the exploit seemed to be that if the exploit worked, it worked.  As a DFIR analyst, my perspective was, how can I be better prepared to serve and support my customers?

We know that when a Windows system is in use (by a user or attacker), there is stuff that goes on while other stuff goes on, and this will often result in indirect artifacts, stuff that folks that are not DFIR analysts might not consider.  For example, I ran across this post a bit ago regarding NetTraveler (the post was written by a malware analyst); being a DFIR analyst, I had submitted the link to social media, along with the question of whether the download of "new.jar" caused a Java deployment cache index (*.idx) file to be created.  From my perspective, and based on my experience, I may respond to a customer that had been infected with something like this that is perhaps a newer version, and in the face of AV not detecting this malware, I would be interested in finding other artifacts that might indicate an infection...something like an *.idx file.

Forensic Perspective
I ran across this post on the Carnal0wnage blog, which describes a method for modifying a compromised system (during a pen test) so that passwords will be collected as they are changed.  A couple of things jumped out at me from the post...

First, the Registry modification would be picked up by the RegRipper lsa_packages.pl plugin.  So, if you're analyzing an acquired image, or a Registry file extracted from a live system, or if you've deployed F-Response as part of your response, you're likely to see something amiss in this value, even if AV doesn't detect the malware itself.

Second, the code provided for the associated DLL not only writes the captured passwords to a file, but also uses the WinInet API to send the information off of the system.  This results in an entry being made into the IE history index.dat file for the appropriate account.  By "appropriate", I mean whichever privilege level the code runs under; on XP systems, I've seen infected systems where the malware ran with System-level privileges and the index.dat file in the "Default User" profile was populated.  I analyzed a Windows 2008 R2 system not long ago that was infected with ZeroAccess, and the click-fraud URLs were found in the index.dat file in the NetworkService profile.

If you haven't seen it yet, watch Mudge's comments at DefCon21...he makes a very good point regarding understanding perspectives when attempting to communicate with others.