Online DFIR Meetups
Tonight (Thu, 15 Dec) at 8pm EST is the first Online DFIR Meetup, hosted by Mike Wilkinson.  Stop by and check it out...Mike and I will be presenting during this first meetup.

I think that we need to come up with a good hashtag for the event, particularly something that's unique to the event.

Future of IR
If you haven't already, check out the Carbon Black white paper  on the future of IR, by moving from a purely response posture to a proactive, incident preparedness posture.

Moving to a proactive posture just makes sense for a lot of reasons.  First, it doesn't matter which annual report you read...Verizon, Mandiant, TrustWave...they all pretty much state that it doesn't matter who or where you are...if you have a computer connected to the Internet, you will be compromised at some point.  In fact, you may very likely already have been compromised; you may simply not realize it yet.  Second, if all of the studies show that you're gonna get punched in the face, why keep your hands down?  Why not put on head gear, get into a good stance, and get your hands up?  If it's gonna happen, why not be ready for it, and be able to react to minimize the effects?  Finally, there are a lot of regulatory bodies out there that are all telling the organizations that they oversee that they have to take a more proactive approach to security.  Paragraph 12.9 of the PCI DSS states that organizations subject to the PCI will have (as in, "thou shalt") an incident response capability, and the subparagraphs provide additional details.

At this point, one would think that there's enough reason to have an IR capability within your organization, and be ready.  One would think...

Now, does a tool like Cb obviate the need for that response capability?  I mean, if you're able to VPN into a system and diagnose and scope an incident within minutes, does that mean we'll no longer need to do DFIR?

No, not at all.  What Cb does bring to the table is a solution for rapidly triaging, scoping, and responding to an incident; however, it does NOT obviate the need for dedicated analysis.  Once the incident has been scoped, you can then target the systems from which you need to acquire data...dumps of physical memory, selective files, or acquire full images.

As a consultant, I can see the immediate value of Cb.  The traditional "emergency response" model dictates that someone be deployed to the location, requiring the expense of last minute travel and open-ended lodging arrangements.  There's also the "cost" of the time it takes for an analyst to arrive on-site.  Remember, costs are multiplied (travel, lodging, hourly rate, etc.) for multiple analysts. 

Let's say I have a customer who has several sensors rolled out and their own internal Cb server.  With their permission, I could VPN into the infrastructure and access the server via RDP, pull up the Cb interface and being investigating the incident while we're on the phone.  Based on what is available via Cb, I could begin answering questions in very short order, with respect to the severity and scope of the issue.  I could also obtain a copy of any particular malware that is involved in the incident and send it to a malware analyst so she can rip it apart (if such activity is within scope).   Having deployed Cb, the customer has already decided to be proactive in their security posture, so we can have local IT staff immediately begin isolating and acquiring data from systems, for analysis.

So, this is the difference between the traditional "emergency response", and the future of IR (i.e., immediate response).  And yes, this is only true if you've already got Cb installed...but, as described in the white paper, Cb is still useful if it is installed after the incident.

Now, Cb also does not obviate the need for working with customers and developing relationships, so don't think that someone's going to arrive on-site, install something on your network, poke a hole in your perimeter, and you never see them again.  Rather, deploying Cb requires that an even stronger relationship be built with the customer, for two reasons.  First, being proactive is an entirely new posture for many organizations, and can require something of a shift in culture.  This is new to a lot of organizations, and new things can be scary.  Organizations who recognize the need for and are open to change are still going to tread lightly and slowly at first.

Second, Cb itself is new.  However, Cb as a number of case studies behind it already that not only demonstrate its utility as an immediate response tool, but also as a tool to solve a variety of other problems.  So, organizations rolling out Cb are going to need some help in identifying problems that can be solved via the use of Cb, as well as how to go about doing so.

