ADSs
I've been fascinated by NTFS alternate data streams for almost 14 years now, and I caught MHL's recent blog post on detecting stealth ADSs with TSK tools.  The idea behind a "stealth ADS" came from this Exploit Monday post, and both posts were very interesting reads.

ADSs are one of those NTFS artifacts that many folks (DF analysts, admins, etc.) don't really know a whole lot about, and I'm not sure why.  I guess it's a chicken-or-the-egg issue; how do you know that there aren't any ADSs on your systems if you're not looking for them?  If you don't look for them, why do you then need to know about them...right?  I remember about 11 years ago, Benny and Ratter of the group 29A wrote Win32/Stream, mostly as a proof of concept.

F-Response
If you haven't heard of Matthew Shannon's F-Response, I'd really have to question where've you been.  F-Response is one of those tools that have really pushed incident response work ahead by leaps and bounds.  Using F-Response, you can reach out systems on another floor, in another building, or even in another city, and make a read-only connection to the physical disk, and from there, run tools to search for specific items, collect specific files, or even conduct a physical or logical acquisition.  With Windows systems, you can even collect the contents of physical memory.

Matt's added the FlexScript scripting capability to F-Response, and through Powershell, recently demonstrated how to use F-Response to automate large collections.  As always, Matt includes a video so you can see what he did, in addition to providing the scripts along with the F-Response Mission Guides.

This adds a whole new dimension to an already-valuable tool; being able to automate large-scale collections is a powerful capability.  If an incident occurs, an organization can use this capability to automate quickly connecting to systems and either collecting data, or

Live Forensics
Speaking of Matt Shannon, thanks to his Twitter account, I was recently directed to this paper, which is intended to dispel some of the myths of live digital forensics.  The paper is just 5 pages long, so I printed it out so I could read it...and found it very interesting.  The paper essentially addresses (and shoots down) three common myths that are encountered within the digital forensics community regarding live forensics, and does so only with respect to the admissibility of "live" digital evidence in a US court of law.  I can see how this distinction is important for the paper, particularly in driving its point home.  Additional discussion in dispelling the myths would extend the length of the paper unnecessarily, and potentially make the argument a bit murky.  In short, each of the myths is addressed with "...the Court makes no requirement...".

This is similar to conversations I've had with Chris Pogue, during which we've discussed "court certified" tools; this is something we've both heard, and the long and short of the discussion is that there is no such thing, regardless of what folks (including marketing staff) my choose to believe or say.


Volatility
Here's a post on the malwarereversing blog that discusses (and provides) the vscan.py plugin for Volatility 2.0, which allows you to submit malicious stuff you've found in a Windows memory dump to an online AV scanning site (the post uses Jotti).

The blog post also mentions MHL's avsubmit.py plugin, which allows for the submission of stuff you've found to VirusTotal.

Tools
I ran across the CERT Linux Forensics Tools Repository recently; very cool.  Not only are some of my tools posted there (i.e., RegRipper, tln_tools) but many of the ones listed also run on Winderz!

Mark Woan recently updated JumpLister to include parsing of DestList streams, as well as looking up AppIDs. It appears from the JumpLister web page that the DestList parsing capability was added based on the information available in the ForensicsWiki, which really shows how useful and powerful a resource the ForensicsWiki can be.  Mark's application downloads as part of an installer package, and it only runs on Windows.  The installer adds 11 files to your system, and when you run it, you can load one autodest JumpList at a time.  The tool did a great job of parsing the DestList stream on the few files I loaded.  Mark mentioned in the Win4n6 Yahoo group that he changed the functionality of the tool, so that instead of loading the entire compound file, it first parses the DestList stream, and then looks for the numbered streams identified in the DestList stream.  Jimmy Weg reports that XWays now supports parsing autodest JumpLists, including the DestList streams.

