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).

ASK THE AUTHOR.

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!

/JP

Did you enjoy this post? Share it!