Thoughts on IR

Those of us in the security community like to share ideas through analogy; I'm sure that's to convey technical issues in an understandable (to others) manner.  As a former military member, there are a number models that I use and refer to in analogies, particularly when communicating to other former military members.

Along those lines, something struck me the other day...the Internet is very much like the ocean, and organizations connected to the Internet are like ships on the ocean.  For the most part, ships (and submarines) are designed to do well on the ocean, within their limitations.  However, like the Internet, there are risks involved and potentially negative events (attacks, etc.) can originate from anywhere (above, or on or below the surface of the ocean, and from any direction) at any time.  There are a lot of events that occur on the Internet all the time, and many have no effect at all on organizations, both large and small.  Some only affect smaller organizations, while larger organizations are not affected at all by these events.

However, the Internet is not the only origination point for negative events.  Devastating events can also originate internally within a ship, just as they can with an organization or company.  As such, internal and external threats are well understood by the captain, and that understanding is subsequently conveyed to the crew.  So, not only do ships have things like radar, sonar and manned watches to protect them from external threats, but there are internal monitors, as well...gauges to monitor pressure and flow rates in pipes, etc.  There are also crew members who monitor these gauges, and keep track of the state of various functions aboard the ship at all times.  Minor events can be detected and addressed early, before they become major incidents, and more significant events are detected and the appropriate individuals warned 

Another thing to consider is this...the risks of operating on the ocean are well understood, and that understanding has guided the construction of the ships themselves.  US Navy ships have, among other things, watertight compartments that can be sealed, preventing fire or flooding (the two primary threats to most ships at sea) from expanding.  For an example of this, consider the sinking of the RMS Titanic (read the first paragraph of the Collision section) versus the bombing of the USS Cole - even with a hole in the hull at the waterline, the Cole did not sink.

Even though all of these risks are understood and planned for, Navy ships still have damage control (DC) teams.  These a members of the crew with regular jobs on the ship, but they are also trained to respond effectively when an incident occurs.  That's right...most naval personnel get some training or familiarity with damage control and what it takes, but there are individuals specifically designated with DC duties.  The leaders and members of the DC teams are identified by name, and they all have specific responsibilities, and they also understand each other's responsibilities...not to critique what the other team members do, but to understand where each team member fits in the response process, and to be able to take over their role, if necessary (due to injury, etc.).  These teams have designated, pre-staged equipment and conduct regular training drills, with the idea being that a missile or torpedo strike against a ship, or even a fire breaking out in the galley, doesn't necessarily wait for the most opportune moment for the crew...as such, the DC team must be able to respond under the worst of conditions.

The purpose of the DC team is to control the situation and minimize the effect of the incident on the health and operation of the ship and its crew.  The Executive Officer (second-in-command) of the ship is usually the person responsible to the captain for the training of the DC team, while the Engineering Officer is usually designated as the damage control officer (ref).

So, where does this model fit in with today's organizations?  Do the risks of operating interconnected IT equipment appear to be understood?  Who within the organization is the DC team leader?  Who are the members of the DC team and how often do they drill?  Perhaps more importantly, what type of monitoring is in place?  Where are the gauges and who monitors them? Sure, these may be questions asked by some guy with a blog, but they're also asked by those responsible for assessing regulatory compliance, be it the PCI DSS (para. 12.9 specifies the requirement for an IR team), HIPAA, FISMA, NCUA, etc.  Further, state notification laws (what are we up to...46 states with notification laws at this point?) such as California's SB-1386 have an implication of a response capability; after all, how would questions be answered without someone getting answers?

Thoughts?  Does the DC team model fit?

OSDFC Follow-up

I had the honor and privilege of speaking at OSDFC yesterday, and wanted to provide something of a follow-up or review of how the conference went.  But first, I want to thank everyone involved in setting up and arranging the conference, as well as presenting and even just attending the conference, for making this event a real success.

This is the second time that Brian has had the conference, which is held in conjunction with a conference put on by his company, Basis Technology, for their government customers.  This year, Brian said that there were about 160 attendees, and from what I saw, we had folks from different parts of the DFIR community...private industry, public, LE, etc.  There were even international speakers and attendees.

The format of the conference was to have a series of talks in the morning, and then split off into two tracks after lunch.  After three presentations in each track, we went back to everyone meeting in one room for another presentation (from Cory Altheide), finishing up with several lightning talks.  This seemed to work very well, but having been to several conferences over the years, any presentation that's longer than 20-30 minutes and doesn't directly engage the audience is going to hit a bit of a slow-down right around the 30 minute mark.  At the end of the conference, Brian did ask some questions with respect to the format for the next year's conference, and I'll return to some thoughts on that at the end of the post.

Rather than going over each presentation that I attended individually, I want to say that they were all excellent, and I want to thank everyone...presenters as well as the organizers...for the time and effort they put into this conference.  Also, one of the things that really make these conferences a success and is often overlooked is the people within the community who, while not presenting, come to attend the conference.  Being able to interact with your peers in the community, engage and exchange ideas (or even just some jokes) is one of the biggest benefits of events like this...so a huge thanks to everyone who drove or flew in to attend the conference!  

During the conference, there were a number of presentations that mentioned JSON, from Jon Stewart discussing scripting with the TSK tools, all the way through to Cory's "Making it Rain" presentation, where he talked about browser artifacts (and we all sang "Happy Birthday" to his daughter!).  So, for what it's worth, this is likely going to be part of a LOT of examinations.

As I attended various presentations, it occurred to me that the common theme of the presentations seemed to be, "I had a problem and here's how I solved it with open source tools".  Now, this isn't specifically about using an open source tool that is already available, although there were a number of presentations that did just this (Cory Altheide of Google, and Elizabeth Schweinsberg, soon to be of Google).  There were other presentations (my own, etc.) that discussed creating something open source to solve a problem.  Like Brian said, last year's conference was a "call for frameworks", and this year's conference was an answer to that call, as a number of frameworks were described.

Now, conference format.  While I have an academic background (I earned my MSEE from NPS), I'm more of a practitioner or engineer.  There seem to be two types of folks who are drawn to conferences like this...practitioners and academics.  Now, I'm not presenting this as a division within the community, because...well...I don't see it that way.  To be honest, we need both within the community.  At the conference, we had presentations from academics who were looking at solving some pretty big problems, and I was very thankful to see them taking this on.  I really think that there is a lot of benefit in doing so.  However, when it comes to how the presentation is viewed, practitioners and academics look at things differently.  Academics ask questions about testing corpus, parallelization, and will the application scale from 4 to 64 processors.  Practitioners ask, how soon can I get this application, and will it run on the system(s) that I have in my lab?

So...Brian took a vote at the end of the conference, asking the attendees what they thought about the format for next year.  I have to say that given who attends this type of conference, it would probably be best to keep the two-track format...have a developer's track, where developers and academics can discuss developer stuff.  Keep the practitioner's track, but you don't have to keep it separate...there may be very good reason to have a developer present in both tracks, including giving a more practitioner-oriented presentation to the guys and gals in the trenches.  I think that it's important that we all come together at an event like this, even if we don't all mix all the time.

So, I'm going to throw my hat into the ring for two tracks and shorter, more narrowly-focused presentations.  I think that the shorter presentations will allow for more of them, and focusing them a bit more probably wouldn't be all that hard.