I hope that with the information in the ForensicsWiki, and a number of available tools (free and otherwise) supporting parsing of these artifacts, that maybe this will push folks to start looking at these files as a valuable forensics resource.  Since I started posting about Jump List analysis, I've created my own code for parsing these files, including not only the compound files that the autodest Jump Lists are stored in, but also the LNK streams and the DestList stream.  This code allows me a great deal of flexibility, not only to troubleshoot issues with "misbehaving" Jump List files, but also to modify the output into any format I desire (CSV, TLN), either to analyze separately or include in a timeline.  I've seen the value of Jump Lists in forensic analysis, and I hope others begin to parse these files and include them in their analysis.

AutoRuns Update
AutoRuns has been updated to version 11, to include a "jump to folder" capability, as well as several new autostart locations.  I haven't gone through all of them yet, but this looks very promising.


Speaking of autostart mechanisms, Martin Pillion recently posted to the HBGary blog regarding malware's use of Local Group Policy to maintain persistence on a system.  I found the blog post fascinating (it's always interested to see stuff you've seen talked about before), albeit a bit hard to follow in some places; for example, just below figure 4, the second sentence states:


What section?  I see the "following line", but for the casual reader (or perhaps someone not quite as knowledgeable in this area), this can be confusing.  Overall, however, this doesn't really take much away from this persistence mechanism.  I mention it here (rather than in its own section), as according the blog post, the new version of AutoRuns does NOT detect this persistence mechanism.

Several other MS/SysInternals tools have been updated, as well, to including ProcDump and Process Explorer.

DFF
DFF RC 1.2 is available.

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...

RegRipper in Use
Simon posted to the Praetorian Prefect blog recently regarding WinPE. In his post, Simon described installing and using RegRipper from the Windows Forensic Environment (WinFE). Very cool! RegRipper (well, specifically ripXP) was designed for XP System Restore Point analysis, and RegRipper itself has been used via F-Response, and on an analysis system to extract Registry data from mounted Volume Shadow Copies.

F-Response
Speaking of WinFE, Matt posted recently on creating a WinFE bootable CD with F-Response pre-installed! Matt shows you how to use Troy's WinFE instructions to quickly make the installation F-Response ready! Along with the Linux bootable CDs Matt's put together, it looks like he's building out a pretty complete set.

XP Mode Issues
I found this on Securabit, how the installation and use of XP Mode in Windows 7 exposes the system to XP OS vulnerabilities, as well as vulnerabilities to applications run through XP Mode. This is going to be a bit more of an issue, now that MS has removed that hardware virtualization requirement for XP Mode to run, making it accessible to everyone. Core Security Technologies announced a VPC hypervisor memory protection bug...wait, is that bad?

Well, I like to look at this stuff from an IR/DF perspective. Right now, we've got enough issues trying to identify the initial infection vector...now we've got to deal with it in two operating systems! I've installed XP Mode, and during the installation, the XP VM gets these little icons for the C: and D: drives in my host...hey, wait a sec! So XP can "see" my Windows 7? Uh...is that bad?

Installing and using Windows 7 isn't bad in and of itself...it's really no different from when we moved from Windows 2000 to XP. New challenges and issues were introduced, and the IT community, as well as those of us in the IR/DF community learn to cope. In this case, IT admins need to remain even more vigilant because now we're adding old issues in with the new...don't think that we've closed the hole by installing Windows 7, only to be running a legacy app...with it's inherent vulnerabilities...through XP Mode.

Volume Shadow Copies
Found this excellent post over on the Forensics from the Sausage Factory blog, detailing mounting a Volume Shadow Copy with EnCase and using RoboCopy to grab files. Rob Lee has posted on creating timelines from Volume Shadow Copies, and accessing VSCs has been addressed several times (here, and here). With Vista and now Windows 7 systems becoming more pervasive (a friend of mine in LE has already had to deal with a Windows 7 system), accessing Volume Shadow Copies is going to become more and more of an issue...and by that I mean requirement and necessity. So it's good that the information is out there...

