Thoughts on Tool Features, pt II

My previous post on this topic addressed an apparent dichotomy (admittedly, based on a limited aperture) of thought between vendors and users when it comes to features being added to commercial forensic suites. This was the result of a road I'd started down a while back, trying to see if there was any value proposition to RegRipper at all (turns out, no, there isn't), and was simply the most recent pit stop along that road.

From my previous post, there seem to be two thoughts on the matter, or maybe it's more correct to say that only two basic positions or perspectives were shared. One is from vendors, some who rely on users to express the need for features; as such, vendors are relying on users to drive their own investigations, requesting or expressing the need for features as they arise. I'm sure vendors have ways of prioritizing those requests/needs, based on limited/available resources.

The other perspective is from users of those forensic tools; the views expressed are that if a vendor finds or 'sees' a cool feature, it should simply be added to the tool or framework, regardless of whether anyone actually wants it or not. To me, this seems to be users relying on vendors to drive investigations.

While I tend to agree more with the vendor perspective, as a user of forensic tools (albeit not commercial products), it seems that I have a different perspective from most users. There have been a few times in my career where I've had to deal with the issue of tool features; some examples follow:

CCN Searches
Circa 2009-ish (give or take), Chris Pogue and I were working a PCI forensic investigation, and found that while Discover and JCB cards had reportedly been processed by the merchant, none were appearing in our searches. As our team had recently grown, we had settled on EnCase (then owned by Guidance Software) as the tool used for all of the PCI-specific searches (CCNs, hashes, file names, etc.); this tool was commonly understood, and we wanted accuracy and consistency above all else.

We began digging into the issue, even going to the brands and getting test data. We kept reducing the scope of our testing, even to the point of, "here's a file with 3 Discover CCNs in it and nothing else...find all Discover CCNs", and each time, got no hits on either Discover or JCB card numbers. We determined that the IsValidCreditCard() built-in function, which was a closed-source "black box" for us, did not consider either brand of card number valid. We needed this capability now, and we were getting nowhere with the vendor, so we reached out to someone who was known for their EnScripting ability and asked for help. We ultimately ended up with a new function, one that included 7 Regexs, that we used to overload the built-in function. Borrowing a trick I learned from one my professors during my undergrad studies, Chris and I wrote up a quick email to everyone, stating, "copy this file to this location within the EnCase installation, etc.", and got everyone up and running at a consistent level pretty quickly. Yes, the process for searching for CCNs was a tad slower, but it was more accurate now, it was consistent across the team, and Chris and I could easily help troubleshoot any issues folks had in running the new function. After all, the only thing that could really go wrong at that point was that the file we sent was copied to the wrong location.

This all boiled down to the fact that we recognized that the tool we were using did not have the functionality we needed, even though, across the industry, everyone assumed that it did. We knew what we needed, we knew we needed it immediately, and we knew that we needed to ensure accuracy and consistency across the team. To do so, we sought help where we felt we needed it, and were more than willing to accept, "yeah, okay, we missed that..." along the way, in order to get to our goal. 

Carving Records
In 2012, I attended the DC3 conference in Atlanta, and after spending several days there and returning home, I ran into a fellow attendee at the baggage claim for our flight. We knew of each other within the community, and I had no idea we'd been on the same flight. As we were waiting, we got to chatting, and they mentioned that they'd been "looking at" a system for about 3 months, and were stuck. I wanted to know more, and they said they were stuck trying to figure out how to recover cleared Event Logs. As soon as they said that, I said that I'd send them a tool I'd written as soon as I got home...which I did. It was late when I got home, so I kissed my wife, turned my computer on, and sent them the tool along with instructions, as promised.

In this case, someone working for the government had a situation, an investigation, where they were stalled "looking at" the image...for 3 months. Now, I have no doubt that that didn't amount to 8 hrs a day, 5 days a week, etc., but that it was more on-and-off over the span of 3 months. However, during that entire time, I had a tool that I'd developed that would have been perfect for the situation, one that I'd not only developed but used to great effect. In fact, the tool was originally written because an Event Log on an XP system had 2 more records within the logical .evt file than were reported by the API, which I'd been able to recover by basically writing a carver. As such, what would work on a logical .evt file would work equally well on unallocated space extracted from an image via blkls.

RegRipper
Something I really like about RegRipper that wasn't something I specifically thought of during the original design is how easily it can be updated (the same applies to Events Ripper). For example, not long ago, I was looking into nssm, the "non-sucking service manager", and ran across the usage page. This page describes a number of Registry values and keys that are used by nssm, as well as by tools like it, such as MS's svrany.exe (which nssm replaces). Both provide persistence and privilege escalation (Admin to LOCALSYSTEM) capabilities, and I knew that I'd never remember to specifically look for some of these keys and values...so I wrote a RegRipperPro plugin to do it for me; the output of a test is illustrated in the figure below.

Fig: Appenvironment.pl Plugin Output

So, as you're reading this, you're probably thinking to yourself, "...but I can't write my own plugin." I get it. Some folks don't bother thinking, "I can't...", and just do it, but I get it..Perl isn't in common usage any longer, and programming simply intimidates some folks. That's cool...it's fine. 

Because all you need to do is ask for help, and maybe provide some sample data to test against. I've consistently turned working plugins around in about an hour, when folks have asked (which hasn't been very often).

The plugin I wrote (output in the figure above) took me just a couple of hours in the evening...I had to stop working to make dinner, take the dog out, etc., but it was pretty straightforward to complete. Now, I don't have to specifically remember these values (and the included key) when conducting an investigation; it's trivial to run all available plugins against various hives, so even a year from now, if I never revisit the issue that led to the plugin again, I'll still have the "corporate knowledge" and the query will still be part of my process.

So, I have something of a different perspective regarding tool features and who drives an investigation. My perspective has always been that as the analyst/investigator, it was my job to drive the investigation. Now, that doesn't prevent me from asking for assistance, or seeking someone else's perspective, but ultimately, the tools I use and the functionality I need are up to me, as an investigator, and I'm not going to structure my investigation around the functionality provided by a tool (or not, as the case may be).