Something else that I think would be hugely beneficial is something like Cory's presentation from the first conference, where he just ran through a list of open source tools and projects, and how they were useful.  There are sights out there to maintain information like this, but they don't seem to be regularly maintained to any significant degree.  For example, there's Open Source Forensics, as well as ForensicsWiki, but as a community, I think we need to come together and come up with a way to bring all of this information together.  That aside, however, while various open source projects were discussed, there are a number of others out there that would be beneficial to many examiners, if they knew about them.  Now, this doesn't have to be a presentation, as it can be a web page or entries at one of the sites above...but I think what really gets folks over the hump regarding using this stuff is recommendations from others.

Another benefit of this conference that I hadn't realized is the reach of open source tools.  Within the US, we have various institutions, ranging from large private, academic and governmental organizations, to local community colleges and law enforcement shops.  We can all benefit from open source projects, but the smaller organizations are limited in background knowledge, training, etc.  Joshua James opened my eyes to the fact that this is an international issue...that LE in Ireland is limited by funds, as are LE in Africa.  Joshua mentioned a department in Africa that has 4 staff members and a total of 2000 Euro available annually for training, hardware, etc.  This opened me up to the need not only for open source tools that meet the needs of these departments, but to the need for free, easily available training for knowledge transfer as well as how to use the tools and really get the most out of them.

Stuff
Simson's bulk-extractor
Cory's write-up and insights on OSDFC

Updates, Links, Etc.

OSDFC
I'm slotted to speak at the Open Source Digital Forensics Conference (put on by Brian Carrier) in McLean, VA, on 14 June.  I'll be presenting on "Extending RegRipper", and I've posted to slides to the WinForensicAnalysis site.

You'll notice something a bit uncharacteristic (or me) about the presentation...I put a LOT of text in the slides.  I sorta figured I needed to do this, as when I've talked about this topic to others, I think I get a lot of head knodding and "okays" so that I'll just stop talking.  I wanted to have the text on the slides for folks to look at, so that when someone was noodling these ideas over (as opposed to deciding whether or not to stay for the rest of the presentation...), they can refer back to what's on the slides, and not have to go with, "...but you said...".

Fresh off of attending the SANS Forensic Summit, Cory Altheide will be providing training on 13 June, and speaking at OSDFC on 14 June.  Corey and I will also be available to sign your copy of DFwOST, if you'd like. 

RegRipper
Speaking of open source tools, Mark Morgan posted "Using RegRipper inside EnCase Enterprise"...jokes aside, I think that this is a great use of resources!  I mean, it wasn't part of the design of RegRipper, but hey, I think things worked out pretty well, and Mark (like others before him) found a way to get the most out of the tools he's using.  Great job!

VSCs
Stacey Edwards has a great post up over on the SANS Forensic blog that demonstrates how to extract file system metadata/MAC times from files in Volume Shadow Copies, using LogParser.  The cool thing about what she discussed is that it can all be scripted through batch files...that's right, you can have a batch file that will run through designated VSCs, mount each one, run the LogParser command against it, unmount the VSC, and move on to the next one.  Pretty cool stuff.  Think of all of the other stuff you could script into a batch file, too...like RegRipper/rip, etc. 

MetaData
Corey Harrell has another really good post over at the jIIr blog, regarding why certain document metadata could possibly look the way it does.  He's taken the time to do some testing, lay out and describe what he did, and then present it clearly.  That kind of sounds like what we all have to do in our jobs, right?  ;-)

EVTX
Andreas has updated his EVTX parser code to v1.0.8.  He's put considerable effort into figuring out the binary format for the Windows Event Logs ("new" as of Vista) and provided his open source code for parsing them.  I've also found LogParser to be very helpful with this.

NoVA Forensics Meetup
Keep 6 July on your calendar for our next meetup.  Tom Harper has graciously offered to present on setting up a dynamic malware analysis platform, so come on by, bring a friend, and join us!

Updates

DLL Search Order Issue
Nick Harbour recently put together another great, very informative post over on the Mandiant that has to do with the DLL search order issue that he'd discussed last year ("Malware Persistence without the Windows Registry").  His recent post has to do with fxsst.dll, which appears to pertain to the Fax Service.  The difference in fxsst.dll with respect to the earlier issue that Nick mentioned (re: ntshrui.dll) is that whilst ntshrui.dll was loaded directly by Windows Explorer (as an approved shell extension), fxsst.dll is actually loaded by stobject.dll (System Tray component for Windows Explorer).

The DLL search order issue is something that's been around for a while (11 years), and as Nick mentioned, allows for malware persistence without the use of the Registry.  The analysis technique that I've used to track down issues like this is timeline analysis...putting a timeline together and looking at various aspects of the incident (timeframe, files involved, etc.) has been a very revealing process, and really turned up some good information.  Nick used an interesting approach to track down how fxsst.dll was loaded...I'd suggest taking a look at what he did, and seeing where you could use a technique similar to his in your examinations.

In short, if you find a copy of fxsst.dll in the Windows or Windows\system32 directory, take a very careful look at it.  However, be sure that when you do look at it, you understand what's going on...because just because you find a file with this name on the system, it doesn't necessarily follow that the file has anything to do with the incident.

NoVA Forensics Meetup Slides
Chris has been kind enough to post his presentation slides from this month's meetup presentation.  Chris provided a lot of great information in his presentation...take a look and see what you think, and feel free to send him questions.

Jump Lists
Jump lists are something new to Windows 7, a nice little feature that appears to be similar to the Windows shortcuts in the user's Recent folder.  Here's more information about Jump Lists, and how they're used, from MS.

A while back, I was at a Microsoft cybercrime conference in Redmond, and Troy Larson mentioned during his presentation that the "old" OLE "structured storage" file structure that was used in MS Office documents prior to Office 2007 was again used in Windows 7, and one of the locations was the Jump Lists.  I made a note of it then, but really hadn't pursued it.  As I've been using Windows 7 more and  more, and looking into forensic artifacts, I thought I'd take a look at them.  Troy had also mentioned that not only did the Jump Lists make use of the OLE "structured storage" mechanism, but the streams within the "file system within a file" were based on the shortcut/LNK file format, so that was something to go on...

ProDiscover v6.11 (I use the IR edition) has a Jump List viewer, and over on the Win4n6 list, Rob Lee said that he uses MiTeC's Structured Storage Viewer and a Windows shortcut/LNK file viewer (MiTeC WFA) to parse the Jump List information.

I used code from wmd.pl and lslnk2.pl to develop a Perl script to parse Jump Lists.  Wmd.pl uses the OLE::Storage module, and lslnk2.pl is completely Perl-based, using no Win32-specific modules, but instead parses the LNK file information on a binary level based on the shortcut file format. I've just got the code working, so it's not ready for prime time, and I still have to figure out how I want to display the information.  I'm considering the TLN format as one means of displaying the information, using something similar to how I recently updated/modified regtime.pl and rip.pl...maybe .csv will be an option, as well.

Addendum:  Using this resource from MS, I was able to identify and parse the ExtraData blocks, and extract the NetBIOS name of the system from the TrackerDataBlock. 


Tools