During the recent SANS360 event, Mike Cloppert (see Mike's Attacking the Kill Chain post) suggested that rather than competing with an adversary on their terms on your infrastructure, that we need to change the playing field and make the adversary react to us.  With only 6 minutes, Mike didn't have the time to suggest how to do that, but Cb gives you that capability.  Cb allows you to change the IR battlefield all together.

File Extension Analysis
I posted a HowTo on file extension analysis a bit ago, and as something of a follow up, I've been working on an article for a Microsoft portal.

I guess what I find most interesting about this post is that even though I see the question that spawned the post asked in online forums and lists, the blog post doesn't have a single comment.  You'd think that as many times as I've seen this in lists and forums, someone would have looked at the post, and maybe found it useful.  Well, I tried the "HowTo" approach to the blog posts, and that didn't seem to be too well received...

Carbon Black
I recently gave a presentation at ETCSS, during which we discussed the need for incident preparedness in order to improve the effect of incident response efforts.  In that presentation, I mentioned and described Carbon Black (Cb), as well as how it can be used in other ways besides IR.

While I was traveling to the venue, Cb Enterprise was released.  Folks, if you don't know what Carbon Black is, you really should take a look at it.  If you use computers in any capacity beyond simply sitting at a keyboard at your house...if you're a dentist's office, hospital, law firm, or a national/global business...you need to take a good hard look at Cb.  Cb is a small, light-weight sensor that monitors execution on a system...remember Jesse Kornblum's Rootkit Paradox paper?  The paradox of rootkits is that they want to hide, but they must run...the same is true with any malware.  Cb monitors program execution on Windows systems.  The guys at Cb have some great examples of how they've tracked down a three-stage browser drive-by infection in minutes, where it may have taken an examiner doing just disk forensics days to locate the issue.

If you have and use computers, or you have customers who do, you should really take a hard look at Cb and consider deploying it.  Seriously...check out the site, give the Kyrus Tech guys a call, and take a good hard look at what Cb can do for you.  I honestly believe that Cb is a game changer, and the Kyrus Tech guys have demonstrated that it is, indeed, a game changer, but not just for IR work.

Timeliner
Jamie Levy has posted documentation and plugins for her OMFW talk (from last July) regarding extracting timeline data from a memory dump using the Volatility framework.  This is a great set of plugins for a great memory analysis framework, folks.  What's really cool is that with a little bit of programming effort,  you can modify the output format of the plugins to meet your needs, as well.  A greatbighuge THANKS to Jamie for providing these plugins, and for the entire Volatility team/community for a great memory analysis framework.

Exploit Artifacts
Speaking of timelines...Corey has posted yet another analysis of exploit artifacts, this one regarding a signed Java applet. This is a great project that Corey works on, and a fantastic service that he's providing.  Using available tools (i.e., MetaSploit), he compromises a system, and then uses available tools and techniques (i.e., timeline analysis) to demonstrate what the artifacts of the exploit "look like" from the perspective if disk analysis.  Corey's write-up is clear and concise, and to be honest, this is what your case notes and reports should look like...not exactly, of course, but there are lot of folks that use the "...I don't know what standard to write to..." as an excuse to not do anything.  Look at what Corey's done here...don't you think that there's enough information to replicate what he did?  Does that work as a standard?

Also, take a look at the technique Corey used for investigating this issue...rather than posting a question online, he took steps to investigate the issue himself.  Rather than starting with an acquired image and a question (as is often the case during an exam), he started with just a question, and set out to determine an answer.  Information like this can be extremely valuable, particular when it comes to determining things such as the initial infection vector of malware or a bad guy, and a good deal of what he's provided can be added to an exam checklist or a plugin for a forensic scanner.  I know that I'm going to continue to look for these artifacts...a greatbighuge THANKS to Corey, not just for doing this sort of work, but posting his results, as well.

DFF
DFF 1.2 is available for download.  Take a look at this for a list of the updates; check out batch mode.  Sorry, I don't have more to write...I just haven't had a chance to dig into it yet.

Community
One of the things I see a great deal of, whether it's browsing the lists or reading questions that appear in my inbox, is that when asking questions regarding forensic analysis, many of us still aren't providing any indication of the operating system that we're analyzing.  Whether its an application question (P2P, FrostWire, a question about MFT entries, etc.), many of us are still asking the questions without identifying the OS, and if it's Windows, the version.

Is this important at all?  I would suggest that yes, it is.  The other presentation I gave at ETCSS (see the Carbon Black entry above) was titled What's new in Windows 7: An analyst's perspective.  During this presentation, we discussed a number of differences, specifically between Windows XP and Win7, but also between Vista and Win7.  Believe it or not, the version of Windows does matter...for example, Windows 2003 and 2008 do not, by default, perform application prefetching (although they can be configured to do so).  With Windows XP, the searches a user executed from the desktop were recorded in the ACMru key; with Vista, the searches were NOT recorded in a Registry key (they were/are maintained in a file); with Windows 7, the search terms are maintained in the WordWheelQuery key.

Still not convinced?  Try analyzing a Windows 7 memory dump with Volatility, but don't use the Windows 7 profile.  

So, it you're asking a question that has to do with file access times, then the version of Windows is very important...because as of Vista, by default, updating of last access times on files is disabled.  This functionality can be controlled by a Registry value, which means that this functionality can also be disabled on Windows XP systems.

I also see a number of questions referring to various applications, many of which are specific to P2P applications.  Different applications behave differently...so saying, "I'm doing a P2P investigation" doesn't really provide much information if you're looking for assistance.  I mean, who's going to write an encyclopedic if/then loop with all of the possibilities?  Not only is the particular application important, but so is the version...for the same reasons that the OS version is important.  I've dealt with older versions of applications, and what those applications do, or are capable of doing, can be very important to an investigation...that is, unless you're planning to fill in the gaps in your investigation with speculation.

In short, if you've got a question about something, be sure to provide relevant background information regarding what you're looking at...it can go a long way toward helping someone answer that question and provide you with assistance.


Tools
I've started a new page for my blog, listing the FOSS forensic tools that I find, come across, get pointed to, and use.  It's a start...I have a good deal of catching up to do.  I've started listing the tools, and provided some descriptions...I'll be updating the tools and descriptions as time goes on.  This is mostly a place for me to post tools and frameworks so that I don't have to keep going back and searching through my blog for something, but feel free to stop by and take a look, or email me a tool that you like to use, or site with several tools.

Endorsements
One final thing...and this is for Mr. Anonymous, who likes to leave comments to some of my blog posts...I get no benefit, monetarily or otherwise, for my comments or endorsement of Volatility, nor for DFF...or any other tool (FOSS or otherwise) for that matter.  I know that in the past, you've stated that you "...want to make sure that it is done with the right intentions".  Although you've never explicitly stated what those intentions are, I just wanted to be up front and clear...I have used these tools, and I see others discovering great benefit from them, as well...as such, I think that it's a great idea to endorse them as widely as possible, so that others don't just see the web site, but also see how they can benefit from using these tools.  I hope that helps.

I was recently afforded an opportunity to download and install the Carbon Black (Cb) standalone server; for testing purposes, I installed it on a Windows 7 host system, and got it up and running right away. 

If you're not aware, Cb is a small sensor that you can load on a Windows system, and it monitors executables being launched.   When a new process is started, information about that process is monitored by the sensor, and sent to the server for correlation and presentation.  The server can be maintained by the Kyrus guys, or it can be maintained within your infrastructure.  If you choose to maintain the server yourself, that's fine...it just means that you're going to need to have someone work with the tool, get familiar with it, and monitor it.

Getting Cb set up is easy.  The process of generating a license and getting the necessary sensor from the guys at Kyrus was simple, straightforward, and very quick.  From there, I rolled out the first sensor to a Windows XP VM that I set up as a guest on the Windows 7 host system via VMPlayer.  Shortly after installing the sensor on the target system, I began seeing events populating the dashboard, just like what I saw in the demo I attended in July.  I even began doing things on the system that one might expect to see being done during the recon phase of an incident, such as running some native tools to start mapping the network just a bit.  My "infrastructure" is a bit limited, but I got to see the Cb functionality first hand.

It's clear that a great deal of thought and effort has gone into the creating Cb, as well as structuring the interface, which is accessible via a browser.  I found that the interface and functionality is far more intuitive that other, similar tools I've seen, and in very short order, I was able to narrow down the information I wanted, based on my experience as an incident responder.

That's another thing I like about Cb...I can use the experience I've developed as an incident responder to get timely answers, and I don't have to learn someone else's framework or methodology.  For example, I look at the dashboard and see a "suspicious" process...in this case, I'd run "ipconfig /all" on the XP VM system...and all I have to do is click on an icon to see the parent process (in this case, cmd.exe).  I could also see loaded modules and files that had been modified.  I could even get a copy of the new executable that was 'seen' by the sensor.  Future enhancements to the sensor include monitoring of network connections and Registry keys.

All of this is very reminiscent of the demo...consider a "normal" incident involving a browser drive-by or some phishing attack against an employee.  Having Cb installed before an incident is the key, as it would allow a responder to very quickly navigate through the interface and once a suspicious process is located (based on a time hack, process name, or in the near future, network connection...), the responder can quickly identify the parent process or any child processes.  So why is this so special?  Well, most times for me, as a responder, I don't get called until after an incident occurs...which means processes have long since run and exited, and there may even have been efforts to clean up (ie, files deleted, etc.).  However, with Cb, there would still be a history of process execution, copies of the EXEs, etc.  In the case of July's demo, there were three stages to the attack, the first two of which launched and exited once their work was complete.  Further, of the three EXEs, AV detection of each was spotty, at best.

Having something like Cb deployed in your environment before an incident occurs is really the best way to approach not just using tools like this, but incident response in general.  In addition, Cb has a range of other uses...just ask the Kyrus guys for their case studies and stories, particularly the one about the CIO who used Cb to save thousands of dollars on Office licenses, based on actual, hard data (Deming, anyone?).

Cb is also a valuable tool to deploy during an incident...it's like sending out a bunch of lightweight little LP/OPs (listening or observation posts) to cast a wide net for data collection and correlation.  Under normal conditions, responders need to start taking systems down or performing live acquisitions, and then start analyzing those acquisitions, along with log files, network captures, etc., in order to begin scoping the incident and identify other systems that need to be acquired and analyzed.  Deploying Cb could (depending upon the type of incident) provide more information in a quicker manner, and require fewer resources (ie, fewer analysts/responders to send on-site, pay for travel, lodging, etc.), and reduce the overall impact on your infrastructure.  Deploying Cb in conjunction with F-Response would REALLY up your game to a whole new level.

Carbon Black is a tool that should be in your arsenal, as it changes the dynamics of incident response, in favor of the targets and responders, and takes away a lot of the advantages currently enjoyed by intruders.  If you have an infrastructure of any size, you should be calling the Kyrus guys.  It's not just large infrastructures that are being targeted...don't believe me?  Spend a rainy Sunday reading through Brian Krebs' blog, and then, if you can stop crying, look me straight in the eye and tell me sincerely that you're below the bad guy's radar.

In my experience as a responder, when a call came in, we'd start collecting information, not only about the incident, but we'd also have to get information from the customer that we'd use to populate the contract, so we'd have a couple of things going on in parallel.  Even so, it would still take us some time to get on-site (6 hrs, sometimes out to 3 or more days...), and then we'd have to start collecting data.  Even though we'd asked for network device and firewall logs to be collected, in some cases, it was only as a result of the incident itself that the customer found out that, "hey, wait a minute, what do you mean we aren't logging on the firewall (or web server)?"  I've had only one instance where I showed up and some data had actually been collected...in every other instance, when an incident occurred, the customer was completely unprepared and we didn't start collecting data until someone got on-site. 

Think about that, as well as any other incidents you may have encountered, for just a moment.  Now, imagine what it would be like if the customer who called you already had a contract and a relationship in place, and you'd helped them install Cb.  With the contract already set up, that's one thing you don't have to deal with...and with Cb rolled out, data is already being collected.  So, while they're on the phone, you can begin to assist them, or you could VPN into their infrastructure and access the Cb server yourself.  If a team needs to be deployed to assist, then you're already collecting information (if you have F-Response rolled out or the local IT staff has the training, memory and images may also be collected) even before the responders are able to get airline tickets!

Cb is like Burger King for IR...have it your way!

Book Review
Ken Pryor posted a review of Windows Registry Forensics over on his blog...I greatly appreciate the effort folks put into these reviews.  Thanks, Ken, for taking the time to read the book and put your thoughts into a blog post!

If you're thinking about purchasing the book, take a look at Ken's review or any of the reviews on the Amazon site.  I've also been fielding questions, which come in from time to time.

Book Sales Numbers
Speaking of books, I was able to get sales numbers for foreign language editions of Windows Forensic Analysis; of the two editions, the book has been translated into Chinese, French, and most recently Korean.  The numbers may be a bit off, as it took Elsevier (thanks, btw...) some time to get the numbers, but here's how the books are doing so far:

Chinese - 4000 printed, 3281 sold to date
French -  1000 copies printed, 494 sold to date
Korean - 1000 copies printed, 700 sold to date

Pretty nifty.

DFwOST
Speaking of books, a hard copy of Digital Forensics with Open Source Tools showed up on my doorstep today!  Cory Altheide was the primary author...heck, the entire book was his idea...and I have to tell you, he did a great job!  Once, in a galaxy far, far away (actually, it was on the IBM ISS ERS team, but close enough...), I worked with Cory and saw firsthand that he's one of the most knowledgeable and capable forensicy folks I've ever worked with.  Not only is Cory REALLY smart, but he also likes beer!  Actually, I think his preference is single malt scotch...I know that sounds like some kind of personal ad but if you see him at a conference...you know what I'm sayin'! 

At first glance, the book turned our really well.  I was more interested in the formatting and how some of the images turned out more than anything else; spelling issues weren't my primary focus. The book is chock full of some really good information, and the content is mostly directed at beginners; however, I think everyone will find something useful.  For example, one of the open source tools that Cory described was the Digital Forensics Framework; I installed v1.0 on my Windows 7 analysis system today, and it fired up quite nicely (I'll be discussing DFF more in a later post).

