Flippin' Sweet!!

I found out today that WFA 2/e is available on Amazon for pre-order! Publisher's info here.

Using RegRipper

Ever wonder how to use RegRipper for analysis? After all, the tool pulls data from Registry hive files, and while there is a considerable amount of data reduction, what do you do with the data you get?

Let's look at an example. Say that you've got an issue going on with some systems, and you (a) acquire an image of a system, (b) use FTK Imager to get copies of just the Registry hive files from a live system, or (c) connect to the system via F-Response...at that point, you run RegRipper, or just rip.exe with one of the plugins to extract information from the Services key in the System hive file. If you happen to see Ndisprot listed as a service, you may have found a Trojan.Flush.M infection.

*Note: Trojan.Flush.M is apparently also known as "DNSChanger", and this blog post refers to some excellent resources for checking your network for rogue DHCP servers, including MS's own dhcploc utility.

Also, RegRipper can be used to check for the existence of patches and updates, such as KB958644, which addresses the Server service vulnerability from MS08-067.

Check out the RegRipper.net forums for some new plugins uploaded by Don Weber.

How do you use RegRipper?

Some Good Reading...

I wanted to post some interesting items I've run across and read recently...

Brian Krebs wrote an excellent article that appeared on the cover of Popular Mechanics entitled "When Hackers Attack". Page 2 of the article discusses data trafficking, which is very timely as Brian has also blogged on that topic recently.

Brett Shavers has a PDF document up called Virtual Machine Forensic Analysis, which is another excellent read and full of valuable information whether you're analyzing a virtual machine for intrusion or compromise, or as part of a malware analysis process.

For a wider range of reading, Christina's updated the eEvidence site recently; she's always posted links to some very valuable articles, presentations, and other resources.

Perl Module Updated!

Just in time from Christmas, James MacFarlane has give us some Perly goodness! James has updated Parse::Win32Registry to version 0.41! The update appears to be to get key classnames, and is demonstrated in an additional script that James has provided as part of the distro.

James has done a fantastic job with this module, making so much of what I and others do possible with respect to forensic analysis. For example, just last night, a friend of mine sent me three RegRipper plugins that he's going to be posting on RegRipper.net. While I can't say that RegRipper would not have been possible without James' module, I can definitely say that it wouldn't be in the state its in now without it.

Thanks, James!

RegRipper

RegRipper made the SANS Forensics blog today in a post by John McCash about Windows viewers. Pretty cool stuff! John has deployed RegRipper (actually, rip) in a manner that I hadn't even considered when I wrote it...by launching rip as a viewer via EnCase. Very cool!

How're YOU using RegRipper? Have a plugin you'd like to share? Have a plugin you'd like to see? If you don't feel that your programming skills are up to the job, then all I've ever asked for is a concise description of what you're looking for, and a sample hive file. For stuff like the ShellBags keys or encrypted data, I'll need some formatting or decryption information.

Addendum: Don Weber posted three new RegRipper plugins to the RegRipper.net forums...

Less blogging, more writing

There's likely a noticeable slow-down in posts to this blog, and that will continue, as I'm working on the second edition of Windows Forensic Analysis right now.

2/e is expanding on the first edition by not only updating/adding information to the existing chapters, but also adding two additional chapters; Tying It All Together, as well as one that presents more freely available tools.

2/e should be available around May or June 2009, and thanks, but I already have a tech editor. ;-)

Windows Hibernation files

Matthieu has made his Exploiting Windows Hibernation File presentation available...for anyone interested at all in Windows memory analysis, his presentation is well worth a look. Matthieu is the first person that I'm aware of to come up with a means of exploiting or taking advantage of the hibernation file as a viable source of data, and is a contributor to the Volatility framework. Other presentations and demos can be found here.

Issues with AV

I noticed Hogfly's been blogging lately about issues with AV, here and here. It's some good stuff, and I think bears repeating...AV is NOT a silver bullet, and I think most of us are really very well aware of that.

A while back, I commented about an issue presented by AV company write-ups providing incorrect information; in this case, identifying a Registry entry that was created not directly by the malware itself, but by the shell as a result of how the malware was launched on the system. Given the level of technical ability of many malware analysts, you'd think it would be an easy catch.

Well, I ran across this one at the MS Malware Protection Center Encyclopedia this morning - malware identified as Win32/Autorun.GR, and yet the write up (as of this morning) gives no indication of any sort of autorun capability, via a Registry setting or otherwise. Ag;ain, as of this morning (6 Dec), the description simply states that the malware writes itself to the root of all available drives; however, there's no description or discussion whatsoever of why this malware is referred to as "autorun". Yeah, yeah, I know that the Technical Details state that additional info is pending analysis, but if you're gonna call it "autorun", shouldn't there be a reason for that? After all, if the files are just written to the root of the drive without any other means of initiation, wouldn't that then be something like "Win32/Usersgottaclickme.GR"??

On the other hand, VirusList has a good write up on AutoRun.ah which pretty clearly states where the autorun capability comes from. At least from this write up, you can pretty clearly see the steps you need to take to prevent this malware from affecting your infrastructure.

The more information you can get, the better prepared you can be to address the threat. I know that on the surface, to many, the issue of viruses and malware seems pretty pedestrian, but to be honest, there are a number of organizations out there that get pretty badly hung up by viruses (not even worms) and other similar issues.

Honor Thy Settings

Some of us have been working with the Sality virus lately, which reportedly propagates by writing an autorun.inf file and an executable file to the root of all volumes or drives found on the infected system. If the user workstation maps to a file share, for example, the virus process writes the files to the volume, and anyone else that then connects to that share also gets infected. The same has been shown to be true for removable storage, such as USB thumb or flash drives.

So when working with analysts and customers, most of us tend to recommend disabling autorun capability all together, or perhaps for specific drives. Usually this is good advice, but only if it works. MS recently published this KB article which basically states that previous advice didn't work, and you need to install an update AND set another Registry value (ie, HonorAutorunSetting) for the functionality that you set to actually work.

Is this really such an important issue? Well, given stuff like this, and this...perhaps. Update your systems, and recommend that your friends and customers do the same. Even Symantec has picked this up.