I ran across this one by accident recently...I'm not really a *nix person (and I don't claim to be), and haven't made wide use of awk, but I thought that this post on using awk to address clock skew in the regtime bodyfile output was worth sharing.  Clock skew on a system, as well as between systems, are definitely an issue when performing analysis, particularly if you're putting things into timelines.  At the OSDFC conference last year, I talked about timelines, and was informed (not asked, but told...) that my technique for developing timelines did not allow for clock skew...and that simply isn't/wasn't the case (dude, it's open source...).  My point is that things like time zones and clock skew are very important when it comes to performing analysis on multiple systems, particularly when they're geographically dispersed.


News
I had posited a bit ago when something like this would happen...the Unveillance CEO faced extortion (JadedSecurity has a different take on the matter).  I added this to this post, as this is something I discussed with others recently via email, and the results were pretty much what they'd suggested would happen...

Updates

NoVA Forensics Meetup
Last night's meetup, our second such get-together, was a rousing success!   Chris Witter gave a great presentation that covered a lot of the different aspects of building a packet capture engine "on da cheap", and all told, we had a total of 38 attendees!

*For those interested, there's a new version of Wireshark available.

I think that we're doing well enough to begin working on a format for these events, so that's something I'll be coming up with for the next meetup (on 6 July).  I think that pretty much what things will look like is an intro, then have everyone go around and introduce themselves, and then we'll kick the presentation off around 7:30pm.  This will give a bit more time for folks to show up.

Also, it might be a good idea to have two shorter talks, as opposed to one presentation...perhaps not every time, but every now and again.  Maybe something like a demo of a very specific tool or technique that you can present in about 20 min or so.

Finally, I'd like to ask everyone to take a moment and think about what they might like to hear about in a presentation, or a topic for a presentation that they'd be willing to give.  Also, try to think of a question or two that you might have for the group...we had a very diverse group of folks at last night's meeting, ranging from very experienced DFIR folks to IT staff and folks who are very new to the industry.

So...a big thanks to everyone who attended last night...we hope to see you again, and hey...bring a friend!  And a huge thanks to Christopher for stepping up and giving an excellent presentation!

DFwOST Reviews
If you're on the fence regarding purchasing "Digital Forensics with Open Source Tools", take a look at these reviews on Amazon.  They're all pretty glowing, and there's even one from a "shark tamer" (is that even possible??).


Upcoming Speaking Events
I have a couple of opportunities for speaking coming up over the next months (and I'll be submitting to other CfPs), and I find myself making some changes to how I'm going to be presenting the material in question.

My next speaking engagement is OSDFC on 14 June; I will be giving a presentation entitled "Extending RegRipper".  As I've been preparing the presentation, I'm finding that I'm putting more text into the slides than I normally would, but I think that under the circumstances, that makes pretty good sense.  After all, what I'm talking about in the presentation is kind of new; after all, I've found (not surprisingly) that there are a good number of forensic analysts that have neither heard of nor used RegRipper, and I'm talking about extending the tool into a forensic scanner framework (which is, itself, a little something different).  I don't usually read from my slides, but I this case, I think that it's important to put the actual text on the screen so that attendees can see it, read it, and marinate on it.  I still plan to do a good deal of discussion and delve into things not explicitly listed in the slides (unfortunately, the set up doesn't allow for a demo...), but my hope is that by putting some of the explicit text in the slides, this will ultimately generate some discussion.

I'm also giving a presentation in August on timeline creation and analysis; similar to the above presentation, this one is going to have some slides in it that contain a good deal of text, but again, I think that there's a very good reason for doing this; some of the things I talk about in the presentation may be somewhat new to many attendees.  As such, I'd like to have certain things phrased in an explicit manner, so that when (not "if"...) discussion ensues, and someone says, "But you said...", we can go right back to the slide and address the question.  Also, I feel like I'd like to have the statement(s) being discussed sitting up there for folks to refer back to during the discussion, so that it has a better chance of crystallizing in their minds.  While I prefer the "hit-and-run" tactic of just having bullet statements (or not even using slides at all), there are really some things that are important enough to not only have explicitly stated on the slides, but to also include in the slide pack for later reference.

Blogs
I've run across a couple of interesting blogs recently.  For example, the guys at Crucial Security still have a blog up and running, even though they're now part of Harris Corp.  There are a couple of very useful posts to this blog, such as this one regarding VM files essential for forensic investigations.  There's also this one regarding malware issues from an operational perspective...which, IMHO, would be far more useful when tied in with malware characteristics.

I've found the Girl, Unallocated blog to be a good read, and I have to say, I've really enjoyed the slant the author takes on some of the topics she presents in her posts.  Sometimes it's good to be less serious, even while remaining on-point...taking a whimsical approach can be a good thing at times.  I have also found some of her posts thought-provoking, such as this one on structured analysis...I've often heard forensicators state, "...sometimes we don't know what we're looking for...", and I have to say, that's bull.  No one just acquires images from systems at random, so when a system is acquired, there's a reason for it, and that reason can lead us to what we're looking for, or trying to prove or disprove.

NoVA Forensic Meetup

Reminder: NoVA Forensic Meetup, Wed, 1 June, at the ReverseSpace location in Herndon (7pm - 8:30pm)

Tools

I've run across a number of tools recently, some directly related to forensics, and others more related more to IR or RE work. I wanted to go ahead and put those tools out there, to see what others think...

Memory Analysis
There have been a number of changes recently on the memory analysis front.  For example, Mandiant recently released their RedLine tool, and HBGary released the Community Edition of their Responder product. 

While we're on the topic of memory analysis tools, let's not forget the erstwhile and formidable Volatility.

Also, if you're performing memory dumps from live systems, be sure to take a look at the MoonSol Windows Memory Toolkit.

SQLite Tools
CCL-Forensics has a trial version of epilog available download, for working with SQLite databases (found on smartphones, etc.).  One of the most noticeable benefits of epilog is that it allows you to recover deleted records, which can be very beneficial for analysts and investigators.

I'm familiar with the SQLite Database Browser...epilog would be interesting to try.

MFT Tools
Sometimes you need a tool to parse the NTFS $MFT file, for a variety of reasons.  A version of my own mft.pl is available online, and Dave Kovar provided his analyzemft.pl tool online, as well.  Mark McKinnon has chimed in and provided MFT parsing tools for Windows, Linux, and MacOSX.

Other Tools
HBGary also made their AcroScrub tool available, which uses WMI to reach across the enterprise and scan for older versions of Adobe Reader.

A very interesting tool that I ran across is Flash Dissector.  If you deal with or even run across SWF files, you might want to take a look at this tool, as well as the companion tools in the SWFRETools set.

The read_open_xml.pl Perl script is still available for parsing metadata from Office 2007 documents.

From the same site as the SWFRETools are some malware write-ups including NiteAim, and Downloader-IstBar.  As a complete aside, here's a very interesting Gh0stNet writeup that Chris pointed me to recently (fans of Ron White refer to him as "Tater Salad"...fans of Chris Pogue should refer to him as "Beefcake" or "Bread Puddin'"...).

ADSs
Alternate data streams isn't something that you see discussed much these days.  I recently received a question about a specific ADS, and thought I'd include some tools in this list.  I've used Frank's LADS, as well as Mark's streams.exe.  Scanning for ADSs is part of my malware detection process checklist, particularly when the goal of the analysis is to determine if there's any malware on the system.

Also, I ran across this listing at MS of Known Alternate Stream Names.  This is some very useful information when processing the output of the above tools, because what often happens is that someone uses one of the above tools and finds one of the listed ADSs, and after the panic that ensues, their attitude switches back to the other side of the spectrum, to apathy...and that's when they're most likely to get hit.

Here are some additional resources from Symantec, IronGeek, and MS. Also, be sure to check out what I've written about these in WFA 2/e.


Scanners

Microsoft recently released their Safety Scanner, which is a one-shot micro-scanner...download it, run it, and it expires after 10 days, and then you have to download it again.  This shouldn't replace the use of Security Essentials or other AV tools, but I'm pointing this out because it could be very useful when included as part of your malware detection process.  For example, you could mount an acquired image via FTK Imager or ImDisk and scan the image.  Also, the folks at ForensicArtifacts recently posted on accessing VSCs (their first research link actually goes back to my post by the same title...thanks to AntiForensics for reposting the entire thing...)...without having to have EnCase or PDE, you could easily scan the mounted VSC, as well.


Frameworks
The Digital Forensics Framework (DFF) is open source, and was recently updated to include support for the AFF format, as well as mailbox reconstruction via Joachim Metz's libpff.

Christopher Brown, of TechPathways, has made ProDiscover Basic Edition v6.10.0.2 available, as well.  As a side note, Chris recently tweeted that he's just finished the beta of the full version of ProDiscover, adding the ability to image and diff VSCs.  Wowzers!

Sites
TZWorks - free "prototypes" tools, including the Windows Shellbags parser, an EVTX file parser, and others.  Definitely worth checking out.

WoanWare - several free forensics tools including a couple for browser forensics, and (like TZWorks) a "USBStor parser".

NirSoft - the link to the site goes to the forensics tools, but there are a lot of free tools available at the NirSoft site...too many to list.

The Open Source Digital Forensics site is a good source of tools, as well.

OSDFC
Speaking of tools, let's not forget that the OSDFC is right around the corner...

Addendum
Check out Phil Harvey's EXIFTool (comes with a standalone Windows EXE)...there's a long list of supported file types at the tool page.

Additional lists of tools include Mike's Forensic Tools, as well as the tools at MiTeC (thanks to Anonymous' comment).  Also, Mark McKinnon has posted some freely available tools, as well.

Brain Droppings

NoVA Forensics Meetup
The next NoVA Forensics Meetup will be held on Wed, 1 June 2011, from 7-8:30pm.  As to a location, I met with the great folks at Reverse Space, a hacker space in Herndon where some of the folks have an interest in forensics.  Thanks to Carl and Richard for taking the time to meet with me, and for offering to host our meetings.

I hope that we get a big turn-out for our currently scheduled presentation, titled "Build your own packet capture engine".

Our meetup in July will be scheduled for Wednesday, 6 July, and we've already got an offer of a presentation regarding setting up virtual machines to use for dynamic malware analysis.

As to further topics, I'd like to get suggestions regarding how we can expand our following; for example, Chris from the NoVA Hackers group told me that they follow the AHA participation model.  I'd like the development of this group to be a group effort, and as such will be asking participants and attendees for thoughts, ideas, comments (and to even volunteer their own efforts) regarding how this group can expand.  For example, do we need a mailing list or is the Win4n6 Group sufficient?  If you have anything that you'd like to offer up, please feel free to drop me a line.



Breakin' In
Speaking of the NoVA Forensics Meetup, at our last meeting, one of our guests asked me how to go about getting into the business.  I tried to give a coherent answer, but as with many things, this question is one of those that have been marinating for some time,  not just in my brain housing group, but within the community.

From my own perspective, when interviewing someone for a forensics position, I'm most interested in what they can do...I'm not so much interested that someone is an expert in a particular vendor's application.  I'm more interested in methodology, process, what problems have you solved, where have you stumbled and what have you learned.  In short, are you tied to a single application, or do you fall back to a process or methodology?  How do you go about solving problems?  When you do something in particular (adding or skipping a step in your process), do you have a reason for doing so?

But the question really goes much deeper than that, doesn't it?  How does one find out about available positions and what it really takes to fill them?  One way to find available positions and job listings is via searches on Monster and Indeed.com.  Another is to take part in communities, such as the...[cough]...NoVA Forensics Meetup, or online communities such as lists and forums.

Breaches
eWeek recently (6 May) had an article regarding the Sony breach available, written by Fahmida Rashad, which started off by stating:

Sony could have prevented the breach if they’d applied some fundamental security measures...

Sometimes, I don't know about that.  Is it really possible to say that, just because _a_ way was found to access the network, that including these "fundamental security measures" would have prevented the breach?

The article went on to quote Eugene Spafford's comments that Sony failed to employ a firewall, and used outdated versions of their web server.  'Spaf' testified before Congress on 4 May, where these statements were apparently made.

Interestingly, a BBC News article from 4 May indicates that at least some of the data stolen was from an "outdated database".   

The eWeek article also indicates (as did other articles) that Data Forte, Guidance Software and Protiviti were forensics firms hired to address the breach.

As an aside, there was another statement made within the article that caught my interest:

“There are no consequences for many companies that under-invest in security,” Philip Lieberman, CEO of Lieberman Software, told eWEEK. 

As a responder and analyst, I deal in facts.  When I've been asked to assist in breach investigations, I have done so by addressing the questions posed to me through analysis of the available data.  I do not often have knowledge of what occurred with respect to regulatory or legislative oversight.  Now and again, I have seen news articles in the media that have mentioned some of the fallout of the incidents I've been involved with, but I don't see many of these.  What I find interesting about Lieberman's statement is that this is the perception.

The Big Data Problem
I read a couple of interesting (albeit apparently diametrically opposed) posts recently; one was Corey Harrell's Triaging My Way (shoutz to Frank Sinatra) post where Corey talked about focusing on the data needed to answer the specific questions of your case.  Corey's post provides an excellent example of a triage process in which specific data is extracted/accessed based on specific questions.  If there is a question about the web browsing habits of a specific user, there are a number of specific locations an analyst can go within the system to get information to answer that question.

The other blog post was Marcus Thompson's We have a problem, part II post, which says, in part, that we (forensic analysts) have a "big data" problem, given the ever-increasing volume (and decreasing cost) of storage media.  Now, I'm old enough to remember when you could boot a computer off of a 5 1/4" floppy disk, remove that disk and insert the storage disk that held your documents...before the time of hard drives that were actually installed in systems.  This dearth of storage media naturally leads to backlogs in analysis, as well as intelligence collection.

I would suggest that the "big data" problem is particularly an issue in the face of the use of traditional analysis techniques.  Traditional techniques applied to Corey's example (above) states that all potential sources of media must be collected, and keyword searches run.  Wait...what?  Well, no wonder we have backlogs!  If I'm interested in a particular web site that the user may have visited, why would I run a keyword search across all of the EXEs and DLLs in the system32 directory?  While there may be files on the 1TB USB-connected external hard drive, what is the likelihood that the user's web browser history is stored there?  And why would I examine the contents of the Administrator (or any other) account profile if it hasn't been accessed in two years?

Another variant on this issue was discussed, in part, in Mike Viscuso's excellent Understanding APT presentation (at the recent AccessData User's Conference)...the presentation indicates that the threat isn't really terribly "advanced", but mentions that the threat makes detection "just hard enough".

Writing Open Source Tools
This is a topic that came up when Cory and I were working on DFwOST...Cory thought that it would be a good section to add, and I agreed, but for the life of me, I couldn't find a place to put it in the book where it just didn't seem awkward.  I still think that it's important, in part because open source tools come from somewhere, but also because I think that a lot more folks out there really have something to contribute to the community as a whole.

To start off, my own motivation for writing open source tools is to simply solve a problem or address something that I've encountered.  This is where RegRipper came from...I found that I'd been looking at many of the same Registry keys/values over and over again, and had built up quite a few scripts.  As such, I wanted a "better" (that's sort of relative, isn't it??) to manage these things, particularly when there was so many, and they seemed to use a lot of the same code over and over.

I write tools in Perl because it's widely available and there a LOT of resources available for anyone interested in learning to use it...even if just to read it.  I know the same is true for Python, but back in '98-'99 when I started teaching myself Perl, I did so because the network monitoring guys in our office were looking for folks who could write Perl, and infosec work was as hard for folks to sell back then as forensic analysis is now.

When I write Perl scripts, I (in most cases) try to document the code enough so that someone can at least open the script in Notepad and read the comments to see what the script does.  I don't always try for the most elegant solution, reducing the number of keystrokes to accomplish a task, as making the steps available not only lets someone see more clearly what was done, but it also lets someone else modify the code to meet their needs...simply comment out the lines in question and modify the script to meet your own needs.

DFF
Speaking of open source tools, one of the tools discussed in DFwOST is the Digital Forensics Framework, of which version 1.1.0 was recently released.  This version includes a couple of updates, as well as a bug fix to the ntfs module.  I've downloaded it and got it running nicely on a Windows XP system...great work and a huge thanks to the DFF folks for their work.  Be sure to check out the DFF blog for some tips on how you can use this open source forensic analysis application.

Updates

NoVA Forensics Meetup
Last night's meetup went pretty well...there's nothing wrong with humble beginnings.  We had about 16 people show up, and a nice mix of folks...some vets, some new to the community...but it's all good.  Sometimes having new folks ask questions in front of those who've done it for a while gets the vets to think about/question their assumptions.  Overall, the evening went well...we had some good interaction, good questions, and we gave away a couple of books. 

I think that we'd like to keep this on a Wed or Thu evening, perhaps once a month...maybe spread it out over the summer due to vacations, etc. (we'll see).  What we do need now is a facility with presentation capability.  Also, I don't think that we want to have the presentations fall on just one person...we can do a couple of quick talks of a half hour each, or just have someone start a discussion by posing a question to the group.

