Meetup
This past Wed was a great NoVA Forensics Meetup, thanks to Sam Pena's efforts in putting the presentation together.  Sam put the effort into pulling together some information about the background and exploits of LulzSec and Anonymous, and then put forth some great questions for discussion.  After the background material slides, we moved the chairs into a circle and carried on from there!  A great big thanks to Sam for stepping up and giving the presentation, and for everyone who attended.  Also, thanks to ReverseSpace and Richard Harman for hosting.

Next month's meeting will feature a presentation botnets from Mitch Harris, and I've already received two offers for presentations on mobile devices, so stay tuned!

For those interested in attending, here's the FAQ:
- Anyone can attend...you don't need to be part of an organization or anything like that
- There are no fees
- We meet the first Wed of each month, starting at 7pm, at the ReverseSpace location; if you need more information, please see the NoVA Forensics Meetup page off of this blog

CDFS
"CDFS" stands for the "consortium of digital forensics specialists", and is a group dedicated to serving the DF community and providing leadership to guide the future of the profession.  Find out more about the focus and goals of the group by checking out the FAQ.  Also, see Eric Huber's commentary, as well (Eric's on the board).

Eric went on to describe the organization recently on G+:
CDFS isn't another organization offering certification, training, conferences and the like. It's an attempt by the various organizations and individuals to essentially act as a trade organization for the industry.

If you're like me and looking around the site, you're probably wondering, okay, I can become a member for $75 (for an individual) a year, but what does that get me?  Well, apparently, there are efforts afoot to yoke our profession with licensing...now, I say "yoke" because it sounds as if the licensing is being done without a great deal of involvement from our community, sort of like "taxation without representation".  I'm sure that I'm like 99.9999% of the community, and have no idea what's going on in those regards, but you know something, as I think about it, I do think that I'd like to have a vote in how that goes.  I'm not sure that I necessarily want to sit back and wait for someone else to make that decision for me, and then follow along (or not) with whatever licensing requirements are put in place, however arbitrarily. 

If you're curious about how you can be involved as a member, I'm sure that the Objectives page offers some insight as to where efforts will likely be directed.

OMFW
The 2011 OMFW was held recently, ahead of the DFRWS conference in New Orleans.  I had the great fortune of attending the original OMFW in 2008, and from what I hear, this one was just as good if not better.  OMFW pulls together the leaders in memory analysis, and brings them together in one place.  I can't speak to the format of this year's workshop, but if it was anything like the one in 2008, I'm sure that it was fast-paced and full of great information.

Speaking of information, MHL's presentation information (and Prezi) can be accessed here (ignore the publication date of the blog post), and Moyix's presentation can be found here.

Gleeda has graciously made her slides available, as well...she covered timelines, the Registry, Volatility and memory analysis all in one presentation!  What's not to love about that!

Let's not forget that Volatility 2.0 is now available (and Rob has added it to the recently updated SIFT appliance).

Tools
Ever been looking for malware in an image, only to find Symantec AV logs indicating that the malware had been detected and quarantined?  Well, check out the Security Braindump blog post on carving the Symantec VBN files.  Based on what BugBear has provided in the post, it should be pretty straightforward for anyone with a modicum of coding skill to write a decoder for this, if it's something that they need.

If you do any work at all with network traffic captures (i.e., capturing data, analyzing that data, analyzing data captured by others, etc.), then you must be sure to look at NetworkMiner.  Along with Wireshark, this is a very valuable (and free) component to your network traffic analysis arsenal. 

PFIC
I've mentioned before that I'll be speaking at PFIC 2011, along with Chad Tilbury.  It turns out that not only will I be speaking, I'll also be giving a lab, as well.  My talk will be on "Scanning for Low-hanging Fruit during an Investigation", and my lab will be "Intro To Windows Forensics", which will be geared toward first responders.  I'm really looking forward to this opportunity to engage with other practitioners from across the DFIR spectrum...I had a great time at PFIC last year, and had a great dinner one night thanks to Chad.

Timelines
I'm sure that at one point during the conference, the topic of timelines will come up (BTW...I'm doing a lecture/demo next week on timelines).  I think that understanding the "why" and "how" of creating timelines is very important for any analyst or examiner, in part because I have seen a number of exams where malware on the system has taken a number of steps to avoid detection and to foil the responder's investigation.  For example, file names and Registry keys are created with random names, file MAC times ($STANDARD_INFORMATION attribute in the MFT) are "stomped", and there are even indications that the malware attempted to "clean up" it's activity by deleting files.  In most cases, on-board AV never detected the infection, albeit in a few instances, the AV alerted on files being executed from at temp directory (but there was only a detection event, no action was taken) rather than detecting the malware based on some file signature.  In all cases, the AV was up-to-date at the time of infection, although MRT wasn't.  Often, the malware itself isn't detected when the analyst mounts and scans the image; rather, a secondary or tertiary file is detected instead.

In every case, a timeline allowed the analyst to "see" a number of related events grouped together, and based on the types of events, evaluate the relative level of confidence and context of that data and determine what is missing.  For example, finding a Prefetch file for an executable, or a reference to an oddly-named file in a Registry autostart location often leads the analyst to ask, "what's missing?" and go looking for it.

This is the first time this workshop has been put on, but I have to say that it was a rousing success right off the starting blocks! An excellent format, excellent schedule, and excellent speakers. More importantly for me, there was a great deal of information and discussion that was either immediately practical, or would lead to something practical and useful in a hands-on manner within a relative short period.

A couple of the big-brain take-away thoughts that came out of this 1/2 day workshop were:

There seemed to be agreement amongst the assembled panel (as well as the attendees) that open-source is the way to go with tools like memory parsing tools. Open-source allows for verification of your findings and how various items were found, transparency, as well as extensibility.

When performing memory acquisition and analysis (parsing, really), what are the essential or pertinent objects/items/elements? What parts of, say, an EPROCESS structure are absolutely essential for determining if you're looking at an actual EPROCESS structure?

The subject of anti-forensics came up as well, and a thought was that if the bad guys know about what the good guys are doing, and know what important elements have been identified simply by looking at the open-source code, then they can easily come up with ways to combat those tools and techniques, and obfuscate what they're doing. This has in part to do with the discussion of essential/critical structure elements. For example, many of the tools that do a brute-force linear scan through a memory dump looking for EPROCESS structures look for specific elements of the structure itself in order to identify, as close as possible, a legitimate structure. Someone could obfuscate what they're doing by discovering which of those elements they can modify in order to avoid detection. Without identifying these critical elements...elements that cannot change without crashing the system...then this relatively new area of memory analysis is more open to anti-forensic and obfuscation techniques. However, Jesse pointed out something very important...a preponderance of anti-forensics and obfuscation (i.e., the over-abundance or relative lack of artifacts that an examiner would expect to see) activity should be a clear indicator to the examiner that something is amiss.

Also, Jesse used the term "tool marks" in his presentation...from what I saw, it sounded like "artifacts" to me, albeit specific to a particular "tool". This can be an important tool (I need to discuss this interesting topic w/ Jesse some more...) in that it can be a very useful data reduction tool to assist the examiner in identifying unusual things. For instance, something that came out of the DFRWS2008 Forensic Rodeo was that an unusual string in memory may indicate the use of TrueCrypt.

Overall, the quality of the presentations and speakers, as well as the panels, made for an excellent workshop! My hat's off to AAron and everyone else who put their time and effort into this event! It was great to finally meet folks like Moyix, Andreas, and have a chance to listen to their thoughts, and thank them. I hope to see this workshop again next year!