Monday, June 18, 2018

Updates

I've had a bunch of draft blog posts sitting around, and for some of them, particularly the really technical ones, I thought, "...ah, no one's gonna read this...", so I opted for another medium, or I simply deleted them.  However, I decided to throw a couple of them in together, into one post, just so I could complete my thoughts and get them out there, and do a bit of housekeeping with respect to my blog drafts.

Publishing
Brett Shavers recently posted some interesting content on the topic of publishing in DFIR.  While DFIR doesn't necessary follow the "publish or perish" adage most often seen in academia, Brett does have some very good points.

To Brett's point about "lack of contributors", this is the reason why efforts like Into The Boxes project never really took off...you can't sustain a community-based project if folks within the community aren't willing to contribute.

By the way, I still have my inaugural hard copy of "Into The Boxes #1", knowing full well that one day it's going to be part of my DFIR museum, right alongside my MS-DOS install diskettes, my original Windows XP install CDs, and an AOL installation CD!

Something else that Brett mentioned in his post was "peer review".  Oddly enough, I've been engaged in a conversation with someone else in the DFIR community about this very topic, particularly as it applies to analysis findings.  In my experience, peer reviews within the community are spotty, at best.  We all know that team member that we can go to, because they'll turn around a 40 page report draft in 15 minutes, saying just that it "looks good."  And we also know that team member we can go to and rely on to catch stuff we may have missed.

Blog-a-Day Challenge
Speaking of publishing, it looks as if over the last couple of weeks a number of folks have decided to take the Zeltser Challenge, that is to post a blog a day for an entire year.  Not only has David Cowen picked it back up (he's done it before...), but others have joined the party, as well.  For example, Stacey has started The Knowledge Bean and decided to partake in the challenge. Tony at Archer Forensics has picked up the mantle, as well, and is off and running.

If anyone else in DFIR is doing something like this...blog-a-day, or even blog-a-week, let me know...I'd like to check it out.

Oh, and tying this back to the previous topic, something Tony mentioned in one of the blog posts:

I would solicit everyone to do that deeper dive research to further the field.

Agreed, 1000%. 

New Plugins
Well, let's see...what's new on the plugin front?  So, I recently received one updated plugin (lastloggedon.pl) and a new plugin (utorrent.pl) from Michael Godfrey (author information included in the plugins), and uploaded them to the repository.  I also added jumplistdata.pl, which is based on this finding from Costas K.  Finally, I created execpolicy.pl, a plugin to check the PowerShell ExecutionPolicy value, if it exists...some folks have said that adversaries have been observed modifying the Registry value to that they can bypass the execution policies in order to run their code, albeit not from the command line.

Not a new plugin, but I also updated the license for RegRipper to the MIT license, at the request of some folks at AWS.

Tool Usage
Mari published a blog article recently, which I thought was great...not just because Mari's great at sharing information in an easy-to-understand and repeatable manner, but more so due to how her post discussed tool usage.  There any number of DFIR sites out there, web sites and blogs alike, that are full of tool listings...here's this tool, and here's this tool.  Great.  It's like shop class, with all of the tools hanging on the peg board, on their specific hooks, over their specific silhouettes. 

The question folks should have is, great, but how can I best employ those tools to complete the goals of my investigation in a complete, thorough, accurate, and timely manner?

If you're looking for something to blog about...there you go.  There are potentially hundreds or thousands of blog posts based on just that single theme, that one topic.

1 comment:

Brett Shavers said...

Within a team, peer review directly affects both the writer and reviewer, since the product will reflect upon a team. Outside of a team, peer reviews are tough unless it is paid employment to review papers. The time and effort is far to great to re-do all the testing of a paper for someone without having some sort of mutual benefit.

Peer reviews of opposing experts' work is the best example of a paid peer review with mutual benefit as it is a job, so to speak; but unfortunately this is only a review of someone's casework, not someone's research to publish.