Besides just basic information sharing, these can be good networking events for the folks who show up.  Looking to add to your team?  Looking for a job?  Looking for advice on how to "break in" to the business?  Just come on by and talk to folks.

So, thanks to everyone who showed up and made this first event a success.  For them, and for those who couldn't make it, we'll be having more of these meetups...so keep your eyes out and don't hold back on the thoughts, comments, or questions.


Volatility
Most folks familiar with memory analysis know about the simply awesome work provided through the Volatility project.  For those who don't know, this is an open source project, written in Python, for conducting memory analysis.

Volatility now has a Python implementation of RegRipper built-in, thanks to lg, and you can read a bit more about the RegListPlugin.  Gleeda's got an excellent blog post regarding the use of the UserAssist plugin.

I've talked a bit in my blog, books, and presentations about finding alternate sources of forensic data when the sources we're looking for (or at) may be insufficient.  I've talked about XP System Restore Points, and I've pulled together some really good material on Volume Shadow Copies for my next book.  I've also talked about carving Event Log event records from unallocated space, as well as parsing information regarding HTTP requests from the pagefile.  Volatility provides an unprecedented level of access to yet another excellent resource...memory.  And not just memory extracted from a live running system...you can also use Volatility to parse data from a hibernation file, which you may find within an (laptop) image.  Let's say that you're interested in finding out how long that system has been compromised; i.e., you're trying to determine the window of exposure.  One of the sources I've turned to is crash dump logs...these are appended (the actual crash dump file is overwritten) with information about each crash, and include a pslist-like listing of processes.  Sometimes you may find references to the malware in these listings, or in the specific details regarding the crashing process.  Now, assume that you're looking at a laptop, and find a hibernation file...you know when the file was created, and using Volatility, you can parse that file and find specifics about what processes were running at the time that the system went into hibernation mode.

