Tools, Books, Lessons Learned

Tools
As part of my Sunday morning reading a bit ago, I was fascinated by an evolving tweet thread...Eric recently tweeted some random threat hunting advice involving shimcache data.  In response, Nick tweeted regarding an analytic approach to using shimcache/appcompatcache data, at scale, along with AmCache data.  Nick also provided a link to the FireEye blog post that describes their AppCompatProcessor tool.

I really like this approach, and I think that it's a fantastic step forward, not only in single system analytics, analyzing one system through the traditional, "dead box" analysis, but also with respect to an enterprise-wide approach to threat hunting and response.  In many ways, threat hunting and response is the next logical step in DFIR work, isn't it?  Taking what you learned from one system and expanding it to many systems just kinda makes sense, and it looks as though what the FireEye folks did was take what they learned from many single system examinations and developed a process, with an accompanying tool, from that information.

From even a single system analysis approach, there are still a number of analysts within the community who either aren't parsing the AppCompatCache data as a matter of course, or they're misinterpreting the time stamp data all together. Back in Dec, 2016, Matt Bromiley wrote an article describing some of the important aspects of the AppCompatCache data ("important" with respect to interpretation of the data).  Also, be sure to check out read thoroughly the section named "AppCompatSecrets" here, as well as Luis's article here.  A correct understanding of the data and it's context is important going forward.

From an enterprise perspective, there are tools that do nothing more than collect/parse this data from systems, but do not provide any analytics to the data itself, in short, simply dumping this massive trove of data on the analyst.  The analytic approach described by the FireEye folks is similar in nature to the Hamming distance, something I learned about while taking Dr. Hamming's seminar at NPS; in short, the closer the temporal execution of two entries (smaller Hamming distance), the stronger the tcorr value.  This can be applied to great effect as a threat hunting technique across the enterprise.  In the case of AppCompatCache data, the time stamp does not indicate temporal execution; rather, it's a combination of a flag value and the position of the entry, in the order that it's stored within the Registry value.  The "temporal" aspect, in this case, refers to the location of entries in the data with respect to each other.

This can also be applied on a single system dead box analysis, when you look at it as a system, and include not just the System hive, but the System hive in the RegBack folder, as well as any that exist in VSCs, as well as within a memory dump.

I'd recently blogged about using several Registry and Registry-like artifacts in a much smaller approach to "analytics", looking at the use and correlation of multiple sources of data on a single system, with my base assumption being that of single system dead box analysis.  I figured, hey, it's a place to start.

Getting a Book Published
I recently had an opportunity to read Scar's blog post entitled, Finding a Publisher For Your Book.  I found it fascinating because what she wrote about is not too dissimilar from my own experiences.

I have not read her book, Windows Forensic Cookbook.  In fact, I wasn't aware of it until recently.  Once I found out about it, I checked the Amazon site and didn't see any reviews of the book; I'm not surprised...after all, this is the DFIR "community"...but I did hope to get a sense of the material within the book.  So, this isn't a book review, but rather commentary in solidarity with her experiences.

Like Scar, I've put a lot of work into writing a manuscript, only to get the proofs back for review and thinking...what?  In one instance, every single instance of "plugin" had been changed to "plug-in" in a chapter. Uh...no.  My response back to the copy editor was simply to state at the being of the chapter, "...change it back...all of it."

Scar's comments about expectations caught my attention, as well, particularly when the publisher wanted a chapter review turned around in 48 hrs.  What?!?  This is one of those things you have to be prepared for when working with publishers...they simply do not understand their suppliers, at all.  A publisher or editor works on getting multiple books out, that's what they do all day.  However, those of us writing books and providing material do other things all day, and write books when we have time.  That's right...we do the stuff during the day that makes us qualified to write books, and then actually get to write the books in our copious "free time", after putting in a full day or week of work.  These crazy deadlines are something I've pushed against, more so since I've developed greater credibility with the publisher by writing more books.  When my tech editor is working full days just like everyone else and gets a 35+ page chapter with a demand to have the review returned within 48 hrs, that's simply an unrealistic expectation that needs to be addressed up front.

I've been writing books for a while now...it didn't occur to me just how long I've been doing it until last week.  I have a book in the process of being published right now...I'm waiting on the proofs to come back for review...and I submitted a prospectus recently for another book, and the reviews of the proposal I sent in have started coming back.  One reviewer referred to WFA 1/e, published in 2005; this means that I actually started working on it late in 2003, or really in 2004.  And that wasn't my first book. All of this is to say that when I see someone write a blog post where they share their experiences in writing a book and getting it published, what I find most interesting about it is that nothing seems to have changed.  As such, a lot of what Scar wrote in her blog post rings very true, even to this day.

Finally, I've mentioned this before but I'll say it again...over the years, I've heard stories about issues folks have had working with publishers; I've had some of my own, but I like to think that I've learned from them.  Some folks don't get beyond the proposal stage for their book, and some folks have gotten to a signed contract, but drop out due to apparently arbitrary changes made by the editorial staff, after the contract was signed by both parties.  What I had proposed to the publisher I have worked with is to create a liaison position, one where I would work directly with authors (singles, groups) to help them navigate the apparent labyrinth of going from a blank sheet of paper to a published book, using what I've learned over the years.  This never really went anywhere, in part due to the turnover with the publisher...once I had found a champion for the idea, that person left the company.  The fact that after attempting to do this three times and not succeeding, and that the publisher hasn't come back to me to pursue it, tells me that they (the publisher) are happy with the status quo.

If you're interested in writing a book, you don't have to be.  Read over Scar's blog post, ask questions, etc., before you make a decision to commit to writing a book.  It isn't easy, but it can be done.  If your main fear against writing a book is that someone else is going to read it and be critical, keep in mind that no one will be as passionate as you about what you write.

Lessons Learned
I was engaged in an exchange with a trusted and respected colleague recently, and he said something to me that really struck a chord...he said that if I wanted to progress in the direction we were discussing, I've got to stop "giving stuff away for free".  He was referring to my blog (I think), and his point was well taken.  If you're like me, and really (REALLY) enjoy the work...the discovery, the learning, solving a problem in what may be a unique manner, etc...then what does something like writing books and blog posts get you?  I'm not sure what it gets others, but it doesn't lead to being able to conduct analysis, that's for sure.  I mean, why should it, right...if I put it in writing what I did or would do, any someone else can replicate it (like a recipe for tollhouse cookies) then why reach out and say, "Hey, Harlan...I could really use your help on this...", or "...can you analyze these images for malicious activity..."?