Tools

I've been thinking about some of the tools I use in my work a good deal lately, and looked back over the breadth of some of those that I've used.  I've even thought a good deal about the book that I helped Cory write (my part was rather small).  I think that what I find most interesting about this is that when I take a good look at the tools, I realize that it's not so much about the tools, as much as it is about the workflow.

I really like tools like Yara and RegRipper not just because they're relatively easy to use, but they provide a great platform for documenting, retaining, and sharing corporate knowledge, as well as intelligence gleaned from previous cases, or other sources...I wrote the logonstats.pl plugin after seeing a Tweet.  The only short-coming is that analysts actually have to either write the rules and plugins themselves, or seek assistance from someone with more experience, in order to get this sort of thing documented in a usable form that can be deployed to and shared with others. 

The folks at H-11 Digital Forensics Services posted their list of the top 30 open source digital forensics tools.  There are some interesting things about the list, such as that Autopsy and TSK both made it as separate entries.  But I wanted to be sure to share the link, as each tool includes a brief description of how they've found it useful, which isn't something that you see very often.

While the list is limited to 30 tools, there is some duplication, which can be viewed as a good thing...it's very often a good idea to have multiple tools capable of doing the same or similar work, although I'd add, doing that work in a different way.  You don't want multiple tools that all do the same thing the same way; for example, Microsoft's Event Viewer and LogParser tools both use the MS API, so it's likely that for basic parsing, they're both going to do it the same way, and produce very similar results.  A better idea would be to use something like LogParser and EVTXtract.

As a bit of a side note, we know that LogParser utilizes the MS API, because of how it operates on different versions of Windows; that is, XP/2003 vs Vista+.

Just to be clear...having and using multiple tools is a great idea, but having multiple tools that all do the same thing the same way, maybe not so much.  It's still up to the individual analyst.

Speaking of tools, or more appropriately, lists of tools, be sure to stop by the dfir.training tools page and check out what's there. 

Tools+
bits_parser - Python script (install it into your installation using 'pip') for parsing the BITS database(s).  Interestingly enough, within the DFIR community as a whole, it's not really clear to me that this is viewed as an infiltration (download) or exfiltration (getting data off of a system) method.  However, if someone has admin access to a system, it's not that hard to put together a command line and use this native tool (i.e., "living off the land") to get data off of the system.  Over on Twitter, Dan has some caveats for installing and running this tool; hint: requires Python3.

vss_carver - requires Python 3.6+ or Python 2.7+; description states that it "carves and recreates VSS catalog and store from Windows disk image."  That's pretty cool...to be able to not only get historical data from VSCs (which I've found to be extremely valuable a number of times...), but now we can carve for and access deleted VSCs, extending our reach into the past for that system.  Pretty nice.

YARP - Yet Another Registry Parser,written in Python3.  One of the great things about the YARP site on GitHub is that test hives are available.

danzek's notes on UAC Virtualization - this is a great idea; so few within the #DFIR community keep notes (Note: in my first iteration of this post, I had included, "...on things like this...", but it occurred to me that few, if any, #DFIR folks keep notes at all...)

RegRipper
Just the other day, I saw that Jason had mentioned a couple of Registry values that seemed to be of interest, so I wrote up new RegRipper plugin and uploaded it into the repository.

Something I've noticed over the years is that as part of a conversation with someone in the #DFIR community, I'll mention RegRipper, and someone will say, "...I've been using RegRipper for years!"  Great...but using, how?  Most often I find out that it's via the GUI, and little else.  There's no real powerful use of the tool; someone may use the command line, but there is very little use of profiles.  And the vast majority of folks seem to run the plugins 'as is'...that is, they use only what comes with the download.

For the sake of transparency, someone did recently suggest (and make) updates to several plugins, and I also assisted in updating the shellbags.pl plugin after someone asking for assistance provided the test data that I needed (I needed it to troubleshoot and fix the plugin).

I've written a LOT of documentation for RegRipper and how to use it.  I've written books, as well as blog posts, and I've also addressed support issues.  I say this because I was recently having a conversation with another analyst on the topic of what RegRipper offers that another tool (the one they were using) doesn't.  The conversation wasn't about, "...why is tool X better than tool Y...", but rather it was about "...what are the gaps that RegRipper fills over this other tool?"  To be honest, the commercial tool in question does, IMHO, a great job of presenting some parsed Registry items to the analyst, providing a layer of abstraction over the binary data itself, but the data that was parsed was based on what had been designed into the application.  As the application isn't just a Registry viewer, what the tool parses and presents to the analyst are commonly-sought, 'big ticket' items.  As is often the case, I heard, "...I've been using RegRipper for years..." but as it turned out, the usage didn't extend beyond running the GUI.  That's fine, if that's your workflow and that's what works for you...but that also means that you're likely missing out on some of the truly powerful aspects of RegRipper.

Something else that occurred to me was that, in attempting to verify the data parsed between two tools, some analysts didn't know where to go to find the data in the RegRipper output.  This goes back to something I've said time and time again, particularly when answering questions from other analysts...it may not seem like it, but the version of Windows you're dealing with IS important, as it not only helps you recognize what data is available and where it's located, but it also helps recognize what other data may be available to verify findings, or fill gaps in analysis.

Tools like RegRipper (and Yara, and many of the other tools mentioned above) can be extremely powerful, surgical tools .  I've converted a number of plugins to sending their output to TLN format, for inclusion in my timeline creation and analysis workflow.  Running a limited number of the plugins against the appropriate hives, or even just one plugin, can give me a "sniper's eye" view of the situation that I couldn't get through any other means...either because a full, complete timeline simply has too much data (I will miss the tree while looking at the forest), or because other means of creating a timeline take longer.