MFT Analysis
Rob Lee posted to the SANS Forensic Blog regarding Windows 7 MFT Entry Timestamp Properties. This is a very interesting approach, because there's been some discussion in other forums, including the Win4n6 Yahoo group, around using information from the MFT to create or augment a timeline. For example, using most tools to get file system metadata, you'll get the entries from the $STANDARD_INFORMATION (SIA) attribute, but the information in the $FILE_NAME (FNA) attribute can also be valuable, particularly if the creation dates are different.

When tools are used to alter file time stamps, you'll notice the differences in the SIA and FNA time values, as Lance pointed out. Brian also mentions this like three times in one of the chapters of his File System Forensic Analysis book. So, knowing how various actions can affect file system time stamps can be extremely important to creating or adding context to a timeline, as well as to the overall analysis.

The Future
Rob's efforts in this area got me to thinking...how long will it be before forensic analysts sit down at their workstation to being analysis, and have a Kindle or an iPad or similar device right there with them, to assist them with their analysis workflow? Given the complexity and variety of devices and operating systems, it would stand to reason that an organization would have a workflow with supporting information (docs like what Rob's putting together, etc.), possibly even online in one location. The analyst would access the online (internally, of course) app and enter their information and begin their case, and they would be presented with workflow, processes and supporting information. In fact, something like that could also provide for case management, as well as case notes and collaboration, and even ease reporting.

Is the workflow important? I'd suggest that yes, it is...wholeheartedly. I've seen a number of folks stumble over what they were looking for and spend a lot of time doing things that really didn't get them any closer to their goals...if they had and understood their goals! This would not obviate the need for training, of course, particularly in basic skills, but having some kind of Wiki-ish framework with a workflow template for an analyst to follow would definitely be beneficial...that is, aside from its CSI coolness (I still yell, "Lt Dan!" at the TV whenever Gary Sinise comes on screen in CSI:NY).

Man, there is just so much stuff sometimes, that it takes several posts to get it all in...

Perhaps one of the biggest things to come through my inbox lately has been that F-Response now has a scripting interface! That's right! According to Matt:

The F-Response Enterprise installation package now includes a partial implementation of the F-Response Enterprise Management Console in a language neutral fully scriptable COM object. This object will allow a technical user of F-Response Enterprise to script actions typically initiated manually in the FEMC.

Sweet! What this technical jargon amounts to is that F-Response EE can now be scripted through Perl! Imagine automating collection of system names from the network, pushing out F-Response EE, collecting information, disconnecting and moving on to the next system!

Here's an analysis tip that I picked up based on a question posted to one of the forums...when posting a question about time stamp oddities (in particular) on Windows systems, it helps to specify which version of Windows you're working with. For example, if you have a last modified date that is three days after the last accessed date on a file, and the system is Vista, then you may have encountered an artifact that has to do with the fact that by default, Vista does not update last access times on files. If the system is XP or Win2K3, you may want to check the NtfsDisableLastAccessUpdate value. Even variations within the same version of Windows (XP Professional vs. Home) can be important...and yes, you can use RegRipper to get this information for you.

Lee posted an excellent write-up regarding issues of MSOffice document metadata, along with an interesting example that many of us have likely run across. This is an issue that's been around for some time, and even though MS's updated the application itself, this is still something that can be very important during an examination, as Chris found out recently.

Are you tired of using RegRipper? Mark Woan has created RegExtract, which according to Mark, is based completely on RegRipper, and implements most of the plugins that are currently publicly available (I currently have 118, a few of which are proof-of-concept and for testing purposes only...) with RegRipper. I downloaded and installed RegExtract and took a look at it. It requires .NET 3.5, and it only runs on Windows (unless you can get .NET 3.5 installed on wine), but if you need a better looking UI and perhaps slightly faster processing, you should take a look at this. A couple of things I found with RegExtract is that while it can run all plugins designed for the NTUSER.DAT hive (or any other hive type) against that hive file, it doesn't appear to be able to automagically determine the hive type, or allow you to run only specific plugins in a predetermined order against the hive file. The results of the plugins are sent to a text field in the UI, and the user doesn't appear to have the ability...at least not obviously...to save the results to a file, for inclusion in a report (directly into the report, or an appendix). You can, however, select what you want from the text field, copy it to the Clipboard, and then paste it into a report or text file.