Carbon Black
The guys over at Kyrus Tech are really moving along with Carbon Black.  If you haven't heard of this product, you really should check it out!  Cb is a lightweight sensor that monitors execution on systems, watching for new stuff being launched.

Kyrus recently sent out invitations to folks to download their latest version of Cb, and they've also set up a user forum (on Ning) for folks to engage with Kyrus and each other regarding the use of the sensor, and the resulting data.

Here's a good read on Cb vs. the RSA hack...

But Cb isn't just about security and IR...one of Kyrus' case studies involved cost reduction across an enterprise by determining how many employees were actually using the full breadth of an office application suite; by reducing the licenses in accordance with actual usage, and purchasing separate copies of the component applications for the employees who actually used them, the organization was able to realize a significant cost savings.

OMFW
Aaron Walters is back at it again!  Prior to DFRWS 2008, Aaron had the first Open Memory Forensics Workshop, and I have to say, the format was a welcome change to many of the conferences I'd attended in the past.  Having short talks followed by panels was a great way to break up the long periods of sitting and listening, and I found the format engaging and stimulating.  Even better was the technical content based on who was there and presenting...all of the big names (Aaron, Moyix/Brendan, George M. Garner, Jr., etc) in memory acquisition and analysis were there, and it looks like Aaron's planning another OMFW soon!