More Updates

New Blog
Ken Pryor has started a new blog, and has his first post up as of Sun, 21 Nov. Check it out, and add it to your RSS feed. I'm sure Ken's going to have some gems.

I met Ken face-to-face at the WACCI conference a bit ago. He's a great guy, very knowledgeable, and very enthusiastic. Speaking of which, Ken was at the WACCI conference along with Brad Garnett, who's also posted to his blog recently. If you like some caffeine-induced forensic ramblings, stop on by and take a look.

Confessor
Russ reached to me recently to let me know about Confessor, a tool that he'd covered in a recent toolsmith column. Russ had previously mentioned MIR-ROR, and says that Confessor uses similar tools but deploys them in an "enterprise-capable manner". Also from Russ's description of Confessor and another tool (mentioned below):

"These tools were born of needing better utilities for incident response and security analysis in complex, massive cloud-like environments."

Russ also mentioned MOLE in his toolsmith article; "MOLE" stands for "malicious online link engine", which allows the analyst to validate URLs to see if malware was present. I can see how a tool like this would be very useful for analysts during a malware investigations and incident response.

Questions
I received a question the other day that I thought was interesting, because I'd seen it before. Back when I had submitted my proposal for the Windows Registry Forensics book, all of the proposal reviewers had stated that this book would need to compare and contrast RegRipper to the commercially available Registry "analysis" tools.

As it turned out, I wasn't able to do this for the book...for the simple reason that I didn't have access to those commercial tools. I don't use EnCase at work, nor do I use FTK. I did try to get a temporary license for one of the commercial tools, and was told "no". In the spirit of full disclosure, I did have an opportunity to meet Brian Karney of AccessData, and he did offer to discuss providing a temporary license for the AccessData product, but by then I was so close to the deadline for the book that there simply wasn't time to go back and work this into the book. I did reference Technology Pathways ProDiscover in the book, and that's because I had access to that commercial tool.

Also, I used quotes around the word "analysis" earlier, because most commercial tools are simply viewers...it's up to the analyst to perform analysis. To some extent, RegRipper is also a viewer, of sorts, although it doesn't so much leave the "what's important" up to the analyst, but instead allows the analyst to extract and analyze what is likely the more important and valuable data.

The question I received was right along the same lines. I guess on the surface, questions such as "how is RegRipper better than or different from the commercial tools" is one that comes from folks who, for the most part, haven't really used RegRipper much if at all, and have pretty much haven't really used the commercial tools to a great extent. I would also think that the question also comes from not really having conducted a great deal of Registry analysis. I wouldn't say that RegRipper is any better than any other tool...because it's just a tool, and is therefore only as useful or as good as the analyst using it. Like any tool that's used improperly, RegRipper would be seen as useless. Or, a knowledgeable analyst can use the tool effectively and even find new ways to use it that had not been thought of before, particularly by the designer.

One of the benefits and useful features of RegRipper is that it's open source, and the tool can be modified to suit your needs. Chris Perkins has modified RegRipper, and so did Adam James. Okay, so most folks are likely to say to this, "...but I don't program", and may even qualify that with "...in Perl." That's okay, because you can always ask someone to assist in meeting your needs. One of the reasons many folks provide tools for free is to get feedback from others who are either doing the same or similar work, or those who may be new to field and have a fresh view or perspective. So when I'm at a conference, and talk to someone who says, "...but I can't program...", I will generally ask them if they have email...because if they do, they can ask someone for assistance.

Another benefit of RegRipper as an open source tool is that if you need something done with a plugin...a new plugin written, or a current plugin with something a bit different done with the output...it's a simple matter to change things. Early on, shortly after releasing RegRipper, I received a request or two for XML output...in response, I asked for recommendations on a style sheet...and never heard back. I've received requests for .csv output...but it's a simple matter for someone to open the plugins of their choice in Notepad, commenting out (add "#" to the beginning of the line) the appropriate "::rptMsg()" statement, and adding their own. Or copy a plugin to a different name...say, copy uassist.pl to uassist_csv.pl and make the appropriate changes.

Okay, so what's the point of all this? To answer the original question, RegRipper is open source, so if you want to know how something is done or if you want to change something, just open up the appropriate file in Notepad. If you're not a programmer, ask someone. It's that easy. RegRipper isn't any better than any other tool, simply because it's not the tool, but the analyst that plays the most important role in any examination.

ZeroAccess Write-up
I was reading through Giuseppe Bonfa's write-up of the ZeroAccess/Max++ rootkit recently, and I have to say...I was interested not only in how detailed and thorough the write-up was, but also the steps taken by the malware author.

In part 1 of the reverse engineering write-up, Giuseppe points out an important artifact associated with this malware...a randomly named Windows service. According the write-up, the service is installed as a kernel driver, set to load on demand, and the ImagePath is set to "\*". The Service key name itself begins with a '.' (dot).

In part 2, Giuseppe reverse engineer's the kernel-mode device driver. His analysis revealed that when the kernel-mode driver loads, it first deletes it's Services Registry key, and then the entries under the "Enum\Root\LEGACY_" path. Apparently, the author(s) of this malware are taking steps to protect their gem from discovery, and are doing so from learning from incident responders and forensic analysts.

Giuseppe's write-up is as thorough as it is interesting. Take an opportunity to read through it...it's not only a good example for reverse engineers, but it's also good for other analysts to see so that they can understand the perspective of a reverse engineer, as well as what a reverse engineer can come up with and find out about malware. In this case, we've not only seen a rootkit that creates a hidden volume for its files, but also actively takes steps to obfuscate its presence on a live system.

OffensiveComputing also has a bit about the reverse engineering of this crimeware rootkit.