Finally, something else to consider...the plugins are compiled DLLs, and are not open. RegRipper's plugins are essentially text files that can be opened in Notepad or an editor of your choice (much like Nessus's plugins), so if you ever have any questions about what the plugin does or why it doesn't work, you can just open the plugin up and have a look-see.

Speaking of RegRipper, Rob posted the results of his updated research on USB devices to the SANS Forensic blog yesterday. This is an excellent bit of work that Rob's done and really taken the original work that Cory and I did oh, lo those many years ago to new levels. Drop by and check out the handouts Rob's put together. Based on an IM exchange with Rob, I've updated mountdev.pl a bit to pull out the sector offset information for the partitions, so that there's less confusion when you see two volumes or drive letters with the same disk signature or MBR disk identity (they're the same thing...the 4 bytes found at offset 0x01B8). The plugin now returns the same information seen when you open the image in FTK Imager and look at the start sector for the partition. With this new information, I need to clean up the plugin a bit to make the output a bit easier to understand.

Finally, Matthieu's been busy, it seems, working away on win32dd (now referred to as "windd") and looking for beta testers (ignore the "2008" in the changelog info...it's 2009). Take a look!

Hey, no kidding! Check it out! Matt's offering a free (as in "beer") copy of WFA 2/e with each purchase or renewel of F-Response CE/EE. Got four consultants? Outfit each of them with a copy of F-Response EE, and they'll each get a copy of WFA 2/e. Sweet! Don't think so? Check out the reviews!

Check out this post over on the F-Response site...Matt's released the lastest and greatest 3rd generation F-Response! I've got it and I have to tell you...it's pretty awesome! Check out the new features listed on the page.

The very first, most coolest thing I found about 3.09 was the installation...it was smooth and fast. Put iSCSI on your system, and then run the installer. It's that easy! Getting up and running is fast, too. Once you're ready, launching the F-Response Enterprise Management Console (FEMC) allows you to quickly and easily connect to systems and access physical memory (32-bit Windows), as well as physical disks and logical volumes. And, F-Response isn't just for Windows (including 32- and 64-bit for disks)...you can use it with multiple Linux distros, as well as MacOSX.

If you have any questions at all about how useful F-Response will be in your organization, check out the training videos. Honestly...this is quick look into how simply yet powerful F-Response is, and you can run through these during lunch, or while you're having a beer after a long day at work.

Folks, F-Response has quite literally changed the face of incident response! Where once was the day that systems would sit compromised until someone could get to them and acquire data, that data can now be acquired and analyzed quickly and efficiently, even from remote locations. This means that not only can consultants carry around an enterprise capability in their pockets, but on-site IT staff can begin staging collected data, even while management is on the phone getting the help they need. Hit with malware that AV doesn't recognize? What's your response time in getting someone on-site now...24 hours? 72? How about if when the issue occurs, you reach out with F-Response EE and grab the contents of RAM from a couple of systems, and when management gets some responders on the line, you already have a RAM dump available for analysis. If you already have a transfer mechanism set up, you could literally have answers WHILE YOU'RE ON THE PHONE, not 72 hrs later!

A letter went out recently from someone at Guidance Software that...well...misrepresented some facts about the F-Response product. I understand that this is how some folks believe that business is done, and that's...well...sad. I'm not going to bash Guidance or their products; instead, I think that as someone who greatly appreciates the work that Matt has done, it is important to clear up some of the misrepresentations put forth in that letter, as some are a bit off, while others are just blatantly wrong.

The letter starts off with: F-Response is a utility that simply allows users to acquire the contents of remote computers and devices, but without any type of security framework, data analysis or forensic preservation capabilities.

F-Response is a tool-agnostic means that facilitates acquisition of data...Matt never intended for it to provide acquisition, analysis or forensic preservation capabilities. There are already enough bloated applications out there, why add another one? Why not instead simply provide sound framework that allows you to do what you need to do? And don't get hung up on the term "sound"...if you're not willing to look into it for yourself, please don't argue the point.

