Working Smarter, Not Harder

There are a couple reasons I enjoy blogging, although my lack of frequent posts would suggest I don't like it that much. Just the same, I do it because I enjoy writing and I find writing something down like this helps me remember it for the next time I need it. If this helps someone else in the process, then so much the better.

I've been working on an intrusion case recently, something I've previously done only in training. I have already started a separate blog post talking about it, but I'm not really ready to finish it yet. However, I wanted to post today about something I should have been doing all along. I've used such great tools as Volatility, Log2Timeline and the SANS Forensics SIFT Workstation on this case, as well as RegRipper. RegRipper is what I wanted to talk about today.

The developer of RegRipper, Harlan Carvey, made a new post on his blog recently about finding evidence of program execution on a system under investigation. As a police officer, most of my cases revolve around finding the porn, trying to figure out how it got there and if it's been viewed. Not terribly difficult, most of the time. I rarely have the need to determine whether or not a particular program has been run. Even in the case of investigating child exploitation video possession, I can usually determine if a video has been viewed through .lnk files, jump lists, recent docs, application history and so on. I was able to determine on a recent case that a particular video had been opened in RealPlayer by finding the .lnk file RealPlayer creates upon playing a file. That, along with timeline evidence and some application testing helped prove the case. But, I digress.

As I said, it's not often that program execution is that important to my cases. I found the need to do this, however, after discovering the intruders in this particular case had downloaded several things to the victim Windows 2008 system, including some hacking tools, a bulk email sender and several different web browsers. While I found ample web history to easily show the browsers had been used, I wanted to find out if the other programs had been only downloaded or actually used. Harlan's post helped me remember some steps I could take and taught me some new ones as well to help figure this out.

That was the set up, but here's the real point of this post. I found myself using RegRipper in my quest to determine program execution. I use the command line rip.exe probably as much, maybe more often than the RegRipper GUI. The problem is, I was using the program in a less than efficient manner. Instead of taking advantage of the ability to create a custom profile and running all the plugins I was interested in at once, I was typing them each in at the command line one at a time, looking at the output and then running another. This amounts to an inefficient use of  the fleeting time I have to work only on forensic cases. My job is such that I frequently get called out from my DFIR work to answer regular "routine" calls for service, car wrecks, domestic disputes, etc. Running one little command at a time instead of preparing a custom profile is just silly and creates unnecessary delay.

Harlan asked me what could be done to get users to run all needed plugins at once instead of doing one and then waiting to do the another later. I think the answer to that, at least in my case, is just reminding myself that there are better, easier ways to do things sometimes than the way I choose.

It's helpful to plan ahead what you may be interested in. The plugins available from the RegRipper Plugins site include the individual plugins applicable to each of the registry hives and a couple plugins that can be used against all the hives. Also included are "all" plugin profiles for each hive, such as one for ntuser-all, system-all and so on. These profiles have every included plugin listed in them and when run via RegRipper, will run every plugin listed in them against the hive file you've indicated. Running rip.exe -r ntuser.dat -f ntuser-all, for example, will run every ntuser.dat specific plugin against the ntuser.dat file.

Creating a custom profile for RegRipper and/or rip.exe is dead simple. The great thing about these profiles is they are just text files, easily edited in your favorite text editor. I decided to create a custom profile for this post and will tell you how I did it.

I used FTK Imager to grab the ntuser.dat file from this system and saved it to a test folder. I next selected at random several plugins in the plugins folder that are used to parse the ntuser.dat file for specific information. In my new blank text file, I typed the following:

#test custom plugin profile
#
userassist
domains
ccleaner

I closed my text file and saved it as kptest. You can call it what you want, I suppose, but that's what I used. Notice the plugins are listed in this profile without the .pl extension. Likewise, whether you run a single plugin at the command line or create a profile, you'll want to leave off the .pl. RegRipper takes care of adding that. That's it. It's that easy.

So, to try out my new test profile, I went to the command line and typed the following (in the same directory where my ntuser.dat copy was stored): rip.exe -r ntuser.dat -f kptest > test.txt. This ran only the plugins I defined in the "kptest" profile against the ntuser.dat file in that directory. This same test profile was available in the RegRipper GUI and produced the same results. The GUI also produces a log file in addition to the output.

So, why do this? Why not just run the included profiles? The answer to that is "information overload". The "all" profiles produce a lot of information, often more than you really need. Making your own profile on a case by case basis, based on your needs to that particular case will save you from sifting through lots of information you don't want or need. Sometimes you may discover you need to run other plugins after doing this and that's fine, but why not try to do as much as you can at one time and then follow up with others later if necessary?

As I said, I write this as much to help me remember it as I do to help others. If you gained something from this post, then I'm very happy about that.
I will be posting again soon about the same investigation I mentioned above. It has all sorts of "win" through the use of FOSS tools and I look forward to telling you about it.