F-Response & Some Mo Stuffz

F-Response
I know I've mentioned this already, but this one is worth repeating...Matt's up to v3.09.07, which includes support for access to physical memory on x64 systems, and a COM scripting object for Windows systems.

I have to say, back when Chris opted to add Perl as the scripting language for ProDiscover, I was really excited, and released a number of ProScripts for use. Matt's really big on showing how easy it is to use F-Response (Matt is incredibly responsive and has released Mission Guides), and has released a number of samples that demo the ability to script tasks with F-Response EE through VBScript, Python, and yes...Perl! My favorite part of his demos is where he has the comment, "Do Work". ;-)

Last year, Matt released the FEMC, taking the use of F-Response EE to an entirely new level, and with the release of the scripting object, he's done it again. Imagine being able to provide a list of systems (and the necessary credentials) to a script, and sitting back to allow it to run; reach out to each system, perform some sort of RegRipper-like queries of the system, look for (and possibly copy) some files...and then you come back from doing other work to view a log file.

I've done some work, with Matt's help, to get a Perl version of his script working against a Windows system, just to kind of get familiar with working with some of the functions his COM object exposes. I have VMWare Workstation and a couple of Windows VMs available, and the biggest issues I ran into were having the firewall running (turn it off for testing), and an issue with connecting to remote shares, even default ones...I found the answer here. I made the change described just so that I could map a share as a means for testing, and then found out by flipping the setting from "Classic" back to "Guest Only" that an untrapped error would be thrown. Once I had the F-Response License Manager running on my analysis system and the adjustment made on my target testing system, the script ran just fine and returned the expected status.

The script I wrote, with Matt's help, runs through the process of connecting to and installing F-Response, running it, enumerating targets and then uninstalling F-Response. The output of the script looks like:

Status for 192.168.247.131: Avail, not installed
Status for 192.168.247.131: Installed, stopped
Status for 192.168.247.131: Installed, started
iqn.2008-02.com.f-response.harlan-202f63d5:disk-0
iqn.2008-02.com.f-response.harlan-202f63d5:vol-c
iqn.2008-02.com.f-response.harlan-202f63d5:pmem
Status for 192.168.247.131: Avail, not installed

I should note that in order to get pmem as a target, I had to open FEMC and check the appropriate box in the Host Configuration dialog.

As you can see, the script cycled through the various states with respect to the target system, from the system being available with no F-Response installed, to installing and viewing targets, to removing F-Response. With this, I can now completely automate accessing and checking systems across an enterprise; connect to systems, log into the appropriate target (vol-c, for example), and as Matt says in his sample scripts, "do work". Add in a little RegRipper action, maybe checking for files, etc.

Awesome stuff, Matt! For more awesome stuff, including a video and Mission Guide for the COM scripting object, check out the F-Response blog posts!

Awesome Sauce Addendum: The script can now access/mount the volume from the remote system, then uses some WMI and Perl hash magic to get the mounted drive letter on the local system, and then determines if Windows\system32 can be found. Pretty awesome sauce!

Documents
Didier has updated his PDFid code recently to detect and disarm the "/Launch" functionality. Didier mentions that this is becoming more prevalent, something important for analysts to note. When performing root cause analysis, we need to understand what's possible with respect to initial infection vectors. Many times, the questions that first responders need to answer (or assist in answering) include how did this get on the system, and what can we do to prevent it in the future? Many times, the actual malware is really the secondary or tertiary download, after the initial infection through some sort of phishing attack.

Over on the Offensive Computing blog, I saw that JoeDoc, a novel runtime analysis system for detecting exploits in documents like pdf and doc, has been released in beta. Check out JoeDoc here...it currently supports PDF format.

If you're trying to determine if there's malware in Flash or Javascript files, you might want to check out wepawet.

Viewers
In the first edition of the ITB, Don wrote an article on potential issues when using an Internet-connected system to view files in FTK Imager. John McCash posted to the SANS Forensic Blog recently regarding a similar topic that ThotCon recently.

Okay, so what's the issue here? Well, perhaps rather than making artifacts difficult to find, an intruder could put out a very obviously interesting artifact in hopes that the analyst will view it, resulting in the infection of or damage to the analysis system.

Also check out iSEC's Breaking Forensic Software paper...