Going on this way throughout the rest of the letter, point for point, would be obnoxious and boring. Instead, I'll illustrate some of the other major points brought up in the letter that include (but are not limited to):

Acquisition validation issues: Acquiring data using a new transfer method introduces an unknown into the acquisition that needs to be vetted by the industry and in the courts - How is new a bad thing? Of course things need to be vetted...EnCase needed to be vetted at one point. I'm not entirely sure I see the point to this "issue".

No logging capabilities - Of course F-Response doesn't have logging capabilities...that's not what it was designed for. This is like complaining that the hammer you brought can't be used to tighten or loosen bolts.

No end node processing - Again, F-Response wasn't designed to be yet another version of available tools; rather it was designed to give greater capabilities to those already possessing a number of the available tools; just watch the videos that are freely available.

Limited Volatile Data Collection - F-Response provides full access to physical memory, exposing it as a physical drive on the analyst's system. Mandiant's Memoryze is capable of directly accessing that physical drive. The contents of physical memory can also be acquired in raw (ie, "dd style") format and immediately imported into HBGary's Responder product with no conversion.

No Solaris, Mac, Linux, AIX, Novell: The solution is Windows only - F-Response currently supports Linux and Apple OSX 10.4, 10.5, with more coming. Characterizing F-Response as "Windows only" is blatantly incorrect.

Invasive compared to servlet - What is "invasive"? F-Response Enterprise is only 70k. You're kidding, right?

Agent deployment is manual - F-Response Enterprise Management Console. It's easier for me to deploy F-Response EE to a dozen systems than it is for me to answer an email on my Blackberry.

No Encryption - F-Response can support Microsoft IPSEC, and F-Response can be run over VPNs.

No compression - F-Response end points can be moved closer to the source machine, effectively reducing the need for compression. Also, compression is CPU-intensive, and wait a second, didn't the author of the letter just mention something about invasiveness??

All in all, the letter really goes a long way toward misrepresenting F-Response. Don't get me wrong...neither Matt nor F-Response need defending from me. Both are fully capable of standing on their own without any help from me. But when I see a misrepresentation as blatant as this, I really feel that it would be a disservice for this go on without at least saying something.

Regardless of my opinions in the matter, I'll leave it to anyone reading this to choose for themselves.

Addendum: Looks like this post got picked up here (in Poland) and by Moyix, as well. Moyix raises some excellent points about the FUD surrounding Volatility...

Matt Shannon is one of those guys that comes along and has a noticeable and definite impact on the world of Incident Response. First there was Nigilant32, then there was F-Response, with which Matt and his crew were able to provide a whole new...and much needed...capability to incident responders.

In October 2008, at the SANS Forensic Summit, Matt and Aaron Walters gave an excellent presentation on Voltage (F-Response + Volatility), showing how a responder can deploy F-Response and use functionality based on Volatility to fight malware. The presentation and the implementation were awesome!

More recently, Matt's shown how F-Response can be used with Nuix and Intella (be sure to check out the videos), clearly showing how F-Response's tool-agnostic framework can be used to really leverage the capabilities of other tools. Matt and Jamie Butler of Mandiant also recently announced that Memoryze supports F-Response.

Well, Matt's gone and done it again with the F-Response Enterprise Management Console (blip.tv video...even if you don't have F-Response EE yet, you should still watch this video)! Until now, pushing out F-Response EE to one system required some work in the command prompt, but now, Matt's made it so that it takes more effort for me to play BrickBreaker on my BlackBerry than it does for me to push out F-Response EE to one, two, or a dozen systems on a network!

So that's what I did...I fired up my Window 7 Ultimate Beta VM and basically followed Matt's video. As a caveat to this, I do have some experience working with F-Response EE via the command prompt, so it may have gone a bit more smoothly for me than for a first time user...but Matt's video is the best place to start. In the video, Matt walks through the various components of the UI and how you use each piece of information.

