Ponder The Bits

Musings and confusings. All things DFIR.

Knowing Your Tools

We all have our favorite tools – whether it’s a simple python script to parse/search a specific type of log or a mainstream commercial forensics tool to ingest a bunch of evidence and search in parallel across a multitude of artifacts. We typically use tools to help us by performing some set of actions that:

  • We are not able to perform due to lack of knowledge (e.g., parsing proprietary format objects, identifying all available information within an object, scanning for anomalies in an obscure technology/file, etc.)
  • We could perform on our own, but are better (more efficient/effectively) performed by a tool (e.g., parallelized searching, parsing of artifacts for specific information, etc.)

Regardless of the tool, one of the main benefits of using them is to save time. Time saved in performing our job as Incident Responders and Forensic Experts means less time between compromise and mitigation/recovery/return to safe operations. This is one of the core responsibilities of our line of work and why we have these jobs – to utilize our expertise and tools to reduce the impact to the business.

With this responsibility to find answers and find them fast comes both the responsibility and propensity to find/use a tool whenever possible. And, given the awesome increasingly collaborative DFIR field of ours, this is quite easily done a large majority of the time. However, with this responsibility also comes an an incredibly important onus on each and every one of us to not just be able to use a tool to get quick answers but to also ensure that the tool(s) being utilized are both well understood and performing as expected/intended. After all, time saved getting a wrong answer is not time saved at all. In fact, it often creates an additional cost of not just time but also both non-monetary and monetary costs/losses.

Do you actually know what each of your tools does?

This is a VERY important question in our line of work. Frankly, it’s an important question in most any line of work in which people rely on an expert to provide them with assistance that is accurate, effective, and efficient during times of which the wrong decision or information can yield substantial consequences. The onus is on you/us, as experts in the field, to not just provide answers spit out from a tool, but to be able to know how that information was processed and how it arrived as output from each tool you used. The effects of not understanding this can range from simply looking unintelligent when queried about what the tool does and why it does it to a catastrophic result of providing incorrect information and losing key insight into a compromise.

As an example, what if you used a tool that misrepresented an executable’s create/modify time on disk? You may have still found it via other methods, or you may have missed that insight completely. This may not necessarily be of substantial consequence to, say, a single-source ransomware case. But, what if an entire decision of possible data exfiltration for a multi-billion dollar company hinged on when, specifically, the executable was created on the system and you incorrectly reported a date/time that was MONTHS OFF because you didn’t know (or your tool misstated) that the dates/times were extracted from the NTFS $SI attribute* (easily timestomped) versus the $FN attribute? I think (hope) you get the point here. THESE ARE THINGS YOU NEED TO KNOW!

*Note: It’s not just small tools susceptible to this poor practice of displaying an NTFS $SI attribute for date/time information during forensic analysis. I know of one very large commercial forensic tool that does this by default, which is not only poor practice for such a broadly utilized and expensive tool but something of which I’ve learned many people are not aware! Gah. But, I digress…

Feeling like I’ve appropriately berated and re-stated the “why” of needing to know how your tools work, let’s move on to formulating an approach for “how” to understand them. As someone who researches, peruses, tests, utilizes, and submits bugs/improvements for a wide variety of both FOSS and commercial tools (mostly the former, I’m a true FOSS junky), my quest for understanding each tool to the fullest extent possible comes down to asking three questions in a variety of different ways:

  • Why does it do or not do <X>?
  • What does it mean when <Y>?
  • How would I know if <Z>?

The basis of these questions can be broken down into many more granular questions of which the sky is the limit. However, as a baseline of where to start, the below is a set of questions I typically ask myself when using a tool that someone else has built (and I encourage you all to add/modify as appropriate):

  • How does it acquire the specific information it is parsing?
  • How, specifically, is it parsing the data?
  • What does it mean if something is not present that I would expect?
  • What does it mean when something is present that I would not expect? 
  • Do I fully understand the intent of the tool?
  • Am I using the tool for its intended usage?
  • How would I know if it was not successfully achieving its intent/goal(s)?
  • Would I know if the tool produced an error?
  • Upon error, how do I find out whether the error may be in the source data and/or the tool’s processing of the data?

… and I could go on, but you get the point. These are all questions you should be asking yourself when you use each of your tools (yes, this includes BOTH commercial and FOSS tools). From these questions comes scenarios in which you should test the tool for expected results with all types of data you expect to encounter. To that end, I would also suggest you test it with data you do not expect to encounter in the event that it can yield better understanding of the tool.

So, we’ve covered “why” you need to understand your tools, “how” you might go about doing that, but what if you do encounter an error with the tool? Should you just give up and try other tools? I would encourage you not to give up and move on as that helps no one (not the author, not you, and not others in the community who are likely experiencing the same issue or issues you are). If there is an issue, try to find an answer! This is a community. Someone has taken the time to create a tool to save you time and effort, the least you can do is return the favor and invest your time to understand the tool and help make it better. Too often I hear about issues with tools and come to find out that the issue was never investigated, posed, or posted to gather feedback from others. And, even if the issue was posed/posted somewhere, they never attempted to contact the author(s).