And that's not all you can use Volatility for...Andre posted to the SemperSecurus blog about using Volatility to study a Flash 0-day vulnerability. 

If you haven't looked at Volatility, and you do have access to memory, you should really consider diving in and giving it a shot.  

Best Tool
Lance posted to his blog, asking readers what they consider to be the best imaging and analysis tools.  As of the time that I'm writing this post, there are seven comments (several are pretty much just "agree" posts), and even reading through some of the thoughts and comments, I keep coming back to the same thought...that the best tool available to an analyst is that grey matter between their ears.

This brings to mind a number of thoughts, particularly due to the fact that last week I had two opportunities to consider some things for topics of analyst training, education and experience...during one of these opportunities, I was considering the fact that when I (like many other analysts) "came up through the ranks", there were no formal schools available to non-LE analysts, aside from vendor-specific training.  Some went that route, but there were others who couldn't afford it.  For myself, I took the EnCase v.3.0 Introductory course in 1999...I was so fascinated by the approach taken to file signature analysis that I went home and wrote my own Perl code for this; not to create a tool, per se, but more to really understand what was happening "under the hood".  Over the years, knowing how things work and knowing what I needed to look for really helped me a lot...it wasn't a matter of having to have a specific tool as much as it was knowing the process and being able to justify the purchase of a product, if need be.

Breaches
If the recent spate of breaches hasn't yet convinced you that no one is safe from computer security incidents, take a look at this story from The State Worker which talks about the PII/PCI data of 2000 LE retirees being compromised.  I know, 2000 seems like such a small number, but hey...regardless of whether its 77 million or 2000, if you're one of those people who's data was compromised, it's everything.

While the story is light on details (i.e., how the breach was identified, when the IT staff reacted in relation to when the incident actually occurred, etc.), if you read through the story, you see a statement that's common throughout these types of announcements; specifically, "...taken steps to enhance security and strengthen [the] infrastructure...".  The sequence of events for incidents like this (and keep in mind, these are only the ones that are reported) is, breach, time passes, someone is notified of the breach, then steps are taken to "enhance security".  We find ourselves coming to this dance far too often.

Incident Preparedness
Not long ago, I talked about incident preparation and proactive IR...recently, CERT Societe Generale (French CERT) posted a 6 Step IRM Worm Infection cheat sheet. I think that things like this are very important, particularly when the basic steps necessarily assume certain things about your infrastructure.  For example, look at step 1 of PDF includes several of the basic components of a CSIRP...if you have all of the stuff outlined in the PDF already covered, then you're almost to a complete CSIRP, so why not just finish it off and formalize the entire thing?

Step 3, Containment, mentions neutralizing propagation vectors...incident responders need to understand malware characteristics in order to respond effectively to these sorts of incidents.

One note about this, and these sorts of incidents...worms can be especially virulent strains of malware, so this applies to malware in general...relying on your AV vendor to be your IR team is a mistake.  Incident responders have seen this time and again, and it's especially difficult for folks who do what I do, because we often get called after response efforts via the AV vendor have been ineffective, and have exhausted the local IT staff.  I'm not saying that AV vendors can't be effective...what I am saying is that in my experience, throwing signature files at an infrastructure based on samples provided by on-site staff doesn't work.  AV vendors are generally good at what they do, but AV is only part of the overall security solution.  Malware infections need to be responded to with an IR mindset, not through an AV business model.

