Stuffy Stuff

...yeah, I get it...I'm not entirely imaginative, and don't come up with the best titles for my blog posts....

#DFIR Intel
About 4 1/2 years ago, I got on a riff and blasted out a bunch of blog posts, over a dozen in one month.  Most of these posts were "how to" articles...

One of the articles I wrote was How To: Add Intelligence to Analysis Processes.  This is also a concept I address to some extent in my new book, Investigating Windows Systems (recently sent the manuscript to the publisher for review and formatting...); not only that, I give lots of examples of how to actually do this.  IMHO, there are a lot of opportunities that are missed during pure #DFIR work to correlate and develop intelligence, which can then be "baked" back into tools and processes to make analysis "better" in the future.

Further, I read Brett's recent post about fitting a square peg into a round #DFIR hole, and I started to see correlations between the intel stuff, and what Brett was saying.  Sometimes, in looking for or at which tool is "best", we may run across something that's extremely valuable during another engagement, or to another analyst all together.

I can easily see Brett's point; how do you answer the question of "what's the best tool to do X?", if the user/analyst requirements aren't fully understood?  "Best" is relative, after all, isn't it?  But I really think that in the process of determining requirements (what is "best"?) and which tool or process is best suited to provide the necessary answers, there's a great deal of intelligence that can and should be preserved.

A great example of developing intel within the community is from Mari's post, where she evaluated MFT parsers.  In her post, Mari clearly specified the testing requirements, and evaluated the various tools against those requirements.  This was great work, and is not only valid today (the post was published about 2 1/2 yrs ago), but continues to offer a great example of what can be done.

By now, you're probably wondering about the connection between correlating and developing intel from #DFIR engagements, and deciding which is the "better" #DFIR tool.  Well, here it is...by correlating and developing intel from #DFIR cases/engagements, we can make all of our tools (and more importantly, analysis processes) inherently "better".

For example, going back to Mari's blog post on MFT parsers, let's say that the issue at hand is time stomping, and you'd like a means, as part of your analysis process to just look at one file and determine if it had been time stomped.  I wrote my own mft.pl parser, in part, to let me do exactly that...and in doing so, improved my analysis process.  You can do the same thing by finding the right tool...or contacting the author of a tool and ask that they provide the capability...to provide the needed capability.

What Does It Look Like?
So, what does this "intel" we're talking about look like?  Well, they can be several things, depending upon what you're doing.  For example, if you do string searches, consider using Yara rules to augment your searches.  Yara rules can be incorporated into analysis processes through a variety of means; one of my favorites is checking systems for web shells.  Usually, I'll mount the image via FTK Imager, and run a Yara scan across the web site folder(s), using a combination of open source Yara rules to scan for web shells, as well as things that have been developed internally.  Sometimes, this approach works great for locating web shells right out of the box; in other cases, further investigation of web server logs may be required to narrow down the hits you received from the Yara scan to the file in question.

Side Note:  "Intel" can also "look like" this blog post. Great stuff, and yes, Yara rule(s) resulted from the analysis, as well.

Speaking of Yara rules, there is a LOT you can do with Yara rules beyond just running them against a file system or folder.  You can run them against memory dumps, and in this article, Jeremy Scott mentions the use of page_brute to run Yara rules across a page file, or in the case of more recent versions of Windows (yet another reason why knowing the version of Windows you're examining matters!), all of the page files.

Another means for preserving and sharing intel is through the use of RegRipper plugins.  I know you're thinking, "oh, yeah...easy, right?  You write them all the time..."...and yes, I do.  And getting a plugin written or modified is as easy as asking.  I've been able to turn around plugins pretty quickly with a concise, clear description of what you're looking for, and some sample data for testing.  Another example is that while I was examining one of the CTF images for my upcoming book, I ran across Registry data I've never encountered, and as a result, I wrote a RegRipper plugin.

Another great thing about RegRipper plugins is that Nuix (for transparency, Nuix is my employer) now has a RegRipper extension for their Workbench product, meaning that you can run RegRipper plugins against Registry hives (and depending upon the version of Windows, the AmCache.hve file) right from Workbench, and then incorporate the results directly into your Nuix case.  That way, all of your word searches, etc., will be run against this data, as well.

There are a myriad other ways of preserving intel and sharing your findings.  The means you may use for preserving intel depends on what you're doing in your analysis process.  Unusual command line options, such as those seen with cryptocurrency miners, can be preserved in EDR filter or alert rules, or in the case of the browser-based miners, Yara rules to be run against memory.  Sometimes, you may not immediately see how to turn your findings into useful intel or tools, nor how to bake what you found back into your own analysis process...this is a great reason for reaching out to someone, and seeing that they might have to offer. 

Side Note: There was a pretty extensive #DFIR sharing thread over on Twitter, that started out as thoughts/discussion, re: writing blogs vs writing books.  As this thread progressed, Jessica reiterated the point that sharing doesn't have to be just about writing, that sharing within the #DFIR community can take a variety of forms; book reviews, podcasts, etc.  I wholeheartedly agree, and also believe at the same time that writing is of paramount importance in our profession, as whether you're writing code, case notes, or a report, you have to be able to communicate.  To that point, Brett shared his thoughts on ham sandwiches.