You can scan a workgroup or domain, IP address range, or directly connect to a system. I chose to connect directly to the system itself, in order to try out that functionality. Once I got connected to the VM (this is the VM I downloaded from BitTorrent, so it appears with the TuxDistro-PC system name), I could clearly see the system in the UI.

From there, all I needed to do is walk through the FEMC interface to install F-Response on the remote system and start the service with the name I provided through the UI. Since I wanted to see the physical memory (and had selected that through the UI) on the remote system, once F-Response was up and running and I had connected to the remote system, I could see two targets. The first target listed (:1) is the physical memory from the remote system, and the second target listed (:0) is the hard drive. At this point, notice that I haven't had to open the iSCSI Initiator console at all...all of the functionality for managing the use of F-Response EE is handled through a single interface.

Pretty cool so far...at this point, this has all just been a couple of mouse clicks. So the next step is to fire up the Disk Manager on the system from which I'm running all this...the memory from the remote system appears as Disk3, and the hard drive appears as Disk4. As the memory does not consist of a recognized file system, it's going to be accessible as \\.\PhysicalDisk3, and can be accessed via FTK Imager or Memoryze, which just reinforces how F-Response is a tool-agnostic platform. The larger partition from Disk4 got mapped to my analysis system as the I:\ drive, and from there I was able to run tools of my own, like RegRipper, which allows me to perform a modicum of triage and analysis.

These will show up in the FEMC UI, you don't NEED to go to the Disk Manager to see and access them...I simply show them here for the sake of transitioning from the CLI method. The physical disks themselves are shown in the Connect tab (you may need to refresh the UI to see them, but they'll be there). Also, you can follow what's happening in the Messages tab, and even cut-n-paste all of the messages from your session and use those in your case notes as your documentation.

Matt blogged on the FEMC here.

I've got two words for you. Suh. WEET! There's no question...for what amounts to a very modest price, you (consultant, IT staffer, etc.) have the capability to get answers NOW, whether you're responding to an incident, or addressing an HR issue, or even just network or system troubleshooting. For example, the current model of incident response is when something happens, many organizations call someone; from there, it takes time set up a conference bridge, describe to someone who isn't familiar with your infrastructure what's going on, and then they have to grab their gear and get on a plane...it could be 24 (or more) hours before someone's on-site, and then they have collect data. With F-Response and the FEMC, you can now preserve the data (i.e., in the case of new malware, collect a memory dump), provide it to consultants, and start getting answers while whomever is designated to come on-site is still looking for flights!

I recently received an email from the organizers of the SANS Forensic Summit and was asked to provide my biggest takeaways from the summit, and I wanted to post what I came up with, to see if others are seeing the same sorts of things...so, here's what I provided:

I would say that the key take-away for me is that speed is essential, but should not be sacrificed for accuracy. Incident responders need to respond quickly in order to identify, classify, and as appropriate, contain an incident. In part, this puts the onus on the organizations...even if they have consultants on retainer, it will still take time for them to arrive, and then they are slowed down even further having to get up to speed and learn the environment. Consultants can assist an organization in developing a tier 1 response, training them in triage, diagnosis, preview, containment, etc., even across an enterprise. I would also say that tools such as F-Response are paramount to this sort of activity, as well. Once the initial training is complete, the consultants can respond as tier 2 or 3 responders, assisting as necessary, but knowing that the necessary data has been collected.

It's clear that state (via PII notification laws) and federal legislation, as well as regulatory oversight (PCI, HIPAA, etc.), play a huge role in incident response. In fact, these are the primary drivers to IR at this point. Think about it...if a company was not required to notify someone when a breach of sensitive data occurred, would they?

To that end, there needs to be a much more immediate response...calling a consulting firm to come on-site to assist after the incident has occurred and been detected is a fantastic idea, but one of two things are going to happen; you're either going to continue "bleeding" data while you're waiting, or you're going to stomp all over the data and destroy the indicators (aka, "evidence") that those consultants will be looking for in order to answer the questions that need to be answered.

