Friday, May 18, 2012

Good time for some 0xBADC0FEE

Every now and then, I'll post (to this blog or to an online forum) on the topic of sharing and collaboration within the community, and how it benefits those who are actively involved.  Actively engaging with others in the field has worked out very well for me in a number of circumstances, both during casework and research, and I seek out that kind of active engagement and recommend it to others.

Here are some examples of how active engagement has been a benefit:

I was working on a malware detection case a while back, and by actively engaging with our malware analysis guy, we were able to provide much more information and intelligence to the customer than either one of us working separately...the final result was much greater than the sum of it's parts.  I provided information to the malware analyst regarding where the malware was found, artifacts associated with it, how it was likely launched, etc.  He was able to successfully launch the malware on a similar platform, and then provide information and intel from memory analysis that was then used to further extend the host-based analysis.  Working together in this manner, we were able to collect much more information in a timely manner, which allowed us to extend that information into intelligence by collecting and incorporating information from external sources.  The final turn-around on all of this was 4 1/2 days, where the customer would have been happy with (and was more used to) 6 months.

Last January, when returning from a conference, a friend mentioned to me that he had an NT 4.0 system (yes, that's exactly right...NT 4.0) to examine, and the Event Logs had apparently been cleared.  I was able to offer him a solution, allowing him to recover Event Log records from unallocated space, and progress and extend his analysis.

Okay, so continuing on...not long ago, the folks at Mandiant posted regarding the AppCompatCache Registry value (which is where the "0xbadc0fee" reference in the post title comes from...), and provided example code.  This was a great bit of sharing with the community, and I was able to not only find and correct an issue with the tools I was using, but also create a RegRipper plugin based on the information and code they provided.  From there, I started looking at other locations within the Registry that could provide indications of program execution, and created plugins for these, as well. 

Then when I updated the Prefetch file parsing code in preparation for some upcoming training courses, I added some 'filters' to the code, so that certain artifacts (modules with "temp" in their path, etc.) were extracted and highlighted.

I was exchanging code and emails with Corey Harrell, engaging in discussions with him with respect to the usefulness of both the code and analysis techniques, and he suggested adding similar filtering capability to some of the already available RegRipper plugins (MUICache, UserAssist, etc.)...something I'd considered, but it hadn't occurred to me how useful that might be.  Thanks to engaging with Corey on this, he made it clear to me that not only would these filters be valuable, but he also suggested some additional filters that would be useful in other areas, as well.  In short, the idea was to take the breadth of both of our experiences and put that into filters that would illustrate to other analysts, "look, here's a bunch of data, but here are some things you might consider looking at sooner rather than later...". 

It was that active sharing and collaboration that not only served to extend our own individual knowledge through the exchange of our experiences, but also allowed us to extend the tools themselves.  Clearly, this would then have a cyclic effect...running the updated tools would likely show us artifacts that we might have missed, extending our knowledge and experience, which we could then use to extend the tools, etc.

One of the things I really appreciate about engaging with Corey is that he puts a great deal of thought into things.  We're all busy, and I don't expect immediate responses from anyone, but I can always count on Corey to come back with something thoughtful, such as, "why would you want to do that?", or "how about if we did it this way?"  It's this kind of thoughtfulness when engaging that allows all parties involved to grow and develop.  Sometimes, when you're used to doing something a certain way, or if you're really actively engaged on something, a simple question like, "why?" can really provide a great deal of value.

If you haven't done so already, I highly recommend that you vote for Corey or his blog in the 2012 Forensic4Cast awards.  Particularly in the last year, Corey has contributed a great deal to the community as a whole, and it would really being doing him justice if he were to win at least one of the awards that he's nominated for.  Also, he'll be at the SANS Forensic Summit in Austin this year, so be sure to buy him a beer, regardless.

You'll notice that throughout this post, I kept using the term "active" or "actively".  I did this to make a distinction; downloading code or tools that someone provides is not actively engaging.  

2 comments:

Anonymous said...

Harlan, Good examples and reasons that we need to be actively engaging each other in the community because there is so much out there to know. This is a great community in the fact that new practitioners can ask questions and be directed towards answers and understanding of what to look for and how to approach the problem.

As you pointed out using a tool is not actively engaging, but providing feedback, use cases, and implementable code changes to these tools are.

H. Carvey said...

Ken,

Agreed, 100%.

What I've found very useful in a great number of instances...many of those when working with Don Weber...is the question, "why?" This can be very useful when it's sincere...not just asked because someone's unwilling to process information. Sometimes, revisiting that question, or just discussing base motivations and assumptions, brings new information to light that can greatly improve analysis and/or response.

Another useful feedback mechanism comes when folks write book reviews...providing more than just "good book" or a reiteration of the table of contents can be valuable, not just to the community, but also to the author.