Firefighters don't learn about putting out a fire during a fire.  Surgeons don't learn their craft during surgery.  Organizations shouldn't hope to learn IR during an incident...and the model of turning your response over to an external third party clearly doesn't work.  You need to be ready for that big incident...as you can see just from the media, it's a wave on the horizon headed for your organization.

NoVA Forensic Meet-Up

I've scheduled a room at the Reston Public Library on Wed, 4 May 2011, for the first NoVA Forensic Meet-Up.  We're scheduled for 7pm to 8:30pm, in meeting room 1.

I'll be talking about the presentation I'll give at the OSDF Conference in June, specifically, "Extending RegRipper".

Due to the short time frame, I'll try to put together and post some slides or something, but if not, it's pretty easy to do a discussion format.

Hope to see you there!

Addendum (1 May): I uploaded the presentation (in PDF) that I'll be working from; the library doesn't have any projection capabilities in the room we've reserved, so be sure to download a copy of the PDF before you come on out.

Proactive IR

There are a couple of things that are true about security, in general, and IR specifically.  One is that security seems to be difficult for some folks to understand (it's not generally part of our culture), so those of us in the industry tend to use a lot of analogies in an attempt to describe things to others that aren't in our area of expertise.  Sometimes this works, sometimes it doesn't.

Another thing that's true is that the current model for IR doesn't work  For consulting companies, it's hard to keep a staff of trained, dedicated, experienced responders available and on the bench, because if they sit unused they get pulled off into other areas (because those guys "do security stuff") and like many areas of information security (web app assessments, pen testing, malware RE, etc.) the hard-core technical skills are perishable.  Most companies that need such skills simply don't keep these sorts of folks around, as they look to consulting companies to provide this service.

Why doesn't this work?  Think about it this way...who calls emergency incident responders?  Well, those who need emergency incident response, of course.  Many of us who work (or have worked) as incident responders know all too well what happens...the responders show up, often well after the incident actually occurred, and have to first develop an understanding of not just what happened (as opposed to what the customer thinks may have happened), but also "get the lay of the land"; that is, understand what the network infrastructure "looks like", what logs may be available, etc.  All of this takes time, and that time means that (a) the incident isn't "responded to" right away, and (b) the clock keeps ticking as far as billing is concerned.  Ultimately, what's determined with respect to the customer's needs really varies; in fact, the questions that the customer had (i.e, "what data left our network?") may not be answered at all.

So, if it doesn't work, what do we do about this?  Well, the first thing is that a cultural shift is needed.  Now, follow me here...all companies that provide a service or product (which is pretty much every one of them) have business processes in place, right?  There's sales, customer validation, provisioning and fulfillment, and billing and collections...right?  Companies have processes in place (documented or otherwise) for providing their product or service to customers, and then getting paid.  Companies also have processes in place for hiring and paying employees...because without employees to provide those products or services, where would you be?

Ever since I started in information security, one of the things I've seen across the board is that most companies do not have information security as a business process.  Companies will process, store and manage all manner of sensitive data...PCI, PHI, PII, critical intellectual property, manufacturing processes and plans, etc...and not have processes for protecting that data, or responding to incidents involving the possible exposure or modification of that data.

Okay, how about those analogies?  Like many, I consider my family to be critical, so I have smoke alarms in my home, fire extinguishers, we have basic first aid materials, etc.  So, essentially, we measures in place to prevent certain incidents, detect others, and we've taken steps to ensure that we can respond appropriately to protect those items we've deemed "critical".

Here's another analogy...when I went to my undergraduate education, we were required to take boxing.  If you're standing in a class and see everyone in line getting punched in the face because they don't keep their gloves up, what do you do?  Do you stand there and convince yourself that you're not going to get punched in the face?  When you do get punched in the face because  you didn't keep your gloves up, do you blame the other guy ("hey, dude! WTF?!?!") or do you accept responsibility for getting punched in the face?  Or, do you see what's happening, realize that it's inevitable, listen to what you're being told, and develop a culture of security and get your gloves up?  The thing about getting punched in the face is no matter what you say or do afterward, the fact remains...you got punched in the face.

Here's another IRL example...I recently ran across this WaPo article that describes how farms in Illinois are pre-staging critical infrastructure information in an easily accessible location for emergency responders; the intention is to "prevent or reduce property damage, injuries and even deaths" in the event of an incident.  Variations of the program have reportedly been rolled out in other states, and seem to be effective.  What I find interesting about the program is that in Illinois, aerial maps are taken to each farm, and the farmers (those who established, designed, and maintain the infrastructure) assist in identifying structures, etc.  This isn't a "here's $40K, write us a CSIRP"...instead, the farmer has to take some ownership in the process, but I guess they do that because a 1 hour or one afternoon interview can mean the difference between minor damage and loosing everything.

Sound familiar?

As a responder, I'm aware of various legislation and regulatory bodies that have mandated the need for incident response capabilities...Visa PCI, NCUA, etc.  States have laws for notification in the case of PII breaches, which indirectly require an IR capability.  Right now, who's better able to respond to a breach...local IT staff who know and work in the infrastructure every day (and just need a little bit of training in incident response and containment) or someone who will arrive on-site in anywhere between 6 and 72 hours, and will still need to develop an understanding of your infrastructure?

If the local IT staff knew how to respond appropriately, and was able to contain the incident and collect the necessary data (because they had the training and tools, and processes for doing so), analysis performed by that trusted third party adviser could begin much sooner, reducing response time and overall cost.  If the local IT staff (under the leadership of a C-level executive, like the farmer) were to take steps to prepare for the incident...identify and correct shortfalls in the infrastructure, determine where configuration changes to systems or the addition of monitoring would assist in preventing and detecting incidents, determine where critical data resides/transits, develops a plan for response, etc...just as is mandated in compliance requirements, then the entire game would change.  Incidents would be detected by the internal staff closer to when they actually occur...rather than months later, by an external third party.  Incident response would begin much quicker, and containment and scoping would follow suit.

Let's say you have a database containing 650K records (PII, PCI, PHI, whatever).  According to most compliance requirements, if you cannot explicitly determine which records were exposed, you have to report on ALL of them.  Think of the cost associated with that...direct costs of reporting and notification, followed by indirect costs of cleanup, fines, lawsuits, etc.  Now, compare that to the cost of doing something like having your DBA write a stored procedure (includes authorization and logging) for accessing the data, rather than simply allowing direct access to the data.

Being ready for an incident is going to take work, but it's going to be less costly in the long run when (not if) an incident occurs.

What are some things you can do to prepare?  Identify logging sources, and if necessary, modify them appropriately (add Process Tracking to your Windows Event Logs, increase logs size, set up a means for centralized log collection, etc.).  Develop and maintain accurate network maps, and know where your critical data is located.  The problem with hiring someone to do this for you is that you don't have any ownership; when the job's done, you have a map that is an accurate snapshot, but how accurate is it 6 months later?  Making incident detection and tier 1 response (i.e., scoping, data collection) a business process, with the help of a trusted adviser, is going to be quicker, easier and far less costly in the long run, and those advisers will be there when you need the tier 3 analysis completed.

What about looking at things like Carbon Black?  Cb has a number of uses besides just IR, and can help you solve a number of other problems.  However, with respect to IR, it can not only tell you what was run and when, but it can keep a copy of it for you...so when it comes to determining the capabilities of the malware downloaded to your system, you already have a copy available; call that trusted adviser and have them analyze it for you.

Remember the first Mission: Impossible movie?  After his team was wiped out, Ethan made it back to the safe house and as he reached the top of the stairwell, took the light bulb out of the socket and crushed it in his jacket, then spread the shards on the floor as he backed toward his room.  What this does is provide a free detection mechanism...anyone approaching the room isn't going to know that the shards are their until they step on them and alert Ethan to their presence; incident detection.

So what are you going to do?  Wait until an incident happens, or worse, wait until someone told you that an incident happened, and then call someone for help?  You'll have to find someone, sign contracts, get them on-site, and then help them understand your infrastructure so that they can respond effectively.  When they're first there, you're not going to trust them (they're new, after all) and you're not going to speak their language.  In most cases, you're not going to know the answer to their questions...do we even have firewall logs?  What about DHCP...do we log that?  What will happen is that you will continue to hemorrhage data throughout this process.