Okay, brief digression here...what questions will need to be answered? There are essentially three questions that need to be answered in the face of a breach of sensitive data...(a) was a system compromised, (b) did the system contain sensitive data, and (c) was that sensitive data exposed or compromised as a result of the breach? In order to determine (c), in most cases, you need to minimize "temporal proximity" (thanks, AAron, for that very Star Trek-y term!!)...that is, you need to detect the breach and collect data as close to the time of the breach as possible.

Rather than fall victim to a breach and not get the answers you need (by "you", perhaps a more appropriate way of saying it would be "your legal counsel or compliance officer"), why not get someone in ahead of time, before an incident occurs, to work with you in setting up a response plan, and training your staff in a timely, accurate response?

I've said before that tools like F-Response and Volatility (the combination of the two being referred to as Voltage) have changed the face of incident response. Having these tools available to you allow you to quickly collect and analyze memory in order to triage and categorize incidents. Too many times I've been asked to come on-site only to find out that prior to the call, the customer had already turned systems off and taken them offline. These tools will help you collect more data than every before, reduce that "temporal proximity", and at the very least have data available for tier 2 incident responders to process and analyze.

Thoughts?

The recent Best Western issue illustrates an important point, which was mentioned in many of the posted articles on this issue...

Compliance != Security

In the face of compromises or any other potential/verified breach, a quick response is essential. You don't know if you have sensitive data (PCI, PHI, PII, etc.) leaving your network, and your first, most immediate and natural reaction (i.e., disconnecting systems) will likely expose you to more risk than the incident itself. Wait...what? Well, here's the deal, kids...if a system has sensitive data on it, and was subject to a compromise (intrusion, malware infection, etc.), and you cannot explicitly prove that the sensitive data was not compromised, you may (depending upon the legal or regulatory requirements for the data) be required to notify, regardless.

So...better to know than to not know...right?

What you need to do is quickly collect the following items:

1. Pertinent network (i.e., firewall, etc.) logs
2. Network packet capture(s)
3. Full or partial contents of physical memory
4. An image acquired from the affected system

