Links

Exploit Artifacts
The Journey into IR blog has an interesting post regarding exploit artifacts.  This one is specific to CVE 2010-0094, and provides information with respect to exploit artifacts for Admin and non-admin users.  The post lists some excellent file system and Registry artifacts, and they're worth taking a look at and cataloging. One of the things I do in my malware detection process is look for PE files (with .tmp or .exe/.dll extensions) in the user %TEMP% directory (based on the operating system version)...this blog post mentions several file system artifacts in that directory that would be of interest and worth checking out during a wide range of exams (CP/Trojan Defense, intrusion, malware detection, etc.).

One thing I would say about the post is that the Registry artifact posted is confusing...it says that the path to the Registry key affected is "HKLM-Admin", but it should say "HKCU-Admin" for the admin user.

Be sure to take a look at the follow-on post, as well...

Addendum: Plugin complete...

SOP
One of the issues faced in corporate environments is that when something is detected, it's simply quicker to take the box offline, "nuke it from orbit", and reinstall the OS, apps and data.  This was noted in a recent SANS ISC post.  The age-old issue with this approach is that if a thorough exam isn't performed, and the infection or compromise vector isn't determined (based on fact and not speculation) then the system remains open to exploitation and compromise all over again.  So, while the argument appears to be that "it's quicker" to just nuke the box and move on, is it really quicker to keep doing it over and over again?

I completely understand the need to quickly reprovision systems and get them back into service.  But there's such a thing as moving too quickly...to keep with the movie references from the SANS ISC post, consider Arnold S. in "Twins"; "You move too soon."

Anyway, there are a couple of things that you should consider adding to your standard operating procedures (SOP) for these situations.  The SANS ISC post mentions using disk2vhd, which is free and is a good option to consider.  Another is to download FTK Imager (free) and acquire a copy of the drive before reprovisioning.  If you need to mount the image as a VHD file, MS provides the free vhdtool.exe.

The point is that "nuking from orbit" is indeed a quicker response...the first time.  However, not understanding the overall issue of how the system became infected/compromised in the first place quickly reduces the value of this approach, as the system becomes re-infected.  Consider the situation where the compromise is NOT a result of out-of-date patches...what good is setting the system up all over again with up-to-date patches?

If you still find yourself without time to pursue more than simply making a copy/image of the system, why not outsource the analysis?  Contact someone you know and trust within the DFIR community and ask for assistance.  If you're addressing this from a corporate perspective, consider establishing a retainer-based setup with a trusted advisor.

APIMonitor
Ever want a tool similar to strace, for Windows?  Did you ever want to see more about what an application is doing, and how it's doing it?  Check out APIMonitor.  While this tool does appear similar to ProcessMonitor, there are some interesting differences, such as the buffer view, and the ability to monitor services.

Review
Eric J. Huber, of the AFoD blog, posted a review of Windows Registry Forensics on Amazon a bit ago, but I wanted to mention it again here, as this is what helps get the word about the book (and its potential value) out to the community.

Thanks again to Eric and the others who've posted reviews on Amazon, or on other publicly-accessible sites!

One thing I'd like to mention with respect to the content of the review is that the tools from the DVD that accompanies WRF are available online, and the link is continually available from the Books page associated with this blog.