The other option is to have detection mechanisms and a response plan in place and tested, and have  a trusted adviser that you can call for assistance.  Your local IT staff needs to be trained to perform the initial response, scoping and assessment, and even containment.  While the IT director is on the phone with that trusted adviser, designated individuals are collecting and preserving data...because they know where it is and how to get it.  The questions that the trusted adviser (or any other consulting firm) would ask are being answered before the call is being made, not afterward ("Uh...we had no idea that you'd ask that...").  That way, you don't loose the whole farm, and if you do get punched in the face, you're not knocked out.

By the way...one final note.  This doesn't apply solely to large companies.  Small business are loosing money hand over fist and some are even going out of business...you just don't hear about it as much.  These same things can be done inexpensively and effectively, and need to be done.  The difference is, do you get it done, even if you have to have a payment plan, or do you sit by and wait for an incident to put you out of business and lay off your employees?

Extending RegRipper (aka, "Forensic Scanner")

I'll be presenting on "Extending RegRipper" at Brian Carrier's Open Source Digital Forensics Conference on 14 June, along with Cory Altheide, and I wanted to provide a bit of background with regards to what my presentation will cover...

In '98-'99, I was working for Trident Data Systems, Inc., (TDS) conducting vulnerability assessments for organizations.  One of the things we did as part of this work was run ISS’s Internet Scanner (now owned by IBM) against the infrastructure; either a full, broad-brush scan or just very specific segments, depending upon the needs and wants of the organization.  I became very interested in how the scanner worked, and began to note differences in how the scanner would report its findings based on the level of access we had to the systems within the infrastructure.  Something else I noticed was that many of the checks that were scanned were a result of the ISS X-Force vulnerability discovery team.  In short, a couple of very smart folks would discover a vulnerability, add a means of scanning for that vulnerability via the Internet Scanner framework, and roll it out to thousands of customers.  Within fairly short order, this check can be rolled out to hundreds or thousands of analysts, none of whom have any prior knowledge of the vulnerability, nor have had to invest the time to investigate it.  This became even more clear as I started to create an open-source (albeit proprietary) scanner to replace the use of Internet Scanner, due in large part to significant issues with inaccurate checks, and the need to adapt the output.  I could create a check to be run, and give it to an analyst going on-site, and they wouldn't need to have any prior knowledge of the issue, nor would they have to invest time in discovery and analysis, but they could run the check and easily review and understand the results.

Other aspects of information security also benefit from the use of scanners.  Penetration testing and web application assessments benefit from scanners that include frameworks for providing new and updated checks to be run, and many of the analysts running the scanners have no prior knowledge of the checks that are being run.  Nessus (from Tenable) is a very good example of this sort of scanner; the plugins run by the scanner are text-based, providing instructions for the scanner.  These plugins are easy to open and read, and provide a great deal of information regarding how the checks are constructed and run.

Given all of the benefits derived from scanners in other disciplines within information security, it just stands to reason that digital forensic analysis would also benefit from a similar framework.

The forensic scanner is not intended to replace the analyst; rather, it is intended as a framework for documenting and retaining the institutional knowledge of all analysts on the team, and remove the tedium of looking for that "low-hanging fruit" that likely exists in most, if not all, exams.