They are often the primary source of information for the tool, not to mention doing so reinforces the fact that people appreciate the time they took to create a tool and are invested in it enough to contact them about how to make it better. Just a simple question about how/why something works can be invaluable to an author. I continue to be amazed at how responsive the authors of various tools are within our community for bug reports and/or improvement requests.

As you can see, I’m very passionate about, and a huge proponent of, investing time into understanding each and every one of your tools (not to mention building your own and contributing back to the community if you are so inclined). It not only makes you better, it also makes the community better. Pointing and clicking without understanding what is going on behind the scenes is a disservice not only to yourself but to the community. Don’t be someone that can be replaced by another tool. Add value to your company/clients by going above and beyond and taking the time to understand the tools for your profession from the ground up. If you do, the investment will come back to you and to the community multiple times over.

If this topic interests you and/or you are simply interested in getting to know your Linux/Mac command line and/or FOSS tools (better), stay tuned for the future “Know Your Tools” series/posts where I will be covering various tools used in my DFIR investigations, to include basic tool usage, lesser known (and useful) capabilities, as well as tips/tricks I’ve collected over the years in refining various tools and processes.

Happy 2017!


DFIR Community Inspirations

Ok, so I lied about not posting until 2017.

As I continue work on the blog, I couldn’t help but think of all the people who have inspired me over the years. Not just to learn and become better at what I do, but to pay it forward so that others may benefit and hopefully be inspired as well.

So, as I close out 2016 and ring in the new year, I’d like to recognize the following individuals for being an inspiration to me over the years and helping me to become an overall better (and now better contributing) DFIR expert. It is no easy feat to maintain and balance a career, home/social life, hobbies, and countless other daily obligations while also taking regular time out to create, test, curate, and develop for the sole purpose of simply helping the community/others.

Seriously. Stop and think about your average day. How often do you finally sit down at the end of a work day or in the middle of a weekend and think to yourself, “I’d love to spend a few (more) hours working for little to no return other than community benefit and growth”? Yeah. On the scale of “wants”, it probably rates somewhere between “shoveling snow” and “hitting the gym on January 2nd”.

Now, don’t get me wrong, there are certainly benefits to doing it whether it be a creative outlet, simply the satisfaction of helping others, or something else altogether. But, regardless of how much or little benefit you get from doing this, the fact remains that you’ve really got to have a LOT of passion to regularly contribute to the community, and these people have nothing short of that.

Without further adieu, I have listed them in no particular order… except alphabetically by last name… with media links successively alphabetical… thank you, OCD!

Adam B – Blog / Twitter
Willi Ballenthin – Blog / Github / Twitter
Matt Bromiley – Medium / Twitter
Harlan Carvey – Blog / Github / Twitter
David Cowen – Blog / Twitter
Cheeky4n6Monkey – Blog / Twitter
Mari Degrazia – Blog / Twitter
Sarah Edwards – Blog / Twitter
Matt Graeber – Twitter
Jared Greenhill – Twitter
Corey Harrell – Blog / Twitter
Rob Lee – SANS Blog / Twitter
Brian Moran – Blog / Twitter
Jessica Payne – Twitter
Hal Pomeranz – Blog / Twitter
Dan Pullega – Blog / Twitter
Lenny Zeltser – Blog / Twitter
Eric Zimmerman – Blog / Twitter

I am sure that I have left some people out. So, to better capture this information as it continues to grow and be updated, I’ve placed it on my DFIR Resources page.

Please feel free to sound off in the comments with feedback for these great individuals or mention others who I have not named that have made a particular impact in/on your career.


Hello. Whirled.

Well, 2016 was quite the whirlwind.

In my DFIR career spanning government (NSM), contractor (cyber investigations), and now private sector (DFIR consulting), I’ve always been passionate, determined, and purposeful in making the time to get better, faster, and stronger at what I do. As a team member, I have extended the products of this passion to the team whenever possible so that we all win together. However, it has most always stopped just there, rarely extending past our internal team(s) into the DFIR community at large. Today, that all changes, my DFIR friends.

I cannot convey how much I have learned and benefitted from others’ blog posts, research, and tool developments. Well, I can, and I will throughout various posts to come. Nonetheless, this past year, the onus began weighing heavily on my mind to give back to the community that has helped me do so much so well. So, a few months ago I began putting a blog into motion, aiming to capture various topics, insights, tips, walkthroughs, tutorials, and/or anything generally worthwhile of thought. It has taken me longer than anticipated, but better late than never, right?

Though much of the blog will likely contain technical content, I will also be developing and publishing non-technical content that I find equally important (and often times more so) to a successful (DFIR) career. As will be the case with every post to follow, I hope this blog can help in some way to foster discussion, collaboration, and overall participation within the DFIR community (and simply give back).

I’m going to take the holidays and remainder of the year to finally sit down and shore up some posts to hopefully get the blog going in the new year.

Until then, see you all in 2017.

Please Note: This blog does not reflect the opinions or views of my employer and solely reflects those of my own. However, any mistakes, oversights, or generally unfavorable posts were definitely done by someone else.


Page 3 of 3

Powered by WordPress & Theme by Anders Norén