Of course, this assumes a great deal...that you have a CSIRP in place, that you've already identified systems that store/process sensitive data, and that you've got the tools and training to collect any of this data. Some of it is fairly trivial...collecting firewall logs may simply be as easy as a call to your NOC. Collecting packet captures is as simple as having a Windows laptop with Wireshark installed, or Linux laptop. Tools for dumping the contents of RAM have recently taken a surge forward, and acquiring an image from a live system (can't shut that server down??) is as straightforward as getting a copy of FTK Imager.

Remember to DOCUMENT everything you do! The rule of thumb is, if you didn't document it, you didn't do it.

What other tools are available? In the case of Best Western, as well as any other organization with remote systems (located in distant data centers or storefronts), something like F-Response may prove to be extremely valuable! If you're not sure about F-Response and don't believe the testimonials, give the Beta Program a try. With the Enterprise Edition of F-Response already deployed (or simply pushed out remotely as needed), getting the data you need is amazingly straightforward!

So why do all this? Why go through all this trouble? Because you will likely have to answer the question, was sensitive data leaving my network? The fact of the matter is that you're not going to be able to answer that question with nothing more than a hard drive image, and the single biggest impediment to doing the right thing (as opposed to something) in a case like this is time...when you don't have the tools, training or support from executive management, the only reaction left is to unplug systems and hope for the best.

Unfortunately, where will that leave you? It'll leave you having to answer the question, why weren't you prepared? Would rather have to face that question, or actually be prepared?

If you want to learn what it takes to be prepared, come on by the SANS Forensic Summit and learn about this subject from the guys and gals who do it for a living!

Resources
CSO Online - Data Breach Notification Laws, State by State
SC Magazine - Data Breach Blog

Matt Shannon posted an excellent article to his blog this morning called Singing in the RAID...it's a must read, folks. Take a look.

One thing that Matt quite correctly points out is that sometimes live acquisition (acquiring an image of system while the system is running) is your only option. There are times when a customer will tell you that the system you need to image can't be taken down, so removing the drives, imaging each, and rebuilding the array is not an option. Of course, there are other issues, such as SAS drives, boot-from-SAN systems, etc., that can all put a responder in the position to have to acquire the system in a live condition. This can be done by running acquisition tools such as FTK Imager from a CD or USB removable device, or the circumstances may permit or require you to use F-Response with its built-in write-blocking capability to access the system and perform the live acquisition (imaging done with the acquisition tool of your choice).

Another advantage of using F-Response is that it obviates the need for expensive enterprise licenses.

I recently played with F-Response Enterprise Edition, and I have to tell you, this stuff rocks! Excuse me...R0x0rz! Imagine as an incident responder if you could have read-only access to a remote disk...completely independent of your toolset? This means that once you get F-Response up and running, you have a disk on your system, which is the physical disk of the remote system...but it's read-only. Wanna grab files? Do it. Wanna image the drive? Do it.

Just so you know, you'll need to get the MS iSCSI Software Initiator as well.

So once I got everything set up (Matt's documentation is pretty straight forward) and running, all I had to do was run the installed service on the remote system...in this case, a Windows XP VMWare session. Once that was done, I had a nice little indicator that the remote system was connected to. Very good. Then I looked and saw that I had an icon for an F:\ drive now attached to my system. I could browse it, copy files, do whatever...it was all read-only. No changes (file modifications, adding files, etc.) appeared on the remote system drive.

So then I thought I'd replicate what Hogfly had done using RegRipper...and it worked like a champ! I simply fired up RegRipper 2.02, pointed it at the NTUSER.DAT for the user account on my remote system, and ran it, saving the report and log files locally.








Awesome! RegRipper ran very well, over F-Response...as if it were running against a file that I'd extracted from an image, locally.

The cool thing is that F-Response EE can be easily pushed out as part of an incident preparedness program, or pushed out remotely using tools like psexec.exe. By design (and an excellent choice, I must say), the F-Response service does NOT start automatically...which means that as an administrator, you can have the service sitting there until you need it. As an incident responder, once you get it set up and running, all you need to do is launch the service.

Matt Shannon, the creator of F-Response, also has two other versions of F-Response...I was using the Enterprise Edition. Check out his site and see which version may be suitable for you.

Great job, Matt! Excellent tool! I really look forward to seeing not only what updates you may have available in the future, but also some of the novel and inventive ways folks come up with for using and employing such a simple and yet 0h-so-powerful tool!

Note: Updating a license for F-Response is a breeze! Download the update file, download the updater, plug in the FOB, run the updater, point it at the update file...and bang, in a couple of seconds you're stick-a-fork-in-me-I'm-DONE!

Addendum:
Rob Hensing blogs about...this post!
Lance "The Man" Mueller's blog post

Hogfly emailed me last night to let me know that he'd posted a video on how to use F-Response and RegRipper together in live response. There's no audio to the video, but it's cool nonetheless...Hogfly does a great job of putting in cues, and focusing in so that the viewer can see what's going on up-close.

One thing that I wanted to address, though, is something that Hogfly stated in his blogpost:

Harlan has said this tool is not designed for live response...

For the record, I never said that. What I did say is:

RegRipper is NOT intended to be run on live Registry hive files.

There's a difference. RegRipper was NOT intended to be run against C:\Documents and Settings\hcarvey\NTUSER.DAT while I'm logged into my system...the hive file is live and locked by the system (populating the HKEY_CURRENT_USER hive in RegEdit). However, what Hogfly did was completely different...he used the excellent tool F-Response to access the remote drives as read-only physical disks, and then used FTK Imager to extract the hive files. You can do this on your own system as well...fire up FTK Imager, add your physical disk as an evidence item, and extract your hive files into another location in the file system. At that point, when you fire up RegRipper, you're not longer really doing "live response".

Thanks, Hogfly...great video! And a mighty THANKS goes out to Matt Shannon for coming up with F-Response...for recognizing and filling a very important need. With what's coming down the road with F-Response, as well as with other tools, the face of incident response and computer forensic analysis is now changing, in a very positive direction!