A number of commercially available forensic analysis applications (EnCase, ProDiscover) have scripting languages and scanner-like functionality; however, in most cases, this functionality is based on proprietary APIs, and in some cases, scripting languages (ProDiscover uses Perl as it's scripting language, but the API for accessing the data is unique to the application). 

A scanner framework is not meant to replace the use of commercial forensic analysis applications; rather, the scanner framework would augment and enhance the use of those applications, by providing an easy and efficient means for educating new analysts, as well as "sweeping up" the "low-hanging fruit", leaving the deeper analysis for the more experienced analysts.

This scanner framework would be based on easily available tools and techniques.  For example, the scanner would be designed to access acquired images mounted read-only via the operating system (Linux mount command) or via freely available applications (Windows - FTK Imager v3.0, ImDisk, vhd/vmdk, etc.); that way, the scanner can make use of currently available APIs (via Perl, Python, etc.) in order to access data within the acquired image, and do so in a "forensically sound manner" (i.e., not making any changes to the original data).

The scanner is not intended to run in isolation; rather, it is intended to be used with other tools (here, here) as part of an overall process.  The purpose of the scanner is to provide a means for retention, efficient deployment, and proliferation of institutional digital forensic knowledge.

Benefits
Some benefits of a forensic scanner framework such as this include, but are not limited to, the following:

1.  Knowledge Retention - None of us knows everything, and we all see new things during examinations.  When an analyst sees or discovers something new, a plugin can be written or updated.  Once this is done, that knowledge exists, regardless of the state of the analyst (she goes on vacation, leaves for another position, etc.).  Enforcing best practice documentation of the plugin ensures that as much knowledge as possible is retained along with the application, providing an excellent educational tool, as well as a ready means for adapting or improving the plugin.

2.  Establish a career progression - When new folks are brought aboard a team, they have to start somewhere.  In most cases, particularly with consulting organizations, skilled/experienced analysts are hired, but as the industry develops, this won't always be the case.  The forensic scanner provides an ancillary framework for developing "home grown" expertise where inexperienced analysts are hired.  Starting the new analysts off in a lab environment and having them begin learning the necessary procedures by acquiring and verifying media puts them in an excellent position to run the scanner.  For example, the analyst either goes on-site and conducts acquisition, or acquires media sent to the lab, and prepares the necessary documentation.  Then, they mount the acquired image and run the scanner, providing the more experienced analyst with the path to the acquired image and the report.

This framework also provides an objective means for personnel assessment; managers can easily track the plugins that are improved or developed by various analysts.

3.  Teamwork - In many environments, development of plugins likely will not occur in a vacuum or in isolation.  Plugins need to be reviewed, and can be improved based on the experience of other analysts.  For example, let's say an analyst runs across a Zeus infection and decides to write a plugin for the artifacts.  When the plugin is reviewed, another analyst mentions that Zeus will load differently based on the permissions of the user upon infection.  The plugin can them be documented and modified to include additional conditions.

New plugins can be introduced and discussed during team meetings or through virtual conferences and collaboration, but regardless of the method, it introduces a very important aspect of forensic analysis...peer review.

4.  Ease of modification - One size does not fit all.  There are times when analysts will not be working with full images, but instead will only have access to selected files from systems.  A properly constructed framework will provide the means necessary for accessing and scanning these limited data sets, as well.  Also, reporting of the scanner can be modified according to the needs of the analyst, or organization.

5.  Flexibility - A scanner framework is not limited to just acquired images.  For example, F-Response provides a means of access to live, remote systems in a manner that is similar to an acquired image (i.e., much of the same API can be used, as with RegRipper), so the framework used to access images can also be used against systems accessed via F-Response.  As the images themselves would be mounted read-only in order to be scanned, Volume Shadow Copies could also be mounted and scanned using the same scanner and same plugins.

Another means of flexibility comes about through the use of "idle" resources.  What I mean by that is that many times, analysts working on-site or actively engaged in analysis may be extremely busy, so running the scanner and providing the output to another, off-site analyst who is not actively engaged frees up the on-site team and provides answers/solutions in a timely and efficient manner.  Or, data can be provided and the off-site analyst can write a plugin based on that data, and that plugin can be run against all other systems/images.  In these instances, entire images do not have to be sent to the off-site analyst, as this takes considerable time and can expose sensitive data.  Instead, only very specific data is sent, making for a much smaller data set (KB as opposed to GB).

Updates

 Book Update
 I've received the counter-signed contract from Syngress for Windows Forensic Analysis 3/e, and I'm finishing up a couple of the chapters to get in for review.  This book is NOT the same as 2/e, in that I did not start with the manuscript from that edition (the way I did when I started 2/e).  Instead, 3/e is a companion edition...if you already have 2/e, you will want to have 3/e, as well.  This is because the information in 2/e is still valid, and in many instances (in particular information such as the PE file format, etc.) hasn't changed.  Also, 2/e focused primarily on XP, and those systems are still around...there hasn't been a huge corporate shift to Windows 7 yet.  As such, 3/e will shift focus to Windows 7...it will also focus more on solving problems, rather than simply depositing technical information in your lap and leaving you to figure out what to do with it.

Another new aspect of WFA 3/e is that rather than providing an accompanying DVD, the tools (as with WRF) will be provided online.  Providing the tools in this manner is just so much easier for everyone, particularly when someone purchases the ebook/Kindle version of the book, or leaves their DVD at home.  As with my previous books, I will do my best to provide functioning, tested code along with book, and provide links to other tools mentioned, described, or discussed in the book.

Accessing VSCs
I've posted before on accessing Volume Shadow Copies, but thanks to a recent blog post from Corey Harrell, I thought that it might be a good idea to revive the topic.  In his post, A Little Help with Volume Shadow Copies, Corey walks through a means for automating access to several VSCs, as well as automating the collection of information from each.  Corey does this through the use of a batch file.

Accessing VSCs in this manner is nothing new...it's been around for a while.  This post appeared on the Forensics from the sausage factory blog over a year ago.  In this post, copying of specific files via robocopy is demonstrated, showing how to use batch files to mount VSCs, copy files and then unmount the VSCs.  Corey's script takes a different approach, in that rather than copying files, he rips Registry hives using RegRipper (more accurately, rip.exe).  Corey was kind enough to provide a commented copy of one iteration of his batch file for inclusion in the materials associated with WFA 3/e (see above).

More than anything else, this is just the beginning.  Corey's had a need and used already-available information as a stepping stone to meeting his needs.  Whether you use the VHD method for mounting images, or the VMWare method (described by Rob Lee and Jimmy Weg), or some other method, the fact is that once you mount the VSC, it's simply a matter of getting the job done.  You can either copy out the Registry hives, or do as Corey's done, and run RegRipper (you'll still have the image and VSCs to access if you need the original data) on the hives.  You can copy or query for other files, as well, or use other tools (some I'll mention later).  In fact, with the right tools and a little bit of thought, you can do pretty much anything...compare files by hash, look for specific files, etc.  You may need to build some tools (or reach to someone for assistance), or download some tools, but you can piece some pretty decent automated (and self-documenting) functionality together and achieve a great deal.

Open Source Tools Book
Speaking of books, the book that Cory Altheide wrote (I was a minor co-author), Digital Forensics with Open Source Tools (aka, "DFwOST"), has been published and should be available to those who pre-ordered it soon.  Also, a really good idea is to follow @syngress on Twitter...I've been asked a couple of times if I will be providing a discount; I didn't provide the discount, Syngress did via Twitter.  I simply "RT'd" it.  You should really check this book out.  Cory's goal was to provide a means for folks with a basic understanding of digital forensics (and limited means) with an understanding of some of the open source tools available to them, and how to get them installed and configured.  And he did a great job of it!

My books have focused on the analysis of Windows systems, and have discussed/described free and open source tools that can assist an analyst.  Cory's book focuses on the open source tools, and covers several that you can use to analyze Linux, MacOSX and Windows systems.

SANS Forensic Summit
I don't know if you've seen it, but Rob's posted the agenda for this year's SANS Forensic Summit, to be held on 7 and 8 June, in Austin, TX.  Check it out...there are a number of great speakers, and several panels, which have proven to be an excellent format for conferences, as opposed to just having speaker after speaker.

It looks like Chris is gonna kick right off with his "Sniper Forensics" presentation, which has been getting him a LOT of mileage.  Richard Bejtlich is also presenting, in addition to being on a panel on the second day.  All in all, it looks like this will be another great opportunity to hear some good presentations, as well as to mingle with some of the folks in the business who are right there in the trenches.

OSDFC
I wanted to give another plug for Brian Carrier's OSDFC, the open source conference coming up on 14 June in McLean, VA.  Cory Altheide and I will both be presenting; I'm presenting in the morning, and Cory's got clean-up in the afternoon; that's Brian's tactic to get everyone to stay, by saving the best for last!  ;-)  I hope that this will be another great opportunity to mingle with others in the community...I had several interesting conversations with attendees at last year's conference.  Also, don't forget...DFwOST is out!  Bring your copy and get both of us to sign it...although you may have to wait for the cocktail reception at the end for that! 

Scalpel
There's an announcement over at the DFS Forensics blog that scalpel 2.0 is available.  There are some interesting enhancements, and the download contains pre-compiled Windows binaries and the source code.

USBStor
I received another question today that I see time and again, via email and in the lists/forums, having to do with LastWrite times on the USBStor subkeys and how they apply to the time that a USB device was last connected to the system.

In this particular case, the person who emailed me had confiscated and secured the thumb drive, and then found that the LastWrite time (apparently, the system itself was still active) for the USBStor subkey had been updated recently.

Folks, I really don't understand how this can be written and talked about so much, published in books (WFA 2/e, WRF, etc.) and STILL be so misunderstood.  Rob Lee's even made PDFs available that describe very clearly how to perform USB device analysis (XP, Vista/Win7).

If you want to know more about what may have caused the USBStor subkey LastWrite time to be updated when the device hadn't been connected, or more about why all of the USBStor subkeys have the same LastWrite time, put together a timeline.  Seriously.  I've seen both of these questions (some even include, "...I need to explain this in court..."), and a great way to answer it is to create a timeline of activity on the system and see what occurred around that time.

Links

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!